Wat is Cloud Native?

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Stop wat u doet en vraag uw collega's om de term 'Cloud Native' te definiëren. Er is een goede kans dat je verschillende antwoorden krijgt.

Laten we beginnen met een eenvoudige definitie:

Cloudeigen architectuur en technologieën zijn een benadering voor het ontwerpen, bouwen en uitvoeren van workloads die zijn ingebouwd in de cloud en optimaal profiteren van het cloud-computingmodel.

De Cloud Native Computing Foundation biedt de officiële definitie:

Cloudeigen technologieën bieden organisaties de mogelijkheid om schaalbare toepassingen te bouwen en uit te voeren in moderne, dynamische omgevingen, zoals openbare, privéclouds en hybride clouds. Containers, service-meshes, microservices, onveranderbare infrastructuur en declaratieve API's illustreren deze benadering.

Deze technieken maken losjes gekoppelde systemen mogelijk die tolerant, beheersbaar en waarneembaar zijn. In combinatie met robuuste automatisering kunnen technici regelmatig en voorspelbaar wijzigingen met een hoge impact aanbrengen met minimale toil.

Cloudeigen gaat over snelheid en flexibiliteit. Bedrijfssystemen ontwikkelen zich van het inschakelen van bedrijfsmogelijkheden tot wapens van strategische transformatie die de snelheid en groei van het bedrijf versnellen. Het is noodzakelijk om onmiddellijk nieuwe ideeën op de markt te krijgen.

Tegelijkertijd zijn bedrijfssystemen ook steeds complexer geworden met gebruikers die meer eisen. Ze verwachten snelle reactiesnelheid, innovatieve functies en geen downtime. Prestatieproblemen, terugkerende fouten en het onvermogen om snel te gaan, zijn niet langer acceptabel. Uw gebruikers bezoeken uw concurrent. Cloudeigen systemen zijn ontworpen om snelle veranderingen, grootschalige en tolerantie te omarmen.

Hier volgen enkele bedrijven die cloudeigen technieken hebben geïmplementeerd. Denk na over de snelheid, flexibiliteit en schaalbaarheid die ze hebben bereikt.

Bedrijf	Ervaring
Netflix	Heeft meer dan 600 services in productie. Implementeert 100 keer per dag.
Uber	Heeft meer dan 1000 services in productie. Implementeert enkele duizenden keren per week.
WeChat	Heeft meer dan 3000 services in productie. Implementeert 1000 keer per dag.

Zoals u kunt zien, maken Netflix, Uber en WeChat cloudeigen systemen beschikbaar die bestaan uit veel onafhankelijke services. Met deze architectuurstijl kunnen ze snel reageren op marktomstandigheden. Ze werken onmiddellijk kleine gebieden van een live, complexe toepassing bij zonder een volledige herverdeling. Ze schalen services afzonderlijk naar behoefte.

De pijlers van cloudeigen

De snelheid en flexibiliteit van cloudeigen toepassingen zijn afgeleid van veel factoren. De belangrijkste plaats is cloudinfrastructuur. Maar er is nog meer: Vijf andere fundamentele pijlers die worden weergegeven in afbeelding 1-3 bieden ook de basissteen voor cloudeigen systemen.

Afbeelding 1-3. Cloudeigen basispijlers

Laten we even de tijd nemen om de betekenis van elke pijler beter te begrijpen.

De cloud

Cloudeigen systemen profiteren optimaal van het cloudservicemodel.

Deze systemen zijn ontworpen om te bloeien in een dynamische, gevirtualiseerde cloudomgeving en maken uitgebreid gebruik van paaS-rekeninfrastructuur (Platform as a Service) en beheerde services. Ze behandelen de onderliggende infrastructuur als wegwerpbaar - ingericht in minuten en aangepast, geschaald of vernietigd op aanvraag - via automatisering.

Houd rekening met het verschil tussen hoe we huisdieren en grondstoffen behandelen. In een traditioneel datacenter worden servers behandeld als huisdieren: een fysieke machine, met een betekenisvolle naam en verzorgd. U schaalt door meer resources toe te voegen aan dezelfde machine (omhoog schalen). Als de server ziek wordt, verpleeg je het weer. Als de server niet beschikbaar is, merkt iedereen dat.

Het servicemodel voor grondstoffen verschilt. U richt elk exemplaar in als een virtuele machine of container. Ze zijn identiek en toegewezen aan een systeem-id, zoals Service-01, Service-02, enzovoort. U schaalt door meer exemplaren te maken (uitschalen). Niemand merkt wanneer een exemplaar niet meer beschikbaar is.

