Vad är Cloud Native?

Dricks

Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

Stoppa det du gör och be dina kollegor att definiera termen "Cloud Native". Det finns en god chans att du får flera olika svar.

Vi börjar med en enkel definition:

Molnbaserad arkitektur och -teknik är en metod för att utforma, konstruera och driva arbetsbelastningar som är inbyggda i molnet och dra full nytta av molnbaserad databehandlingsmodell.

Cloud Native Computing Foundation tillhandahåller den officiella definitionen:

Med molnbaserad teknik kan organisationer skapa och köra skalbara program i moderna, dynamiska miljöer som offentliga, privata moln och hybridmoln. Containrar, tjänstnät, mikrotjänster, oföränderlig infrastruktur och deklarativa API:er är exempel på den här metoden.

Dessa tekniker möjliggör löst kopplade system som är motståndskraftiga, hanterbara och observerbara. I kombination med robust automatisering gör de det möjligt för ingenjörer att göra ändringar med hög påverkan ofta och förutsägbart med minimalt arbete.

Molnbaserat handlar om hastighet och flexibilitet. Affärssystem utvecklas från att möjliggöra affärsfunktioner till vapen för strategisk omvandling som påskyndar affärshastighet och tillväxt. Det är absolut nödvändigt att få nya idéer till marknaden omedelbart.

Samtidigt har affärssystem också blivit allt mer komplexa med användare som kräver mer. De förväntar sig snabb svarstid, innovativa funktioner och noll stilleståndstid. Prestandaproblem, återkommande fel och oförmåga att röra sig snabbt är inte längre godtagbara. Användarna besöker din konkurrent. Molnbaserade system är utformade för snabba förändringar, storskaliga system och motståndskraft.

Här är några företag som har implementerat molnbaserade tekniker. Tänk på den hastighet, smidighet och skalbarhet som de har uppnått.

Företag	Upplevelse
Netflix	Har över 600 tjänster i produktion. Distribuerar 100 gånger per dag.
Uber	Har över 1 000 tjänster i produktion. Distribuerar flera tusen gånger varje vecka.
WeChat	Har över 3 000 tjänster i produktion. Distribuerar 1 000 gånger om dagen.

Som du ser exponerar Netflix, Uber och WeChat molnbaserade system som består av många oberoende tjänster. Med den här arkitekturstilen kan de snabbt svara på marknadsvillkoren. De uppdaterar omedelbart små områden i ett levande, komplext program utan en fullständig omdistribution. De skalar tjänster individuellt efter behov.

Grundpelarna i molnbaserat

Hastigheten och flexibiliteten hos molnbaserat härstammar från många faktorer. Det viktigaste är molninfrastrukturen. Men det finns fler: Fem andra grundläggande pelare som visas i bild 1-3 utgör också grunden för molnbaserade system.

Bild 1-3. Molnbaserade grundpelare

Låt oss ta lite tid att bättre förstå betydelsen av varje pelare.

Molnet

Molnbaserade system drar full nytta av molntjänstmodellen.

De här systemen är utformade för att utvecklas i en dynamisk, virtualiserad molnmiljö och använder paaS-beräkningsinfrastrukturen (Platform as a Service) och hanterade tjänster i stor utsträckning. De behandlar den underliggande infrastrukturen som disponibel – etablerad på några minuter och ändra storlek, skalas eller förstörs på begäran – via automatisering.

Tänk på skillnaden mellan hur vi behandlar husdjur och råvaror. I ett traditionellt datacenter behandlas servrar som husdjur: en fysisk dator, ges ett meningsfullt namn och tas omvårdnad. Du kan skala genom att lägga till fler resurser på samma dator (skala upp). Om servern blir sjuk, sjuksköterska du tillbaka till hälsa. Om servern blir otillgänglig märker alla det.

Varutjänstmodellen skiljer sig. Du etablerar varje instans som en virtuell dator eller container. De är identiska och tilldelade en systemidentifierare, till exempel Service-01, Service-02 och så vidare. Du kan skala genom att skapa fler instanser (skala ut). Ingen märker när en instans blir otillgänglig.

