Virtuele machines en containers in de cloud

Een virtuele machine (VM) is een computer die in software is gedefinieerd. Die heeft virtuele processors, geheugen, schijven, een netwerkverbinding en een eigen besturingssysteem. Een hypervisor verdeelt een fysieke server over VM’s en houdt die van elkaar geïsoleerd. Een draaiende VM in de cloud wordt ook een instance genoemd.

Kies de resources

De centrale diensten zijn Amazon EC2, Azure Virtual Machines en Google Compute Engine. Elk verhuurt infrastructuur aan je; jij beheert het besturingssysteem en de applicatie. Dit is infrastructuur als dienst (IaaS).

Bij het starten van een VM maak je verschillende samenhangende keuzes:

• Locatie: een regio en, waar aangeboden, een beschikbaarheidszone.
• Image: een sjabloon met het besturingssysteem en vooraf geïnstalleerde software. AWS noemt dit een Amazon Machine Image (AMI); Azure en Google bieden openbare en eigen images aan.
• Grootte: de vCPU’s, het geheugen en de bijbehorende capaciteit. Een vCPU is de verwerkingseenheid die aan de VM is toegewezen.
• Schijf: persistente opslag waarvan het besturingssysteem opstart.
• Netwerk: een interface in een subnet, plus verkeersregels. Een openbaar IP-adres is optioneel.

AWS gebruikt EBS-volumes, VPC-subnetten en beveiligingsgroepen. Azure gebruikt beheerde schijven, VNet-subnetten en netwerkbeveiligingsgroepen. Google gebruikt persistente schijven, VPC-subnetten en firewallregels. De namen verschillen, maar de resources vervullen vergelijkbare functies.

Volg een startbeslissing

Een team heeft een Linux-webserver in Frankfurt nodig. Het kiest de regio Europe (Frankfurt), een Ubuntu-AMI en m7g.large, met 2 vCPU’s en 8 GiB geheugen. Het voegt een EBS-opstartvolume van 30 GiB toe en verbindt de VM met een VPC-subnet. De beveiligingsgroep staat HTTPS op poort 443 vanaf internet toe en SSH op poort 22 alleen vanaf het kantoornetwerk. Het image biedt het uitgangspunt voor de software; de grootte levert rekencapaciteit; de verkeersregels bepalen wie verbinding kan maken.

Volg de levenscyclus en de rekening

Een VM wordt aangemaakt, draait, kan worden gestopt en gestart en wordt uiteindelijk verwijderd. Er ontstaan kosten voor rekenkracht zolang de VM is toegewezen om te draaien, ook als het CPU-gebruik bijna nul is. Stoppen beëindigt normaal gesproken de kosten voor rekenkracht, maar behouden schijven en gereserveerde openbare IP-adressen kunnen nog steeds geld kosten. Controleer bij Azure op “Stopped (deallocated)”: afsluiten binnen het gastbesturingssysteem kan de VM in de status “Stopped” achterlaten, waarbij nog steeds kosten voor rekenkracht worden gerekend.

Tijdelijke lokale schijven verschillen van persistente opstartschijven. AWS instance store, tijdelijke Azure-schijven en Google Local SSD bewaren gegevens op de fysieke host; als je een VM stopt, verplaatst of de toewijzing ervan opheft, kunnen die gegevens verloren gaan. Zet bestanden die bewaard moeten blijven op persistente opslag. Controleer na het verwijderen van een VM welke betaalde resources zijn behouden. Een beveiligingsgroep op zichzelf brengt geen afzonderlijke kosten met zich mee, terwijl een niet-verwijderde schijf kosten kan blijven opleveren.

Weet wie wat onderhoudt

De cloudaanbieder onderhoudt het datacenter, de fysieke hardware en de hypervisor. Jij werkt het gastbesturingssysteem en de geïnstalleerde software bij, beschermt gegevens en beheert toegang en firewallinstellingen. Door een VM te huren draag je het bijwerken van het gastbesturingssysteem niet over aan de cloudaanbieder.

Een exclusieve host reserveert een fysieke server voor jouw gebruik, wat nuttig is voor licenties die aan fysieke kernen zijn gekoppeld. Een bare-metalinstance biedt toegang tot hardware zonder hypervisorlaag. Azure Virtual Desktop en Amazon WorkSpaces streamen juist desktops die in de cloud worden gehost naar apparaten van gebruikers.

Een instancefamilie bepaalt de verhouding tussen rekenkracht, geheugen, opslag en versnellers. De grootte bepaalt hoeveel je van die resources krijgt. Kies de familie op basis van de belangrijkste behoefte van de workload en kies daarna een grootte die aan alle vereisten voldoet.

Herken de belangrijkste families

Snelle lokale opslag maakt gegevens niet persistent. Een workload die instances gebruikt die voor opslag zijn geoptimaliseerd, heeft nog steeds een plan nodig voor gegevens die het verlies van een host moeten overleven.

Lees de naam

In m7g.large betekent m algemeen gebruik, is 7 de generatie, duidt g op AWS Graviton en is large de grootte. Dezelfde familie groeit van 2 vCPU’s en 8 GiB bij large naar 4 vCPU’s en 16 GiB bij xlarge, en vervolgens naar 8 vCPU’s en 32 GiB bij 2xlarge.

In Azures Standard_D4s_v5 is D de familie, 4 het aantal vCPU’s, duidt s op ondersteuning voor premium SSD en is v5 de versie. Googles e2-standard-4 noemt de E2-serie, de standaardgeheugenverhouding en 4 vCPU’s. Een vCPU is vaak een hardwarethread; bij Graviton is het een hele kern. Beschouw de vCPU van elke cloudaanbieder niet als een identieke fysieke kern.

