Du har bygget en sky, og nu vil de også have containere?

Du byggede en privat sky til store omkostninger, og på trods af de oprindelige omkostninger foretages der reelle besparelser. Og selvom du troede, skyen var netop, hvad dine udviklingshold ville have, kæmper de nu for containere. Hvorfor?

Som det er tilfældet med de fleste forretningsvirksomheder, har du sandsynligvis retfærdiggjort investeringen i din sky fra et infrastrukturperspektiv med vægt på øget anvendelse af fysisk hardware. Den gennemsnitlige udnyttelse før virtualisering var ofte under 10%, og virtualisering som muliggør konsolidering af arbejdsbyrde har været et kritisk værktøj til at sikre, at penge, der bruges på hardware ikke spildes.

Men - og det er en stor, men - typisk, private private skyer, der tilbyder lidt ud over omkostningsbesparelser og hurtigere (virtuel) maskinlevering til de udviklingshold, der bruger dem. Disse er bestemt værdifulde, men er temmelig korte til det fulde løfte om sky.

Hvad udviklingshold virkelig ser efter er en platform med API'er, de kan bruge til direkte at vedhæfte deres automatiserede softwarelevecyklusværktøjer. For at citere en udviklingsledning: ”Jeg vil bare ikke tale med infrastruktur.”

Hvad infrastruktur typisk gav dem i stedet, var dog lige så begrænset som den gamle fysiske verden - med byrdefulde processer, begrænset livscyklusautomatisering, de samme gamle problemer med patches og absolut ingen værktøjsintegration.

Kort sagt, servere var nu virtuelle, men de fleste af de gamle smertepunkter for udviklere eksisterede stadig - og infrastrukturfunktioner blev fortsat karakteriseret som en blokerer snarere end en mulighed for ændring i udviklingsverdenen.

Indtast containere.

Hvad er de, og hvorfor bruger udviklere dem?

For at citere Wikipedia er en container “enhver enhed… der kan bruges til at indeholde, opbevare og transportere genstande eller materialer.”Selvom dette gælder lige så meget som kurvekurve som softwarecontainere, er det vigtigste for IT, hvordan containere adskiller sig fra virtuelle servere.

Containere gør det muligt for udviklingshold at pakke deres software sammen med løste softwareafhængigheder til en enkelt artefakt. Containere kræver et vært-operativsystem for at køre - men flere containere kan køres på en enkelt OS-instans, mens de opretholder logisk isolering fra hinanden (ikke mere har du brug for en OS-licens pr. Applikationskomponentforekomst for at få denne isolering).

Da containere ikke hver især har brug for deres eget operativsystem, kan de startes så hurtigt, som den indpakkede applikationssoftware kan startes (ingen venter på, at en OS-instans starter), og da de inkluderer løste softwareafhængigheder, er instantiering på en server blot et spørgsmål om at kopiere containeren og starte den op. Repeterbarheden og abstraktionen, der leveres af containere, gør det muligt for udviklere at koncentrere sig om at levere let implementerbar og fungerende software, mens en anden leverer en administreret platform for disse containere at køre på.

Konceptet med containere er ikke nyt. Google har brugt deres egen sort i årevis (de siger, at alt hos Google kører i containere), Sun introducerede en form for containere i Solaris i 2004/2005, og containere har endda været tilgængelige på Windows gennem produkter som Parallels Virtuozzo.

Det nye er imidlertid skiftet til at tænke på containere som en udvikler (snarere end infrastruktur) teknologi og kritisk set fremkomsten af ​​software som Docker, der giver et enkelt containerformat, der kan fungere på tværs af flere hardware- og operativtyper.

Entusiasme i udviklerfællesskabet er høj, og udviklingen af ​​både Docker- og standardiseringsbestræbelser som Open Container Initiative fortsætter i tempo, men styringsværktøjet til storskala containerdistribution (som Kubernetes) er først lige begyndt at dukke op til generel brug og har bestemt endnu ikke nået graden af ​​modenhed for den, der er tilgængelig for server virtualisering.

Betyder det, at containere skal undgås i øjeblikket?

Nej. Containere tilbyder fordele både til infrastruktur (yderligere konsolidering af arbejdsbyrden, men potentielt med en reduktion i OS-licensantal) og udvikling (enkelt implementerbar artefakt, der kører, uanset hvor det sættes og starter øjeblikkeligt - især vigtigt for dem, der bygger dynamiske skaleringsprogrammer) . Containere er komplementære til server virtualisering og vil (og bør ikke) fortrænge den.

Hvad virksomheder imidlertid skal gøre, er at opbygge partnerskaber på tværs af infrastruktur- og udviklingshold for at pilotere brugen af ​​containere oven på robuste virtualiseringsplatforme. Start lille, udvikl hosting-platformen, styringsværktøj og kritisk den samlede proces sammen. At vente betyder bare, at mere proaktive konkurrenter først får produktivitet, tid til marked og omkostningsreduktionsfordele.

Som hovedkonsulent for Virtuel klarhed, Chris Buckley hjælper store og komplekse organisationer moderniserer deres tilgang til IT-infrastruktur. Arbejder med IT-organisationer for at identificere de rigtige problemer, der skal løses fra et forretningsmæssigt perspektiv, Chris leder klienter gennem udvikling og implementering af infrastrukturstrategi.

Deltag i Network World-samfundene på Facebook og LinkedIn for at kommentere emner, der er øverste af sindet.