Du har byggt ett moln och nu vill de också ha containrar?

Du byggde ett privat moln till stor kostnad och trots de initiala kostnaderna görs verkliga besparingar. Och även om du trodde att molnet var precis vad dina utvecklingsgrupper ville ha, klagar de nu på containrar. Varför?

Som vanligt med de flesta företagsföretag har du antagligen rättfärdigat investeringen i ditt moln ur ett infrastrukturperspektiv med tonvikt på att öka användningen av fysisk hårdvara. Det genomsnittliga utnyttjandet före virtualisering var ofta under 10%, och virtualisering som möjliggörande av konsolidering av arbetsbelastning har varit ett kritiskt verktyg för att säkerställa att pengar som spenderas på hårdvara inte slösas bort.

Men - och det är en stor men - typisk privata moln för företag erbjuder lite utöver kostnadsbesparingar och snabbare (virtuell) maskinleverans till utvecklingsgrupper som konsumerar dem. Dessa är verkligen värdefulla, men är ganska kort till det fulla löfte om moln.

Vad utvecklingsteam verkligen letar efter är en plattform med API: er som de kan använda för att direkt fästa sina automatiserade verktyg för livscykel för mjukvara. För att citera en utvecklingsledning: "Jag vill bara inte prata med infrastruktur."

Men vad Infrastructure vanligtvis gav dem istället var lika begränsat som den gamla fysiska världen - med betungande processer, begränsad livscykelautomatisering, samma gamla problem med korrigeringar och absolut ingen verktygsintegration.

Kort sagt, servrar var nu virtuella men de flesta av de gamla smärtpunkterna för utvecklare fanns fortfarande - och infrastrukturfunktioner fortsatte att karakteriseras som en blockerare snarare än en möjliggörande för förändring i utvecklingsvärlden.

Ange behållare.

Vad är de och varför använder utvecklare dem??

För att citera Wikipedia är en behållare "alla enheter ... som kan användas för att innehålla, lagra och transportera föremål eller material.”Även om detta gäller lika korgkorgar som mjukvarukontainrar, är det viktigaste för IT hur behållare skiljer sig från virtuella servrar.

Behållare gör det möjligt för utvecklingsgrupper att paketera sin programvara, tillsammans med lösta mjukvaruberoende, till en enda artefakt. Behållare kräver ett värdoperativsystem för att kunna köra - men flera containrar kan köras på en enda OS-instans medan de upprätthåller logisk isolering från varandra (du behöver inte mer en OS-licens per applikationskomponentinstans för att få den isoleringen).

Eftersom behållare inte behöver sina egna operativsystem, kan de startas så snabbt som den inpackade applikationsprogramvaran kan startas (ingen väntar på att en OS-instans ska starta), och eftersom de inkluderar lösta mjukvaruberoende är inställning på en server bara en fråga om att kopiera behållaren och starta den. Repeterbarheten och abstraktionen som tillhandahålls av containrar gör det möjligt för utvecklare att koncentrera sig på att leverera lätt distribuerbar och fungerande programvara medan någon annan tillhandahåller en hanterad plattform för dessa containrar att köra på.

Konceptet med containrar är inte nytt. Google har använt sin egen sort i flera år (de säger att allt på Google körs i containrar), Sun introducerade en form av containrar i Solaris 2004/2005 och containrar har till och med varit tillgängliga på Windows genom produkter som Parallels Virtuozzo.

Det nya är emellertid övergången till att tänka på containrar som en utvecklare (snarare än infrastruktur) teknik och kritiskt framväxten av mjukvara som Docker, som ger ett enda containerformat som kan fungera över flera hårdvara och OS-typer.

Entusiasm i utvecklargemenskapen är hög och utvecklingen av både Docker- och standardiseringsinsatser som Open Container Initiative fortsätter i takt, men hanteringsverktyg för storskalig containerdistribution (som Kubernetes) börjar bara dyka upp för allmänt bruk och har visst nådde ännu inte graden av mognad för den som är tillgänglig för servert virtualisering.

Betyder det att behållare bör undvikas för närvarande?

Nej. Behållare erbjuder fördelar både för infrastruktur (ytterligare konsolidering av arbetsbelastningen, men potentiellt med en minskning av OS-licensantalet) och utveckling (en enda distribuerbar artefakt som körs oavsett var den sätts och startar direkt - särskilt viktigt för dem som bygger dynamiska utskalningsapplikationer) . Behållare kompletterar servern virtualisering och kommer (och borde inte) förskjuta den.

Vad företag dock bör göra är att bygga partnerskap mellan infrastruktur- och utvecklingsgrupper för att pilotera användningen av containrar ovanpå robusta virtualiseringsplattformar. Börja litet, utveckla värdplattformen, hanteringsverktyg och kritiskt den övergripande processen tillsammans. Att vänta betyder bara att mer proaktiva konkurrenter kommer att få produktivitet, tid att marknadsföra och kostnadsminskningsfördelar först.

Som huvudkonsult för Virtuell tydlighet, Chris Buckley hjälper till stora och komplexa organisationer moderniserar sin strategi för IT-infrastruktur. I samarbete med IT-organisationer för att identifiera rätt problem att lösa ur ett affärsperspektiv leder Chris kunder genom utveckling och implementering av infrastrukturstrategi.

Gå med i nätverkets världssamhällen på Facebook och LinkedIn för att kommentera ämnen som är övertygade.