Råvarumodellen omfattar oföränderlig infrastruktur. Servrar repareras eller ändras inte. Om en misslyckas eller kräver uppdatering förstörs den och en ny etableras – allt görs via automatisering.

Molnbaserade system omfattar råvarutjänstmodellen. De fortsätter att köras när infrastrukturen skalas in eller ut utan hänsyn till de datorer som de körs på.

Azure-molnplattformen stöder den här typen av elastisk infrastruktur med automatisk skalning, självåterställning och övervakningsfunktioner.

Modern design

Hur skulle du utforma en molnbaserad app? Hur skulle arkitekturen se ut? Vilka principer, mönster och bästa praxis följer du? Vilka infrastruktur- och driftproblem skulle vara viktiga?

Tolvfaktorprogrammet

En allmänt accepterad metod för att konstruera molnbaserade program är Twelve-Factor Application. Den beskriver en uppsättning principer och metoder som utvecklare följer för att skapa program som är optimerade för moderna molnmiljöer. Särskild uppmärksamhet ägnas åt portabilitet mellan miljöer och deklarativ automatisering.

Även om det gäller för alla webbaserade program anser många utövare att Twelve-Factor är en solid grund för att skapa molnbaserade appar. System som bygger på dessa principer kan distribuera och skala snabbt och lägga till funktioner för att reagera snabbt på marknadsförändringar.

I följande tabell visas tolvfaktormetoden:

Faktor	Förklaring
1 – Kodbas	En enda kodbas för varje mikrotjänst som lagras på sin egen lagringsplats. Den spåras med versionskontroll och kan distribueras till flera miljöer (QA, Mellanlagring, Produktion).
2 – Beroenden	Varje mikrotjänst isolerar och paketerar sina egna beroenden och omfattar ändringar utan att påverka hela systemet.
3 – Konfigurationer	Konfigurationsinformation flyttas från mikrotjänsten och externaliseras via ett konfigurationshanteringsverktyg utanför koden. Samma distribution kan spridas mellan miljöer med rätt konfiguration tillämpad.
4 – Stödtjänster	Underordnade resurser (datalager, cacheminnen, meddelandeköer) ska exponeras via en adresserbar URL. Om du gör det frikopplas resursen från programmet, vilket gör att den kan vara utbytbar.
5 – Skapa, släppa, köra	Varje version måste framtvinga en strikt separation mellan bygg-, versions- och körningsfaserna. Var och en ska taggas med ett unikt ID och stödja möjligheten att återställa. Moderna CI/CD-system bidrar till att uppfylla den här principen.
6 – Processer	Varje mikrotjänst ska köras i sin egen process, isolerad från andra tjänster som körs. Externalisera nödvändigt tillstånd till en säkerhetskopieringstjänst, till exempel en distribuerad cache eller ett datalager.
7 – Portbindning	Varje mikrotjänst ska vara fristående med sina gränssnitt och funktioner som exponeras på sin egen port. Detta ger isolering från andra mikrotjänster.
8 – Samtidighet	När kapaciteten behöver öka skalar du ut tjänster horisontellt över flera identiska processer (kopior) i stället för att skala upp en enda stor instans på den mest kraftfulla datorn som är tillgänglig. Utveckla programmet så att det samtidigt gör skalningen i molnmiljöer smidig.
9 – Disposability	Tjänstinstanser bör vara disponibla. Gynna snabb start för att öka skalbarhetsmöjligheter och graciösa avstängningar för att lämna systemet i rätt tillstånd. Docker-containrar tillsammans med en orkestrerare uppfyller detta krav.
10 – Dev/Prod Parity	Håll miljöer i hela programlivscykeln så lika som möjligt och undvik kostsamma genvägar. Här kan införandet av containrar i hög grad bidra genom att främja samma körningsmiljö.
11 – Loggning	Behandla loggar som genereras av mikrotjänster som händelseströmmar. Bearbeta dem med en händelseaggregator. Sprida loggdata till verktyg för datautvinning/logghantering som Azure Monitor eller Splunk och slutligen till långsiktig arkivering.
12 – Administrationsprocesser	Kör administrativa/hanteringsuppgifter, till exempel datarensning eller databehandlingsanalys, som engångsprocesser. Använd oberoende verktyg för att anropa dessa uppgifter från produktionsmiljön, men separat från programmet.