Werk een keuze voor de grootte uit

Een interne rapportageapp heeft bij piekbelasting 2 vCPU’s en 6 GiB nodig. Vergelijk deze AWS-grootten:

• c7g.large: 2 vCPU’s en 4 GiB; het geheugen is onvoldoende.
• m7g.large: 2 vCPU’s en 8 GiB; beide vereisten passen, met 2 GiB over.
• r7g.large: 2 vCPU’s en 16 GiB; die levert veel meer geheugen dan deze app nodig heeft.

De grootte voor algemeen gebruik is het verstandige uitgangspunt. Het geheugen per vCPU is $8÷2=4$ GiB. De opties die voor rekenkracht en voor geheugen zijn geoptimaliseerd, leveren respectievelijk 2 en 8 GiB per vCPU. Googles E2-typen highcpu, standard en highmem met 4 vCPU’s verschillen op dezelfde manier in geheugen: 4 GB, 16 GB en 32 GB.

Capaciteitsafstemming betekent dat je het werkelijke gebruik meet en de keuze aanpast. Bekijk naast de CPU ook het geheugen-, schijf- en netwerkgebruik voordat je een kleinere grootte kiest. AWS Compute Optimizer, Azure Advisor en Googles aanbevelingen voor machinetypen kunnen helpen. Om de grootte van een bestaande VM te wijzigen moet je die stoppen of herstarten, dus houd rekening met een onderbreking van een app op één server.

Maak onderscheid tussen pieken en onderbreking

AWS T, Azure B en Google E2-typen met gedeelde processorkern en tijdelijke piekcapaciteit zijn geschikt voor rustige workloads met korte pieken. AWS T en Azure B verdienen CPU-credits onder een basisniveau en verbruiken die erboven. Als de credits op zijn, keren Azure B en AWS T in de standaardmodus terug naar het basisniveau; huidige AWS T-typen gebruiken standaard de onbeperkte modus en kunnen extra CPU-gebruik in rekening brengen.

Spot-VM’s gebruiken ongebruikte capaciteit die de cloudaanbieder op korte termijn kan terugnemen. Ze passen bij opnieuw te starten batchwerk waarvan de voortgang wordt opgeslagen. Eén productiedatabase is een slechte combinatie. Googles oudere onderbreekbare VM’s hebben ook een maximale levensduur van 24 uur; die limiet is niet de bepalende regel voor moderne Spot-VM’s.

Een dienst heeft met twee verschillende problemen te maken: er komt meer werk binnen en apparatuur valt uit. Schalen verandert de capaciteit. Hoge beschikbaarheid houdt de dienst bruikbaar wanneer onderdelen uitvallen. Een ontwerp kan het ene probleem oplossen en het andere onopgelost laten.

Verander de grootte of het aantal

Bij verticaal schalen verander je de grootte van één machine: bijvoorbeeld van 2 vCPU’s en 8 GiB naar 8 vCPU’s en 32 GiB. Verticaal opschalen voegt resources toe; verticaal afschalen verwijdert ze. Het is een directe manier om een bestaande applicatie meer capaciteit te geven, maar de machine moet meestal herstarten, de grootste grootte is begrensd en de machine blijft één punt dat kan uitvallen.

Bij horizontaal schalen verander je het aantal kopieën. Drie webservers kunnen er negen worden en daarna weer drie. Horizontaal opschalen voegt instances toe; horizontaal afschalen verwijdert ze. Een loadbalancer verdeelt webverzoeken, terwijl achtergrondwerkers taken uit een gedeelde wachtrij kunnen halen. De applicatie moet ondersteunen dat meerdere kopieën samen nuttig werk doen. Een gedeelde database kan de doorvoersnelheid nog steeds beperken of uitvallen, ook als veel webservers gezond blijven.

Schaalbaarheid is het vermogen om meer werk aan te kunnen door resources toe te voegen. Elasticiteit is automatisch en tijdig groeien en krimpen als de vraag verandert. Een winkel die automatisch wisselt van 4 servers ’s nachts naar 20 tijdens een uitverkoop, is elastisch. Een vaste groep met reservecapaciteit kan een hoge beschikbaarheid hebben zonder elastisch te zijn.

Maak kopieën vervangbaar

Een toestandsloze applicatie-instance bewaart geen unieke gegevens die een later verzoek nodig heeft. Sla winkelwagentjes, sessies en geüploade bestanden op in een gedeelde database, cache of opslagdienst. Dan kan een verzoek elke instance bereiken en kun je bij horizontaal afschalen een instance verwijderen zonder de winkelwagentjes van gebruikers te verliezen.

Een winkelwagentje dat alleen in het geheugen van één webserver wordt bewaard, verdwijnt bijvoorbeeld wanneer die server wordt beëindigd. De gebruiker via sessieaffiniteit op die server houden, beschermt het winkelwagentje niet tegen uitval van de server. Door het winkelwagentje naar gedeelde opslag te verplaatsen, verandert wat je veilig kunt verwijderen.

Houd voldoende capaciteit over na uitval van een zone

Beschikbaarheidszones zijn afzonderlijke locaties binnen een regio met onafhankelijke stroomvoorziening, koeling en netwerken. Instances over zones verdelen beschermt tegen uitval van een hele zone. Meerdere instances in één zone delen nog steeds het risico van die zone.

Stel dat een applicatie de capaciteit van 4 instances moet behouden nadat één willekeurige van 3 zones uitvalt. De twee overgebleven zones moeten elk 2 instances leveren:

