De definitie van Microservices Architectuur

Laten we eerst het begrip Microservices Architectuur definiëren en bepalen wat het betekent voor het bredere perspectief. Als we het begrip opsplitsen in delen, kunnen we de volgende definitie(s) bepalen:

Micro – micro refereert aan kleine componenten, maar vooral aan kleine componenten die geïsoleerd zijn van andere componenten.

Service – elk component zou één bepaalde business service moeten vertegenwoordigen, focus je alleen daarop, doe niets anders en doe het goed!

Architectuur – combinatie en organisatie van een aantal componenten (Microservices) om een grotere, gecombineerde, volledig functionele applicatie te creëren.

Met andere woorden is een Microservices Architectuur dus:

Een suite van kleine, geïsoleerde business services die zo georganiseerd zijn dat ze zakelijk veel mogelijkheden bieden.

Waarom kiezen voor een Microservices Architectuur?

Nu we de definitie hebben bepaald kunnen we ingaan op de vragen als: “Waarom zouden wij de implementatie van een Microservices Architectuur moeten overwegen?” en “Wat zijn de voordelen vergeleken met meer traditionele applicatie architectuur?” Om die vragen te kunnen beantwoorden, benoem ik vijf redenen waarom wij bij INFO zo graag met een Microservices Architectuur werken.

Bron: MartinFowler.com

1. Kleinere, meer simpele services

Het simpele – en eerlijk gezegd meest voor de hand liggende – antwoord vinden we in de definitie. Een kleinere service met één doel is overzichtelijker en daarom makkelijker te onderhouden. De complexiteit van een service zou zich binnen één enkel domein (of nog kleiner) moeten afspelen. De precieze grenzen zijn niet keihard, maar moeten wel bepaald en bewaakt worden zodat de zakelijke redenen voor een enkele Microservice niet verwateren.

2. Meerdere kleinere services

Wanneer een aantal kleinere componenten in een architectuur samen moeten werken om een complete bedrijfsapplicatie in kaart te brengen, moeten we de interacties tussen deze onderdelen scherp in de gaten houden. Dit is waar de complexiteit van een enkele, grote applicatie duidelijk tot uiting komt, zelfs als we dat niet kunnen zien. Deze complexiteit moet worden ontworpen en onderhouden met dezelfde striktheid en passie als de individuele services. Een ander voordeel van deze kleine services is dat we ze eenvoudig afzonderlijk kunnen schalen, waardoor de back-upservers effectiever kunnen worden gebruikt.

3. Vele handen maken licht werk

Iets minder voor de hand liggend misschien, zijn de voordelen die het hebben van kleine, individuele services met zich meebrengt. Eén van de voordelen van kleine services is dat ze, mits goed gebouwd, horizontaal geschaald kunnen worden: waar verschillende instanties van dezelfde dienst de last gezamenlijk dragen. Wanneer we volledig gebruik zouden maken van Orchestration Platforms, kunnen we de services zelfs automatisch op- en af laten schalen, afhankelijk van de vraag.

4. Eén team, één focus

De mantra die in ons vakgebied rondzingt en die we bij INFO ook zeer serieus nemen is dat “de structuur van je organisatie wordt gereflecteerd in het soort applicaties dat je maakt.” Wij zorgen ervoor dat we multidisciplinaire teams hebben die zich uitsluitend focussen op de wensen van de klant die de Microservice levert als onderdeel van de complete applicatie.

5. Kortere time to market

Bovendien kunnen, naarmate de vraag verandert, de benodigde veranderingen aan een enkele service uitgerold worden zonder de applicatie volledig te beïnvloeden; het welbekende concept “continuous deployment“. Dit verkort de time to market voor nieuwe functionaliteiten aanzienlijk.

INFO’s ervaringen met Microservices Architectuur

Bij INFO maken we gebruik van een Microservices Architectuur, omdat het keer op keer heeft bewezen dat het voor ons de beste manier is om gevraagde veranderingen snel en consequent door te voeren.

Lessons learned

Hoewel het veel voordelen heeft, heeft een Microservices Architectuur ook zo zijn nadelen en daar hebben wij flink van geleerd.

Het definiëren van de juiste grenzen van de business services en deze beschermen tegen scope creep, is een constante cyclus van validaties die een team moet doorlopen. Doordat van het team wordt verwacht dat zij snel functionaliteiten kunnen leveren, kan dit wrijving veroorzaken met de definitie van de reikwijdte van een Microservice. Wanneer de keuze wordt gemaakt om een Microservice uit te breiden, kan het bovendien voorkomen dat de micro een monoliet wordt en dat de korte termijn winst snel in lange termijn kosten veranderen.

En een enkel team dat focust op de development van Microservice applicaties en de omgeving waarin ze opereren heeft – in tegenstelling tot een meer verzuilde, traditionele benadering waarbij development en operationele taken de verantwoordelijkheden van twee teams zijn – veel bredere kennis binnen het team nodig. De beste manier is om een operationeel teamlid toe te voegen: de DevOps engineer. Door deze kennis over hoe het team opereert te gebruiken, kunnen we ons ervan verzekeren dat de Microservice soepel in de applicatie-suite wordt geïntegreerd.

De theorie versus de praktijk

Normaliter gebruiken we Docker om elke Microservice mee te bouwen, omdat dit de de facto-standaard binnen de branche is en er ontelbaar veel Docker-afbeeldingen zijn die kunnen worden gebruikt als de basis waar een service op draait.

We gebruiken Docker Orchestration Platforms Kubernetes, Mesos/Marathon en AWS, aangezien deze een uitrol van implementaties zonder uitval (downtime) bieden en het schalen van individuele services en een monitoring- en logboekconnectiviteit mogelijk maakt die vereist zijn voor operationele doeleinden. Als de situatie daarom vraagt, kunnen we ook de Serverless Architectuur van de cloud gebruiken. Onze multidisciplinaire development en operationele teams hebben zeer veel ervaring met Microservices Architectuur en vertellen je er graag meer over.

Conclusie

Wat we bij INFO door de jaren heen hebben geleerd over het bouwen van Microservices Architectuur is dat de voordelen aanzienlijk kunnen zijn, vergeleken met meer traditionele architecturen. Om het maximale uit Microservices te halen, zorgen wij ervoor dat onze focus op die gebieden ligt waar de meeste winst te behalen valt; het samenstellen van een multidisciplinair team om de Microservices te onderhouden, de services klein en overzichtelijk te houden, de focus te behouden wanneer het op time to market aankomt, de organisatie van het uitrollen op zich te nemen en voor schaalbaarheid te zorgen.

Referenties

Er zijn ontzettend veel blogs, boeken en tweets geschreven over Microservices Architectuur, maar dit zijn er een paar waar wij zelf enthousiast over zijn:

• Microservices – a definition of this new architectural term door Martin Fowler
• Microservices Architecture principle #1: Each Microservice delivers a single complete business capability door Jan Vermeir