Wat zijn microservices?

Definitie: Microservices is een manier om software op te bouwen uit kleine, zelfstandige services die elk één taak uitvoeren en via API’s met elkaar communiceren. Het tegenovergestelde is een monoliet: één applicatie waarin alle onderdelen samen worden gebouwd en uitgerold.

In het kort

• Bij microservices heeft elke service een eigen taak, vaak een eigen database, en kan hij los worden aangepast, uitgerold en opgeschaald.
• Bekende voorbeelden zijn Netflix, Amazon en Uber, die allemaal begonnen als monoliet en later overstapten.
• Voordelen zijn gerichte schaalbaarheid, onafhankelijke teams en foutisolatie; nadelen zijn meer complexiteit, beheer en communicatie tussen services.
• Voor de meeste kleine en middelgrote applicaties is een goed opgezette monoliet de verstandigste start.

Wat zijn microservices?

Microservices zijn kleine, zelfstandige onderdelen van een grotere applicatie. Elke service doet één ding: gebruikers beheren, bestellingen verwerken, betalingen afhandelen of e-mails versturen. De services praten met elkaar via API’s, meestal over HTTP, of via een berichtensysteem.

OVHcloud noemt vier kenmerken: services worden onafhankelijk uitgerold, elke service mag een eigen technologie gebruiken, gegevens worden per service beheerd (vaak met een eigen database) en de applicatie blijft werken als één service uitvalt.

AppMaster merkt op dat er geen precieze definitie van microservices bestaat, en dat het idee sterk lijkt op de oudere servicegeoriënteerde architectuur (SOA). Het verschil zit vooral in de schaal: microservices zijn kleiner en zelfstandiger.

Microservices of monoliet: wat is het verschil?

Een monoliet is niet ouderwets of slecht. Een goed opgezette monoliet met duidelijk gescheiden onderdelen, ook wel een modulaire monoliet genoemd, is voor veel bedrijfsapplicaties de beste keuze.

Hoe communiceren microservices met elkaar?

Volgens PayPro Global zijn er twee hoofdvormen:

• Synchroon: een service vraagt iets aan een andere service en wacht op antwoord, bijvoorbeeld via REST of gRPC.
• Asynchroon: een service plaatst een bericht in een wachtrij of op een berichtenbus, zoals Apache Kafka of RabbitMQ, en een andere service pakt dat op wanneer hij kan.

Daarnaast gebruiken microservices vaak een API-gateway als centrale ingang. Die verdeelt binnenkomende verzoeken over de juiste services en regelt zaken als inloggen en beveiliging.

Bekende voorbeelden van microservices

• Netflix. Volgens AppMaster begon Netflix na een grote storing in 2008, waardoor de verzending van dvd’s drie dagen stillag, aan een overstap. Die liep van 2009 tot 2012.
• Amazon. De webwinkel was eerst één grote applicatie. Door de groei werd de code onbeheersbaar, en Amazon splitste die op in kleinere diensten.
• Uber. Stapte over op een microservices-architectuur om sneller uit te breiden en nieuwe diensten te ontwikkelen.

Opvallend is dat al deze bedrijven begonnen als monoliet. Ze stapten pas over toen de omvang van hun applicatie en hun organisatie daarom vroeg.

Voordelen van microservices

• Gericht schalen. Een drukke service krijgt meer capaciteit, zonder dat de rest mee hoeft.
• Onafhankelijke teams. Elk team werkt aan een eigen service en rolt die uit zonder op anderen te wachten.
• Foutisolatie. Een storing in één service legt niet de hele applicatie plat.
• Vrije technologiekeuze. Een service voor beeldverwerking kan in een andere taal worden geschreven dan de rest.
• Snellere releases. Kleine onderdelen zijn sneller te testen en uit te rollen.

Nadelen en uitdagingen

• Complexiteit. Tien services zijn moeilijker te overzien dan één applicatie.
• Communicatie over het netwerk. Aanroepen tussen services zijn trager en kunnen mislukken. AppMaster noemt dure externe aanroepen in plaats van interne.
• Gegevensconsistentie. Als elke service een eigen database heeft, is het lastiger om gegevens op elkaar te laten aansluiten.
• Testen. Een fout kan ontstaan in de samenwerking tussen services, niet in één service zelf.
• Beheer. Er zijn containers, orkestratie (zoals Kubernetes), monitoring en tracing nodig om het geheel draaiend te houden.
• Beveiliging. Meer services betekent meer verbindingen die moeten worden beveiligd.

Wanneer kies je voor microservices?

Microservices passen bij een situatie met:

• Meerdere ontwikkelteams die tegelijk aan dezelfde applicatie werken.
• Onderdelen met sterk verschillende belasting, zoals een zoekfunctie die veel drukker is dan de rest.
• Hoge eisen aan beschikbaarheid, waarbij een storing in één onderdeel niet alles mag raken.
• Voldoende kennis en capaciteit voor DevOps, containers en monitoring.