Laat in elke zone 2 instances draaien, in totaal 6. Als een willekeurige zone uitvalt, blijven er 4 over. Dit is reservecapaciteit voor uitval, geen verhoging van de normale capaciteitsbehoefte van de workload. Een loadbalancer stuurt verzoeken naar de overgebleven instances; elke gedeelde gegevensdienst heeft ook passende beschikbaarheid nodig.

Herken Azure-beschikbaarheidssets

Een beschikbaarheidsset verdeelt VM’s binnen één datacenter over foutdomeinen voor hardware en updatedomeinen voor onderhoud. Een foutdomein deelt hardware zoals stroomvoorziening en netwerkswitches. Sets ondersteunen maximaal 3 foutdomeinen; updatedomeinen staan standaard op 5 en kunnen oplopen tot 20. Ze verkleinen de risico’s van uitval van racks en geplande herstarts. Zones beschermen tegen het grotere risico dat een hele datacenterlocatie onbeschikbaar wordt.

Automatisch schalen voegt instances toe en verwijdert ze als de vraag verandert. Amazon EC2 Auto Scaling gebruikt Auto Scaling-groepen, Azure gebruikt Virtual Machine Scale Sets met regels voor automatisch schalen en Google gebruikt beheerde instancegroepen met een automatische schaalfunctie.

Begin met een herhaalbaar sjabloon

Een nieuwe instance heeft hetzelfde image, dezelfde grootte, netwerkinstellingen en opstartinstructies nodig als de andere instances. AWS gebruikt een startsjabloon, Azure een VM-model voor de schaalset en Google een instancesjabloon. Een wijziging die je handmatig binnen één draaiende VM maakt, verdwijnt wanneer die VM wordt vervangen, tenzij de wijziging is opgenomen in de herhaalbare inrichting.

De groep heeft drie capaciteitsinstellingen:

• Minimum: de ondergrens die de groep handhaaft.
• Gewenst: het aantal dat de groep op dat moment probeert te laten draaien.
• Maximum: de bovengrens die de groep niet mag overschrijden.

Bij minimum 2, gewenst 4 en maximum 10 streeft de groep naar 4 instances. Beleidsregels kunnen de gewenste capaciteit van 2 tot en met 10 aanpassen. Het maximum staat groei toe; als je het op 10 zet, draaien er niet vanzelf 10 VM’s en betaal je daar niet vanzelf voor. Het begrenst het aantal instances, niet alle kosten in de applicatie.

Kies wat een wijziging veroorzaakt

Schalen op basis van een streefwaarde probeert een meetwaarde dicht bij een doel te houden, zoals gemiddeld 50% CPU-gebruik. Stapsgewijs of regelgebaseerd schalen verandert de capaciteit wanneer een drempel wordt overschreden, bijvoorbeeld door 2 instances toe te voegen nadat de CPU-belasting 5 minuten boven 70% blijft. Gepland schalen stelt de capaciteit op bekende tijden in. Voorspellend schalen voorspelt de vraag op basis van eerdere patronen en bereidt de capaciteit vooraf voor.

Bij een dagelijkse drukte om 08.00 uur is het verstandig instances vóór 08.00 uur gereed te maken. Als je wacht op een alarm voor hoge CPU-belasting, is de drukte al begonnen terwijl de extra VM’s nog opstarten.

Bereken de capaciteit bij een streefwaarde

Vier identieke instances hebben gemiddeld 80% CPU-belasting en de streefwaarde is 50%. Tel voor een vereenvoudigde schatting bij constante belasting eerst het werk op in instanceprocentpunten:

Deel door de streefwaarde per instance:

Rond naar boven af op 7 instances, omdat bij 6 het gemiddelde boven de streefwaarde zou blijven. Bij 7 is de schatting $320÷7\approx \mathrm{45,7}\mathrm{\%}$. Als het maximum van de groep 6 is, stopt die daar en komt het gemiddelde op ongeveer 53,3%.

Maak onderscheid tussen gereed zijn en herstel na uitval

Een VM heeft tijd nodig om op te starten, opstarttaken uit te voeren en statuscontroles te doorstaan. Een opwarmperiode voorkomt dat onvolledige metingen van een nieuwe instance een schaalbeslissing vertekenen. Een afkoelperiode beperkt snelle wijzigingen heen en weer.

Schaalgroepen kunnen ook uitgevallen VM’s vervangen om de gewenste capaciteit te herstellen. Controles op applicatieniveau en herstelacties moet je configureren: een VM kan draaien terwijl de webapplicatie defect is. Bij Azure kan een herstelactie herstarten, opnieuw een image plaatsen of vervangen; Google noemt herstel autohealing. Een loadbalancer kan een defecte app detecteren, maar de schaalgroep moet zijn geconfigureerd om die informatie voor herstel te gebruiken.

Horizontaal afschalen verwijdert instances. Bewaar loggegevens centraal en blijvende gegevens buiten hun lokale bestanden, zodat het verwijderen van een gezonde kopie geen unieke informatie verwijdert.

Een loadbalancer geeft clients één toegangsadres en stuurt inkomend verkeer door naar gezonde servers. AWS noemt de servergroep een target group; Azure gebruikt een backend pool; Google gebruikt een backend service. Clients hebben niet telkens een nieuw adres nodig wanneer de groep verandert.

Routeer verkeer en detecteer storingen

Een statuscontrole test herhaaldelijk een doel, bijvoorbeeld door elke 10 seconden /health op te vragen. Na voldoende mislukte controles krijgt het doel de status ongezond en ontvangt het geen nieuw verkeer totdat het weer een controle doorstaat. Detectie kost tijd omdat de controles met tussenpozen plaatsvinden.

