Microservices: als je voor een software- of e-commercebedrijf werkt dan heb je waarschijnlijk wel van deze term gehoord. Grote bedrijven zoals Netflix, Google en Amazon zweren erbij. En zoals wel vaker volgen Nederlandse startups en scale-ups al snel het voorbeeld van de internationale techcommunity. In deze blogpost duiken we iets dieper in het begrip microservices. Wat zijn microservices? Hoe verschillen ze ten opzichte van monolitische applicaties? En is het één beter dan het andere?

📖 Leestijd: 8 tot 10 minuten

Wat zijn microservices?

Microservices, ook wel een microservice-architectuur genoemd, kun je het best zien als een architectuurstijl voor software-ontwikkeling. Net als bij een gebouw heeft software te maken met verschillende architectuurstijlen. De gekozen architectuurstijl bepaalt onder andere de manier waarop functies in software geprogrammeerd worden en hoe deze functies met elkaar verband houden. Bij een microservice-architectuur wordt de software opgebouwd aan de hand van allerlei kleine mini-applicaties. Deze kleine applicaties hebben elk een eigen taak of een reeks aan taken en zijn met elkaar verbonden. Samen vormen deze kleine applicaties voor de eindgebruiker één geheel. Doordat de front-end in één stijl is, lijkt de applicatie een geheel.

De kleine applicaties worden ook wel ‘microservices’ genoemd, omdat ze elk verantwoordelijk zijn voor de functies van de software. Een microservice kan bijvoorbeeld bestaan uit alle functies die nodig zijn voor het inloggen in de software. Een andere microservice kan weer gericht zijn op de instellingen van de software. Allebei de microservices worden los van elkaar ontwikkeld, vaak door verschillende software-ontwikkelaars of teams. Hoe groot of klein de microservices zijn en wat de aantallen microservices zijn die samen 1 applicatie vormen verschilt sterk per bedrijf. Er is namelijk geen eenduidige definitie van een microservices architectuur: iedereen mag het zelf bepalen.

Veel ontwikkelaars spieken daarom bij grote techbedrijven die al eerder microservices hebben ingezet voor hun webshops, webapplicaties of websites. Bekende bedrijven die microservices succesvol inzetten zijn Amazon (die hebben de term zo’n beetje bedacht) Netflix en Uber.

Monolitische applicaties vs. microservices

Een andere architectuurstijl die vaak in één adem met microservices wordt genoemd is de monolitische applicatie-infrastructuur. In veel opzichten is een monolitische applicatie het tegenovergestelde van een microservices applicatie. Een monolitische applicatie is namelijk één grote applicatie die alle functies van de software in één omgeving bevat.

Een afbeelding zegt vaak meer dan duizend woorden:

Monolitische applicaties

Een monolitische applicatie is vaak gehost bij één hostingprovider, bijvoorbeeld on-premise (eigen datacenter, colocatie, dedicated server of virtuele machine) of in een private cloud. De hostingprovider zorgt ervoor dat de applicatie stabiel blijft en helpt met het opschalen van bijvoorbeeld extra opslagcapaciteit.

Microservices architectuur

Microservices hoeven niet op dezelfde plek gehost te worden. Zo kunnen een aantal microservices in een publieke cloud als Azure worden gehost en anderen weer in bijvoorbeeld AWS. De microservices communiceren onderling met elkaar via API’s en omdat er één front-end is merkt de eindgebruiker er meestal niets van. De microservices maken daarnaast vaak gebruik van Docker containers, wat voor veel snelheid in het ontwikkelproces zorgt.

Legacy software

Legacy software is de naam voor software die al wat ouder is. Deze software is vaak van monolithische aard. De microservices applicatie architectuur is nieuwer en die zie je daarom in oude software niet terug. Maar dat de legacy software wat ouder is, wil niet zeggen dat het niet belangrijk is. Ook in die software kunnen veel belangrijke bedrijfsprocessen samenkomen. Een fout in de software of onbeschikbaarheid kan catastrofaal zijn voor een bedrijf.

Deze legacy software draait regelmatig ook op oudere vormen van applicatiehosting, zoals niet gevirtualiseerde on-premise oplossingen zoals colocatie of dedicated hosting. Deze applicaties migreren naar een virtuele machine in de cloud levert dikwijls niet de voordelen op waar je op hoopt, omdat de applicatie niet om kan gaan met zaken als horizontale en verticale schaalbaarheid. Wanneer bedrijven dus hun applicaties en infrastructuur willen moderniseren, hebben ze een aantal mogelijkheden om dit te doen. Gartner beschrijft zeven mogelijke strategieën voor applicatiemodernisatie, van het volledig herontwikkelen van de applicatie tot een ‘simpele’ migratie.

