Echter, als je voor het eerst leest over de eindeloze voordelen die een microservice architecture biedt, kan het lijken of er niet veel ruimte is voor fouten. In de praktijk kunnen al deze mogelijkheden namelijk niet bestaan zonder een goede basis en je weet (of zou in elk geval moeten weten) dat jouw toekomstige succes afhangt van het ontwerp van de microservice architectuur.

Een belangrijk principe dat we loose coupling noemen geeft aan wat de development-teams moeten bereiken voor een succesvol microservice architectuur ontwerp. In deze blog zal ik wat verder ingaan op dit principe.

Het idee achter microservice architecture is simpel: Om een groot systeem te ontwerpen en bouwen moet je de functies opsplitsen in relatief kleine, single-purpose en loosely coupled services.

Loose coupling

Een loosely coupled system is een systeem waarin elk van de componenten geen of weinig kennis heeft of gebruikt van de definities van andere componenten. Coupling van classes, interfaces, data en services vallen allemaal onder de deelgebieden. Loose coupling is het tegenovergestelde van tight coupling.

Kort samengevat betekent loose coupling in microservice architectuur dat microservices maar weinig over en van elkaar hoeven te weten en dat veranderingen aan de ene dienst de anderen niet mag beïnvloeden.

Waarom is loose coupling zo belangrijk in microservice architectuur?

Wanneer microservices niet op de juiste manier opgesplitst worden, creëert dit tight coupled microservices die alle nadelen van een monolith hebben en alle complexiteit van microservice, oftewel distributed monolith. Een architectuur die loose coupling inzet heeft verschillende voordelen, zoals:

• Loosely coupled services verhogen de mogelijkheid om te blijven ontwikkelen, moedigen verschillende veranderingen en nieuwe oplossingen aan, vooral in situaties waarin het systeem zich aan zou moeten passen aan veranderingen in de omgeving. Zoals we allemaal weten; in software-development verandert alles de hele tijd!
• Loosely coupled services verhogen de optimale efficiëntie van de architectuur. Ze stellen ons in staat om de connectie tussen services te verbreken of opnieuw te configureren. Daardoor nemen ook de coördinatiekosten af.
• Loosely coupled services verhogen de wendbaarheid wat het mogelijk maakt om snel kleine, gefocuste stukjes van de functionaliteit te itereren, wat even zo snelle resultaten oplevert.
• Loose coupling maakt het mogelijk om veranderingen onafhankelijk van elkaar door te voeren, wat de inzetbaarheid vergroot.
• De onafhankelijkheid van het systeem neemt belemmeringen bij het wachten op de andere service-implementatie(s) weg. Dit levert ons de frequentie en stabiliteit van implementaties op, terwijl het de productiviteit verhoogt.

Synchrone vs asynchrone interacties

Mircoservices moeten effectief met elkaar communiceren. Dit vereist mogelijk het gebruik van een synchronous call, zoals REST of gRPC of een asynchronous call met een berichtsysteem (Event-driven Architecture), zoals RabbitMQ, Apache Kafka, etc.

Synchrone interacties hebben de neiging om naarmate je dichterbij de gebruiker komt (zoals met een website) de overhand te nemen, terwijl asynchrone service interacties in actie komen als er werk is dat uitgesteld kan worden. Het uitgestelde werk wordt gedaan zodra daar ruimte voor is.

Tijdens het ontwikkelen van microservices focussen mensen vaak op het synchrone aspect van een systeem, terwijl de asynchrone kant ervan ook aandacht verdient.

Synchrone communicatie tussen microservices creëert al te vaak een directe connectie, een tightly coupled system. In een dergelijk systeem hangt de prestatie van het systeem vooral af van de langzaamste service. Daarom wordt bij wijze van langetermijnoplossing aangeraden om microservices asynchroon met elkaar te laten communiceren. Als bijvoorbeeld een service een andere service synchroon aanroept via een HTTP-gebaseerde API en die service op zijn beurt ook weer (een) andere service(s) aanroept en als sommige van deze services misschien wéér een andere service oproepen, enzovoort, dan loopt de totale duur van de aanroep vanzelf op.

Asynchrone communicatie, zoals bij event-driven architecture, maakt het aan de andere kant mogelijk dat diensten samenwerken door events te publiceren en consumeren. In deze context kan een event een simpele verandering in de status zijn. Een service kan verschillende events uitzenden naar één of meerdere gebruikers zonder dat het nodig is om te weten wie er meeluistert of hoe ze zouden kunnen reageren.

Deze aanpak moedigt loose coupling tussen services aan door een indirecte stijl van samenwerking af te dwingen waarbij services geen kennis van elkaar hoeven te hebben. Voor de zender maakt het niet uit wie het event ontvangt en de gebruiker maakt het niet uit wie de afzender is.

Services die zijn geïntegreerd via asynchrone event streams zijn over het algemeen beter op te schalen dan degene die directe API calls gebruiken. Dit verbetert ook de robuustheid doordat de uitval van diensten niet meer voor een kettingreactie aan errors zorgen.

Bron: Microsoft – Communication in a microservice architecture

Conclusie

Loose coupling is een van de belangrijkste aspecten voor een goede microservice architectuur. Hoewel loose coupling vele voordelen biedt, is het in de praktijk soms lastig toe te passen. Natuurlijk kunnen we niet alle coupling uit het systeem bannen, sommige zijn prima zolang ze maar geen negatief effect hebben op de gewenste uitkomst.

Voor een schaalbare, robuuste microservice architectuur is loose coupling vereist. Zodat we onze doelen kunnen bereiken en in staat zijn om:

• een onafhankelijke service in te zetten die de anderen niet beïnvloedt.
• onze service te testen en te verifiëren zonder gebruik te maken van een geïntegreerde omgeving.
• de andere services door te laten lopen als er één is uitgevallen.