Routering en herstel zijn verschillende taken. De loadbalancer stopt met het sturen van nieuwe verzoeken naar een uitgevallen doel. Een schaalgroep of beheerder repareert of vervangt die server. Alleen een loadbalancer toevoegen levert geen extra verwerkingscapaciteit voor de applicatie op.

Round-robinverdeling neemt gezonde doelen om de beurt. Verdeling op basis van het kleinste aantal verbindingen of uitstaande verzoeken geeft de voorkeur aan het doel met minder werk in uitvoering. Routering op basis van een hash koppelt verbindingsgegevens, waaronder adressen en poorten, aan een doel. Eén verbinding blijft bij hetzelfde doel, maar een nieuwe verbinding van dezelfde gebruiker kan elders terechtkomen.

Sessieaffiniteit houdt de verzoeken van een gebruiker bij één server. Dit kan een applicatie met lokale sessies ondersteunen, maar verdeelt het verkeer minder gelijkmatig en stelt sessies bloot aan uitval van die server. Met gedeelde sessieopslag kunnen andere gezonde servers het werk van de gebruiker voortzetten.

Bereken het effect van uitval van een server

Drie gezonde servers delen 900 verzoeken per minuut gelijkmatig. Elk verwerkt:

Eén server doorstaat de statuscontroles niet. Hetzelfde werk gaat nu naar twee servers:

Als elke server slechts 400 verzoeken per minuut aankan, blijft er ondanks routering naar gezonde servers een overbelasting. De groep heeft reservecapaciteit of meer instances nodig. Automatisch schalen verandert de capaciteit; een loadbalancer verdeelt die.

Kies de laag die bij de routering past

Een dienst op laag 7 kan ook TLS termineren, waarbij HTTPS bij het toegangspunt wordt ontsleuteld, en kan samenwerken met een webapplicatiefirewall. Een dienst op laag 4 bekijkt geen HTTP-pad om de achterliggende server te kiezen. Controleer welke transportprotocollen een bepaald product ondersteunt.

AWS Elastic Load Balancing biedt Application Load Balancers op laag 7, Network Load Balancers op laag 4 en Gateway Load Balancers voor netwerkapparaten, binnen een regio. Azure Load Balancer werkt op laag 4; Application Gateway is regionaal en werkt op laag 7; Front Door biedt een wereldwijd toegangspunt op laag 7. Google Cloud Load Balancing biedt Application en Network Load Balancers in regionale en wereldwijde varianten.

Verbind routering met schalen

Als de integratie is geconfigureerd, melden nieuwe instances van de groep zich aan als doelen en ontvangen ze verkeer zodra ze gezond zijn. Tijdens het verwijderen krijgen actieve verzoeken de tijd om te worden afgerond doordat verbindingen uitlopen voordat een doel verdwijnt. Een uitrol over meerdere zones routeert tijdens een storing naar gezonde zones, mits de overgebleven zones voldoende capaciteit hebben. Zelfs twee servers hebben baat bij dit gedeelde toegangspunt en routering op basis van de status.

Een container voert een applicatie en de afhankelijkheden ervan uit als een geïsoleerd proces op een host. Door de bibliotheken en uitvoeringsomgeving te verpakken, kun je de geteste software op dezelfde manier in productie uitvoeren.

Image, register en draaiende kopie

Een image is het alleen-lezen-sjabloon; een register bewaart en verspreidt images; een container is een draaiende kopie. Amazon ECR, Azure Container Registry en Google Artifact Registry bieden registers. Het Open Container Initiative bepaalt standaardimageformaten; Docker hielp het gebruik ervan populair te maken.

Een team verpakt bijvoorbeeld zijn Python-API voor bestellingen als orders-api:1.4, test die, stuurt het image naar een register en start vanuit dat image 3 productiecontainers. Omgevingsinstellingen en toegang tot externe diensten moet het team nog steeds configureren.

Deel een kernel in plaats van een gastbesturingssysteem op te starten

Elke VM heeft een volledig gastbesturingssysteem achter een hypervisor. Containers delen de kernel van de host, de kern van het besturingssysteem die resources en processen beheert. Ze hoeven minder software mee te nemen en te starten: images zijn vaak tientallen of honderden megabytes groot en het opstarten duurt enkele seconden of korter. VM-images zijn doorgaans gigabytes groot en VM’s starten in enkele minuten op. Een host kan daardoor meer containers dan volledige VM’s uitvoeren.

Delen beïnvloedt ook de isolatie. Een fout in de kernel van de host kan meerdere containers raken, terwijl afzonderlijke gastkernels VM’s een sterkere afbakening geven. Linux-containers hebben een Linux-kernel nodig; Windows-containers hebben Windows nodig. Het image moet ook bij de processorarchitectuur passen, zoals x86 of Arm. Containers draaien vaak op VM’s in de cloud.

Vervang software en bewaar gegevens

Werk een container bij door een gecorrigeerd image te bouwen en oude kopieën te vervangen. Een handmatig aangebrachte update verdwijnt bij vervanging en laat andere replica’s ongewijzigd.

Hetzelfde geldt voor bestanden die tijdens de uitvoering in de beschrijfbare laag ontstaan. Een factuur die daar wordt gegenereerd, moet vóór vervanging op een persistent volume of in een opslagdienst worden opgeslagen. Het imageregister bewaart applicatiepakketten, geen documenten die draaiende containers maken.

Splits diensten op wanneer dat helpt

Een monoliet wordt als één geheel uitgerold. Microservices splitsen een app op in via het netwerk verbonden diensten die afzonderlijk worden uitgerold en geschaald. Een winkel kan containers voor de betalingsdienst toevoegen zonder kopieën van de catalogusdienst toe te voegen.

