Wat is Cloud Native?

Aanbeveling

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.

Cloud-native gaat over snelheid en wendbaarheid. 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. Voert 100 keer per dag uit.
Uber	Heeft meer dan 1000 services in productie. Implementeert enkele duizenden keren per week.
WeChat	Heeft meer dan 3000 services in productie. Wordt 1.000 keer per dag geïmplementeerd.

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 cloud-native

De snelheid en flexibiliteit van cloudeigen toepassingen zijn afgeleid van veel factoren. Het belangrijkste 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 - binnen enkele minuten ingericht en op verzoek aangepast, geschaald of vernietigd - 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 terwijl de infrastructuur wordt ingeschaald of uitgeschaald, ongeacht op welke machines ze draaien.

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 Twelve-Factor-applicatie

Een algemeen geaccepteerde methodologie voor het bouwen van cloudtoepassingen is de Twelve-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 een webtoepassing, beschouwen veel beoefenaars Twelve-Factor 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 Twelve-Factor methodologie:

Kenmerk	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, waardoor veranderingen kunnen worden doorgevoerd zonder dat dit van invloed is op het hele systeem.
3 - Configuraties	Configuratiegegevens worden uit de microservice gehaald en extern gemaakt via een configuratiebeheertool die buiten de code werkt. Dezelfde implementatie kan worden doorgegeven in omgevingen waarop de juiste configuratie is toegepast.
4 - Ondersteunende Diensten	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 zelfstandig zijn, waarbij de interfaces en functionaliteit op een eigen poort worden blootgesteld. 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 - Wegwerpbaarheid	Service-exemplaren moeten vervangbaar zijn. Geef de voorkeur aan snel opstarten om de schaalbaarheid van het systeem te vergroten en zorg voor zorgvuldige afsluitingen om het in een correcte staat achter te laten. Docker-containers samen met een orchestrator voldoen inherent aan deze vereiste.
10 - Gelijkwaardigheid tussen Ontwikkel- en Productieomgeving	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. Verwerk ze met een gebeurtenisaggregator. Logboekgegevens doorgeven aan hulpprogramma's voor gegevensanalyse/logboekbeheer, zoals Azure Monitor of Splunk, en uiteindelijk aan archivering op lange termijn.
12 - Beheerprocessen	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 beschrijft 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 doe je dat niet. 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 (Azure Goed-Ontworpen Raamwerk)

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 uitstekende 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. Draai 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 veerkracht kunnen workloads zich herstellen van storingen en blijven functioneren. 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 inkapseling van een eigen gegevensopslagtechnologie, 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 werken samen om een toepassing samen te stellen.

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 Twelve-Factor Toepassing, 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.

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 volledige stack microservice-referentiearchitectuur 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 zullen front-end clienttoepassingen communiceren met de kernmicroservices van de back-end? 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 overweegt u mogelijk gedecoupeerd berichtenverkeer met wachtrij- en topictechnologieën?

Communicatie wordt behandeld in het hoofdstuk Cloudeigen communicatiepatronen .

Herstellingsvermogen

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 insteekbare componenten vereenvoudigt het de infrastructuur 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.

figuur 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.

Verpakkingen

Het is gebruikelijk om de term container te horen noemen in een cloud-native gesprek. In het boek Cloud Native Patterns observeert auteur Cornelia Davis dat 'containers een geweldige enabler zijn van cloud-native software'. De Cloud Native Computing Foundation plaatst microservicecontainerisatie als eerste stap in hun Cloud-Native Trail Map - richtlijnen voor ondernemingen die hun cloud-native traject starten.

Het containeriseren van een microservice is simpel en ongecompliceerd. De code, de bijbehorende afhankelijkheden en runtime worden ingepakt in een binair bestand dat een containerafbeelding wordt genoemd. Afbeeldingen worden opgeslagen in een containerregister, dat fungeert als een opslagplaats of bibliotheek voor afbeeldingen. 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 opgeschaald, transformeert u de containerafbeelding in een actieve containerinstantie. Het exemplaar wordt uitgevoerd op elke computer waarop een containerruntime-engine is geïnstalleerd. U kunt zoveel exemplaren van de gecontaineriseerde service 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 principe van afhankelijkheden van de Twelve-Factor-toepassing omarmt.

Factor #2 geeft aan dat "Elke microservice zijn eigen afhankelijkheden isoleert en verpakt, waarbij wijzigingen worden omarmd zonder het hele systeem te beïnvloeden."

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 leidt de softwarecontainerbeweging. 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.

Containerorkestratie

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 grote schaal werkt met veel onafhankelijke draaiende containers, is orchestratie essentieel.

Afbeelding 1-7 toont beheertaken die containerorchestrators automatiseren.

Afbeelding 1-7. Wat containerorchestrators doen

In de volgende tabel worden algemene orkestratietaken 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.
Gezondheidsmonitoring	Fouten automatisch detecteren en corrigeren.
Overgang bij uitval	Automatisch een mislukt exemplaar herconfigureren op een functionele machine.
Opschalen	Automatisch een containerinstantie toevoegen of verwijderen om aan de vraag te voldoen.
Netwerken	Een netwerkoverlay beheren voor containercommunicatie.
Serviceontdekking	Stel containers in staat om elkaar te vinden.
Rolling upgrades	Coördineer geleidelijke updates met implementatie zonder onderbrekingen. Hiermee worden problematische wijzigingen automatisch teruggedraaid.

Let op hoe container-orchestrators de principes Disposability en Concurrency van de Twelve-Factor-toepassing omarmen.

Factor #9 geeft aan dat service-instanties wegwerpbaar moeten zijn, waarbij snelle opstartprocessen worden bevorderd om schaalbaarheidskansen te vergroten en gecontroleerde afsluitingen worden toegepast om het systeem in een correcte staat achter te laten. 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.

Containerorkestratie wordt uitgebreid besproken in Cloud-Native toepassingen opschalen.

Ondersteunende diensten

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 ondersteunende diensten die cloudeigen systemen gebruiken.

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 Twelve-Factor Toepassing, die eerder in het hoofdstuk zijn 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 ondersteunende services in de testomgeving. Vervolgens injecteert u de instellingen in uw container via een omgevingsvariabele.

Cloudleveranciers bieden API's waarmee u kunt communiceren met hun eigen backingservices. Deze bibliotheken encapsuleren de eigen mechanismen 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.

Een laatste overweging is dat de ondersteundiensten ook het statelessheidsprincipe van de Twelve-Factor Toepassing, die eerder in het hoofdstuk is besproken, bevorderen.

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.

Automatisering

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.

Achter de schermen 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 middelen worden beïnvloed.

In het artikel What is Infrastructure as Code beschrijft auteur Sam Guckenheimer hoe "Teams die IaC implementeren stabiele omgevingen snel en op schaal kunnen leveren." Ze vermijden handmatige configuratie van omgevingen en dwingen consistentie af door de gewenste status van hun omgevingen te vertegenwoordigen via code. Infrastructuurimplementaties met IaC zijn herhaalbaar en voorkomen runtimeproblemen die worden veroorzaakt door configuratiedrift 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 Twelve-Factor-toepassing, eerder 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 functionaliteit in hun ontwikkelomgeving en doorloopt de zogenaamde 'interne lus' van coderen, uitvoeren en debuggen.
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