I boken Beyond the Twelve-Factor App beskriver författaren Kevin Hoffman var och en av de ursprungliga 12 faktorerna (skriven 2011). Dessutom diskuterar han tre extra faktorer som återspeglar dagens moderna molnprogramdesign.

Ny faktor	Förklaring
13 – API First	Gör allt till en tjänst. Anta att koden kommer att förbrukas av en klientdelsklient, gateway eller en annan tjänst.
14 – Telemetri	På en arbetsstation har du djup insyn i ditt program och dess beteende. I molnet gör du inte det. Se till att designen innehåller insamling av övervaknings-, domänspecifika och hälso-/systemdata.
15 – Autentisering/auktorisering	Implementera identitet från början. Överväg RBAC-funktioner (rollbaserad åtkomstkontroll) som är tillgängliga i offentliga moln.

Vi kommer att referera till många av de 12+ faktorerna i det här kapitlet och i hela boken.

Välstrukturerat Azure-ramverk

Det kan vara svårt att utforma och distribuera molnbaserade arbetsbelastningar, särskilt när du implementerar molnbaserad arkitektur. Microsoft tillhandahåller bästa praxis för branschstandard som hjälper dig och ditt team att leverera robusta molnlösningar.

Microsoft Well-Architected Framework innehåller en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en molnbaserad arbetsbelastning. Ramverket består av fem grundpelare för en utmärkt arkitektur:

Grundsatser	beskrivning
Kostnadshantering	Fokusera på att generera inkrementellt värde tidigt. Använd build-measure-learn-principer för att påskynda tiden till marknaden och samtidigt undvika kapitalintensiva lösningar. Med hjälp av en betala per användning-strategi investerar du när du skalar ut, snarare än att leverera en stor investering i förväg.
Driftsäkerhet	Automatisera miljön och åtgärderna för att öka hastigheten och minska de mänskliga felen. Rulla problemuppdateringarna bakåt eller framåt snabbt. Implementera övervakning och diagnostik från början.
Prestandaeffektivitet	Effektivt uppfylla de krav som ställs på dina arbetsbelastningar. Gynna horisontell skalning (utskalning) och designa den i dina system. Utför kontinuerligt prestanda- och belastningstester för att identifiera potentiella flaskhalsar.
Tillförlitlighet	Skapa arbetsbelastningar som är både motståndskraftiga och tillgängliga. Återhämtning gör det möjligt för arbetsbelastningar att återställa från fel och fortsätta att fungera. Tillgänglighet säkerställer användarnas åtkomst till din arbetsbelastning hela tiden. Utforma program för att förvänta sig fel och återställa från dem.
Säkerhet	Implementera säkerhet under hela livscykeln för ett program, från design och implementering till distribution och åtgärder. Var uppmärksam på identitetshantering, infrastrukturåtkomst, programsäkerhet och datasuveränitet och kryptering.

För att komma igång tillhandahåller Microsoft en uppsättning onlineutvärderingar som hjälper dig att utvärdera dina aktuella molnarbetsbelastningar mot de fem väldefinierade pelarna.

Mikrotjänster

Molnbaserade system omfattar mikrotjänster, en populär arkitekturstil för att konstruera moderna program.

Mikrotjänster har skapats som en distribuerad uppsättning små, oberoende tjänster som interagerar via en delad infrastrukturresurs och har följande egenskaper:

• Var och en implementerar en specifik affärsfunktion i en större domänkontext.

• Var och en utvecklas självständigt och kan distribueras oberoende av varandra.

• Var och en är fristående inkapsling av sin egen datalagringsteknik, beroenden och programmeringsplattform.

• Var och en körs i sin egen process och kommunicerar med andra med hjälp av standardkommunikationsprotokoll som HTTP/HTTPS, gRPC, WebSockets eller AMQP.