Een orkestratiesysteem plaatst containers op hosts, herstart uitgevallen kopieën, schaalt ze, rolt versies uit en verbindt diensten. Kubernetes doet dit, net als eenvoudigere beheerde containerdiensten. Containers vereisen geen Kubernetes.

Kubernetes rolt containers uit en beheert ze over een groep machines die een cluster wordt genoemd. Het is opensourcesoftware, is bij Google ontstaan en wordt onderhouden binnen de Cloud Native Computing Foundation. Hetzelfde platform kan in verschillende clouds en private datacenters draaien.

Begrijp de onderdelen van het cluster

De besturingslaag bewaart de configuratie, plant werk in en coördineert het cluster. Werkknooppunten, meestal VM’s, leveren de rekenkracht en het geheugen die containers gebruiken.

Een pod is de kleinste eenheid die Kubernetes inplant. Die bevat één of meer containers die een netwerkadres delen en samen op één knooppunt blijven. Een pod is geen afzonderlijke VM. Meerdere pods kunnen hetzelfde werkknooppunt delen als hun resourcebehoeften passen.

Je geeft een gewenste toestand op: bijvoorbeeld 3 replica’s van orders-api:1.4. Kubernetes probeert 3 pods draaiende te houden. Als een pod uitvalt, maakt Kubernetes een vervanger; na uitval van een knooppunt kunnen vervangende pods draaien op overgebleven knooppunten met beschikbare capaciteit. Een Kubernetes Service biedt een stabiele naam en een stabiel adres om pods te bereiken, ook als hun afzonderlijke adressen veranderen.

Schaal pods en machines afzonderlijk

Een horizontale podautoscaler (HPA) verandert het aantal pods op basis van meetwaarden zoals de CPU-vraag. Een clusterautoscaler verandert de knooppuntcapaciteit wanneer pods niet passen of knooppunten overbodig worden. Pods toevoegen zonder ruimte om ze uit te voeren leidt tot wachtend werk, niet tot meer verwerkingscapaciteit.

Stel dat elke pod 0,5 vCPU aanvraagt en elk knooppunt 2 vCPU’s beschikbaar heeft voor pods. Laat in dit voorbeeld andere resourcelimieten buiten beschouwing. Op één knooppunt passen:

Als de HPA het gewenste aantal verhoogt naar 10 pods, passen er op twee knooppunten maar 8. Nodig zijn:

Rond naar boven af op 3 knooppunten. Het derde knooppunt biedt ruimte aan de laatste 2 pods. Gebruik de capaciteit die beschikbaar is voor pods, want het besturingssysteem en de Kubernetes-onderdelen van het knooppunt hebben ook resources nodig. Bij het daadwerkelijk inplannen zijn naast de CPU ook geheugen en plaatsingsregels van belang.

Verdeel de beheerverantwoordelijkheden

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) en Google Kubernetes Engine (GKE) voeren beheerde besturingslagen uit. De cloudaanbieder onderhoudt die besturingslaag, inclusief de beschikbaarheid en updates. Jij beheert images, applicatie-instellingen, toegang en resourceaanvragen van workloads. In veel modi beheer je ook de keuze en updates van werkknooppunten. Clusterkosten kunnen losstaan van de kosten voor knooppunten.

Bij GKE Standard maak je zelf de keuzes voor knooppunten en betaal je voor de VM’s van de knooppunten. GKE Autopilot richt knooppunten in en beheert ze en rekent doorgaans kosten voor de aangevraagde podresources. EKS kan geschikte pods uitvoeren op AWS Fargate, zodat je de VM’s van de knooppunten niet beheert. Deze modi verminderen het beheerwerk en beperken tegelijk sommige keuzes voor de host.

Bepaal of de complexiteit helpt

Kubernetes past bij veel onafhankelijk uitgerolde diensten en teams die een gemeenschappelijk platform bij verschillende cloudaanbieders nodig hebben. De hulpmiddelen en workloaddefinities verbeteren de overdraagbaarheid, al kunnen gekoppelde clouddatabases, identiteitssystemen en netwerken nog steeds aanpassingen vereisen.

Voor één eenvoudige webapp kan een hostingplatform of serverloze containerdienst minder werk kosten. Beheerde Kubernetes verhelpt geen fout in je image en kiest niet de juiste geheugenaanvraag voor je. Als een app herhaaldelijk geheugen tekortkomt, moet het team de app en de instellingen onderzoeken, ook wanneer de besturingslaag volledig wordt beheerd.

Serverloze containerdiensten voeren je images uit op hosts die de cloudaanbieder beheert. Je kiest nog steeds resources, onderhoudt het image en configureert de app. Schalen en facturering hangen af van de dienst.

Maak onderscheid tussen orkestratie en rekenkracht

Amazon ECS orkestreert containers als taken. Een ECS-service houdt een gewenst aantal taken in stand, eventueel achter een loadbalancer. Taken draaien op EC2-hosts die je zelf beheert of op rekenkracht van Fargate.

Fargate ondersteunt ook geschikte EKS-pods. Je kiest de vCPU’s en het geheugen voor de taak of pod en betaalt zolang die resources draaien; je kiest, onderhoudt of schaalt de onderliggende EC2-hosts niet. Automatisch schalen van ECS-services gebruikt beleidsregels die je zelf configureert. Fargate levert rekenkracht, niet het gewenste aantal taken van de applicatie. ECS op EC2 biedt meer controle over de host en instancefamilie, met meer beheerwerk.

Vergelijk de diensten van Azure en Google

