Microservices implementatiestrategieën

In tegenstelling tot microservices was monolithische architectuur een single-tier architectuur bestaande uit sterk gekoppelde componenten gebouwd als één toepassing op één platform. Om een specifieke service te schalen, moest het hele systeem worden geschaald, wat uiterst inefficiënt bleek te zijn.

Om dergelijke problemen te overwinnen, kiezen bedrijven tegenwoordig voor microservices, omdat het hen helpt isolatie tussen hun services tot stand te brengen. Dit maakt eenvoudige unit testing van afzonderlijke services mogelijk en maakt de toepassing flexibeler voor veranderingen in hun afhankelijkheden.

Deze voordelen stimuleren bedrijven om te kiezen voor een microservices-architectuur. Om een microservices-toepassing te implementeren, zijn er verschillende implementatiestrategieën die men kan volgen. Deze post leidt je door de meest voorkomende.

Meerdere diensten per host 

Dit is een vrij traditionele aanpak die door veel bedrijven wordt gevolgd, vooral diegenen die geen eerdere ervaring hebben met microservices. In dit patroon worden meerdere service-instanties uitgevoerd op een host, die fysiek of virtueel kan zijn. De services worden geïsoleerd uitgevoerd en delen de resources van de hostmachine, zoals het besturingssysteem, de CPU en andere rekenintensieve middelen.

Er zijn verschillende manieren om service-instanties in een gedeelde host te implementeren. Je kunt bijvoorbeeld elke service-instantie implementeren als JVM (Java Virtual Machine) processen die op verschillende hosts draaien. Een andere manier is om meerdere service-instanties in dezelfde JVM te implementeren als webapplicaties of gedeelde bundels. Het is echter onmogelijk om elke service-instantie te isoleren, aangezien ze op dezelfde host draaien.

Hier zijn enkele voordelen van deze strategie: 

1. Efficiënt gebruik van middelen: meerdere service-instanties delen hetzelfde besturingssysteem en de server, wat resulteert in efficiënt gebruik van resources. 
2. Snellere implementatie van een reeks services in een toepassing: doordat meerdere service-instanties op dezelfde machine draaien, kan de implementatie van een suite van services sneller plaatsvinden. 

Enkele nadelen van deze strategie zijn: 

1. Gebrekkige isolatie: aangezien meerdere service-instanties worden gehost op één machine, is de isolatie tussen deze instanties zwak.
2. Mogelijke afhankelijkheidsconflicten: conflicten tussen afhankelijkheden kunnen ontstaan doordat meerdere services dezelfde resources delen.
3. Geen beperking van resources: er zijn geen beperkingen met betrekking tot het gebruik van resources zoals besturingssystemen en servers. Dit kan leiden tot situaties waarin sommige service-instanties meer resources verbruiken dan de drempel, wat kan resulteren in een deadlock. 

Service-instantie per host patroon

In dit patroon worden de service-instanties geïsoleerd uitgevoerd op hun eigen host, afhankelijk van het type host (VM of containers). Het service-instantie per host-patroon bestaat uit twee verschillende variaties:

1. Service-instantie per virtuele machine
2. Service-instantie per container

Service-instantie per virtuele machine

In tegenstelling tot meerdere services per host, zijn bij het Service-instantie per host-patroon de service-instanties goed geïsoleerd en verpakt als een virtuele machine (VM)-image, zoals bijvoorbeeld een Amazon EC2 AMI. Elke service-instantie wordt een VM (virtuele machine) nadat deze VM-images heeft uitgevoerd.

Deze aanpak wordt gebruikt door Netflix om zijn videoservice te implementeren. Elke service wordt verpakt in een Amazon Machine Image (AMI) met behulp van Aminator, een tool voor het verpakken van services in AMI's die vergelijkbaar zijn met VM-images, en wordt vervolgens gelanceerd. 

De voordelen van deze strategie: 

1. Strikte toewijzing van resources: Een groot voordeel van het uitvoeren van service-instanties als geïsoleerde VM's is dat resources strikt worden toegewezen aan elke service en het resourceverbruik beperkt blijft. Een service kan geen resources stelen van andere services.
2. Profiteren van volwassen Cloud-infrastructuur: Het gebruik van microservices als virtuele machine-images stelt je in staat te profiteren van volwassen Cloud-infrastructuur. Dit helpt bij het balanceren van de belasting en automatisch schalen van verzoeken naar je services.
3. Technologie-abstractie door VM-encapsulatie: Het implementeren van service-instanties als VM's omhult de technologie van je service-implementatie. Met andere woorden, je VM wordt een black box, wat betekent dat je je geen zorgen hoeft te maken over wat er onder de motorkap gebeurt of hoe het intern werkt. Hierdoor wordt implementatie eenvoudiger en betrouwbaarder.