• De skapar tillsammans för att bilda ett program.

Bild 1–4 kontrasterar en monolitisk programmetod med en mikrotjänstmetod. Observera hur monoliten består av en arkitektur i flera lager som körs i en enda process. Den förbrukar vanligtvis en relationsdatabas. Mikrotjänstmetoden separerar dock funktioner i oberoende tjänster, var och en med sin egen logik, sitt tillstånd och sina data. Varje mikrotjänst är värd för ett eget datalager.

Bild 1-4. Arkitektur för monolitisk kontra mikrotjänster

Observera hur mikrotjänster främjar principen Processer från tolvfaktorprogrammet, som beskrevs tidigare i kapitlet.

Faktor 6 anger "Varje mikrotjänst ska köras i sin egen process, isolerad från andra tjänster som körs.".

Varför mikrotjänster?

Mikrotjänster ger flexibilitet.

Tidigare i kapitlet jämförde vi ett e-handelsprogram som skapats som en monolit med det med mikrotjänster. I exemplet såg vi några tydliga fördelar:

• Varje mikrotjänst har en autonom livscykel och kan utvecklas oberoende och distribueras ofta. Du behöver inte vänta på att en kvartalsversion ska distribuera en ny funktion eller uppdatering. Du kan uppdatera ett litet område i ett liveprogram med mindre risk för att störa hela systemet. Uppdateringen kan göras utan en fullständig omdistribution av programmet.

• Varje mikrotjänst kan skalas separat. I stället för att skala hela programmet som en enda enhet skalar du bara ut de tjänster som kräver mer bearbetningskraft för att uppfylla önskade prestandanivåer och serviceavtal. Detaljerad skalning ger bättre kontroll över systemet och hjälper till att minska de totala kostnaderna när du skalar delar av systemet, inte allt.

En utmärkt referensguide för att förstå mikrotjänster är .NET Microservices: Architecture for Containerized .NET Applications. Boken fördjupar sig i design och arkitektur för mikrotjänster. Det är en följeslagare för en fullständig mikrotjänstreferensarkitektur som är tillgänglig som en kostnadsfri nedladdning från Microsoft.

Utveckla mikrotjänster

Mikrotjänster kan skapas på vilken modern utvecklingsplattform som helst.

Microsoft .NET-plattformen är ett utmärkt val. Kostnadsfria och öppen källkod har många inbyggda funktioner som förenklar mikrotjänstutvecklingen. .NET är plattformsoberoende. Program kan byggas och köras i Windows, macOS och de flesta linux-varianter.

.NET är mycket högpresterande och har fått bra resultat jämfört med Node.js och andra konkurrerande plattformar. Intressant nog genomförde TechEmpower en omfattande uppsättning prestandamått för många webbprogramplattformar och ramverk. .NET gjorde poäng i topp 10 - långt över Node.js och andra konkurrerande plattformar.

.NET underhålls av Microsoft och .NET-communityn på GitHub.

Mikrotjänstutmaningar

Distribuerade molnbaserade mikrotjänster kan ge enorm flexibilitet och snabbhet, men de har många utmaningar:

Kommunikation

Hur kommunicerar klientprogram på klientsidan med serverbaserade kärnmikrotjänster? Kommer du att tillåta direkt kommunikation? Eller kan du abstrahera serverdelsmikrotjänster med en gatewayfasad som ger flexibilitet, kontroll och säkerhet?

Hur kommunicerar serverdelens kärnmikrotjänster med varandra? Kommer du att tillåta direkta HTTP-anrop som kan öka kopplingen och påverka prestanda och flexibilitet? Eller kan du överväga frikopplade meddelanden med kö- och ämnestekniker?

Kommunikationen beskrivs i kapitlet molnbaserade kommunikationsmönster .

Elasticitet

En mikrotjänstarkitektur flyttar systemet från processbaserad till out-of-process-nätverkskommunikation. Vad händer i en distribuerad arkitektur när Service B inte svarar på ett nätverkssamtal från Service A? Eller vad händer när Service C blir tillfälligt otillgängligt och andra tjänster som anropar det blockeras?

