Microservices zijn al jaren een buzzword in de IT-wereld. Organisaties zien ze vaak als dé oplossing voor schaalbaarheid, flexibiliteit en innovatie. Toch is het belangrijk om kritisch te kijken naar wat microservices nu werkelijk zijn en of ze altijd de beste keuze zijn. In dit artikel verken ik de essentie van microservices, hun oorsprong en de relatie met andere architectuurpatronen. Tot slot geef ik een beslisboom om te bepalen of microservices geschikt zijn voor jouw situatie.

Wat zijn microservices écht?

De term “microservice” wordt vaak verkeerd gebruikt. Het gaat niet simpelweg om kleine services of een verzameling API’s. Een microservice is een autonome, zelfstandig te deployen component die een duidelijk afgebakende businessfunctie vervult. Dit betekent dat elke service onafhankelijk ontwikkeld, getest en uitgerold kan worden, vaak met een eigen database. Communicatie tussen services verloopt meestal via lichte protocollen zoals gRPC of REST. Het belangrijkste is dat microservices zelfstandige onderdelen zijn die samen een systeem vormen, en niet zomaar losse stukjes code.

Microservices en Domain Driven Design

Microservices en Domain Driven Design (DDD) worden vaak in één adem genoemd, en dat is niet zonder reden. Waar microservices een architectuurstijl zijn, biedt DDD een ontwerpmethodiek om deze stijl zinvol toe te passen. DDD introduceert het concept van bounded contexts: duidelijke grenzen waarbinnen een bepaald domeinmodel geldig is. Elke microservice zou idealiter één bounded context vertegenwoordigen.

Hoe stuurt DDD je microservice opzet:

  • Strategisch ontwerp: Identificeer Core Domains, Supporting Domains en Generic Domains. Core Domains verdienen vaak een eigen microservice.
  • Tactisch ontwerp: Binnen een bounded context gebruik je patterns zoals Entities, Value Objects en Aggregates om je interne model robuust te maken.
  • Context Mapping: Visualiseer relaties tussen bounded contexts. Dit helpt om afhankelijkheden tussen microservices expliciet te maken.

Microservices zonder DDD zijn als een stad zonder stadsplanning: je krijgt een wirwar van straten en gebouwen zonder logica. DDD biedt de kaart en de regels om een goed gestructureerde microservice-architectuur te bouwen.

Geschiedenis en hype

Microservices zijn niet uit het niets ontstaan. Ze zijn een evolutie van Service-Oriented Architecture (SOA), maar met een sterkere focus op autonomie en eenvoud. Waar SOA vaak zwaar en complex was, kozen bedrijven als Netflix en Amazon voor lichtere, gedecentraliseerde services om hun enorme schaalbaarheidseisen aan te kunnen.

Waarom zijn microservices zo populair geworden? De ontwikkeling naar cloud-native applicaties en DevOps maakten het mogelijk om snel en onafhankelijk te ontwikkelen en deployen. Tegelijk zie je dat sommige organisaties vooral de technologie omarmen omdat ze de succesverhalen van techgiganten lezen en hetzelfde willen bereiken. Terwijl ze vaak niet dezelfde use-case en al helemaal niet dezelfde technische volwassenheid hebben. In dat geval zie je vaak dat er in de praktijk een zogenaamde “distributed monolith” ontstaat. Op papier zijn er verschillende services, maar in de praktijk is alles met elkaar verbonden en ben je vaak slechter af dan wanneer je gewoon een goed gestructureerde monoliet had gemaakt.

Welke architectuur pas je toe in je microservice?

In principe staat het je vrij om hier eigen keuzes in te maken. Een microservice oplossing dicteert niet welke technologie of architectuur je voor je services gebruikt. Sterker nog: omdat je services volledig los van elkaar moeten staan, heb je de vrijheid om de beste oplossing per service te kiezen. Voor sommige services betekent dit dat je enkel één project gebruikt zonder verdere lagen of complexiteit. Voor andere wil je misschien iets met onion architectuur toepassen. Dat staat je vrij. Het is vooral belangrijk dat de componenten in je service goed automatisch te testen zijn. Communicatie tussen services zal nagenoeg altijd asynchroon verlopen. Dit betekent ook dat de applicatie vaak een vorm van “eventual consistency” implementeert, of voor de minder technische lezer: dat wijzigingen in een systeem pas na verloop van tijd volledig verwerkt zijn. Wanneer je merkt dat je de behoefte hebt om services synchroon met elkaar te verbinden, is dit meestal een teken dat de domeinen niet helemaal lekker opgesplitst zijn (aka dat je mogelijk veel te kleine services aan het maken bent).

Voor- en nadelen van microservices

Microservices zijn een goede keuze voor systemen met heldere businessdomeinen en hoge eisen aan schaalbaarheid en flexibiliteit. Tegelijk vraagt het om een organisatie die volwassen is in DevOps en technische vaardigheden. Het is goed om je te realiseren dat het succesvol implementeren van microservices ook impact heeft op je organisatie en cultuur. Teams die geen ownership over hun services kunnen nemen, zullen niet in staat zijn om een succesvolle microservice omgeving op te zetten. Veel applicaties hebben echter niet de complexiteit die microservices rechtvaardigt. In die gevallen is een modulaire monoliet vaak een betere oplossing.

Beslisboom voor het gebruik van microservices

➡️ Is je organisatie volwassen in DevOps, CI/CD, monitoring en distributed systems?

  • Nee → Eerst deze volwassenheid opbouwen, anders faalt microservices.
  • Ja → Ga verder.

➡️ Is je applicatie complex genoeg om op te splitsen in duidelijke businessdomeinen?

  • Nee → Waarchijnlijk is een Monoliet prima (of modulair monoliet).
  • Ja → Ga verder.

➡️ Heb je meerdere autonome teams die onafhankelijk willen ontwikkelen en deployen?

  • Nee → Een Modulaire Monoliet is een prima alternatief voor relatief kleine organisaties (minder complex, wel gestructureerd).
  • Ja → Ga verder.

➡️ Zijn schaalbaarheid en flexibiliteit cruciaal (bijv. verschillende technologieën per domein)?

  • Nee → Modulaire Monoliet is waarschijnlijk voldoende.
  • Ja → Ga verder.

➡️ Kun je omgaan met complexiteit zoals eventual consistency, service discovery, observability en security?

  • Nee → Overweeg modulaire monoliet of hybride aanpak.
  • Ja → Microservices zijn een geschikte keuze.

Conclusie

Een microservice-architectuur is zeker niet altijd de beste oplossing, ondanks de hype. Maak een weloverwogen keuze op basis van de behoeften van je applicatie en de volwassenheid van je organisatie.