Het model van grondstoffen omvat onveranderbare infrastructuur. Servers worden niet hersteld of gewijzigd. Als één mislukt of een update vereist, wordt deze vernietigd en wordt er een nieuwe ingericht, allemaal via automatisering.

Cloudeigen systemen omarmen het servicemodel voor grondstoffen. Ze blijven actief als de infrastructuur wordt ingeschaald of uitgeschaald, zonder rekening te houden met de machines waarop ze worden uitgevoerd.

Het Azure-cloudplatform ondersteunt dit type zeer elastische infrastructuur met automatische schaalaanpassing, zelfherstel en bewakingsmogelijkheden.

Modern ontwerp

Hoe zou u een cloudeigen app ontwerpen? Hoe ziet uw architectuur eruit? Aan welke principes, patronen en best practices voldoet u? Welke infrastructuur- en operationele problemen zijn belangrijk?

De Twaalf-Factor-toepassing

Een algemeen geaccepteerde methodologie voor het bouwen van cloudtoepassingen is de Twaalf-Factor-toepassing. Het beschrijft een set principes en procedures die ontwikkelaars volgen om toepassingen te bouwen die zijn geoptimaliseerd voor moderne cloudomgevingen. Er wordt speciale aandacht besteed aan portabiliteit in omgevingen en declaratieve automatisering.

Hoewel dit van toepassing is op elke webtoepassing, beschouwen veel beoefenaars Twaalf factor als een solide basis voor het bouwen van cloudeigen apps. Systemen die op deze principes zijn gebouwd, kunnen snel worden geïmplementeerd en geschaald en functies toevoegen om snel te reageren op marktwijzigingen.

In de volgende tabel ziet u de Twaalf-Factor-methodologie:

Factor	Uitleg
1 - Codebasis	Eén codebasis voor elke microservice, opgeslagen in een eigen opslagplaats. Bijgehouden met versiebeheer, kan deze worden geïmplementeerd in meerdere omgevingen (QA, Fasering, Productie).
2 - Afhankelijkheden	Elke microservice isoleert en verpakt zijn eigen afhankelijkheden, waarbij wijzigingen worden omarmen zonder dat dit van invloed is op het hele systeem.
3 - Configuraties	Configuratiegegevens worden buiten de microservice verplaatst en extern via een hulpprogramma voor configuratiebeheer buiten de code. Dezelfde implementatie kan worden doorgegeven in omgevingen waarop de juiste configuratie is toegepast.
4 - Backing Services	Aanvullende resources (gegevensarchieven, caches, berichtbrokers) moeten worden weergegeven via een adresseerbare URL. Als u dit doet, wordt de resource losgekoppeld van de toepassing, zodat deze uitwisselbaar kan zijn.
5 - Build, Release, Uitvoeren	Elke release moet een strikte scheiding afdwingen tussen de build-, release- en uitvoeringsfasen. Elk moet worden gelabeld met een unieke id en ondersteuning bieden voor de mogelijkheid om terug te draaien. Moderne CI/CD-systemen helpen dit principe te vervullen.
6 - Processen	Elke microservice moet in een eigen proces worden uitgevoerd, geïsoleerd van andere actieve services. Externaliseer de vereiste status naar een back-upservice, zoals een gedistribueerde cache of gegevensopslag.
7 - Poortbinding	Elke microservice moet onafhankelijk zijn van de interfaces en functionaliteit die beschikbaar zijn op een eigen poort. Dit biedt isolatie van andere microservices.
8 - Gelijktijdigheid	Wanneer de capaciteit moet toenemen, schaalt u services horizontaal uit over meerdere identieke processen (kopieën) in plaats van één groot exemplaar op te schalen op de krachtigste machine die beschikbaar is. Ontwikkel de toepassing zodat deze gelijktijdig kan worden uitgeschaald in cloudomgevingen.
9 - Disposability	Service-exemplaren moeten wegwerpbaar zijn. Geef de voorkeur aan snel opstarten om de schaalbaarheidsmogelijkheden en respijtvolle afsluitingen te vergroten om het systeem in een juiste staat te laten. Docker-containers samen met een orchestrator voldoen inherent aan deze vereiste.
10 - Dev/Prod Parity	Houd omgevingen in de levenscyclus van de toepassing zo veel mogelijk op elkaar, waardoor kostbare snelkoppelingen worden vermeden. Hier kan de acceptatie van containers aanzienlijk bijdragen door dezelfde uitvoeringsomgeving te bevorderen.
11 - Logboekregistratie	Behandel logboeken die door microservices worden gegenereerd als gebeurtenisstromen. Ze verwerken met een gebeurtenisaggregator. Logboekgegevens doorgeven aan hulpprogramma's voor gegevensanalyse/logboekbeheer, zoals Azure Monitor of Splunk, en uiteindelijk aan archivering op lange termijn.
12 - Beheer processen	Voer administratieve/beheertaken uit, zoals het opschonen van gegevens of computinganalyses, als eenmalige processen. Gebruik onafhankelijke hulpprogramma's om deze taken aan te roepen vanuit de productieomgeving, maar los van de toepassing.