Återhämtning beskrivs i det molnbaserade återhämtningskapitlet.

Distribuerade data

Varje mikrotjänst kapslar avsiktligt in sina egna data och exponerar åtgärder via det offentliga gränssnittet. I så fall, hur frågar du efter data eller implementerar en transaktion över flera tjänster?

Distribuerade data beskrivs i kapitlet molnbaserade datamönster .

Hemligheter

Hur kommer dina mikrotjänster att lagra och hantera hemligheter och känsliga konfigurationsdata på ett säkert sätt?

Hemligheter beskrivs i detalj molnbaserad säkerhet.

Hantera komplexitet med Dapr

Dapr är en distribuerad programkörning med öppen källkod. Genom en arkitektur med pluggbara komponenter förenklar det dramatiskt VVS bakom distribuerade program. Det ger ett dynamiskt lim som binder ditt program med fördefinierade infrastrukturfunktioner och komponenter från Dapr-körningen. Bild 1-5 visar Dapr från 20 000 fot.

Bild 1-5. Dapr på 20 000 fot.

Observera hur Dapr tillhandahåller språkspecifika SDK:er för populära utvecklingsplattformar på den översta raden i bilden. Dapr v1 innehåller stöd för .NET, Go, Node.js, Python, PHP, Java och JavaScript.

Även om språkspecifika SDK:er förbättrar utvecklarupplevelsen är Dapr plattformsoberoende. Under huven exponerar Daprs programmeringsmodell funktioner via standardprotokoll för HTTP/gRPC-kommunikation. Alla programmeringsplattformar kan anropa Dapr via sina interna HTTP- och gRPC-API:er.

De blå rutorna i mitten av figuren representerar Dapr-byggblocken. Var och en exponerar fördefinierad VVS-kod för en distribuerad programfunktion som programmet kan använda.

Komponentraden representerar en stor uppsättning fördefinierade infrastrukturkomponenter som programmet kan använda. Tänk på komponenter som infrastrukturkod som du inte behöver skriva.

Den nedre raden visar portabiliteten för Dapr och de olika miljöer där den kan köras.

Framöver har Dapr potential att ha en djupgående inverkan på molnbaserad programutveckling.

Containers

Det är naturligt att höra termen container som nämns i alla molnbaserade konversationer . I boken Cloud Native Patterns konstaterar författaren Cornelia Davis att "Containrar är en bra möjliggörare av molnbaserad programvara.". Cloud Native Computing Foundation placerar containerinkapsling av mikrotjänster som det första steget i deras molnbaserade trail map – vägledning för företag som påbörjar sin molnbaserade resa.

Att containerisera en mikrotjänst är enkelt och enkelt. Koden, dess beroenden och körningen paketeras i en binär fil som kallas för en containeravbildning. Avbildningar lagras i ett containerregister som fungerar som en lagringsplats eller ett bibliotek för avbildningar. Ett register kan finnas på utvecklingsdatorn, i ditt datacenter eller i ett offentligt moln. Docker själv underhåller ett offentligt register via Docker Hub. Azure-molnet har ett privat containerregister som lagrar containeravbildningar nära de molnprogram som ska köra dem.

När ett program startar eller skalar omvandlar du containeravbildningen till en containerinstans som körs. Instansen körs på alla datorer som har en containerkörningsmotor installerad. Du kan ha så många instanser av den containerbaserade tjänsten efter behov.

Bild 1–6 visar tre olika mikrotjänster, var och en i sin egen container, som alla körs på en enda värd.

Bild 1-6. Flera containrar som körs på en containervärd

Observera hur varje container har en egen uppsättning beroenden och körning, som kan skilja sig från varandra. Här ser vi olika versioner av produktmikrotjänsten som körs på samma värd. Varje container delar en del av det underliggande värdoperativsystemet, minnet och processorn, men är isolerad från varandra.

Observera hur väl containermodellen omfattar principen Beroenden från Tolvfaktorprogrammet.

Faktor 2 anger att "Varje mikrotjänst isolerar och paketerar sina egna beroenden och omfattar ändringar utan att påverka hela systemet".

