Cloud-native development: software die voor de cloud is ontworpen

Made with AI

Bij cloud-native development gaat het er niet om waar je software draait, maar om hoe ze gebouwd is. Een applicatie die voor servers on-premises is ontworpen en naar de cloud is verhuisd, is niet cloud-native. Ze wordt alleen ergens anders gehost.

Bij cloud-native development worden applicaties zo ontworpen dat ze in de cloud draaien, schalen en zich herstellen. Daar horen andere tools bij, een andere manier van werken en een andere houding tegenover storingen.

Wat is cloud-native development?

Cloud-native development is applicaties bouwen met containers, automatisering en managed services, zodat ze alles benutten wat cloudinfrastructuur te bieden heeft.

Hoe wordt cloud-native development gebruikt? Het is het geheel van werkwijzen en tools waarmee een cloud-native architectuur werkelijkheid wordt. Zonder die werkwijzen blijft de architectuur een tekening.

Het verschil met traditionele softwareontwikkeling

Bij traditionele softwareontwikkeling bouwt een team één grote applicatie, test die en brengt om de paar weken of maanden een nieuwe versie uit. Verander je één deel van het systeem, dan moet je het geheel opnieuw uitrollen. En als er iets stukgaat, kan het moeilijk zijn te zien waar.

Cloud-native development werkt anders. De applicatie is opgedeeld in kleine services die je los van elkaar kunt uitrollen. Elke service heeft een duidelijke eigenaar, kan worden bijgewerkt zonder de rest van het systeem aan te raken, en kan uitvallen zonder al het andere mee te slepen.

Voor het team is de overstap naar cloud-native development groot. Releases van data volgen elkaar sneller op, soms vele keren per dag. Het eigenaarschap is duidelijker, omdat elk team verantwoordelijk is voor zijn eigen service. Een storing geldt als iets normaals en niet als een crisis, omdat het systeem erop is ontworpen.

De cloud-native gereedschapskist: containers, Kubernetes en serverless

Cloud-native development leunt op een klein aantal tools, elk met een eigen taak.

Een container verpakt een applicatie en alles wat ze nodig heeft om te draaien in één eenheid. Dezelfde container draait op dezelfde manier in ontwikkeling, test en productie. Die consistentie neemt een hele categorie bugs weg die door verschillen tussen omgevingen ontstaan.

Kubernetes beheert containers op grote schaal. Het bepaalt waar containers draaien, start ze opnieuw als ze uitvallen en schaalt ze op of af naar de vraag. Het maakt het beheer wel complexer, en daarom is het voor kleinere workloads niet altijd de juiste keuze.

Serverless opties zoals Cloud Run werken anders dan Kubernetes. Jij levert de container, Google beheert de infrastructuur. Er is geen cluster om in te richten of te onderhouden. Voor veel workloads, vooral die met wisselend verkeer, is dit de praktischere keuze.

CI/CD en DevOps als motor van de oplevering

Een cloud-native architectuur zonder geautomatiseerde oplevering is alleen complexiteit, zonder de winst. CI/CD en DevOps zijn wat de architectuur echt snelheid geeft.

CI/CD staat voor continuous integration en continuous delivery. Continuous integration betekent dat elke codewijziging automatisch wordt getest voordat ze wordt samengevoegd. Continuous delivery betekent dat een wijziging die door die tests komt, automatisch of met één goedkeuring naar productie kan worden uitgerold.

Zonder een goede oplossing eindigen teams met microservices die technisch onafhankelijk zijn maar met de hand worden uitgerold. Dat is trager en riskanter dan een goed beheerde monoliet.

DevOps is de cultuur die CI/CD laat werken. Het team dat een service bouwt, is ook verantwoordelijk voor het draaien ervan. Die verantwoordelijkheid verandert hoe software wordt geschreven. Teams die om twee uur 's nachts hun eigen bugs moeten oplossen, schrijven doorgaans betrouwbaardere code.

Ontwerpen voor schaalbaarheid en veerkracht

In een cloud-native systeem is een storing geen uitzondering. Op grote schaal valt er altijd wel iets uit. Een server valt weg, een netwerkaanroep krijgt een time-out, een afhankelijkheid wordt traag. De vraag is of het systeem daar netjes mee omgaat of alles meesleept.

Ontwerpen voor veerkracht betekent services bouwen die op storingen rekenen. Aanroepen naar andere services moeten een time-out hebben en opnieuw worden geprobeerd. Een trage afhankelijkheid mag niet het hele verzoek blokkeren. Valt een service uit, dan moet het verkeer er automatisch omheen worden geleid.

Horizontaal schalen betekent meer instanties van een service toevoegen in plaats van één instantie groter te maken. Daarvoor moeten services stateless zijn. Ze mogen geen sessiedata lokaal opslaan, omdat het volgende verzoek door een andere instantie kan worden afgehandeld. State hoort in een database of een cache, niet in de service zelf.

De valkuilen van cloud-native (en hoe je ermee omgaat)

Cloud-native development heeft echte kosten, en daar is het goed om eerlijk over te zijn.

Gedistribueerde systemen zijn moeilijker te debuggen dan monolieten. Gaat een verzoek langs vijf services voordat er een antwoord terugkomt, dan moet je het door alle vijf volgen om de bron van een probleem te vinden. Zonder goede observability, logging, metrics en distributed tracing is dat heel lastig. Begin met een eenvoudigere opzet en deel die pas op als daar een duidelijke reden voor is.

Gaten in de observability zijn de meest voorkomende bron van blijvende ellende. Veel teams investeren in het bouwen van services, maar niet in begrijpen wat die in productie doen. Monitoring en alerting zijn geen optionele extra's. Ze moeten deel uitmaken van het systeem.

Zo bouw je cloud-native software op Google Cloud

Het begint met een veilige basis. Elke omgeving start met een landing zone die netwerkgrenzen, identiteitscontroles en toegangsbeleid vastlegt voordat er applicatiecode wordt uitgerold.

Managed services vervangen zelf beheerde infrastructuur overal waar ze het operationele risico verkleinen. Cloud Run draait gecontaineriseerde workloads zonder dat je een cluster hoeft te beheren. Pub/Sub regelt de berichtenuitwisseling. BigQuery regelt de analytics. Het team richt zich op de applicatie, niet op het draaiende houden van de infrastructuur.

De oplevering loopt via geautomatiseerde pipelines. Code wordt bij elke commit getest, uitrollen is geautomatiseerd en terugdraaien gaat snel. De pipeline is geen bijzaak. Hij hoort bij het systeem.

Het doel is software die betrouwbaar en onderhoudbaar is en lang meegaat. Niet de nieuwste tools, maar de tools die bij het werk passen.

Wil je een cloud-native project bespreken? Neem contact op om je huidige opzet door te nemen en te kijken hoe een goed gestructureerde basis eruit zou zien. Wil je het goed aanpakken, vraag ons dan om een demo!