We kennen allemaal wel het klassieke monolithisch applicatiemodel. Vaak gelaagd ontworpen met een UI, Business laag en database. In veel enterprise omgevingen kom je complexe Service Oriënted Architecture (SOA) omgevingen tegen. In dit geval is de N-tier monolithische applicatie opgesplitst in verschillende (web)services. Wat je vaak ziet dat deze webservices erg afhankelijk zijn geworden van elkaar. Een waar web van services die elkaar aanroepen, al dan niet via een centrale Enterprise Service Bus (ESB). Je ziet vaak ook dat vele services op een en dezelfde SQL-database opereren. Eigenlijk heb je dan alsnog een monolithisch systeem, alleen verspreid over veel computers. Het idee van SOA komt uit de jaren 90, dus voor het ontstaan van cloud platformen zoals Microsoft Azure, AWS en Google Cloud. Microservices is de volgende evolutie, met de voordelen van cloud computing.
Wat is een microservice?
Een formele definitie van een microservice is er niet, maar we kunnen wel in het kort een aantal eigenschappen noemen die microservices onderscheiden:
- Ze hebben een eigen datastore, zijn verantwoordelijk voor die data en hebben geen directe toegang tot de datastore van andere services.
- Ze zijn ontworpen omtrent specifieke bedrijfsprocessen.
- Ze zijn apart uit te rollen, zonder downtime van andere microservices.
- Een systeem of applicatie wordt opgebouwd door een groep van microservices.
- Doordat een microservice bestaat uit de interfaces, business logica en de datastore, is deze als eenheid op te schalen over meerdere servers. Op deze manier kan om de juiste redenen de juiste functionaliteit opgeschaald worden.
Reactive Manifesto
Met een enkele REST-API i.c.m. dataopslag ben je er natuurlijk niet. Om een goede robuuste architectuur neer te zetten adviseer ik om volgens het Reactive Manifesto je microservices te implementeren.
Het manifesto beschrijft de principes van een Reactive System. We spreken van een Reactive System wanneer het systeem voldoet aan een viertal eigenschappen. In het kort:
- Reactief (Eng: Responsive)
Het systeem reageert snel en consistent op communicatie van gebruikers of andere systemen. Problemen in het systeem kunnen snel en effectief afgehandeld worden. Dit bevordert het vertrouwen in het systeem. - Weerbaar (Eng: Resilient):
Het systeem blijft altijd reactief, ook al faalt een component binnen het system. Het system is opgebouwd uit losse afgebakende componenten. Als daar één van faalt, blijven andere componenten doorweken. Hierdoor blijft het systeem reactief en blijft de storing beperkt tot een zo klein mogelijk deel. - Elastisch (Eng: Elastic)
Het systeem blijft reageren, ook onder hoge werkdruk. De componenten zijn dusdanig ontworpen, zowel qua gedrag als infrastructuur, dat deze automatisch kunnen op en afschalen afhankelijk van de benodigde rekenkracht. - Bericht Gestuurd (Eng: Message Driven)
Als de componenten met elkaar communiceren gebeurt dat door het asynchroon uitwisselen van berichten. Hierdoor blijven de componenten onafhankelijk van elkaar functioneren. Dit bevordert de andere drie eigenschappen.
Figuur 1: Reactive Systems principes. (Bron: https://www.reactivemanifesto.org)
Domain-Driven Design
Misschien wel de belangrijkste eigenschap van een microservice architectuur is dat de microservices gebouwd worden omtrent bedrijfsprocessen. Domain-Driven Design (DDD) sluit erg aan bij het ontwikkelen van deze architectuur. Een term uit DDD die vaak terugkomt bij het ontwerpen van microservices is ‘Bounded Context’. Als men vraagt hoe groot een microservices moet zijn, is vaak het antwoord om een bounded context als uitgangspunt te nemen. Kort gezegd is een bounded context alles omtrent een afgebakend functioneel deel van het probleem domein (Engels: “subdomain”). Dus het model en de business functionaliteiten, maar ook infrastructuur en deployment scripts en dergelijke. Bounded context is dus een abstract begrip. Een uitgebreide uitleg met voorbeeld kun je vinden op in mijn blog artikel Domain-Driven Design: What are Bounded Contexts and why should you define them?
Microservices in de Microsoft Cloud
De cloud is bijzonder geschikt voor het realiseren van een microservices architectuur. De diensten en infrastructuur van Microsoft Azure bieden hier alle middelen voor. App Services als Azure Functions bieden Consumption Plan prijsmodellen waardoor je met lage kosten kunt instappen. Cosmos DB is een multi-model database. Voor elke microservice kun je je eigen data store bepalen. Table, Graph, Document, Cosmos DB kan het allemaal. Daarbij krijg je replicatie functionaliteit met de eenvoud van een druk op de knop.
Voor bedrijven die liever een oplossing willen beheren met containers is er Azure Kubernetes Service (AKS) beschikbaar en dan is er ook nog Service Fabric. Je beheert niet de hardware, maar wel de virtual machine clusters met Service Fabric software. Hierop bouw je je microservices. Je begint met gereserveerde computerkracht. De instapkosten zijn dan ook veel prijziger dan de Platform-as-a-Service diensten als App Service. (Microsoft ontwikkelt momenteel ook Service Fabric Mesh waarbij ook de infrastructuur beheerd wordt door het platform. Deze is echter nog in preview. Het prijsmodel is nog onbekend)
Het mooie aan een microservices architectuur is dat je elke microservice kun baseren op eigen specifieke technologieën. Ze zijn autonoom en communiceren via berichten. Microsoft Azure heeft meerdere diensten waarmee je dit kunt opzetten. Service Bus, Event Hubs, Event Grid. Je kunt dus prima een oplossing hebben waarbij de ene microservice in de cloud draait en de ander on-premise. De een gebouwd op basis van Azure Functions en Redis cache, terwijl deze berichten uitwisselt met microservice in een Service Fabric omgeving op Microsoft Azure. Dit is een van de krachten van microservices. Je bent flexibel in welke technologie je wilt gebruiken.
Vaak wordt gedacht dat een microservice gelijk is aan een enkele technische service. Dit is een vaak voorkomende misconceptie. Microservices zijn zoals gezegd gebaseerd op bedrijfsprocessen, niet technische processen. Een microservice kan bijvoorbeeld bestaan uit een API-service (business logica), repository service, logging service etc. Je kunt een microservice dus eigenlijk zien als een soort mini-applicatie. Even terugkomende op de vraag hoe groot een microservice – zo’n mini applicatie – mag zijn. Deze is dus altijd kleiner dan een bounded context. Zo behouden ze functioneel hun autonomie. Dit maakt je oplossing beter onderhoudbaar en uitbreidbaar. Daarbij kunnen de microservices onafhankelijk blijven functioneren. Dit levert een stabiel en reactief systeem op. En dát zijn de waarden van een Reactive Microservices op Microsoft Azure.
Erik Hoogendoorn – Microsoft Cloud Consultant