Containrar stöder både Linux- och Windows-arbetsbelastningar. Azure-molnet omfattar öppet båda. Intressant nog är det Linux, inte Windows Server, som har blivit det mer populära operativsystemet i Azure.

Även om det finns flera containerleverantörer har Docker fångat lejonparten av marknaden. Företaget har drivit containerflytten. Det har blivit den faktiska standarden för paketering, distribution och körning av molnbaserade program.

Varför containrar?

Containrar ger portabilitet och garanterar konsekvens mellan miljöer. Genom att kapsla in allt i ett enda paket isolerar du mikrotjänsten och dess beroenden från den underliggande infrastrukturen.

Du kan distribuera containern i alla miljöer som är värdar för Docker-körningsmotorn. Containerbaserade arbetsbelastningar eliminerar också kostnaden för att förkonfigurera varje miljö med ramverk, programvarubibliotek och körningsmotorer.

Genom att dela det underliggande operativsystemet och värdresurserna har en container ett mycket mindre fotavtryck än en fullständig virtuell dator. Den mindre storleken ökar densiteten, eller antalet mikrotjänster, som en viss värd kan köra samtidigt.

Orkestrering av containrar

Även om verktyg som Docker skapar avbildningar och kör containrar behöver du också verktyg för att hantera dem. Containerhantering utförs med ett särskilt program som kallas containerorkestrerare. När du arbetar i stor skala med många oberoende containrar som körs är orkestrering viktigt.

Bild 1–7 visar hanteringsuppgifter som containerorkestrerare automatiserar.

Bild 1-7. Vad containerorkestrerare gör

I följande tabell beskrivs vanliga orkestreringsuppgifter.

Uppgifter	Förklaring
Schemaläggning	Etablera containerinstanser automatiskt.
Tillhörighet/antitillhörighet	Etablera containrar i närheten eller långt ifrån varandra, vilket bidrar till tillgänglighet och prestanda.
Hälsoövervakning	Identifiera och korrigera fel automatiskt.
Redundans	Återskapa automatiskt en misslyckad instans till en felfri dator.
Skalning	Lägg automatiskt till eller ta bort en containerinstans för att möta efterfrågan.
Nätverk	Hantera ett nätverksöverlägg för containerkommunikation.
Tjänsteidentifiering	Aktivera containrar för att hitta varandra.
Löpande uppgraderingar	Samordna inkrementella uppgraderingar med noll driftstoppsdistribution. Återställ automatiskt problematiska ändringar.

Observera hur containerorkestrerare använder principerna Disposability och Concurrency från Twelve-Factor Application.

Faktor 9 anger att "Tjänstinstanser ska vara disponibla, vilket gynnar snabba nystartade företag för att öka skalbarhetsmöjligheterna och graciösa avstängningar för att lämna systemet i rätt tillstånd." Docker-containrar tillsammans med en orkestrerare uppfyller detta krav."

Faktor 8 anger att "Tjänster skalar ut över ett stort antal små identiska processer (kopior) i stället för att skala upp en enda stor instans på den mest kraftfulla datorn som är tillgänglig.

Det finns flera containerorkestrerare, men Kubernetes har blivit de facto-standarden för den molnbaserade världen. Det är en bärbar, utökningsbar plattform med öppen källkod för hantering av containerbaserade arbetsbelastningar.

Du kan vara värd för din egen instans av Kubernetes, men då skulle du ansvara för att etablera och hantera dess resurser – vilket kan vara komplext. Azure-molnet har Kubernetes som en hanterad tjänst. Med både Azure Kubernetes Service (AKS) och Azure Red Hat OpenShift (ARO) kan du utnyttja funktionerna och kraften i Kubernetes som en hanterad tjänst fullt ut, utan att behöva installera och underhålla den.

Containerorkestrering beskrivs i detalj i Skala molnbaserade program.

Stödtjänster

Molnbaserade system är beroende av många olika underordnade resurser, till exempel datalager, meddelandeköer, övervakning och identitetstjänster. Dessa tjänster kallas för säkerhetskopieringstjänster.