Ontbreken die omstandigheden, dan levert een monoliet meestal sneller en goedkoper resultaat op. AppMaster adviseert zelf om klein te beginnen, bijvoorbeeld met een monolithisch basissysteem, en pas later op te splitsen.

Welke techniek hoort bij microservices?

Microservices vragen een infrastructuur die veel losse onderdelen kan draaien en bewaken. OVHcloud en PayPro Global noemen een vaste set hulpmiddelen:

PayPro Global noemt een cijfer van de Cloud Native Computing Foundation: 82 procent van de containergebruikers draait Kubernetes in productie. Dat laat zien hoe sterk microservices en containers met elkaar verbonden zijn, maar ook dat er een flinke technische laag bij komt kijken.

Wat kosten microservices?

Er zijn geen vaste prijzen, maar de kostenposten zijn duidelijk anders dan bij een monoliet. Bij een monoliet betaal je voor één applicatie op één of enkele servers. Bij microservices komen daar bij: meer servers of containers, een orkestratieplatform, monitoring, een API-gateway en vooral meer ontwikkel- en beheertijd. Elke service heeft zijn eigen pijplijn, tests en updates nodig. Die extra kosten verdienen zich terug als de applicatie zo groot is dat teams elkaar in de weg zitten of één onderdeel veel meer capaciteit vraagt dan de rest. Bij een kleinere applicatie zijn het vooral extra kosten.

Uitgewerkt voorbeeld: een groeiende webwinkel

Een webwinkel begint als één applicatie met een catalogus, een winkelwagen, betalingen en een beheeromgeving. Dat werkt jaren goed. Na verloop van tijd groeit het aantal bezoekers sterk, vooral rond acties. De zoekfunctie trekt dan zoveel rekenkracht dat de hele winkel trager wordt, ook het afrekenen. In plaats van alles op te splitsen, haalt het team alleen de zoekfunctie uit de monoliet en maakt er een aparte service van die zelfstandig kan opschalen. De rest blijft één applicatie. Zo lost het team het echte knelpunt op zonder de complexiteit van tientallen services.

Veelgemaakte fouten

• Te vroeg opsplitsen. Wie begint met microservices, moet grenzen kiezen voordat duidelijk is hoe de applicatie wordt gebruikt.
• Te kleine services. Services die voor elke actie op elkaar moeten wachten, zijn in feite een monoliet over het netwerk.
• Eén gedeelde database. Dan zijn services nog steeds sterk aan elkaar gekoppeld.
• Geen monitoring. Zonder zicht op de verbindingen is een fout moeilijk te vinden.

Van monoliet naar microservices

Wie later wil overstappen, doet dat meestal stap voor stap:

1. Breng de onderdelen in kaart. Welke delen van de applicatie hebben een eigen taak en eigen gegevens?
2. Kies één onderdeel om af te splitsen, liefst een onderdeel met een duidelijke grens en een eigen reden, zoals veel belasting.
3. Bouw een API tussen de monoliet en de nieuwe service.
4. Verplaats de gegevens die bij de service horen.
5. Meet het effect voordat je het volgende onderdeel aanpakt.

Deze aanpak wordt ook wel het strangler-patroon genoemd: de nieuwe services groeien om de oude applicatie heen, tot die klein genoeg is.

Wat betekent dit voor jouw project?

Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Voor de meeste bedrijfsapplicaties betekent dat een nette, modulaire opbouw in één applicatie, met duidelijke grenzen tussen onderdelen. Dat is sneller te bouwen, eenvoudiger te beheren en goed uit te breiden. Microservices zijn een antwoord op problemen van grote organisaties met veel teams en veel verkeer, en die problemen heb je bij een eerste versie meestal nog niet.

Koppelingen met andere systemen, zoals een boekhoudpakket of CRM, zijn wel vanaf het begin belangrijk. Die leggen we vast in de blauwdruk, samen met de schermschetsen en het voorstel voor de eerste versie.

Twijfel je hoe je een applicatie het beste opzet? Stuur me voor wie het is, wat er nu gebeurt en welke systemen ermee moeten samenwerken. Dan bepalen we samen de logische eerste stap. Lees ook wat er komt kijken bij een webapplicatie bouwen.

Veelgestelde vragen over microservices

Wat zijn microservices?

Microservices zijn kleine, zelfstandige services die samen een applicatie vormen. Elke service voert één taak uit, kan los worden aangepast en opgeschaald, en communiceert met andere services via API’s.

Wat is het verschil tussen microservices en een monoliet?

Een monoliet is één applicatie waarin alle onderdelen samen worden gebouwd en uitgerold. Bij microservices is de applicatie opgesplitst in losse services die elk onafhankelijk worden ontwikkeld, uitgerold en geschaald.

Wanneer zijn microservices zinvol?

Microservices zijn zinvol bij grote applicaties met meerdere ontwikkelteams, sterk wisselende belasting per onderdeel en hoge eisen aan beschikbaarheid. Voor kleinere applicaties is een goed opgezette monoliet meestal eenvoudiger en goedkoper.

Verwante termen

Schaalbaarheid · Middleware · API-koppeling · Technische schuld · Webapplicatie · SaaS