In het boek, Beyond the Twelve-Factor App, schrijft Kevin Hoffman elk van de oorspronkelijke 12 factoren (geschreven in 2011). Daarnaast bespreekt hij drie extra factoren die het moderne ontwerp van cloudtoepassingen weerspiegelen.

Nieuwe factor	Uitleg
13 - API eerst	Maak alles een service. Stel dat uw code wordt gebruikt door een front-endclient, gateway of een andere service.
14 - Telemetrie	Op een werkstation hebt u diep inzicht in uw toepassing en het gedrag ervan. In de cloud is dat niet zo. Zorg ervoor dat uw ontwerp de verzameling bewakings-, domeinspecifieke en status-/systeemgegevens bevat.
15 - Verificatie/autorisatie	Implementeer identiteit vanaf het begin. Overweeg RBAC-functies (op rollen gebaseerd toegangsbeheer) die beschikbaar zijn in openbare clouds.

We verwijzen naar veel van de 12+ factoren in dit hoofdstuk en in het hele boek.

Azure Well-Architected Framework

Het ontwerpen en implementeren van cloudworkloads kan lastig zijn, met name bij het implementeren van cloudeigen architectuur. Microsoft biedt best practices voor industriestandaarden om u en uw team te helpen robuuste cloudoplossingen te leveren.

Het Microsoft Well-Architected Framework biedt een reeks richtlijnen die kunnen worden gebruikt om de kwaliteit van een cloudeigen workload te verbeteren. Het Framework bestaat uit vijf pijlers van hoogwaardige architectuur:

Principes	Beschrijving
Kostenbeheer	Richt u op het vroeg genereren van incrementele waarde. Pas build-Measure-Learn-principes toe om de tijd tot de markt te versnellen en kapitaalintensieve oplossingen te voorkomen. Als u een strategie voor betalen per gebruik gebruikt, investeert u terwijl u uitschaalt, in plaats van een grote investering vooraf te leveren.
Operationele uitmuntendheid	Automatiseer de omgeving en bewerkingen om de snelheid te verhogen en menselijke fouten te verminderen. Schakel probleemupdates snel terug of vooruit. Implementeer bewaking en diagnose vanaf het begin.
Prestatie-efficiëntie	Efficiënt voldoen aan de vereisten voor uw workloads. Geef de voorkeur aan horizontaal schalen (uitschalen) en ontwerp deze in uw systemen. Voer voortdurend prestatie- en belastingtests uit om potentiële knelpunten te identificeren.
Betrouwbaarheid	Werkbelastingen bouwen die zowel tolerant als beschikbaar zijn. Dankzij tolerantie kunnen workloads herstellen na fouten en blijven werken. Beschikbaarheid zorgt ervoor dat gebruikers altijd toegang hebben tot uw workload. Ontwerp toepassingen om fouten te verwachten en te herstellen.
Beveiliging	Implementeer de beveiliging gedurende de gehele levenscyclus van een toepassing, van ontwerp en implementatie tot implementatie en bewerkingen. Let goed op identiteitsbeheer, toegang tot infrastructuur, toepassingsbeveiliging en gegevenssoevereine en -versleuteling.

Om aan de slag te gaan, biedt Microsoft een set online evaluaties om u te helpen uw huidige cloudworkloads te beoordelen op basis van de vijf goed ontworpen pijlers.

Microservices

Cloudeigen systemen omarmen microservices, een populaire architectuurstijl voor het bouwen van moderne toepassingen.

Microservices zijn gebouwd als een gedistribueerde set kleine, onafhankelijke services die communiceren via een gedeelde infrastructuur, microservices delen de volgende kenmerken:

• Elk implementeert een specifieke bedrijfsmogelijkheid binnen een grotere domeincontext.

• Elk is autonoom ontwikkeld en kan onafhankelijk worden geïmplementeerd.

• Elk is een zelfstandige inkapselen van een eigen technologie voor gegevensopslag, afhankelijkheden en programmeerplatform.