Bild 1–8 visar många vanliga säkerhetskopieringstjänster som molnbaserade system använder.

Bild 1-8. Vanliga säkerhetskopieringstjänster

Du kan vara värd för dina egna säkerhetskopieringstjänster, men då skulle du ansvara för licensiering, etablering och hantering av dessa resurser.

Molnleverantörer erbjuder ett omfattande utbud av hanterade backningstjänster. I stället för att äga tjänsten använder du den helt enkelt. Molnleverantören driver resursen i stor skala och ansvarar för prestanda, säkerhet och underhåll. Övervakning, redundans och tillgänglighet är inbyggda i tjänsten. Leverantörerna garanterar prestanda på servicenivå och har fullt stöd för sina hanterade tjänster – öppna ett ärende och åtgärda problemet.

Molnbaserade system föredrar hanterade säkerhetskopieringstjänster från molnleverantörer. Besparingarna i tid och arbete kan vara betydande. Den operativa risken att vara värd för din egen och uppleva problem kan bli dyr snabbt.

Bästa praxis är att behandla en säkerhetskopieringstjänst som en ansluten resurs, dynamiskt bunden till en mikrotjänst med konfigurationsinformation (en URL och autentiseringsuppgifter) som lagras i en extern konfiguration. Den här vägledningen beskrivs i tolvfaktorprogrammet, som beskrevs tidigare i kapitlet.

Faktor 4 anger att stödtjänster "ska exponeras via en adresserbar URL. Om du gör det frikopplas resursen från programmet, vilket gör att den kan vara utbytbar."

Faktor 3 anger att "Konfigurationsinformation flyttas från mikrotjänsten och externaliseras via ett konfigurationshanteringsverktyg utanför koden".

Med det här mönstret kan en säkerhetskopieringstjänst kopplas från utan kodändringar. Du kan höja upp en mikrotjänst från QA till en mellanlagringsmiljö. Du uppdaterar mikrotjänstkonfigurationen så att den pekar på säkerhetskopieringstjänsterna i mellanlagringen och matar in inställningarna i containern via en miljövariabel.

Molnleverantörer tillhandahåller API:er som du kan använda för att kommunicera med deras proprietära säkerhetskopieringstjänster. Dessa bibliotek kapslar in den proprietära VVS och komplexiteten. Men att kommunicera direkt med dessa API:er kommer att nära koppla din kod till den specifika säkerhetskopieringstjänsten. Det är en allmänt accepterad metod att isolera implementeringsinformationen för leverantörs-API:et. Introducera ett förmedlingslager, eller mellanliggande API, som exponerar generiska åtgärder för din tjänstkod och omsluter leverantörskoden i den. Med den här lösa kopplingen kan du växla ut en säkerhetskopieringstjänst mot en annan eller flytta koden till en annan molnmiljö utan att behöva göra ändringar i huvudlinjetjänstkoden. Dapr, som beskrevs tidigare, följer den här modellen med sin uppsättning fördefinierade byggstenar.

Vid en slutlig tanke främjar stödtjänster också principen om statslöshet från tolvfaktorprogrammet, som diskuterades tidigare i kapitlet.

Faktor 6 anger att varje mikrotjänst ska köras i sin egen process, isolerad från andra tjänster som körs. Externalisera nödvändigt tillstånd till en säkerhetskopieringstjänst, till exempel en distribuerad cache eller ett datalager."

Säkerhetskopieringstjänster beskrivs i molnbaserade datamönster och molnbaserade kommunikationsmönster.

Automation

Som du har sett omfattar molnbaserade system mikrotjänster, containrar och modern systemdesign för att uppnå snabbhet och flexibilitet. Men det är bara en del av historien. Hur etablerar du de molnmiljöer som dessa system körs på? Hur distribuerar du snabbt appfunktioner och uppdateringar? Hur rundar du av hela bilden?

Ange den allmänt accepterade metoden infrastruktur som kod eller IaC.