Wij zien echter dat de meeste bedrijven kiezen voor een hybride, gefaseerde aanpak. Door bijvoorbeeld bepaalde delen van de legacy-software om te bouwen naar microservices, kan de software stap-voor-stap naar een cloudprovider worden gebracht. Voor de eindgebruiker verandert er dan niets aan front-end: de software blijft er hetzelfde uitzien. Voor het bedrijf biedt dit echter het beste van twee werelden: ze behouden de functionaliteit die moeilijk naar de cloud is te brengen, maar kunnen ondertussen wel belangrijke functionaliteit ombouwen naar clouddiensten, waardoor ontwikkelaars de software sneller kunnen vernieuwen.

Majestic monoliths

Het algemene discours is dat monolitische applicaties minder goed schalen dan applicaties die gebouwd zijn volgens een microservices-architectuur. Werken op een microservices manier zou daarom een uitkomst bieden. Toch zijn er veel personen binnen de softwaredevelopmentcommunity die het daar niet mee eens zijn. Bijvoorbeeld David Heinemeier Hansson (DHH) van het bedrijf Basecamp en de maker van webapplicatieframework Ruby on Rails, een developmentframework die onder andere door GitHub, AirBnB en Zendesk wordt gebruikt. In een blogpost pleit DHH voor ‘majestic monoliths’.

Een monolitische applicatie bestaat over het algemeen minder uit ‘bewegende onderdelen’, waardoor het beheer en onderhoud een stuk overzichtelijker zijn. Applicaties die bestaan uit microservices zijn over het algemeen complexer omdat ze uit meerdere bewegende onderdelen bestaan. Er kan dus ook meer fout gaan.

Tl;dr De architectuurstijl waarin software wordt ontwikkeld is dus sterk afhankelijk van wat de software moet doen en wat de wensen van een business zijn.

De voordelen van microservices

Waarom zijn developers en bedrijven dan geïnteresseerd in het ontwikkelen van microservices? Dat is met name te danken aan de volgende voordelen.

Kleine, autonome teams

Wanneer organisaties groeien, groeit ook de communicatie onderling tussen ontwikkelteams. Hoe groter het team: hoe meer overleg er is.

Met microservices wordt het mogelijk om teams agile, klein en autonoom in te richten. Een team kan bijvoorbeeld verantwoordelijk zijn voor een enkele microservice of voor meerdere microservices.

Omdat deze kleine teams met een code repository zoals Github of Gitlab werken kunnen zij redelijk autonoom werken. Ze hoeven geen rekening te houden met andere onderdelen van de webapplicatie omdat zij alleen verantwoordelijk zijn voor hun eigen stukje code. Ook beperkt dit het aantal vergaderingen en communicatie.

Flexibiliteit in technologiekeuzes

Een belangrijke reden waarom teams klein en autonoom kunnen zijn heeft ook te maken met de flexibiliteit in technologiekeuzes. Ontwikkelteams kunnen namelijk per microservice zelf de technologiestack bepalen. Waar zij bij een monolitische applicatie vaak gebonden zijn aan één programmeertaal, één framework en één type database-applicatie, kunnen zij bij microservices die helemaal naar wens inrichten.

De ene microservices bouwen met het React framework en de ander met Laravel? Geen probleem. Zolang de twee maar wel met elkaar kunnen ‘communiceren’ via API’s en er aan de front-end niets van te merken is.

Deze keuzevrijheid geeft ontwikkelaars ontzettend veel bewegingsvrijheid. Veel legacysoftware is bijvoorbeeld geschreven in oude programmeertalen waardoor het moeilijk is om nieuwe generatie developers aan te laten haken. Maar als deze ontwikkelaar de microservice mag bouwen in een framework naar keuze dan is dat een enorm pluspunt. Het wordt bovendien gemakkelijker om sneller nieuw talent aan te trekken.

Snellere time-to-market

Een snellere time-to-market wordt vaak in één adem genoemd met bedrijven die de ‘digitale transformatie’ hebben omarmd omdat zij zo een ‘voorsprong op de concurrent’ kunnen krijgen.

Als je alle wolligheid van die termen afpelt dan kom je vaak tot de kern. Een snellere time-to-market is namelijk vooral te danken aan ontwikkelaars die (nieuwe) functies kunnen leveren in de software, deze snel beschikbaar kunnen stellen aan klanten zodat er snel feedback kan worden opgehaald die informatie verschaft voor de volgende software release. Des te korter de tijdsduur van deze cirkel, des te sneller de vooruitgang. En steeds vaker is dit mede te danken aan microservices.

