Wat is microservicesarchitectuur?

Microservices architectuur is een methode om applicaties te bouwen als een verzameling van kleine, op zichzelf staande componenten die via API's over een netwerk communiceren. NIST SP 800-204 erkent de aanpak met een kleinere codebase, onafhankelijke teams en schaalbaarheid per component.

Het is alsof je een team van werknemers hebt die allemaal gecoördineerd samenwerken met een gemeenschappelijke agenda, waarbij ieder vanuit een bepaalde expertise opereert. Dit is anders dan de voorgaande monolithische structuur, die vergelijkbaar is met één enkele entiteit die alles doet, en naarmate de applicatie complexer wordt, is deze omslachtig te beheren.

Microservices-architectuur verschilt op de volgende manieren van traditionele monolithische architectuur.

• Decentralisatie: Microservices nemen functionaliteit en verspreiden deze over individuele services, terwijl een een monoliët alle functionaliteit binnen één codebasis combineert.
• Losse koppeling: Microservices communiceren via API's met een hoge mate van samenhang en een lage mate van koppeling, terwijl in het geval van monolieten componenten meestal gekoppeld en samenhangend zijn.
• Onafhankelijke implementatie: Microservices maken het mogelijk om een individuele service te wijzigen of te implementeren zonder dat het hele systeem uitvalt, terwijl wijzigingen binnen een monolithische architectuur implementatiecoördinatie vereisen.
• Schaalbaarheid: Microservices kunnen onafhankelijk van elkaar worden aangepast op basis van gebruikersvereisten, in tegenstelling tot benaderingen zoals monolithisch, waarbij schaling over de hele applicatie vereist is.
• Fout-isolatie: Bij microservices heeft het uitvallen van één service geen invloed op de rest van de services, terwijl bij monolithische services het uitvallen van één component kan leiden tot het uitvallen van de hele applicatie.

Het adopteren van een microservices-architectuur ruilt operationele complexiteit in voor onafhankelijke schaalbaarheid en foutisolatie.

Voordelen:

• Schaalbaarheid: Bepaalde services op een bepaalde schaal ontwikkelen volgens de vraag, zodat het gebruik van middelen efficiënt is.
• Verhoogde wendbaarheid: Onafhankelijk ontwikkelen en implementeren houdt verband met een snellere start van de cyclus en een snellere reactie op veranderingen.
• Flexibiliteit van technologie: Het vermogen van elke service om geschikte taal en tools te gebruiken, is een factor die kan bijdragen aan innovatie en service-optimalisatie.
• Fout-isolatie: Om de impact van servicefouten te verminderen en de systeemstabiliteit te verbeteren.
• Onderhoudbaarheid: Elke kleine, specifieke service is gemakkelijker te begrijpen, ontwikkelen en beheren dan één allesomvattende service.

Uitdagingen:

• Toegenomen complexiteit: Het beheren van gedistribueerde systemen vereist een complexere aanpak dan gecentraliseerde systemen vanwege inherente complexiteiten.
• Gegevensbeheer: In datamanagement worden afzonderlijke gegevensopslagen voor elke service vaak geassocieerd met uiteindelijke gegevensconsistentie tussen die services, in plaats van onmiddellijke consistentie.
• Testen: Het is belangrijk om alle eenvoudige en complexe tests uit te voeren om de compatibiliteit van alle services en de stabiliteit van het hele systeem na de implementatie te garanderen.
• Communicatie: Communicatie tussen services is cruciaal voor een efficiënte werking, maar het brengt latentie en mogelijke faalgebieden met zich mee.
• Beveiliging: Het beveiligen van gevoelige gegevens over meerdere services moet goed worden gepland en uitgevoerd om kwetsbaarheden in services te voorkomen.

Microservices communiceren meestal via API's (Application Programming Interfaces), die beschrijven hoe gegevens worden uitgewisseld en in welk formaat. Dergelijke communicatiepatronen omvatten:

• Synchrone aanvraag-reactie: Eén service stuurt een verzoek door naar een andere service en verwacht dat deze reageert. Dit is eenvoudig, maar als het niet goed wordt beheerd, kan het leiden tot strakke koppeling en prestatieproblemen. Meestal REST over HTTP, of gRPC voor lagere latentie; externe clients komen binnen via een API-gateway. Een REST API is hoe een service wordt bereikt, niet een service zelf.
• Asynchrone berichten: Services wisselen berichten uit via een berichtenmakelaar om te vertrouwen op ontkoppeling en meer schaalbaarheid te verkrijgen. Dit patroon is het meest effectief wanneer een grote hoeveelheid gegevens of gebeurtenissen moet worden verwerkt. De broker is meestal Apache Kafka of RabbitMQ, geen microservice zelf.
• Event-Driven Architectuur: Services publiceren events waarnaar andere services vervolgens kunnen luisteren , om te bevorderen losse koppeling en responsiviteit. Dit patroon sluit goed aan bij situaties waarin updates of wijzigingen vereist zijn over meerdere services.

Best practices omvatten:

• Domeingestuurd ontwerp (DDD): Decomposeer het systeem in bounded contexts die bedrijfsfunctionaliteiten bestrijken die de leesbaarheid en onderhoudbaarheid van het systeem zullen verbeteren.
• API-First Ontwerp: Zet duidelijke en goed gedocumenteerde interfaces op waar services in het systeem moeten samenwerken om consistentie en eenvoudige integratie te garanderen.
• Containerisatie: Verdeel services in pakketten en plaats ze in implementatiecontainers voor betere controle en eenvoudige schaling van oplossingen. Dat betekent deze te implementeren in Docker-containers die Kubernetes inplant: 82% van de containergebruikers draait Kubernetes in productie (CNCF, 2026).
• Continue integratie en continue levering (CI/CD): Standardiseer bouwen, testen en implementeren met regelmatige, voorspelbare en herhaalbare releases.
• Monitoring en Observeerbaarheid: Log en controleer de servicestatus en -prestaties om ervoor te zorgen dat ze goed worden geregistreerd en gedocumenteerd, zodat de hoofdoorzaak gemakkelijk kan worden geïdentificeerd als er een probleem is.

Voorbeelden uit de praktijk van succesvolle microservices zijn onder andere:

• Netflix: Een op microservices gebaseerde architectuur geïmplementeerd om wereldwijde uitbreiding te ondersteunen en grote verkeersvolumes voor hun streamingdienst te beheren.
• Amazon: De e-commerce website koos voor een microservices-architectuur na de migratie van het vorige monolithische ontwerp, met als doel de aanpasbaarheid en veelzijdigheid te verbeteren.
• Uber: Microservices beheren ritverzoeken, betalingen en chauffeurs afzonderlijk, wat de groei bevordert.

Beide Netflix en Amazon begonnen als monolieten en splitsten ze later op: bouw de modules binnen één applicatie, haal vervolgens de module eruit waarvan de schaling problemen veroorzaakt.