Med IaC automatiserar du plattformsetablering och programdistribution. Du tillämpar i princip programvaruteknikmetoder som testning och versionshantering på dina DevOps-metoder. Infrastrukturen och distributionerna är automatiserade, konsekventa och repeterbara.

Automatisera infrastrukturen

Med verktyg som Azure Resource Manager, Azure Bicep, Terraform från HashiCorp och Azure CLI kan du deklarativt skripta den molninfrastruktur som du behöver. Resursnamn, platser, kapaciteter och hemligheter är parametriserade och dynamiska. Skriptet är versionshanterat och checkas in i källkontrollen som en artefakt i projektet. Du anropar skriptet för att etablera en konsekvent och repeterbar infrastruktur i systemmiljöer, till exempel QA, mellanlagring och produktion.

Under huven är IaC idempotent, vilket innebär att du kan köra samma skript om och om för sig utan biverkningar. Om teamet behöver göra en ändring redigerar och kör de skriptet igen. Endast de uppdaterade resurserna påverkas.

I artikeln Vad är infrastruktur som kod beskriver författaren Sam Guckenheimer hur Teams som implementerar IaC kan leverera stabila miljöer snabbt och i stor skala. De undviker manuell konfiguration av miljöer och framtvingar konsekvens genom att representera önskat tillstånd för sina miljöer via kod. Infrastrukturdistributioner med IaC är upprepbara och förhindrar körningsproblem som orsakas av konfigurationsavvikelser eller saknade beroenden. DevOps-team kan arbeta tillsammans med en enhetlig uppsättning metoder och verktyg för att leverera program och deras stödjande infrastruktur snabbt, tillförlitligt och i stor skala."

Automatisera distributioner

Tolvfaktorprogrammet, som beskrevs tidigare, kräver separata steg när du omvandlar slutförd kod till ett program som körs.

Faktor 5 anger att "Varje version måste framtvinga en strikt separation mellan bygg-, versions- och körningsfaserna. Var och en ska taggas med ett unikt ID och stödja möjligheten att återställa."

Moderna CI/CD-system bidrar till att uppfylla den här principen. De tillhandahåller separata bygg- och leveranssteg som hjälper till att säkerställa konsekvent och kvalitetskod som är lättillgänglig för användarna.

Bild 1–9 visar separationen mellan distributionsprocessen.

Bild 1-9. Distributionssteg i en CI/CD-pipeline

I föregående siffra bör du ägna särskild uppmärksamhet åt uppdelning av uppgifter:

1. Utvecklaren konstruerar en funktion i sin utvecklingsmiljö och itererar genom vad som kallas den "inre loopen" för kod, körning och felsökning.
2. När koden är klar skickas den till en kodlagringsplats, till exempel GitHub, Azure DevOps eller BitBucket.
3. Push-överföringen utlöser en byggfas som omvandlar koden till en binär artefakt. Arbetet implementeras med en CI-pipeline (Continuous Integration). Programmet byggs, testas och paketas automatiskt.
4. Versionssteget hämtar den binära artefakten, tillämpar konfigurationsinformation för externa program och miljöer och skapar en oföränderlig version. Versionen distribueras till en angiven miljö. Arbetet implementeras med en PIPELINE för kontinuerlig leverans (CD). Varje version ska vara identifierbar. Du kan säga: "Den här distributionen kör version 2.1.1 av programmet."
5. Slutligen körs den utgivna funktionen i målkörningsmiljön. Versioner är oföränderliga, vilket innebär att alla ändringar måste skapa en ny version.

Genom att tillämpa dessa metoder har organisationer radikalt utvecklat hur de skickar programvara. Många har gått från kvartalsvisa versioner till uppdateringar på begäran. Målet är att fånga problem tidigt i utvecklingscykeln när de är billigare att åtgärda. Ju längre varaktigheten mellan integreringar är, desto dyrare blir problemen att lösa. Med konsekvens i integreringsprocessen kan teamen genomföra kodändringar oftare, vilket leder till bättre samarbete och programvarukvalitet.

Infrastruktur som kod- och distributionsautomatisering, tillsammans med GitHub och Azure DevOps beskrivs i detalj i DevOps.

FöregåendeNästa