Azure Container Instances (ACI) start één container of een kleine groep zonder cluster en rekent per seconde af. Het is geschikt voor tests en eenvoudige taken met een eindpunt, maar heeft geen ingebouwde functie voor automatisch schalen.

Azure Container Apps onttrekt het onderliggende Kubernetes-platform aan het zicht. Geconfigureerde regels schalen gecontaineriseerde apps op basis van HTTP-verkeer of gebeurtenissen, bij geschikte workloads ook terug naar nul.

Google Cloud Run biedt services voor inkomende verzoeken en taken die tot voltooiing worden uitgevoerd. Services kunnen vanaf nul groeien en weer krimpen. Facturering van rekenkracht op basis van verzoeken omvat de verwerking van verzoeken plus het opstarten en afsluiten. Zonder minimuminstances en zonder draaiende instances kost inactieve rekenkracht niets; databases en opgeslagen images kunnen nog wel kosten opleveren. Cloud Run host ook Cloud Run functions, die beginnen met functiecode in plaats van een door de klant aangeleverd app-image.

Weeg besparingen bij inactiviteit af tegen opstartvertraging

Een interne reserverings-API is op werkdagen druk van 08.00 tot 18.00 uur: 10 uur op 5 dagen, oftewel 50 van de 168 uur per week. Ook ’s nachts komen af en toe verzoeken binnen. Cloud Run of Container Apps kan tijdens pieken meerdere kopieën uitvoeren en in rustige perioden tussen verzoeken terugschalen naar nul.

Een verzoek na een periode van inactiviteit moet mogelijk wachten op een koude start. Door minimaal één instance warm te houden, verminder je de vertraging binnen de capaciteit van die instance, maar ontstaan doorlopende kosten. Bij een piek boven die capaciteit kunnen extra instances nog steeds koud starten.

Kies de controle over de host die je nodig hebt

Deze diensten beperken de toegang tot de host en stellen limieten aan resources en duur. Je kunt geen hostagents installeren of de hostkernel wijzigen. VM’s of geschikte Kubernetes-knooppunten passen bij die behoeften. Voor standaard gecontaineriseerde API’s kunnen eenvoudigere diensten het werk van Kubernetes-beheer voorkomen; ACI is een directe optie voor een eenvoudige containergroep.

Een serverloze functie is code die wordt uitgevoerd wanneer een passende gebeurtenis binnenkomt. De cloudaanbieder beheert de servers en de beheerde uitvoeringsomgeving. AWS Lambda, Azure Functions en Google Cloud Run functions bieden dit model van functie als dienst (FaaS) aan.

Verbind een trigger met een functieaanroep

Een trigger start één uitvoering, een functieaanroep genoemd. Triggers zijn onder meer HTTP-verzoeken, geüploade bestanden, wachtrijberichten, databasewijzigingen en tijdschakelaars. Een fotoupload kan een functie activeren die een miniatuur van 200 pixels maakt en in opslag bewaart. Zonder uploads hoeft er bij een uitrol op aanvraag geen rekenkracht voor functies actief te zijn.

De cloudaanbieder schaalt de uitvoering wanneer gebeurtenissen binnenkomen, binnen de limieten voor gelijktijdigheid en van de dienst. Veel gelijktijdige functies kunnen veel databaseverbindingen openen. De functielaag kan ruimte hebben om te schalen terwijl de database dat niet heeft. Beperk de gelijktijdigheid tot wat verbonden systemen aankunnen.

Functies zijn toestandsloos tussen functieaanroepen. Een latere aanroep kan een nieuwe omgeving gebruiken en kan dus niet afhankelijk zijn van het geheugen of tijdelijke bestanden van een eerdere aanroep. Bewaar tellers, sessies en blijvende resultaten in een database, cache of objectopslag. Een warme omgeving kan opnieuw worden gebruikt, maar dat hergebruik garandeert niet dat gegevens bewaard blijven.

Bereken het verbruik

De standaardfacturering op aanvraag van Lambda combineert het aantal functieaanroepen met GB-seconden (GB-s): toegewezen geheugen in GB vermenigvuldigd met de uitvoeringstijd in seconden. Neem voor een voorbeeldberekening aan dat elk van de 3.000.000 functieaanroepen 0,2 seconde draait met 0,5 GB geheugen. Laat gratis tegoeden en alle andere diensten buiten beschouwing.

Bij aangenomen prijzen van 0,0000167 Amerikaanse dollar per GB-s en 0,20 Amerikaanse dollar per miljoen verzoeken kost rekenkracht 5,01 Amerikaanse dollar en kosten verzoeken 0,60 Amerikaanse dollar, samen 5,61 Amerikaanse dollar. Dit zijn aangenomen prijzen om het model te leren. Cloud Run functions meet ook de CPU; Azure-abonnementen kunnen kosten rekenen voor gereedstaande of toegewezen instances.

Bij 100.000.000 verder identieke functieaanroepen is het verbruik 10.000.000 GB-s: 167 Amerikaanse dollar voor rekenkracht plus 20 Amerikaanse dollar voor verzoeken tegen die aangenomen tarieven. Een VM met een aangenomen prijs van 0,04 Amerikaanse dollar per uur kost 29,20 Amerikaanse dollar voor 730 uur, maar een eerlijke vergelijking controleert ook of die hetzelfde werk kan verwerken en neemt het beheerwerk mee. Bij een vraag met pieken is het gunstig om ongebruikte capaciteit te vermijden; bij een constante belasting kan rekenkracht die altijd aanstaat gunstig zijn.

Controleer uitvoeringslimieten en opstartvertraging