• Elk wordt uitgevoerd in een eigen proces en communiceert met anderen met behulp van standaardcommunicatieprotocollen zoals HTTP/HTTPS, gRPC, WebSockets of AMQP.

• Ze vormen samen om een toepassing te vormen.

Afbeelding 1-4 contrasteert een monolithische toepassingsbenadering met een microservicesbenadering. Let op hoe de monolith bestaat uit een gelaagde architectuur, die in één proces wordt uitgevoerd. Doorgaans wordt een relationele database gebruikt. De microservicebenadering scheidt echter functionaliteit in onafhankelijke services, elk met zijn eigen logica, status en gegevens. Elke microservice fungeert als host voor een eigen gegevensarchief.

Afbeelding 1-4. Monolithische versus microservicesarchitectuur

Houd er rekening mee dat microservices het principe Processen promoten van de Twaalf-Factor-toepassing, eerder in het hoofdstuk besproken.

Factor 6 geeft aan dat elke microservice in een eigen proces moet worden uitgevoerd, geïsoleerd van andere actieve services.

Waarom microservices?

Microservices bieden flexibiliteit.

Eerder in het hoofdstuk hebben we een eCommerce-toepassing vergeleken die is gebouwd als een monolithische toepassing met microservices. In het voorbeeld hebben we enkele duidelijke voordelen gezien:

• Elke microservice heeft een autonome levenscyclus en kan onafhankelijk worden ontwikkeld en regelmatig worden geïmplementeerd. U hoeft niet te wachten op een kwartaalrelease om een nieuwe functie of update te implementeren. U kunt een klein gebied van een live-toepassing bijwerken met minder risico om het hele systeem te verstoren. De update kan worden uitgevoerd zonder de toepassing volledig opnieuw te implementeren.

• Elke microservice kan onafhankelijk worden geschaald. In plaats van de hele toepassing als één eenheid te schalen, schaalt u alleen de services uit waarvoor meer verwerkingskracht nodig is om te voldoen aan de gewenste prestatieniveaus en serviceovereenkomsten. Fijnmazig schalen biedt meer controle over uw systeem en helpt de totale kosten te verlagen wanneer u delen van uw systeem schaalt, niet alles.

Een uitstekende referentiegids voor het begrijpen van microservices is .NET Microservices: Architectuur voor in containers geplaatste .NET-toepassingen. Het boek gaat dieper in op het ontwerp en de architectuur van microservices. Het is een aanvulling voor een referentiearchitectuur voor een volledige stack microservice die beschikbaar is als gratis download van Microsoft.

Microservices ontwikkelen

Microservices kunnen worden gemaakt op elk modern ontwikkelplatform.

Het Microsoft .NET-platform is een uitstekende keuze. Gratis en open source, het heeft veel ingebouwde functies die de ontwikkeling van microservices vereenvoudigen. .NET is platformoverschrijdend. Toepassingen kunnen worden gebouwd en uitgevoerd op Windows, macOS en de meeste varianten van Linux.

.NET is zeer goed presterend en heeft goed gescoord in vergelijking met Node.js en andere concurrerende platforms. TechEmpower heeft op veel platformen en frameworks voor webtoepassingen een uitgebreide set prestatiebenchmarks uitgevoerd. .NET scoorde in de top 10 - ruim boven Node.js en andere concurrerende platforms.

.NET wordt onderhouden door Microsoft en de .NET-community op GitHub.

Microservice-uitdagingen

Hoewel gedistribueerde cloudeigen microservices enorme flexibiliteit en snelheid kunnen bieden, zijn er veel uitdagingen:

Communicatie

Hoe communiceren front-endclienttoepassingen met microservices met back-end kernen? Staat u directe communicatie toe? Of kunt u de back-end microservices abstraheren met een gatewayfaçade die flexibiliteit, controle en beveiliging biedt?

Hoe communiceren back-end kernmicroservices met elkaar? Staat u directe HTTP-aanroepen toe die de koppeling kunnen verhogen en de prestaties en flexibiliteit kunnen beïnvloeden? Of kunt u overwegen om berichten los te koppelen met wachtrij- en onderwerptechnologieën?

Communicatie wordt behandeld in het hoofdstuk Cloudeigen communicatiepatronen .

Flexibiliteit

Een microservicesarchitectuur verplaatst uw systeem van in-proces naar out-of-process-netwerkcommunicatie. Wat gebeurt er in een gedistribueerde architectuur wanneer Service B niet reageert op een netwerkaanroep van Service A? Of, wat gebeurt er wanneer Service C tijdelijk niet beschikbaar is en andere services die deze aanroepen, worden geblokkeerd?

