Een hype als microservices lijkt uit het niets op te komen. Niets is minder het geval: een aantal paradigma verschuivingen liggen aan de grondslag waardoor microservices nu mogelijk zijn geworden. In een reeks blogs zal ik Microservices in een historisch perspectief plaatsen en daarmee verklaren waarom juist nu de hype is kunnen worden die het is. In deze blog zal ik, staccato, een overzicht geven van al die ontwikkelingen; in de volgende blogs zal ik telkens 1 onderwerp verder uitdiepen.
Microservices, als software architectuur stijl, ontwikkelt een applicatie als een suite van relatief kleine services, die elk in een eigen omgeving draaien en met elkaar communiceren op basis van eenvoudige, “lichtgewicht” mechanismen. Deze services zijn gebouwd rond business capabilities, en worden onafhankelijk van elkaar, volledig geautomatiseerd, gedeployed. Er is een minimum aan gecentraliseerde coördinatie van de services, die op basis van verschillende technologieën kunnen worden ontwikkelt.
In de vergelijking met andere stijlen worden microservices vaak afgezet tegen ‘Monolieten’. Wat mij betreft is het beter het te vergelijken met Service Oriëntatie (hierna SOA): het is vooral een reactie op de lessen die we daaruit hebben geleerd. In essentie is het een klassieke omslag van centralisatie naar decentralisatie: daar waar SOA een sterke centrale coördinatie verlangt, propageert Microservices een sterke decentralisatie.
Sinds de opkomst van SOA zijn een aantal paradigma’s verschoven:
- wereldbeeld: het besef dat de wereld een complexe samenstelling van verschillende wereldbeelden is; Domain Driven Design leert ons dat informatie een “bounded context” heeft, en dat het daarbuiten niet bruikbaar is;
- hergebruik: hergebruik was vooral een middel om kosten te besparen en een middel om consistentie in je gegevens te bereiken; beiden blijken minder voor de hand te liggen dan oorspronkelijk bedacht. Hergebruik over verschillende “bounded contexten” heen, is een slecht idee waar veel onnodige complexiteit door wordt geïntroduceerd;
- consistentie: vanuit de database transacties is ACID een mantra dat zich slecht laat verenigen met asynchrone communicatie, een kern van Microservices; door permanente consistentie los te laten, zijn nieuwe mogelijkheden ontstaan;
- eindigheid van resources: de wet van Moore, dat elke twee jaar het aantal schakelingen op een chip verdubbeld, gaat nog steeds op; alles wordt sneller en groter (intern geheugen bijvoorbeeld), waardoor we minder “zuinig” hoeven te zijn;
- doorlooptijden: er zijn nog organisaties die een paar keer per jaar releasen, maar ze worden zeldzaam; meerdere releases per dag wordt de norm;
Deze paradigma wijzigingen worden ondersteund door een gewijzigde kijk op het ontwikkelen van informatie systemen, die hier ook niet los van gezien kunnen worden:
- DDD, Domain Driven Design: het opsplitsen van het probleemdomein in subdomeinen die elk een eigen taal hebben; tussen de subdomeinen moet zorgvuldig worden “vertaald” om verwarring te voorkomen;
- CQRS, Command Query Responsibility Segregation: het strikt scheiden van de logica die commando’s verwerkt (lees toestandswijzigingen in je model doorvoert) en de logica die die informatie beschikbaar stelt om gelezen te worden; zowel de complexiteit wordt gereduceerd, maar ook de schaalbaarheid neemt toe;
- ES, Event Sourcing: ontkoppelen op basis van een ‘publish subscribe’ mechanisme, waarbij de “wereld” wordt vastgelegd door de gebeurtenissen (events) die plaatsvinden;
- Technological enablers: de cloud, container technologie, het automatiseren van het testen en deployments, allemaal ontwikkelingen die de decentralisatie slag ondersteunen;
Voordat Microservices worden uitgeroepen als heilige graal is een waarschuwing op zijn plaats: zoals bij elke decentralisatie golf ligt chaos op de loer. Er zijn een aantal punten die zorgvuldig moeten worden bestuurd:
- governance: om overzicht te houden zijn een vergaande automatisering en “failure isolation” een vereiste; het falen van 1 service mag nooit leiden tot het meetrekken van andere services;
- consistentie: het loslaten van ACID transacties moet verklaarbaar zijn in de context van de gebruikers ervaring; het is niet geoorloofd dat een gebruiker een adreswijziging opvoert en in het volgende scherm het oude adres weer terug ziet …
- decentralisatie: is niet alleen technologische en informatiekundige omslag maar moet ook (en vooral) organisatorisch worden ondersteund;
- logging en audit trails: door de verhoogde complexiteit op het centrale niveau (decentraal wordt er vereenvoudigd) is een goede coördinatie van logging en audit trails een vereiste;
In volgende blogs zal ik elk onderwerp verder uitwerken en de relatie naar Micro Services toelichten.