Met standaardrekenkracht van Lambda mag een functieaanroep maximaal 15 minuten duren en maximaal 10.240 MB geheugen gebruiken. Een conversie van 40 minuten past niet in die aanroep. Een containertaak, VM of kortere stappen kunnen wel passen; regels voor de maximale uitvoeringstijd verschillen bij andere abonnementen en rekenmodi.

Een koude start treedt op wanneer een nieuwe uitvoeringsomgeving moet worden voorbereid, na een periode van inactiviteit of tijdens horizontaal opschalen. Opnieuw gebruikte warme omgevingen starten sneller. Vooraf ingerichte uitvoeringscapaciteit bij Lambda, altijd gereedstaande instances bij Azure Premium of Flex Consumption en minimuminstances bij Cloud Run verminderen opstartvertraging tegen extra kosten.

De cloudaanbieder onderhoudt servers en de beheerde uitvoeringsomgeving. Jij herstelt nog steeds je code en meegeleverde bibliotheken, beschermt geheimen, configureert machtigingen en beveiligt gegevens. Serverloze gegevensverwerking neemt het serverbeheer weg, niet de verantwoordelijkheid voor de applicatie.

Een applicatiehostingplatform neemt je code of containerimage en levert de infrastructuur om die uit te voeren. Het is platform als dienst (PaaS): het platform biedt uitrol, statusbewaking, serverbeheer en schalen, terwijl jij de applicatie bouwt.

Vergelijk de belangrijkste platforms

AWS Elastic Beanstalk maakt gewone AWS-resources voor je app aan, meestal EC2-instances in een Auto Scaling-groep achter een Elastic Load Balancer. Het verzorgt uitrol en statusbewaking. Beanstalk zelf heeft geen extra dienstkosten; je betaalt voor de resources die het aanmaakt. Die resources blijven zichtbaar in je account en je kunt de configuratie aanpassen.

Azure App Service host webapps, API’s en mobiele backends vanuit code of containers. Een App Service-plan bepaalt de regio, de instancegrootte en het aantal instances. Apps in dat plan delen die instances. Bij exclusieve abonnementslagen betaal je voor het plan, ook als de apps rustig zijn. Functies zoals automatisch schalen en implementatiesleuven hangen af van de gekozen abonnementslaag.

Google App Engine heeft een standaard- en een flexibele omgeving. Standaard gebruikt ondersteunde uitvoeringsomgevingen in een afgeschermde omgeving en kan met passend automatisch schalen terugschalen naar nul. Flexibel voert containers uit op Compute Engine-VM’s, staat meer aanpassingen toe en houdt minimaal één instance draaiende. Cloud Run is een andere manier om een app te hosten die al als container is verpakt.

Breng veilig een nieuwe versie uit

Een winkelteam van twee personen gebruikt een App Service-abonnementslaag met implementatiesleuven. Het laat 2 instances draaien en rolt een nieuwe versie uit naar een acceptatiesleuf, een afzonderlijke plek om de versie te testen voordat klanten die gebruiken. Na het testen wisselt het team acceptatie en productie om. De oude versie blijft in de andere sleuf beschikbaar om eventueel terug te zetten.

Tijdens een uitverkoop verhoogt de geconfigureerde regel voor automatisch schalen het aantal in het plan naar 5 instances nadat de gemiddelde CPU-belasting boven 70% blijft, en brengt het terug naar 2 als de vraag daalt. Het platform voert het schalen uit, maar het team kiest nog steeds het plan, de regels en de limieten. Het installeert nooit het besturingssysteem van de host of de webserver.

Houd de juiste verantwoordelijkheden

Je onderhoudt op elk platform code, meegeleverde bibliotheken, instellingen, geheimen, gegevens en toegang. App Service en App Engine onderhouden het besturingssysteem van hun host en de beheerde uitvoeringsomgeving. Beanstalk staat meer aanpassingen aan EC2 toe; AWS publiceert platformupdates en jij past die toe of schakelt beheerde platformupdates in. Extra software die je installeert, heeft ook onderhoud nodig.

Een platform verschilt van SaaS. Bij PaaS rol je de app uit die je bouwt; bij SaaS gebruik je de voltooide applicatie van iemand anders, zoals een e-mailpakket. Platformspecifieke instellingen en dienstintegraties kunnen een latere overstap naar een andere cloudaanbieder ook moeilijker maken.

Voorzie in eenvoudigere hostingbehoeften

Amazon Lightsail bundelt een virtuele privéserver, opslag en gegevensoverdracht in een voorspelbaar maandpakket. Het is geschikt voor kleine websites, maar brengt nog steeds VM-verantwoordelijkheden mee. Een statische site bestaat uit bestanden zoals HTML, CSS, JavaScript en afbeeldingen. AWS Amplify Hosting, Azure Static Web Apps en Firebase Hosting kunnen die bestanden wereldwijd leveren zonder dat je een webserver hoeft te onderhouden. Een app die volledige controle over het besturingssysteem van de host vereist, hoort thuis op VM’s.

Vergelijk rekenmodellen voor dezelfde workload. Controleer controle, beheerinspanning, opstarttijd, facturering, limieten en overdraagbaarheid.

Wie onderhoudt wat?

Gegevens en toegang blijven in alle gevallen de verantwoordelijkheid van de klant. Bij Elastic Beanstalk moet je ook kiezen hoe platformupdates worden toegepast.

Vergelijk verkeer en bruikbare capaciteit

Een VM heeft meestal een minuut of langer nodig om op te starten en controles te doorstaan; een container start vaak binnen enkele seconden; een warme functie kan binnen milliseconden beginnen. Een nieuwe omgeving kan vertraging door een koude start toevoegen. Warme capaciteit vermindert die vertraging tegen doorlopende kosten.

