Over konijnen en massatransport

Dit is de eerste van een reeks blog posts. In deze serie geven we je een blik achter de schermen van de architectuur van onze intelligente loonmotor.

Over marters en augurken hebben we het al eens gehad. Nu willen we het over konijnen hebben 🙂

Bij Prato werken we volop aan onze gloednieuwe loonmotor. Het project bestaat uit meerdere microservices. Als je een microservice architectuur omarmt, is de algemene regel dat elke microservice zijn eigen database heeft.

Waarom een database per microservice, hoor ik je denken. De nadelen van een gezamenlijke database voor meerdere microservices zijn legio:

• Als één team een tabelstructuur wijzigt, moeten andere teams mogelijk ook aanpassingen doen aan hun microservices.
• Een veld kan voor iedere microservice een andere betekenis hebben. Hierdoor weet niemand wat er juist in dit veld thuis hoort en in welk formaat. Iedere microservice heeft mogelijk ook andere velden nodig binnen één tabel.

Als je kiest voor een aparte database per microservice is het veel makkelijker om de microservices afzonderlijk van elkaar te laten evolueren zonder bovenstaande conflictsituaties.

Eigenaar van eigen data

Aparte databases benadrukken ook het feit dat iedere microservice eigenaar (master) is van zijn eigen data. Zo bewaart de loonbepaling microservice de loonberekeningen. De betaling microservice is dan weer eigenaar van gegevens over betalingen. PratoFlex bijvoorbeeld is eigenaar van gegevens over werknemers, contracten, prestaties en premies. De loonbepaling service heeft deze gegevens ook, maar is er geen master van en laat dus niet toe om deze gegevens te editeren.

We kunnen dus 2 belangrijke regels vastleggen:

• Microservices delen geen database.
• Een microservice heeft geen toegang tot de database van een andere microservice.

Hoe zorg je er dan voor dat er informatie kan worden uitgewisseld tussen deze microservices?

Messaging to the rescue

In een microservices architectuur gebruik je een messaging systeem voor het uitwisselen van informatie. Voor onze nieuwe loonmotor kozen we RabbitMQ. En we zitten in goed gezelschap 🙂 Ook Netflix, Instagram, 9Gag, SendGrid en vele anderen draaien op RabbitMQ.

In plaats van data te gaan lezen uit andere systemen draaien we de rollen dus om. Als er binnen een microservice iets gebeurt (bijvoorbeeld een wijziging van een werknemer of een nieuwe prestatie) publiceert deze microservice een bericht. Nemen we het voorbeeld van een wijziging aan een werknemer dan is dit een WerknemerGewijzigd bericht.

Andere microservices kunnen op hun beurt aangeven of ze al dan niet geïnteresseerd zijn in dit bericht. Ze kunnen bij het ontvangen van een bericht bijvoorbeeld hun eigen database updaten of een actie ondernemen.

We maken een onderscheid tussen 2 verschillende soorten berichten:

• Commands
  Een command bericht plaats je op de bus als je wil dat er een bepaalde actie wordt ondernomen. Je benoemt deze in de gebiedende wijs. Een voorbeeld van een command bericht is SluitLoonperiodeAf.
• Events
  Een event bericht wordt op de bus geplaatst als er zich een gebeurtenis heeft voorgedaan. Zo’n event wordt geschreven in de voltooid tegenwoordig tijd. Een voorbeeld van een event bericht is LoonperiodeAfgesloten.

Is dit dan wat ze vroeger een Enterprise Service Bus noemden?

Neen, allesbehalve. RabbitMQ behoort niet tot het rijtje van zware Enterprise Service Bus producten zoals Oracle Service Bus, BizTalk en MQ Services. Het is een lichtgewicht server die enkel gebruikt wordt voor het verzorgen van het berichtenverkeer tussen onze microservices. Zo stoppen we bijvoorbeeld geen enkele logica in de bus. Dit in tegenstelling tot Enterprise Service Bus producten.

OK, klinkt goed. Is het allemaal rozengeur en maneschijn?

Zo goed als 🙂 Messaging lost een heleboel problemen op. Maar je gaat van synchrone processen naar asynchrone processen. Berichten kunnen met vertraging aankomen. Ze kunnen in een error queue terechtkomen. Ook de volgorde van het aankomen van berichten is niet gegarandeerd. Gelukkig staan we op de schouders van reuzen en zijn er oplossingen voor al deze problemen. Meer daarover later… (tipje van de sluier: eventual consistency).

Vind je deze blogposts leuk of wil je meer weten over welke technologie we binnen Prato gebruiken, neem dan zeker eens een kijkje op onze technology blog.

Psssst: we zijn nog steeds op zoek naar collega’s. Gepassioneerd door software? Neem zeker eens een kijkje op onze vacaturepagina.