Välkommen till den första i en serie av fyra artiklar som diskuterar containeriseringen och molnets rörelse som leds av Docker, Google och ett växande ekosystem av traditionella och nya aktörer. I den här serien vågar vi definiera och diskutera detta framväxande och spännande utrymme i ett försök att hjälpa organisationer att bättre navigera i det. Även om den här första artikeln kommer att fokusera på att definiera "molnbaserad" och vissa relaterade rörliga delar, kommer vi i framtida artiklar att utforska de viktiga lagren och relaterade utmaningar med nätverk, lagring och containerorkestrering för att ge dig en mer komplett bild...men låt oss först börja kl. början.
I början fanns Free BSD och Solaris, som lade en mästerlig grund för vad som nu anses vara moderna containeriseringsteknologier med funktioner som kallas FreeBSD Jails respektive Solaris Zones. Google hjälpte till att föra behållare till Linux genom att lägga till cgroups till Linux-kärnan. I kombination med namnrymder och chroot lades den tekniska grunden. Docker gjorde behållare mer tillgängliga genom att skapa ett enkelt arbetsflöde kring behållarbilder och fokusera på en enkel utvecklarupplevelse.
Förmodligen är det bästa sättet att definiera utrymmet genom att svara på några grundläggande frågor och få några gästexperter att svara på dem. (se hur jag överför arbete till andra människor som är mer kvalificerade!?)
Vad är en container?
Gästbidragsgivare Cameron Brunner, chefsarkitekt Navops
Behållare gör att applikationer kan flyttas tillförlitligt från en datormiljö till en annan. Detta kan vara från en utvecklares bärbara dator, till QA-miljön till produktion på plats eller i molnet. Mjukvarustackberoende för applikationen som körs i behållaren, såsom operativsystemet eller andra programvarukomponenter och bibliotek, kan till stor del bäddas in i en behållare så att den kan köras frikopplad från detaljerna i den underliggande IT-miljön. Behållare designades ursprungligen för att ge isolering mellan applikationer som körs på ett operativsystem. De tillhandahåller en kombination av resurskontroller och gränsseparation som hjälper till att isolera exekveringen av kod i behållaren från andra aktiviteter och andra behållare som körs på den maskinen/operativsystemet. Behållare uppnår denna isolering genom att utnyttja operativsystemsfunktioner som cgroups och namnutrymmen.
Vad är Docker?
Docker är både ett företag och en kommersiell/open source-implementering av containrar. Containers har funnits länge före Docker med tidiga implementeringar som FreeBSD Jails (2000) och Solaris Zones (2004) och Docker har gjort ett fantastiskt jobb med att göra containrar användbara för massorna genom att avsevärt förenkla skapandet och exekveringsprocessen. Medan Docker snabbt håller på att bli det defacto-standardiserade containerformatet, har företaget gjort ytterligare steg mot öppenhet och samarbete genom att skapa Open Container Initiative (OCI) under Linux Foundation. OCI involverar ett antal industrideltagare och arbetar mot industristandarder för containerformat och körtider. (Se www.opencontainers.org/)
Så vad är Cloud Native Computing?
Gästbidragsgivare Joe Beda, grundare och bidragsgivare till både Google Compute Engine och Kubernetes
Cloud Native är ett av många nya sätt att tänka på att bygga och hantera applikationer i stor skala. I grunden strukturerar Cloud Native team, kultur och teknologi för att använda automation och arkitekturer för att hantera komplexitet och låsa upp hastighet.
Medan containrar och containerhantering ofta är en del av "Cloud Native"-tänkandet, har organisationer som Netflix välkänt tillämpat detta tänkande med virtuella datorer och virtuella datorer. Dessutom behöver du inte springa i molnet för att börja inse några fördelar med detta skifte i tänkande. Applikationer och team kan vara mer hanterbara när applikationer distribueras på prem.
Det finns inga hårda och snabba regler för vad Cloud Native är. Det finns dock några teman som dyker upp.
- DevOps och Ops automation: Ingenjörer som bär applikationsutvecklarhatt spelar en aktiv roll för att säkerställa att applikationer kan köras tillförlitligt i produktionen. På samma sätt ser de som fyller verksamhetsrollen till att erfarenheter återkopplas till utveckling. Automatisering är nyckeln för att hantera många rörliga pjäser.
- Behållare: Behållare är ett bekvämt sätt att skapa en utplacerbar byggartefakt som kan testas och valideras. Detta säkerställer att driftsättningen är förutsägbar.
- Beräkningskluster: Ett API-drivet beräkningskluster och schemaläggningssystem tillåter ett litet antal ingenjörer att hantera ett stort antal arbetsbelastningar. Utöver det tillåter det att dessa arbetsbelastningar effektivt kan packas till noder för att öka utnyttjandegraden. Slutligen minskar ett välskött kluster driftsbördan för applikationsteam.
- Mikrotjänster: Mikrotjänster delar upp applikationer i mindre utplacerbara enheter så att utvecklingsteam kan vara snabba och smidiga. Dessa idéer är inte nya, nödvändigtvis, utan tillämpas tillsammans med verktyg för att möjliggöra skalbar hantering. Vi kommer att prata mer om detta nedan.
- Djup synlighet: Cloud Native innebär djupare insikter om hur tjänsterna körs. Distribuerade spårnings-, insamlings- och indexeringsloggar och djup applikationsövervakning hjälper alla till att belysa vad som faktiskt händer i en applikation.
Vad är en mikrotjänstbaserad arkitektur?
Gästbidragsgivare Joe Beda, grundare och bidragsgivare till både Google Compute Engine och Kubernetes
Mikrotjänster är ett nytt namn på ett koncept som har funnits väldigt länge. I grund och botten är det ett sätt att dela upp en stor applikation i mindre bitar så att de kan utvecklas och hanteras självständigt. Låt oss titta på några av de viktigaste aspekterna här:
- Starka och tydliga gränssnitt. Tät koppling mellan tjänsterna måste undvikas. Dokumenterade och versionerade gränssnitt bidrar till att stärka det kontraktet och bibehålla en viss grad av frihet för både konsumenterna och producenterna av dessa tjänster.
- Självständigt utplacerad och hanterad. Det bör vara möjligt för en enskild mikrotjänst att uppdateras utan att synkroniseras med alla andra tjänster. Det är också önskvärt att enkelt kunna återställa en version av en mikrotjänst. Detta innebär att binärfilerna som distribueras måste vara framåt- och bakåtkompatibla både vad gäller API och eventuella datascheman. Detta kan testa samarbetet och kommunikationsmekanismerna mellan lämpliga operations- och utvecklarteam.
- Inbyggd motståndskraft. Mikrotjänster bör byggas och testas för att vara oberoende av motståndskraft. Kod som förbrukar en tjänst bör sträva efter att fortsätta arbeta och göra något rimligt i händelse av att den förbrukade tjänsten ligger nere eller inte beter sig. På samma sätt bör alla tjänster som erbjuds ha ett visst försvar med avseende på oväntad belastning och dålig input.
- Mikrotjänster handlar mer om människor än teknik. Små lag är smidigare. Jeff Bezos är känd för att ha tipsat om att hålla möten och team tillräckligt små så att de kan matas med 2 pizzor. Genom att strukturera ett stort projekt som en serie mindre team och sedan komma ur vägen, kan dessa team tänka samman och äga den delen av projektet.
Vi ser fram emot nästa artiklar där vi kommer att diskutera några av de viktiga lagren i den inbyggda molnstacken.
Rob Lalonde är vice VD och koncernchef för Navops . Han är en aktiv deltagare i olika öppen källkodsstiftelser, inklusive Cloud Native Computing Foundation (CNCF), Open Container Initiative (OCI) och Linux Foundation. Rob har haft ledande befattningar i flera framgångsrika högteknologiska företag och startups. Han har avslutat MBA-studier vid York Universitys Schulich School of Business och har en examen i datavetenskap från Laurentian University.
Amazon