Een directorydienst die ’s nachts weinig wordt gebruikt, kan baat hebben bij terugschalen naar nul; een constante vraag kan gunstig zijn voor toegewezen rekenkracht. Vergelijk vóór de maandtotalen een gelijkwaardige doorvoersnelheid, hoeveelheid geheugen en gelijktijdigheid: één goedkope VM kan mogelijk niet hetzelfde werk aan als veel gelijktijdige functieaanroepen. Neem ook de beheerinspanning mee.

Voor VM’s en exclusieve hostingplannen betaal je gedurende de toegewezen tijd, of ze nu actief of inactief zijn. De standaardfacturering op aanvraag van Lambda combineert verzoeken en GB-seconden; andere functieabonnementen gebruiken andere meeteenheden. Nul instances neemt kosten voor inactieve rekenkracht alleen weg als er geen betaald minimum overblijft. Opslag en databases kunnen nog steeds kosten opleveren.

Controleer limieten en verplaatsing tussen platforms

Langlopende processen passen bij VM’s of geschikte containers. Eén Lambda-functieaanroep met standaardrekenkracht is beperkt tot 15 minuten, dus een ononderbroken taak van twee uur heeft een andere compatibele uitvoeringsoptie nodig. Functies kunnen er niet op rekenen dat lokale toestand tussen aanroepen bewaard blijft; vervangbare containers en VM’s in een schaalgroep hebben ook externe opslag voor blijvende gegevens nodig.

Volledige controle over het gastbesturingssysteem, kernelwijzigingen en gespecialiseerde gelicentieerde software wijzen op VM’s. Veel onafhankelijk uitgerolde diensten kunnen Kubernetes rechtvaardigen. Standaardwebapps passen vaak bij hostingplatforms; korte gebeurtenistaken passen bij functies.

Containerimages kunnen tussen compatibele hosts worden verplaatst en Kubernetes biedt gemeenschappelijke uitrolhulpmiddelen in verschillende clouds. Databases, identiteit en netwerken kunnen nog steeds aanpassingen nodig hebben. VM-migratie hangt af van de formaten en hulpmiddelen van de cloudaanbieder; functies en platforms zijn sterker verbonden met diens instellingen en triggers. Verschillende onderdelen kunnen verschillende modellen gebruiken.

Controleer eerst de vereisten die een optie kunnen uitsluiten. Vergelijk daarna verkeer, kosten en teamvaardigheden.

Zoek de doorslaggevende beperking

1. Controleer toegang tot het gastbesturingssysteem, speciale software, hardware en licenties.
2. Controleer bij kort werk dat door gebeurtenissen wordt geactiveerd de functieduur, toestand en gelijktijdigheid.
3. Vergelijk bij gecontaineriseerde apps de controle van Kubernetes met eenvoudigere beheerde diensten.
4. Overweeg voor standaardwebapps die als code worden uitgerold een hostingplatform.
5. Controleer opstartvertraging, verkeerspatronen, resourcelimieten en totale beheerkosten.

Koppel de bedrijfssituaties aan een oplossing

Een leverancier ondersteunt een boekhoudapp alleen op Windows Server, met een licentie op basis van kernen. VM’s behouden die omgeving; gebruik een exclusieve host als licenties op basis van fysieke kernen dat vereisen. Kopieën over meerdere zones vereisen een compatibel applicatie- en gegevensontwerp. Grotendeels ongewijzigd verplaatsen heet verplaatsing naar cloudinfrastructuur zonder aanpassingen, of verplaatsen zonder aanpassingen (lift and shift), en laat het onderhoud van het gastbesturingssysteem bij jou.

Het aantal fotouploads stijgt van enkele per nacht tot duizenden per minuut. Korte onafhankelijke taken voor miniaturen passen bij functies die door uploads worden geactiveerd. Ze schalen mee met de binnenkomende uploads; controleer koude starts, tijdslimieten en de capaciteit van achterliggende diensten.

Een winkel heeft 30 microservices, 6 teams en vereist een platform voor twee clouds. Beheerde Kubernetes levert gemeenschappelijke orkestratiehulpmiddelen. Een start-up met 3 diensten en zonder Kubernetes-ervaring kan Cloud Run, Container Apps of ECS met Fargate gebruiken en blijft verantwoordelijk voor images en apps zonder hostbeheer.

Het bureau van een museum bouwt een kaartverkoopwebsite, maar heeft geen beheerders. Een hostingplatform levert uitrolhulpmiddelen en schaalt voor openingsdagen. App Service en App Engine onderhouden hosts; bij Beanstalk moet je een keuze voor platformupdates maken, zoals beheerde updates.

Een nachtelijk rapport van twee uur past bij een containertaak of VM met een geschikte uitvoeringslimiet, niet bij één Lambda-functieaanroep met standaardrekenkracht. Spot kan kosten verlagen als de taak de voortgang opslaat en na onderbreking wordt hervat.

GPU-modeltraining van meerdere dagen vereist VM’s met versnellers of geschikte Kubernetes-GPU-knooppunten. Opgeslagen controlepunten maken Spot praktisch doordat minder voortgang verloren gaat.

Leg een gefaseerde keuze uit

Een bedrijf kan applicaties eerst zonder aanpassingen verplaatsen om snel het datacenter te verlaten en daarna geselecteerde onderdelen moderniseren met containers, hostingplatforms of functies. Alleen verplaatsen zonder aanpassingen behoudt de oude manier van beheren.

Bijvoorbeeld: “Gebruik Cloud Run omdat de API al in een container zit, het verkeer ’s nachts stopt en het team geen serverbeheerder heeft; houd rekening met een koude start na inactiviteit.”