Tolerantie wordt behandeld in het hoofdstuk over cloudeigen tolerantie .

Gedistribueerde gegevens

Elke microservice bevat standaard zijn eigen gegevens, waarbij bewerkingen beschikbaar worden gemaakt via de openbare interface. Zo ja, hoe voert u een query uit op gegevens of implementeert u een transactie in meerdere services?

Gedistribueerde gegevens worden behandeld in het hoofdstuk over cloudeigen gegevenspatronen .

Geheimen

Hoe worden geheimen en gevoelige configuratiegegevens veilig opgeslagen en beheerd in uw microservices?

Geheimen worden uitgebreid behandeld in cloudeigen beveiliging.

Complexiteit beheren met Dapr

Dapr is een gedistribueerde opensource-toepassingsruntime. Dankzij een architectuur van pluggable componenten vereenvoudigt het de sanitair achter gedistribueerde toepassingen aanzienlijk. Het biedt een dynamische lijm die uw toepassing verbindt met vooraf gebouwde infrastructuurmogelijkheden en onderdelen van de Dapr-runtime. Afbeelding 1-5 toont Dapr van 20.000 voet.

Afbeelding 1-5. Dapr op 20.000 meter.

In de bovenste rij van de afbeelding ziet u hoe Dapr taalspecifieke SDK's biedt voor populaire ontwikkelplatforms. Dapr v1 bevat ondersteuning voor .NET, Go, Node.js, Python, PHP, Java en JavaScript.

Hoewel taalspecifieke SDK's de ontwikkelaarservaring verbeteren, is Dapr platformneutraal. Onder de schermen biedt het programmeermodel van Dapr mogelijkheden via standaard-HTTP/gRPC-communicatieprotocollen. Elk programmeerplatform kan Dapr aanroepen via de systeemeigen HTTP- en gRPC-API's.

De blauwe vakken in het midden van de afbeelding vertegenwoordigen de Dapr-bouwstenen. Elk bevat vooraf gebouwde loodgieterscode voor een gedistribueerde toepassingsmogelijkheid die uw toepassing kan gebruiken.

De onderdelenrij vertegenwoordigt een grote set vooraf gedefinieerde infrastructuuronderdelen die uw toepassing kan gebruiken. Denk aan onderdelen als infrastructuurcode die u niet hoeft te schrijven.

In de onderste rij ziet u de draagbaarheid van Dapr en de diverse omgevingen waarin deze kan worden uitgevoerd.

Vooruitkijkend heeft Dapr het potentieel om een grote impact te hebben op cloudeigen toepassingsontwikkeling.

Containers

Het is natuurlijk om de termcontainer te horen die wordt genoemd in een cloudeigen gesprek. In het boek, Cloud Native Patterns, auteur Microsoft Davis merkt op dat 'Containers zijn een geweldige enabler van cloudeigen software'. De Cloud Native Computing Foundation plaatst microservicecontainerisatie als de eerste stap in hun Cloud-Native Trail Map - richtlijnen voor ondernemingen die hun cloudeigen traject starten.

Containeriseren van een microservice is eenvoudig en eenvoudig. De code, de bijbehorende afhankelijkheden en runtime worden verpakt in een binair bestand dat een containerinstallatiekopieën wordt genoemd. Installatiekopieën worden opgeslagen in een containerregister, dat fungeert als een opslagplaats of bibliotheek voor installatiekopieën. Een register kan zich op uw ontwikkelcomputer, in uw datacenter of in een openbare cloud bevinden. Docker zelf onderhoudt een openbaar register via Docker Hub. De Azure-cloud bevat een privécontainerregister voor het opslaan van containerinstallatiekopieën dicht bij de cloudtoepassingen die deze uitvoeren.

Wanneer een toepassing wordt gestart of geschaald, transformeert u de containerinstallatiekopieën in een actieve containerinstantie. Het exemplaar wordt uitgevoerd op elke computer waarop een containerruntime-engine is geïnstalleerd. U kunt zoveel exemplaren van de containerservice hebben als nodig is.

In afbeelding 1-6 ziet u drie verschillende microservices, elk in een eigen container, die allemaal op één host worden uitgevoerd.

Afbeelding 1-6. Meerdere containers die worden uitgevoerd op een containerhost