Omdat ontwikkelteams in kleine, autonome teams werken kunnen zij onafhankelijk van elkaar aan diverse microservices in de software werken. Ze hoeven niet op elkaars code te wachten maar kunnen tegelijk de software verbeteren. Omdat je dan te maken krijgt met verschillende versies, gebruiken zij een Git-systeem (software voor versiebeheer) en een code repository zoals GitHub of GitLab. Als zij de code van de microservice committen wordt deze eerst gecontroleerd voordat het wordt toegevoegd aan de master branch. In sommige teams zijn ze al zo ver dat ze dit proces automatiseren met een Continuous Integration pipeline.

Lees ook: Wat is Continuous Integration, Continuous Delivery en Continuous Deployment?

Het fijne aan een Git-systeem zoals GitHub of Gitlab is dat ontwikkelteams ook hun efficiëntie kunnen monitoren. Doordat er van alles gemeten wordt, kan er ook veel verbeterd worden. Die intelligentie kan bijvoorbeeld gebruikt worden tijdens een developmentsprint, zodat het team al lerende sneller kan opleveren.

Sneller fouten opsporen

Microservices zijn over het algemeen complexer omdat een microservice architectuur uit veel ‘bewegende onderdelen’ bestaat. Er kan in vrijwel elk onderdeel van de microservice een fout zitten waardoor het mogelijk is dat de software stukgaat. Ook kan een verandering in 1 onderdeel een onverwachte storing in een ander onderdeel teweegbrengen. Deze storingen zijn soms moeilijk op te lossen als er te weinig kennis is over de afhankelijkheden en interconnectiviteit van de microservices.

Het goede nieuws is dat er talloze tools bestaan die alle metrics van een applicatie en de bijhorende microservices in de gaten kan houden. Met bijvoorbeeld een Application Performance System is bijvoorbeeld de status van API’s te monitoren, maar ook integraties met derdepartijtools zoals Kubernetes, Docker of VM instances in de publieke cloud en Github.

Een Application Performance Monitoring systeem helpt met het snel opsporen van fouten of hiccups in de gezondheid van de applicatie, inclusief de microservices. Hierdoor zijn fouten sneller op te sporen. En omdat het vaak om geïsoleerde fouten gaat hoeft het niet zo te zijn dat de gehele applicatie dan plat ligt. Met een APM kun je zien welke onderdelen disfunctioneren zodat je het ook heel gericht kunt oplossen.

Lees ook: De voordelen van Application Performance Monitoring

Er is trouwens ook een nieuwe functie ontstaan die hier alleen maar op gericht is: een Chaos Engineer. Dat is iemand die bewust de fouten in een microservice opzoekt en zelfs onderdelen in de applicatie bewust stukmaakt om te kijken wat het effect is op de gehele applicatie. Maar daarover in een andere blogpost meer.

Verhoogde productiviteit ontwikkelteams

Ontwikkelteams die met microservices ontwikkelen krijgen over het algemeen te maken met minder omslachtige communicatie (minder vergaderingen), zijn kleiner en autonomer en hebben veel keuzevrijheid in de developmentstack waar ze mee ontwikkelen. Daarnaast werken ze vaak met een Git-systeem zoals GitHub of Gitlab, en automatiseren zij onnodige, herhalende processen met een CI/CD pipeline. Een combinatie van deze factoren maakt dat de ontwikkelaars die met microservices werken over het algemeen een stuk productiever zijn.

Hier valt natuurlijk wel het een en ander te nuanceren. Die productiviteitswinst zal zeer sterk verschillen per bedrijf en is onder andere afhankelijk van de hoeveelheid ontwikkelaars en het stadium van microservices en CI/CD pipelines waar het ontwikkelteam op dat moment in zit. Teams die aan het begin van hun reis staan zullen niet per definitie direct productiever zijn. Het kost ontzettend veel tijd om iets goed te automatiseren en het bedenken van een solide microservice-architectuur gaat niet zonder slag of stoot.

Een belangrijk aspect hierin is dat ontwikkelteams een lerende mindset adapteren. Gaandeweg wordt het team sneller in het leveren van nieuwe functies omdat zij veelvoudig committen. Deze herhaling, het veelvoudig committen van code, zorgt uiteindelijk dat teams scherper, sneller, beter en productiever worden. Maar dat gaat dus niet over één nacht ijs.

Nadelen microservices