De nadelen van deze strategie: 

1. Kostenefficiëntie: Een typische IaaS (Infrastructure as a Service) brengt kosten in rekening voor VM's ongeacht hun status van activiteit, of ze nu inactief of actief zijn. Hoewel AWS auto-scaling biedt, is het moeilijk om snel te reageren op veranderingen op aanvraag. Om VM's te wijzigen, moet je je VM's over dimensioneren, wat de kosten van implementatie verhoogt. Daarom is deze benadering niet ergkostenefficiënt.
2. Trage instantiëring vanwege VM-grootte: Over het algemeen zijn VM's trager om te instantiëren vanwege hun grote omvang. Bij het implementeren van een nieuwe versie van een service verloopt het proces traag.
3. Complexiteit van VM-beheer: Het hanteren en beheren van VM's kan een ontmoedigende taak zijn. Tenzij je bedrijf externe tools voor VM-beheer gebruikt, kan het service-instantie per VM-patroon je afleiden van je kernactiviteiten.

Service-instantie per container

In dit patroon worden service-instanties uitgevoerd in containers. In tegenstelling tot virtuele machines die het volledige computersysteem virtualiseren, zijn containers beperkt tot virtualisatie op het niveau van het besturingssysteem. Je kunt ook de CPU en het geheugen van de container beheren. Om dit patroon te implementeren, moet je je services verpakken in container-images. Een container-image is een bestandssysteem dat alle afhankelijkheden en bibliotheken bevat die nodig zijn voor het uitvoeren van de service.

De voordelen van deze strategie: 

1. Isolatie van services vergelijkbaar met VM’s: Containers zijn vergelijkbaar met VM's als het gaat om het isoleren van services. Je hebt de mogelijkheid om de resources die door elke container worden verbruikt, te monitoren.
2. Lichtgewicht in vergelijking met VM’s: Containers zijn lichtgewicht in vergelijking met VM's. Daarom kost het minder tijd om container-images te bouwen en zijn ze doorgaans sneller op te starten.
3. Focus op de kernactiviteiten zonder uitgebreid beheer: Je kunt je richten op je kernactiviteiten zonder te veel tijd te besteden aan het beheren van je microservices in containers. Dit komt doordat de container management API je helpt bij het beheren van je microservices die in containers worden uitgevoerd.

De nadelen van deze strategie: 

1. Minder veiligheid vergeleken met VM’s: Containers zijn over het algemeen niet zo veilig als VM's, omdat de kernel van het besturingssysteem wordt gedeeld tussen containers.
2. Kosten voor infrastructuur en piekbelasting: Containers worden vaak geïmplementeerd in infrastructuren met prijsstelling per VM. Net als bij VM's is er ook extra voorziening van resources nodig tegen extra kosten om grote pieken in belasting op te vangen.

Serverloze deployment  

Serverloze deployment wordt steeds populairder als concept, omdat het de verwarring wegneemt bij het kiezen tussen VM's of containers voor het implementeren van microservices. Dit stelt bedrijven in staat zich beter te concentreren op hun kernactiviteiten, in plaats van zich het hoofd te breken over container- of VM-implementaties.

AWS Lambda is een klassiek voorbeeld van een serverloos implementatiepatroon. Om microservices te implementeren, moet je ze verpakken als een zip-bestand en uploaden naar AWS Lambda. Hierbij voeg je ook metadata toe en de naam van de functie die moet worden aangeroepen wanneer er een verzoek moet worden afgehandeld. AWS Lambda neemt vervolgens de rest voor zijn rekening door voldoende instanties van je microservices uit te voeren om meerdere verzoeken te verwerken.

Hier zijn de voordelen van deze strategie:

• In tegenstelling tot de andere twee strategieën voor het implementeren van microservices, maakt serverloze implementatie geen gebruik van een virtuele host (virtuele machines of containers), waardoor de noodzaak voor extra infrastructuur wegvalt.
• Omdat het als een zip-bestand moet worden geïmplementeerd, gaat dit relatief sneller.
• De serverloze implementatie-infrastructuur, met name AWS Lambda, hanteert prijsstelling op basis van verzoeken. Dit betekent dat je alleen betaalt voor wat je services hebben verbruikt.

Hier zijn de nadelen van deze strategie:

• Serverloze implementatie is niet betrouwbaar voor langdurige services die berichten nodig hebben van een externe broker.
• Services moeten snel worden gestart, anders kunnen ze worden beëindigd of time-outen in serverloze IaaS.

Conclusie

Het implementeren van microservices-toepassingen kan behoorlijk belastend zijn zonder de juiste strategie, omdat er honderden services draaien die zijn geschreven in verschillende talen en frameworks. Als het gaat om microservices, is elke service een mini-applicatie met zijn eigen set