Houd er rekening mee dat elke container een eigen set afhankelijkheden en runtime onderhoudt, die van elkaar kan verschillen. Hier zien we verschillende versies van de microservice product die op dezelfde host worden uitgevoerd. Elke container deelt een segment van het onderliggende hostbesturingssysteem, het geheugen en de processor, maar is geïsoleerd van elkaar.

Merk op hoe goed het containermodel het afhankelijkhedenprincipe van de Twaalf-Factor-toepassing omarmt.

Factor 2 geeft aan dat "Elke microservice isoleert en verpakt zijn eigen afhankelijkheden, waarbij wijzigingen worden omarmen zonder dat dit van invloed is op het hele systeem."

Containers ondersteunen zowel Linux- als Windows-workloads. De Azure-cloud omarmt beide. Het is interessant dat het Linux, niet Windows Server, het populairste besturingssysteem in Azure is geworden.

Hoewel er verschillende containerleveranciers bestaan, heeft Docker het leeuwendeel van de markt vastgelegd. Het bedrijf drijft de softwarecontainerverplaatsing aan. Het is de feitelijke standaard geworden voor het verpakken, implementeren en uitvoeren van cloudtoepassingen.

Waarom containers?

Containers bieden draagbaarheid en garanderen consistentie tussen omgevingen. Door alles in één pakket in te kapselen, isoleert u de microservice en de bijbehorende afhankelijkheden van de onderliggende infrastructuur.

U kunt de container implementeren in elke omgeving die als host fungeert voor de Docker Runtime-engine. Workloads in containers elimineren ook de kosten van het vooraf configureren van elke omgeving met frameworks, softwarebibliotheken en runtime-engines.

Door het onderliggende besturingssysteem en hostresources te delen, heeft een container een veel kleinere footprint dan een volledige virtuele machine. De kleinere grootte verhoogt de dichtheid of het aantal microservices dat een bepaalde host tegelijk kan uitvoeren.

Containerindeling

Hoewel hulpprogramma's zoals Docker installatiekopieën maken en containers uitvoeren, hebt u ook hulpprogramma's nodig om ze te beheren. Containerbeheer wordt uitgevoerd met een speciaal softwareprogramma dat een containerorchestrator wordt genoemd. Wanneer u op schaal werkt met veel onafhankelijke actieve containers, is indeling essentieel.

Afbeelding 1-7 toont beheertaken die containerorchestrators automatiseren.

Afbeelding 1-7. Wat containerorchestrators doen

In de volgende tabel worden algemene indelingstaken beschreven.

Opdrachten	Uitleg
Plannen	Containerinstanties automatisch inrichten.
Affiniteit/antiaffiniteit	Richt containers in de buurt of ver van elkaar in, waardoor de beschikbaarheid en prestaties worden verbeterd.
Statuscontrole	Fouten automatisch detecteren en corrigeren.
Failover	Automatisch opnieuw inrichten van een mislukt exemplaar naar een goede machine.
Schalen	Automatisch een containerinstantie toevoegen of verwijderen om aan de vraag te voldoen.
Netwerken	Een netwerkoverlay beheren voor containercommunicatie.
Servicedetectie	Schakel containers in om elkaar te vinden.
Rolling Upgrades	Coördineer incrementele upgrades met geen downtime-implementatie. Hiermee worden problematische wijzigingen automatisch teruggedraaid.

Houd er rekening mee dat containerorchestrators de principes Disposability en Concurrency van de Twaalf-Factor-toepassing omarmen.

Factor 9 geeft aan dat service-exemplaren wegwerpbaar moeten zijn, waardoor snelle start-ups sneller kunnen worden geschaad om de schaalbaarheidskansen te verhogen en het systeem in een juiste staat te houden. Docker-containers samen met een orchestrator voldoen inherent aan deze vereiste.

Factor 8 geeft aan dat 'Services worden uitgeschaald over een groot aantal kleine identieke processen (kopieën) in plaats van één groot exemplaar op te schalen op de krachtigste beschikbare machine.

Hoewel er verschillende containerorchestrators bestaan, is Kubernetes de feitelijke standaard geworden voor de cloudeigen wereld. Het is een draagbaar, uitbreidbaar, opensource-platform voor het beheren van workloads in containers.

U kunt uw eigen exemplaar van Kubernetes hosten, maar dan bent u verantwoordelijk voor het inrichten en beheren van de resources. Dit kan complex zijn. De Azure-cloud biedt Kubernetes als een beheerde service. Met zowel Azure Kubernetes Service (AKS) als Azure Red Hat OpenShift (ARO) kunt u volledig gebruikmaken van de functies en kracht van Kubernetes als beheerde service, zonder dat u deze hoeft te installeren en onderhouden.

