Belangrijkste punten
- Een microservices-architectuur splitst een applicatie op in afzonderlijke, onafhankelijke services die elk een specifieke bedrijfsfunctie vervullen.
- Anders dan bij monolithische systemen maken microservices onafhankelijke implementatie, gerichte opschaling en geïsoleerde fouttolerantie per component mogelijk.
- De belangrijkste voordelen van microservices zijn betere schaalbaarheid, parallelle workflows tussen teams, technologische flexibiliteit en veerkrachtigere applicaties.
- Duidelijke servicegrenzen zijn cruciaal: slecht afgebakende services leiden tot gedistribueerde monolieten die wel de overhead van microservices meebrengen maar nauwelijks de voordelen.
- Microservices passen het best bij grote, complexe systemen met uiteenlopende eisen aan schaalbaarheid en beschikbaarheid, terwijl eenvoudigere systemen prima uit de voeten kunnen met een monolithische architectuur.
Moderne workloads vragen om applicaties die onvoorspelbaar verkeer, frequente updates en een groeiend aantal functies aankunnen. Een microservices-architectuur lost dit op door elke microservice onder te brengen in een eigen codebase die afzonderlijk uitgerold en geschaald kan worden.
In deze gids leest u wat microservices precies zijn, waarin ze verschillen van monolithische systemen en hoe u bepaalt of deze architectuur de juiste keuze is voor uw omgeving.
De microservices-architectuur begrijpen
Een microservices-architectuur is een manier van software bouwen waarbij applicaties worden opgedeeld in kleinere services die onafhankelijk van elkaar werken. In plaats van elke functie in één geheel te verpakken, wordt elke mogelijkheid van de applicatie als een eigen service beheerd.
Elke microservice:
- Is verantwoordelijk voor één duidelijk omschreven service en blijft binnen die functie.
- Beheert een eigen database in plaats van één centrale database te delen met de rest van het systeem.
- Communiceert via API’s zodat alle onafhankelijke applicaties samen een samenhangend geheel vormen.
- Werkt zelfstandig waardoor teams één service kunnen bijwerken, herstarten of opschalen zonder de hele applicatie opnieuw uit te rollen.
Met deze applicatiearchitectuur creëren IT-teams een gedistribueerde applicatieomgeving waarin componenten zich los van elkaar kunnen ontwikkelen. Zo werken verschillende teams parallel en schalen ze services mee met de vraag, terwijl storingen niet van de ene codebase naar de andere doorslaan.
Wat is een microservice en hoe verschilt die van monolithische systemen?
Een vergelijking naast elkaar maakt het duidelijker:
| Vergelijkingspunten | Monolithische systemen | Microservices |
| Structuur | Alle functionaliteit zit in één codebase en draait als één geheel. | De functionaliteit is verdeeld over onafhankelijke services die apart draaien. |
| Implementatiestrategie | De eerste implementatie is eenvoudig, maar bij elke wijziging moet de volledige applicatie opnieuw worden uitgerold. | Elke service kan afzonderlijk worden bijgewerkt zonder gevolgen voor het hele systeem. |
| Koppeling tussen componenten | Componenten delen code, geheugen en database. | Services communiceren uitsluitend via duidelijk omschreven API’s. |
| Opschaling | Opschalen betekent dat de hele applicatie mee moet veranderen. | Afzonderlijke services kunnen los van elkaar worden geschaald naar gelang de vraag. |
| Fouttolerantie | Eén storing kan de hele applicatie platleggen. | Storingen blijven beperkt tot één service waardoor de rest van het systeem blijft werken. |
| Technologiestack | Vastgelegd op één taal en één kader voor de volledige codebase. | Elke service kan de taal, het kader of de database gebruiken die het best bij de functie past. |
| Teamworkflow | Meerdere teams moeten in dezelfde codebase werken wat samenwerking tussen teams vereist bij elke release. | Teams zijn eigenaar van afzonderlijke services en kunnen parallel ontwikkelen, testen en uitbrengen. |
Microservices worden meestal ingezet om schaalbaarheid en de specifieke eisen van evoluerende systemen te ondersteunen. Deze architectuur helpt teams ook om parallel te werken met verschillende talen of kaders waardoor ontwikkelcycli korter worden. De betere fouttolerantie van microservices voorkomt bovendien dat problemen zich over componenten verspreiden.
De eigenschappen die microservices krachtig maken, brengen echter ook ongewenste extra complexiteit met zich mee. Microservices werken bijvoorbeeld niet met gedeelde databases waardoor het afstemmen van gegevens lastig wordt, naast mogelijke componentstoringen die op meerdere plekken in de omgeving kunnen ontstaan.
Servicegrenzen bepalen binnen een microservices-architectuur
Grenzen bepalen de reikwijdte van een microservice: welke service hij levert, welke gegevens hij bezit en waar dat eigenaarschap ophoudt. Een betaalservice beperkt zich bijvoorbeeld tot transacties en betaalgegevens; die reikwijdte hoort zich niet te bemoeien met workflows rond logistiek.
Goed afgebakende grenzen zorgen ervoor dat microservices aansluiten op de functies die ze daadwerkelijk uitvoeren, beperken afhankelijkheden tussen services en maken onafhankelijke opschaling mogelijk.
Slecht afgebakende grenzen leveren daarentegen ruis op doordat services elkaar voortdurend aanroepen wat netwerkverkeer en latency vermenigvuldigt. Daarnaast kan dit prestatieknelpunten veroorzaken en de complexiteit van het systeem vergroten.
Om optimaal te profiteren van een microservices-architectuur, moeten teams vooraf grenzen vastleggen die aansluiten op de business en die verfijnen naarmate systemen evolueren. Zonder goed gedefinieerde grenzen, eindigen organisaties met een gedistribueerde moloch die wel de overhead van microservices meebrengt maar niet de flexibiliteit.
Bepalen of een microservices-architectuur bij u past
Voordat u voor microservices kiest, weegt u eerst af waar ze in uw omgeving passen, waar niet en welke alternatieven er naast een microservices-architectuur bestaan.
Wanneer microservices de juiste keuze zijn
Microservices leveren de meeste waarde in omgevingen waar de eisen verder gaan dan wat monolithische systemen kunnen bieden. Ze zijn meestal de juiste keuze wanneer uw organisatie aan de volgende criteria voldoet:
- Grote en complexe systemen: overweeg microservices als uw applicatie zo groot is geworden dat één codebase moeilijk veilig te onderhouden of uit te brengen is.
- Teams moeten parallel werken: meerdere teams dragen bij aan hetzelfde systeem en een gedeelde codebase is een knelpunt in de afstemming geworden.
- Uiteenlopende eisen aan schaalbaarheid: sommige functies verwerken veel zwaardere belasting dan andere en moeten afzonderlijk kunnen opschalen.
- Continuous delivery is een prioriteit: kies voor microservices als uw organisatie vaak releases uitbrengt en zich geen uitvaltijd kan veroorloven bij nieuwe versies.
Wanneer microservices niet de juiste keuze zijn
Soms levert een eenvoudigere architectuur betere resultaten op zonder de operationele overhead van een microservices-architectuur. Vermijd microservices als uw omgeving aan het volgende voldoet:
- Eenvoudige applicaties: een moloch kan eenvoudige functionaliteit leveren met veel minder infrastructuur en complexiteit.
- Teams missen ervaring: zonder kennis van service-orkestratie, monitoring en foutafhandeling veroorzaakt deze architectuur meer problemen dan ze oplost.
- Beperkte infrastructuurresources: microservices vragen om tooling en capaciteit die kleinere omgevingen misschien niet hebben.
- Onafhankelijk opschalen is niet nodig: als de componenten van een app in een beheersbaar tempo samen opschalen, brengt het opsplitsen ervan alleen onnodige kosten met zich mee.
Enkele alternatieven voor een microservices-architectuur
IT-teams hoeven niet te kiezen tussen uitsluitend microservices of monolithische applicaties. Er zijn verschillende architectuurmodellen die daartussenin zitten en die beter kunnen passen bij de eisen en mogelijkheden van uw omgeving.
Modulaire monolithische architectuur
Een modulaire monolithische architectuur is één uitrolbare eenheid die intern is opgedeeld in gescheiden modules. Zo combineren IT-teams de duidelijke interne scheiding van microservices met de operationele eenvoud van een moloch. Deze architectuur schaalt echter als één geheel wat de flexibiliteit van elke module beperkt.
Service-oriented architecture
Een service-oriented architecture (SOA) brengt verschillende functionaliteiten onder in gedeelde services, vaak gecoördineerd via een enterprise service bus (ESB). Dit stimuleert hergebruik van services en kan integraties binnen de hele organisatie ondersteunen. Het biedt interoperabiliteit tussen verschillende services, maar vertragingen, wijzigingen of storingen in de ESB werken door in elke aangesloten service.
Begrijp een microservices-architectuur voordat u ermee aan de slag gaat
Microservices ondersteunen schaalbaarheid en bieden flexibiliteit in beheer, maar ze brengen aanzienlijke overhead met zich mee. Door de eisen van uw omgeving af te zetten tegen die afwegingen, bepaalt u of een eenvoudiger systeem u beter van dienst is of dat de stap naar microservices de moeite waard is.
