Wij horen en zien dat veel mensen praten over Microservices en Service Mesh, maar wat is dit? En wat kun je ermee? In dit artikel bespreken we de volgende onderwerpen die hier bij komen kijken, namelijk:
- Wat Microservices zijn
- Wat een Service Mesh is
- Wat kan je met een Service Mesh?
- Heb je het nu wel echt nodig?
- Hoe gebruik je een Service Mesh met AKS?
Wat zijn Microservices?
Microservices is eigenlijk een architectuurstijl die je in staat stelt je applicatie te structureren als een verzameling van services. Meestal is elke dienst een kleine applicatie (maar niet te klein) die eigendom is van een klein team. De applicatie is ontworpen om loosely coupled te zijn, dit betekent in principe dat je applicatie zelfstandig kan worden ingezet en niet je systeem neerhaalt. Door gebruik te maken van een Microservices architectuur gekoppeld met DevOps praktijken, kun je snelle, frequente en betrouwbare releases van complexe applicaties doen.
Microservices zijn geen wondermiddel of dé holy grail, je moet goed over de keuze nadenken voordat je de Micro-services route kiest. Sommige valkuilen of nadelen van microservies hebben te maken met de communicatie tussen diensten en externe bronnen, denk aan latency en beveiliging. Het kan zijn dat ontwikkelaars extra code moeten schrijven om hier mee om te gaan. Een andere valkuil zou kunnen zijn dat hoe meer microservices je hebt hoe meer resources je moet developen en beheren. Debugging is een andere uitdaging. Maar laat je niet afschrikken door de nadelen of valkuilen, kijk ook naar de voordelen en voornamelijk naar jouw eigen situatie. Zorg voordat je begint aan deze reis dat je weet wat microservices voor jouw kunnen betekenen.
Wat is een Service Mesh?
Een service mesh is een klein hulpmiddel dat helpt om de waarneembaarheid, veiligheid en betrouwbaarheid van jouw microservice applicaties te verbeteren door zichzelf in de platform laag te injecteren in plaats van in de applicatie laag. Bij de meeste servicemesh’s wordt een proxycontainer aan de applicatie pods toegevoegd. Dit wordt normaal gesproken een sidebar container genoemd. De belangrijkste rol van een service mesh is zoals je vast wel geraden hebt door het gebruik van een proxy; het beheren van het netwerkverkeer tussen de services.
Er zijn momenteel verschillende service meshes beschikbaar. De meest populaire is Istio (het griekse woord voor zeil). Istio is gemaakt door teams van Google en IBM in samenwerking me het Envoy team van Lyft en wordt ontwikkeld in GitHub. Een andere populaire service mesh is Linkerd, die beweert ‘s ’werelds lichtste, snelste, service mesh’ te zijn. Ook dit wordt in GitHub bijgehouden.
Er zijn ook enkele bedrijven die service meshes maken, waaronder Microsoft met hun Open Service Mesh (OSM). OSM is erg nieuw en nog steeds in Alpha op het moment van schrijven. Ngix werkt aan hun eigen service mesh genaamd NGINX Service Mesh (NSM). NSM wordt achter gesloten deuren ontwikkeld, maar problemen kunnen via Github worden gelogd. Hier vind je een mooie vergelijking van de verschillende Services Meshes.
Omdat er verschillende service mesh opties zijn raad ik je aan om elke optie goed te onderzoeken en uit te proberen voordat je een keuze maakt. Oh, en vergeet niet om de projecten in de gaten te houden, want zoals alles met Kubernetes te maken heeft, wordt er veel geüpdatet. Dus baanbrekende veranderingen kunnen zomaar gebeuren.
Wat kun je doen met een Service Mesh?
Hieronder beschrijf ik enkele functionaliteiten die je met een service mesh kan realiseren:
Dynamische Service Discovery en Routing
Door gebruik te maken van een service mesh kun je dynamische service discovery en traffic management krijgen. Dit stelt je in staat om traffic shadowing uit te voeren, denk aan duplicatie, erg handig voor het testen. Bijvoorbeeld, je hebt misschien een applicatie die communiceert met een service, je bent van plan een nieuwe versie van deze service uit te brengen, maar je wilt testen wat er zou gebeuren met live data. Door gebruik te maken van traffic shadowing kun je dit live verkeer dupliceren naar de productie omgeving en in de nieuwe test service zien hoe het reageert en presteert.
Een ander kenmerk is het splitsen van verkeer. Dit maakt het canary testen makkelijk. Laten we het zojuist genoemde voorbeeld gebruiken, maar nu is de applicatie getest en al en willen we het uitrollen, maar nog niet voor iedereen. Met verkeerssplitsing kunnen we het verkeer opsplitsen tussen de twee diensten, zeg maar 70% voor de oude service/dienst en 30% met de nieuwe service/dienst. We kunnen dan de nieuwe service monitoren op eventuele fouten en problemen en het percentage die de nieuwe versie ziet verhogen wanneer je er zeker van bent dat de het allemaal werkt. Je kunt dit ook gebruiken voor het testen van nieuwe functionaliteiten middels A/B testing.
Service-to-Service communicatie betrouwbaarheid
De primaire functie van een service mesh is het beheren van service-to-service communicatie. Hierdoor kun je gebruik maken van de opties om functies zoals request retries, timeouts, rate limiting en circuit breaking te implementeren.
Zoals hierboven vermeld wordt bij de meeste service mesh installaties een proxyserver sidecar container toegevoegd aan elke pod in jouw cluster. Deze sidecars worden aangestuurd door de service mesh controle plan. Zodra alle proxies zijn geconfigureerd heb je de data plane. Deze data plane stelt je in staat om slimme routing in te schakelen, denk aan latency aware load balacing en het implementeren van routing rules op basis van request properties.
Let wel op: niet alle service meshes zijn hetzelfde, dus het kan zijn dat bovengenoemde opties niet in de gekozen mesh zit.
Door gebruik te maken van opties zoals time-outs en circuit brekers kun je ervoor zorgen dat jouw diensten geen enorme achterstanden krijgen of een slechte gebruikerservaring oplevert. Ik zou zeker wat tijd besteden aan het onderzoeken van deze mogelijkheden en samen werken met de business om zo aan alle vereisten te voldoen.
Waarneembaarheid van het verkeer
Doordat alle service to service communicatie via de proxy’s in een service mesh verloopt, heb je de mogelijkheid om het netwerk verkeer beter waar te nemen. Hierdoor kun je een verzoek traceren via alle services in de service mesh, de frequentie van HTTP-foutcodes en elke vertraging, of het nu gaat om service to service of wereldwijd. Sommige service meshes hebben een eigen dashboard zodat je in een weergave inzicht kan hebben op alle netwerkverkeer, maar ze bieden vaak ook de mogelijkheid om de logs naar Prometheus te sturen of ze met Grafana te gebruiken. Dit zijn dé meest gebruikte tools voor het monitoren van AKS.
Communicatie beveiliging
Ik weet dat dit het laatste punt is in dit artikel, maar dit is waarschijnlijk dé reden waarom de meeste mensen een service mesh gebruiken. Met de meeste service meshes kun je bepalen met welke diens je kunt praten. Dus ‘Service A’ kan communiceren met ‘Service C’, maar niet met ‘Service B’, en ‘Service B’ kan alleen praten met ‘Service C’. Standaard heeft AKS wel een netwerkbeleid, maar dit wordt niet gecontroleerd via manifest files en kan erg omslachtig zijn.
Deze functie is dé reden waarom mensen kiezen voor een service mesh: gecodeerd verkeer. Dit betekent dat al het intere netwerkverkeer is versleuteld met behulp van certificaten. Deze certificaten kunnen zelfs afkomstig zijn van een externe CA zoals let’s encrypt of van Azure Key Vault indien deze wordt ondersteund door de service mesh.
Heb je een Service Mesh nodig?
Als je een paar services hebt draaien die verbinding maakt met een event grid of een message queue, dan heb je waarschijnlijk geen service mesh nodig. Tenzij je natuurlijk een van bovenstaande functies nodig heeft, zoals intercluster communicatie over https.
Als je meerdere services hebt die met elkaar praten dan is een service mesh wellicht iets voor jou. Door een service mesh te gebruiken stel je je ontwikkelaars ook in staat om zich te concentreren op de zakelijke waarde van jouw applicatie in plaats van de services met elkaar te verbinden.
Kan je Service Mesh gebruiken met AKS?
Service meshes zijn 100% compatible met AKS. AKS draait net als elke Kubernetes-installatie, of het nu op locatie is, in een andere cloud, of op virtuele machines draait.
Het voordeel van het koppelen van een service mesh met AKS is dat je nu niet ook de onderliggende systemen hoeft te beheren. Microsoft regelt dat voor je. Dit betekent dat je meer tijd vrij hebt voor het ontwikkelen van je applicatie en te onderzoeken of Service mesh iets voor je is.
Microsoft is momenteel bezig met het creëren van haar eigen service mesh (OSM). Ik zou aanraden de ontwikkelingen hierover goed in de gaten te houden, omdat het uiteindelijk waarschijnlijk extreem compatibel zal zijn met AKS en misschien zelfs wel super eenvoudig te implementeren als add-on.
Kom meer te weten over AKS tijdens onze AKS workshop
Leer nog meer over AKS door onze interactieve AKS workshop. In 1.5 uur ontvang jij de voordelen en de best practices om jouw omgeving efficiënter te maken. Middels veelvoorkomende AKS uitdagingen ben jij klaar voor AKS. Klik hier voor data en meld je aan!