Microservices zijn de laatste jaren in opkomst. Het is de mogelijkheid om een grote applicatie (monoliet) op te knippen in kleinere stukjes om deze zo makkelijker te kunnen ontwerpen en beheren. Dat klinkt aantrekkelijk, maar microservices zijn niet alleen maar rozengeur en maneschijn. In de opstartfase van een nieuwe applicatie creëert het een zekere overhead, wat juist weer resulteert in meer werk. Wanneer is het handig om over te stappen op microservices? En wanneer juist niet?
Voordelen microservices
Het woord ‘monoliet’ doet je wellicht denken aan een reusachtige meteoriet, maar is in wezen niets anders dan een term waarmee binnen de IT een geheel wordt aangegeven. Een applicatie opgebouwd uit één codebundel. Met microservices is het mogelijk om deze codebundel op te knippen in kleine stukjes en onafhankelijk van elkaar in containers of lambda functies op te bouwen. Door ze vervolgens aan elkaar te koppelen door middel van API’s werken ze als een geheel. Dat heeft een aantal voordelen:
- Programmeurs kunnen sneller werken door per team een klein onderdeel op te pakken van de applicatie
- Bij omvangrijke apps waaraan veel mensen tegelijkertijd werken is het makkelijker om ze te beheren en verder uit te bouwen.
Groot en klein
Dat laatste geeft gelijk aan waar de kink in de kabel zit. Voor grote apps als Google Maps, Uber of Thuisbezorgd is het opsplitsen in Microservices onontbeerlijk. Dergelijke apps zijn continu in ontwikkeling en er werken grote groepen ontwikkelaars tegelijkertijd aan. Door op te splitsen kan men parallel aan functionaliteiten werken.
Voor veel apps die nog in de startfase zitten, is een dergelijke benadering overkill en kan contraproductief werken. Door je app vanaf de start agressief in microservices op te willen knippen verspil je veel tijd aan het perfectioneren van het ontwikkelproces, terwijl er helemaal nog geen volledig beeld is over hoe gebruikers de applicatie benutten en welke features zich lenen om als een apart component (microservice) door te ontwikkelen.
Wanneer overstappen?
Er is niks mis met een “monolitische” opstartfase. Je wilt zo snel mogelijk functionaliteit op eindgebruikers testen via een zogeheten “minimal-viable-product” (MVP). Dat levert vrijwel gegarandeerd nieuwe inzichten op waardoor je terug naar de tekentafel moet. Het is dan handig om geleidelijk naar een modulaire structuur te werken door telkens stukjes code te verhangen. Schroom echter ook niet om componenten weer samen te voegen indien een component op zichzelf geen toegevoegd waarde heeft. Voorkom dat microservices zelf het doel worden en laat de weg naar microservices vooral een organisch proces zijn. Microservices ontstaan vaak vanzelf uit noodzaak. Bijvoorbeeld omdat er een bottleneck is in de performance van een bepaalde functionaliteit, of indien er een extra ontwikkelteam aanhaakt dat focust op een selectief stuk van de code.
Wil je meer weten over de voor- en nadelen van microservices? Wij helpen je graag verder! Neem contact op met één van onze experts voor meer informatie.