We verklapten het al een beetje toen we over monolitische applicaties schreven, maar microservices zijn niet voor iedere organisatie weggelegd. Ook omdat ontwikkelen met microservices een aantal nadelen heeft.

Microservices zijn complexer

Omdat elke microservice los van elkaar ontwikkeld wordt is de kans op fouten bij integraties aanwezig. Sommige developers noemen dit ook wel ‘integration hell’. Hoe meer microservices een organisatie heeft, hoe complexer het vaak wordt. Het oppervlakte op fouten wordt namelijk grote naarmate de organisatie meer microservices maakt en gebruikt.

Gelukkig is het in de meeste gevallen oké om fouten te maken. Wat wel belangrijk is, is dat deze fouten tijdig gesignaleerd worden en dat ze ook aangepakt worden. Veel ontwikkelteams kiezen daarom om microservices te combineren met een Git-systeem zoals GitHub of Gitlab, waar versiebeheer en controle centraal staan. Ook worden er geautomatiseerde tests ingebouwd in het CI/CD proces. Bij het falen van deze tests gaat de applicatie terug naar de developer om de problemen op de lossen. Er zijn altijd een aantal individuen binnen de organisatie die de code eerst moeten controleren en valideren voordat deze toegevoegd wordt aan een live productie-omgeving.

Ook is het zo dat de complexiteit van microservices te monitoren is, bijvoorbeeld met een Application Performance Monitoring systeem.

En als fouten vaak voorkomen, dan zijn ze bijvoorbeeld te controleren met een geautomatiseerd scriptje die runt zodra de code de CI/CD pipeline inrolt. Fouten maken hoort er ook een beetje bij als je met microservices werkt. Door ze inzichtelijk te maken en te stoppen voordat ze optreden in de productie-omgeving wordt het team slimmer en uiteindelijk productiever.

Culturele veranderingen nodig

De ontwikkeling van microservices is een technische keuze, maar deze wordt gevoerd door een bedrijfsvraag. Werken met microservices vraagt ook om een bedrijfsbrede aanpak en om een culturele verandering. Niet elke ontwikkelaar is gewend om te werken met microservices, met CI/CD pipelines of met Git. Dat betekent dat er nieuwe vaardigheden aangeleerd moeten worden.

Naast technologische vaardigheden moeten mensen ook leren om te werken met incrementele wijzigingen. ‘Release early, release often’ is een mantra dat de meeste ontwikkelteams wel kennen, maar wat soms ook wordt tegengehouden door bijvoorbeeld een managementlaag of door andere beperkingen uit het bedrijf.

Daarom is het handig als het bedrijf managementbegrippen zoals ‘lean’ en ‘agile’ accepteert en actief stimuleert. Deze begrippen bevatten een aantal kernwaarheden die met name gericht zijn op het leren door te doen, kleine wijzigingen doorvoeren en het leren van je fouten. Je ziet diezelfde principes terug in bijvoorbeeld methodieken zoals SCRUM, DevOps en het iets nieuwere SRE. De kern ligt echter in de manier waarop mensen gemanaged worden (of in het geval van microservices: hoeveel vrijheid de ontwikkelteams krijgen om gewoon hun werk te doen).

Dit is echter moeilijk om alleen vanuit de developmentafdeling voor elkaar te krijgen. Het moet een bedrijfsbrede strategie zijn om slimmer en incrementeler te werken en leren.

Conclusie: Microservices goed voor je webapplicatie?

Net als met veel onderwerpen is het wijs om eerst vragen te stellen voordat je volledig stort op een nieuwe technologische trend. In het geval van microservices inzetten voor de webapplicatie hangt het sterk af van de vraag die de business heeft. Microservices kunnen helpen om legacy-software gefaseerd naar een publieke cloud te brengen. Het kan ook helpen om sneller software te releasen en zo innovatiever te zijn dan de concurrent. Maar dan moeten er wel aan een aantal randvoorwaarden worden voldaan.

Bij de ontwikkeling van een nieuwe applicatie is het altijd zinvol om af te vragen hoeveel wijzigingen er continu plaats moeten vinden. In sommige gevallen volstaat een monolitische applicatie misschien prima.

Wanneer je wel met microservices begint is het verstandig dat deze keuze zo breed mogelijk wordt gedragen door het hele bedrijf. Microservices zijn onderdeel van een bredere, culturele verandering onder ontwikkelaars. Een lerende mindset is belangrijk, en daar moet draagvlak voor zijn binnen het bedrijf. En een beetje geduld.

Wij denken graag met je mee! Neem contact met onze solutions architecten en vertel ons over je uitdaging.