Containerindeling wordt uitgebreid besproken in cloudtoepassingen schalen.

Backing-services

Cloudeigen systemen zijn afhankelijk van veel verschillende ondersteunende resources, zoals gegevensarchieven, berichtenbrokers, bewaking en identiteitsservices. Deze services worden backing-services genoemd.

Afbeelding 1-8 toont veel algemene back-upservices die cloudeigen systemen verbruiken.

Afbeelding 1-8. Algemene back-upservices

U kunt uw eigen backingservices hosten, maar dan bent u verantwoordelijk voor licenties, inrichting en beheer van deze resources.

Cloudproviders bieden een uitgebreid assortiment beheerde backingservices. In plaats van de service te bezitten, gebruikt u deze gewoon. De cloudprovider beheert de resource op schaal en draagt de verantwoordelijkheid voor prestaties, beveiliging en onderhoud. Bewaking, redundantie en beschikbaarheid zijn ingebouwd in de service. Providers garanderen prestaties op serviceniveau en ondersteunen hun beheerde services volledig. Open een ticket en ze lossen uw probleem op.

Cloudeigen systemen geven de voorkeur aan beheerde backing-services van cloudleveranciers. De besparingen in tijd en arbeid kunnen aanzienlijk zijn. Het operationele risico van het hosten van uw eigen bedrijf en het ondervinden van problemen kan snel duur worden.

Een best practice is om een backing-service te behandelen als een gekoppelde resource, dynamisch gebonden aan een microservice met configuratiegegevens (een URL en referenties) die zijn opgeslagen in een externe configuratie. Deze richtlijnen worden beschreven in de Twaalf-Factor-toepassing, die eerder in het hoofdstuk is besproken.

Factor 4 geeft aan dat backing-services 'moeten worden weergegeven via een adresseerbare URL. Hierdoor wordt de resource losgekoppeld van de toepassing, zodat deze uitwisselbaar kan worden."

Factor #3 geeft aan dat 'Configuratiegegevens worden verplaatst uit de microservice en extern worden verplaatst via een hulpprogramma voor configuratiebeheer buiten de code'.

Met dit patroon kan een back-upservice worden gekoppeld en losgekoppeld zonder codewijzigingen. U kunt een microservice promoveren van QA naar een faseringsomgeving. U werkt de microserviceconfiguratie bij zodat deze verwijst naar de backing-services in fasering en de instellingen in uw container injecteert via een omgevingsvariabele.

Cloudleveranciers bieden API's waarmee u kunt communiceren met hun eigen backingservices. Deze bibliotheken bevatten de eigen sanitair en complexiteit. Als u echter rechtstreeks met deze API's communiceert, wordt uw code nauw gekoppeld aan die specifieke back-upservice. Het is een algemeen geaccepteerde praktijk om de implementatiedetails van de leverancier-API te isoleren. Introduceer een intermediation-laag of tussenliggende API, waarbij algemene bewerkingen worden weergegeven in uw servicecode en de leveranciercode erin verpakt. Met deze losse koppeling kunt u de ene backingservice voor een andere wisselen of uw code verplaatsen naar een andere cloudomgeving zonder dat u wijzigingen hoeft aan te brengen in de hoofdregelservicecode. Dapr, eerder besproken, volgt dit model met de set vooraf gemaakte bouwstenen.

Bij een laatste gedachte bevorderen de ondersteuningsservices ook het statelessheidsprincipe van de Twaalf-Factor Application, die eerder in het hoofdstuk zijn besproken.

Factor 6 geeft aan dat elke microservice in een eigen proces moet worden uitgevoerd, geïsoleerd van andere actieve services. Externaliseer de vereiste status naar een back-upservice, zoals een gedistribueerde cache of gegevensopslag.

Backing-services worden besproken in cloudeigen gegevenspatronen en cloudeigen communicatiepatronen.

Automation

Zoals u hebt gezien, omarmen cloudeigen systemen microservices, containers en modern systeemontwerp om snelheid en flexibiliteit te bereiken. Maar dat is slechts een deel van het verhaal. Hoe richt u de cloudomgevingen in waarop deze systemen worden uitgevoerd? Hoe implementeert u snel app-functies en -updates? Hoe rond je het volledige plaatje af?

Voer de algemeen geaccepteerde praktijk van Infrastructure as Code of IaC in.

Met IaC automatiseert u platforminrichting en toepassingsimplementatie. U past in wezen software-engineeringprocedures toe, zoals testen en versiebeheer op uw DevOps-procedures. Uw infrastructuur en implementaties zijn geautomatiseerd, consistent en herhaalbaar.

