Microservices is de laatste tijd het nieuwe buzzword in applicatie-architectuur. Het doel is om kleinere, doelgerichte applicaties te bouwen. Het is een antwoord op de problemen, die ontstaan in de alom vertegenwoordigde, complexe, monolithische applicaties. Onder een monoliet verstaan we applicaties, die heel veel verschillende businessfunctionaliteit bevatten en als één geheel worden gedeployed. Een groot nadeel van zo’n architectuur is dat een wijziging op één stuk businessfunctionaliteit leidt tot een nieuwe deployment van de gehele applicatie.
Een belangrijk element in een microservices-architectuur is het groeperen van functionaliteit. Als object-georiënteerde programmeurs zijn we wel gewend om de businesslogica te ordenen en te structureren op class- en packageniveau. Microservices past deze technieken toe op applicatieniveau.
Elke applicatie, groot of klein, heeft zijn eigen businessdomein. Doordat je nu een traditionele applicatie met een vaak complex businessmodel opdeelt in meerdere applicaties, wordt het totale businessmodel inzichtelijker. Immers heeft elke microservice zijn eigen domein, dat een onderdeel is van het totale businessmodel van je uiteindelijke applicatie.
De interacties tussen microservices heb je door de splitsing expliciet gemaakt. Dit geeft niet altijd een overzicht. Er kunnen heel veel interacties tussen microservices ontstaan naar mate je landschap van services groeit.
De grenzen tussen deze deeldomeinen zijn daarom cruciaal. Het is de kunst om als team te bepalen welke functionaliteit nu bij welke domein (lees: microservice) hoort. De ervaring leert dat een generieke interface uiteindelijk leidt moeilijk onderhoudbare services.
Het is verstandig om de interfaces tussen microservices zeer specifiek te benoemen. Het benoemen van grenzen en de interfaces tussen services vraagt om een goede, eenduidige, afstemming tussen de businessexperts, ontwikkelaars en beheer.
De technieken uit Domain Driven Design geven je verscheidende handvatten om deze grenzen tussen domeinen te bepalen en zo je applicatie op te delen in verschillende microservices. Het voert wat ver om deze in dit artikel te behandelen, maar het is zeker een aanrader om je hierin te verdiepen als je met microservices aan de slag wilt gaan.
In deze serie beschrijven we in een aantal cases hoe verschillende projecten aan de slag zijn gegaan met microservices. Uit de verschillende cases blijkt dat het onderwerp veel breder is dan enkel de manier waarop je code organiseert. Het heeft een directe impact op je manier van werken, je organisatie en het opleveringsproces. Dit effect is niet te onderschatten.
Je ondergaat een leerproces met deze verandering van architectuur. Daar is geen goed of slecht in. Stadia zijn ook lastig te herkennen. Misschien zijn ze zelfs onwenselijk om te benoemen, omdat ze als meetlat gaan dienen. En het daarmee vergelijken leidt eerder af van de onderliggende uitdagingen.
Zoals zo vaak is het beter om klein te beginnen en je successen en tegenslagen te blijven communiceren en analyseren. Op die manier kom je vanzelf uit op het uiteindelijke doel: een model dat het beste past bij je organisatie en bedrijfsvoering. En wie weet… Misschien is het wel een vorm van microservices waar de volgende auteurs over spreken.