Bij Prato blijven we volop werken aan onze intelligente loonmotor Elvive. Het Elvive-applicatielandschap is samengesteld uit een reeks aparte microservices. We hadden het al eerder over microservices, zoals in de blog over konijnen en massatransport. De volgende figuur geeft een vereenvoudigd beeld van het Elvive-applicatielandschap. We maken abstractie van een aantal eerder opgezette services zoals ASR/Dimona.
Al die aparte, nieuwe (reactive) microservices (loonbepaling/berekening, DMFA, betaling, BV) hebben een eigen database. Je moet dus ook code voorzien om die data tot in die verschillende services te krijgen (met de hulp van RabbitMQ/Masstransit). Dat klinkt als extra werk … Data zitten ook gedupliceerd over de verschillende microservices. En was data duplicatie geen bad practice?
Toch kiezen we voor microservices. We motiveren in deze blog graag waarom.
Cruciale eigenschappen
De basis om voor microservices te kiezen, legden we eigenlijk meer dan een jaar geleden bij de bepaling van de Quality Attributes die relevant zijn voor Elvive. Eigenschappen zoals aanpasbaarheid, uitbreidbaarheid en onderhoudbaarheid werden en worden als cruciaal ingeschat, meer nog dan bijvoorbeeld performantie en schaalbaarheid.
We hebben natuurlijk een reeks best practises (zoals TDD) die ons een flink eind op weg helpen om tot een onderhoudbaar systeem te komen. Bij relatief kleine projecten is het voldoende als je deze practices volgt. De grote uitdaging bij een project van het genre Elvive is de omvang. Gans het project is ingeschat op meer dan 7000 mandagen werk. Om binnen een redelijke termijn tot resultaten te komen, hebben we dus een vrij grote groep mensen nodig.
Twee pizza’s
Zo’n grote groep mensen kan je niet zomaar efficiënt laten samenwerken. Jeff Bezos (Amazon) gebruikt zijn bekende Two-Pizza Team Rule om aan te geven dat een team niet groter mag zijn dan pakweg 6 personen om deftig te kunnen samenwerken. ‘Individual teams shouldn’t be larger than what two pizzas can feed.’ Als een team groter is, kan de communicatie simpelweg niet langer vlot verlopen en dat zie je onmiddellijk terug aan de kwaliteit van het opgeleverde werk.
Binnen Prato zijn we gelukkig al in dergelijke teams georganiseerd. Maar waar laat je elk van die teams dan los van de andere teams aan werken? Volgens Conway kan je teams enkel min of meer geïsoleerd van elkaar laten werken als ze bezig zijn aan de ontwikkeling van systemen die ook min of meer geïsoleerd van elkaar functioneren … microservices met andere woorden! De voornaamste redenen om over te gaan naar een microservice architectuur in een groot project zijn dus simpelweg aanpasbaarheid, uitbreidbaarheid en onderhoudbaarheid (ja, daar zijn ze weer).
Nog meer voordelen
Een reeks relatief kleine, los van elkaar levende systemen kan je ook heel fijnmazig gaan schalen. Quality Attributes zoals performantie en capaciteit zitten dus gewoon ingebakken in een dergelijke setup. In de vorige blog noemden we ook al een belangrijk voordeel: wanneer een microservice een probleem ervaart, faalt niet het hele systeem. Met zo veel voordelen, was het logisch om bij Elvive voor microservices te kiezen.
Join us
We zoeken nog collega’s. Gepassioneerd door software en niet bang voor complexe vraagstukken? Neem een kijkje op onze vacaturepagina. Eerst zeker zijn dat Prato bij je past? Laat je overtuigen door ons boek en ontdek onze unieke cultuur.