Infrastructuur automatiseren

Met hulpprogramma's zoals Azure Resource Manager, Azure Bicep, Terraform van HashiCorp en de Azure CLI kunt u declaratief scripts uitvoeren voor de cloudinfrastructuur die u nodig hebt. Resourcenamen, locaties, capaciteiten en geheimen worden geparameteriseerd en dynamisch. Het script is geversied en ingecheckt in broncodebeheer als een artefact van uw project. U roept het script aan om een consistente en herhaalbare infrastructuur in te richten in systeemomgevingen, zoals QA, fasering en productie.

Onder de motorkap is IaC idempotent, wat betekent dat u hetzelfde script telkens opnieuw kunt uitvoeren zonder bijwerkingen. Als het team een wijziging moet aanbrengen, wordt het script bewerkt en opnieuw uitgevoerd. Alleen de bijgewerkte resources worden beïnvloed.

In het artikel What is Infrastructure as Code, Author Sam Guckenheimer beschrijft hoe"Teams die IaC implementeren stabiele omgevingen snel en op schaal kan leveren. Ze vermijden handmatige configuratie van omgevingen en dwingen consistentie af door de gewenste status van hun omgevingen te vertegenwoordigen via code. Implementaties van infrastructuur met IaC zijn herhaalbaar en voorkomen dat er runtimeproblemen ontstaan door configuratieverschuivingen of ontbrekende afhankelijkheden. DevOps-teams kunnen samenwerken met een geïntegreerde set procedures en hulpprogramma's om toepassingen en hun ondersteunende infrastructuur snel, betrouwbaar en op schaal te leveren."

Implementaties automatiseren

De Twaalf-Factor-toepassing, die eerder is besproken, roept afzonderlijke stappen aan bij het transformeren van voltooide code in een actieve toepassing.

Factor 5 geeft aan dat 'Elke release moet een strikte scheiding afdwingen tussen de build-, release- en uitvoeringsfasen. Elk moet worden gelabeld met een unieke id en ondersteuning bieden voor de mogelijkheid om terug te draaien.".

Moderne CI/CD-systemen helpen dit principe te vervullen. Ze bieden afzonderlijke build- en leveringsstappen die zorgen voor consistente en kwaliteitscode die direct beschikbaar is voor gebruikers.

In afbeelding 1-9 ziet u de scheiding tussen het implementatieproces.

Afbeelding 1-9. Implementatiestappen in een CI/CD-pijplijn

Let in het vorige cijfer vooral op de scheiding van taken:

1. De ontwikkelaar bouwt een functie in de ontwikkelomgeving, doorloopt wat de 'interne lus' van code wordt genoemd, wordt uitgevoerd en foutopsporing wordt genoemd.
2. Wanneer deze code is voltooid, wordt deze naar een codeopslagplaats gepusht , zoals GitHub, Azure DevOps of BitBucket.
3. De push activeert een buildfase die de code transformeert in een binair artefact. Het werk wordt geïmplementeerd met een CI-pijplijn (Continuous Integration). De toepassing wordt automatisch gebouwd, getest en verpakt.
4. De releasefase haalt het binaire artefact op, past externe toepassings- en omgevingsconfiguratiegegevens toe en produceert een onveranderbare release. De release wordt geïmplementeerd in een opgegeven omgeving. Het werk wordt geïmplementeerd met een CD-pijplijn (Continuous Delivery). Elke release moet identificeerbaar zijn. U kunt zeggen: 'Deze implementatie voert release 2.1.1 van de toepassing uit.'
5. Ten slotte wordt de uitgebrachte functie uitgevoerd in de doeluitvoeringsomgeving. Releases zijn onveranderbaar, wat betekent dat elke wijziging een nieuwe release moet maken.

Door deze procedures toe te passen, hebben organisaties zich ingrijpend ontwikkeld hoe ze software verzenden. Velen zijn overgestapt van kwartaalreleases naar updates op aanvraag. Het doel is om problemen vroeg in de ontwikkelingscyclus te ondervangen wanneer ze minder duur zijn om op te lossen. Hoe langer de duur tussen integraties, hoe duurdere problemen worden opgelost. Met consistentie in het integratieproces kunnen teams codewijzigingen vaker doorvoeren, wat leidt tot betere samenwerking en softwarekwaliteit.

Infrastructuur als code- en implementatieautomatisering, samen met GitHub en Azure DevOps, worden uitgebreid besproken in DevOps.

VorigeVolgende