Software in de cloud: van monoliet naar microservices

Sander Horst Cloud Engineer

7 oktober 2022

Software in de cloud: van monoliet naar microservices

Dat jouw software in de cloud draait, maakt het nog niet cloud-native. Om de volledige toegevoegde waarde van de cloud te ontsluiten, is een ander fundament voor software nodig. De oude, monolithische architectuur van software moet transformeren in een flexibele architectuur op basis van microservices. Dat vereist niet alleen innovatie en technologisch vernuft: organisatorische verandering en een goed doordacht proces zijn onmisbaar.

De transitie uit de doeken

Iedere softwareapplicatie is feitelijk een verzameling samenwerkende functionaliteiten. Neem een webshop: de zoekfunctie, het aanbevelingsalgoritme, het winkelmandje en andere soortgelijke bouwblokjes vormen samen de applicatie. Wanneer je deze functionaliteiten allemaal in dezelfde ‘runtime’ stopt en als één geheel draait, spreek je van een monolithische architectuur.

In een cloud-native architectuur week je de verschillende functionaliteiten juist los van elkaar als microservices die met elkaar communiceren. Deze microservices kunnen draaien in containers: een softwarepakket binnen een virtueel besturingssysteem (OS) dat in vrijwel iedere omgeving kan functioneren. Wat deze opzet “cloud-native” maakt, is dat de applicaties zijn gebouwd om gebruik te kunnen maken van de schaalbaarheid, flexibiliteit en veerkracht die de cloud biedt.

Een cloud-native microservice-architectuur biedt verschillende voordelen:

Makkelijker op- en afschalen. Een monolithische architectuur kun je alleen in zijn geheel op- en afschalen. Maar microservices zijn los van elkaar te beïnvloeden, zodat je voor veelgebruikte functionaliteiten meer capaciteit kunt vrijmaken, zonder de kosten van andere omgevingen op te jagen.
Meer flexibiliteit. Een monolithische architectuur zit vast aan één bepaald operating system en webserver. Maar voor containers ben je flexibel in deze keuzes en zelfs in je migratie naar een andere cloud-provider, omdat een container alle elementen bevat om op elke omgeving te kunnen draaien.
Makkelijker beheer. Cloud-native applicaties maken beheer gemakkelijker. Dit komt omdat je het in de cloud kan draaien, waarbij onder andere OS-updates achter de schermen gebeuren. Ook beheertools zoals Kubernetes en OpenShift maken beheer van containers een stuk efficiënter.

"Zijn de gebruikte oplossingen zoals containers, CI/CD en monitoring veilig en compliant genoeg voor de behoeften van je organisatie?"

De technische uitdagingen van microservices

Cloud-native technologieën maken het leven een stuk makkelijker, maar dat komt wel met uitdagingen. Cloudtechnologie evolueert ontzettend snel. Daar moet je bovenop blijven zitten. Als je bijvoorbeeld met het uitrollen van een technologie als Kubernetes steken laat vallen, is de kans groot dat de omgeving onveilig is ingericht en daarmee een makkelijk doelwit voor hackers vormt.

Ook kan het lastiger zijn om overzicht te behouden. Een monolithische applicatie is overzichtelijk. Je hebt één omgeving met vaste kosten. In een cloud-native omgeving kun je ongelimiteerd de capaciteit opschalen. Je moet dan ook de juiste controlemechanismen en limieten inrichten, zodat applicaties blijven presteren zonder duizenden euro’s per maand verbranden omdat ze te veel capaciteit gebruiken.

Wanneer je van een monolithische architectuur naar microservices migreert, zijn er ook uitdagingen rond monitoring en alerting. De architectuur is immers getransformeerd tot een complex geheel van allerlei kleine, kort- of langdurig draaiende services. Monitoring hiervan vereist nieuwe tooling, andere kennis én een andere denkwijze. Het is belangrijk hierop te anticiperen en je medewerkers hiervoor op te leiden.

Tot slot is security een continue overweging. Zijn de gebruikte oplossingen zoals containers, CI/CD en monitoring veilig en compliant genoeg voor de behoeften van je organisatie? Een kleine fout in de inrichting of een enkel openbaar wachtwoord kan leiden tot een groot securitylek.

"Een verkeerde keuze of instelling kan duizenden euro’s kosten, maar door hier actief op te monitoren en te sturen, kun je deze keuzes blokkeren voordat ze naar de productieomgeving gaan."

Organisatorische vraagstukken

Naast technische uitdagingen, komt de transitie van monoliet naar microservices met organisatorische vraagstukken. De teamstructuur en werkwijze moeten op de kop: teams werken niet meer samen aan één grote release, maar aan kleine releases per microservice en ontwikkelen met een CI/CD-releaseproces. Bovendien worden teams volledig verantwoordelijk voor het functioneren van hun microservice(s). Troubleshooting kan bijvoorbeeld niet worden doorgeschoven naar een hostingafdeling. Deze veranderingen kunnen wrijving veroorzaken zonder gedegen verandermanagement.

Daarnaast moet ook de financiële strategie mee veranderen. Kosten komen in de cloud niet vooraf, maar op basis van gebruik. Daar moet je op kunnen anticiperen en je moet het kunnen controleren. Een verkeerde keuze of instelling kan duizenden euro’s kosten, maar door hier actief op te monitoren en te sturen, kun je deze keuzes blokkeren voordat ze naar de productieomgeving gaan.

Een weldoordachte transitie

De overstap van een monolithische structuur naar microservices brengt dus heel wat uitdagingen met zich mee. Zonder een gedegen proces om deze transitie te ondersteunen, stel je je organisatie bloot aan onnodige bedreigingen. Een van de bewezen processen om deze transitie te doorlopen, is het zogenaamde Strangler Pattern.

Dit is een transitieproces gebaseerd op incrementele verandering: functionaliteiten worden stuk voor stuk herbouwd als een microservice. Zodra zo’n nieuwe functionaliteit klaar is, wordt de oude component in de monoliet de nek om gedraaid (‘strangled’) en vervangen door een koppeling naar de nieuwe microservice. Zo kun je de monoliet steen voor steen afbreken, zonder de hele applicatie te moeten uitschakelen.

Toch zul je, ook met Strangler Patterns, in de transformatie naar een cloud-native architectuur tegen obstakels aanlopen. Op die momenten is het fijn een ervaren sparringpartner te hebben die dit soort trajecten al vaker heeft doorlopen. Zo hoef je niet elke keer het wiel opnieuw uit te vinden en kun je veel geziene valkuilen vermijden.