🥇Gebruiksscenario's van de service mesh

Opmerking vertaler.: de auteur van dit artikel (Luc Perkins) is developer advocate bij de organisatie CNCF, die het huis is voor Open Source-projecten zoals Linkerd, SMI (Service Mesh Interface) en Kuma (overigens, heb je je ooit afgevraagd waarom Istio niet in deze lijst staat?). Nogmaals probeert hij het DevOps-community beter begrip te geven van de trendy hype genaamd 'service mesh', door 16 kenmerkende mogelijkheden te presenteren die dergelijke oplossingen bieden.

Tegenwoordig service mesh ― een van de heetste onderwerpen in software engineering (en niet zonder reden!). Ik beschouw deze technologie als ongelooflijk veelbelovend en droom ervan getuige te zijn van haar brede adoptie (natuurlijk als dat zinvol is). Desondanks wordt het nog steeds omgeven door een aura van mysterie voor de meeste mensen. Toch hebben zelfs degenen die goed bekend met haar, dikwijls moeite om de voordelen en wat het precies inhoudt te formuleren (inclusief uw nederige dienaar). In dit artikel zal ik proberen de situatie te verbeteren door verschillende gebruiksscenario's van 'service meshes'.

* Opmerking vertaler: vanaf hier en verder in het artikel zal deze vertaling ('service mesh') worden gebruikt voor de nog nieuwe term service mesh.

Maar eerst wil ik enkele opmerkingen maken:

Ik heb nooit met service meshes gewerkt en heb ze niet gebruikt buiten projecten die zijn opgezet voor mijn eigen opleiding. Aan de andere kant heb ik een hoop documentatie geschreven voor de interne service mesh van Twitter in 2015 (toen het nog niet eens 'service mesh' werd genoemd) en heb ik deelgenomen aan de ontwikkeling van de website en documentatie voor Linkerd, dus dat betekent iets.
Mijn lijst is indicatief en niet volledig. Er zijn mogelijk onbekende gebruiksscenario's en na verloop van tijd zullen er ongetwijfeld nieuwe vormen ontstaan, naarmate de technologie zich ontwikkelt en de populariteit groeit.
Tegelijkertijd ondersteunt lang niet elke bestaande implementatie van service mesh alle genoemde gebruiksgevallen. Daarom moeten mijn uitspraken zoals 'service mesh kan...' worden gelezen als 'bepaalde, en mogelijk alle populaire implementaties van service mesh kunnen...'.
De volgorde van de voorbeelden doet er niet toe.

Korte lijst:

detectie van services;
versleuteling;
authenticatie en autorisatie;
lastverdeling;
circuit breaking;
automatische schaalvergroting;
canary deployments;
blue-green deployments;
gezondheidscontrole;
load shedding;
verkeersspiegeling;
isolatie;
verzoekfrequentiebeperkingen, herhalingen en time-outs;
telemetrie;
audit;
visualisatie.

1. Detectie van services

TL;DR: verbind met andere services in het netwerk met eenvoudige namen.

Services moeten in staat zijn elkaar automatisch te 'vinden' door gebruik te maken van geschikte namen, bijvoorbeeld, service.api.production, pets/staging of cassandra. Cloudomgevingen onderscheiden zich door hun elasticiteit, en achter één naam kunnen zich meerdere service-instanties verschuilen. Het is duidelijk dat het fysiek onmogelijk is om alle IP-adressen hardcoded in te stellen in zo'n situatie.

Bovendien, wanneer één service een andere service vindt, moet deze in staat zijn om verzoeken naar die service te sturen zonder zich zorgen te maken dat deze in de ingang van de niet-functionele instantie terechtkomen. Met andere woorden, de service mesh moet de beschikbaarheid van alle service-instanties in de gaten houden en de lijst met hosts zo actueel mogelijk houden.

Elke service mesh implementeert een service detectiemechanisme op zijn eigen manier. Op dit moment is de meest voorkomende manier om dit aan externe processen zoals DNS Kubernetes te delegeren. In het verleden gebruikten we bij Twitter voor deze doeleinden het naamgevingssysteem Finagle. Bovendien maakt technologie van de service mesh het mogelijk om op maat gemaakte naamgevingsmechanismen te creëren (hoewel ik nog geen enkele implementatie van SM met deze functionaliteit ben tegengekomen).

2. Versleuteling

TL;DR: verwijder niet-versleuteld verkeer tussen services en zorg ervoor dat dit proces geautomatiseerd en schaalbaar is.

Het is prettig om te weten dat aanvallers niet binnen in uw interne netwerk kunnen doordringen. Firewalls zijn hier uitstekend in. Maar wat gebeurt er als een hacker toch naar binnen komt? Kan hij alles doen met het interne servicetrafiek dat hij wil? Laten we hopen dat dit niet zal gebeuren. Om een dergelijk scenario te voorkomen, is het noodzakelijk om een zero-trust netwerk te implementeren, waarbij al het verkeer tussen de services is versleuteld. De meeste moderne service-meshen bereiken dit met behulp van onderlinge TLS (mutual TLS, mTLS). In sommige gevallen werkt mTLS in hele cloudomgevingen en clusters (ik denk dat interplanetair communiceren ooit ook zo geregeld zal zijn).

Natuurlijk is mTLS voor service-meshen niet verplicht. Elke service kan zelf zorgen voor zijn eigen TLS, maar dat betekent dat er een manier gevonden moet worden om certificaten te genereren, deze over de hosts van de service te distribueren en code in de applicatie op te nemen die deze certificaten uit bestanden laadt. En vergeet niet om deze certificaten op bepaalde tijdstippen te vernieuwen. Service-meshen automatiseren mTLS met systemen zoals SPIFFE, die op hun beurt het proces van het uitgeven en roteren van certificaten automatiseren.

3. Authenticatie en autorisatie

TL;DR: Bepaal wie de aanvrager is en wat hem is toegestaan om te doen nog voordat de aanvraag de service bereikt.

Services willen vaak weten, wie de aanvraag doet (authenticatie), en aan de hand van deze informatie besluiten, we gaan laden, kunnen we vertellen hoe we dit gaan doen: wat deze entiteit is toegestaan om te doen (autorisatie). In dit geval kunnen achter het voornaamwoord 'wie' zich schuilhouden:

Andere services. Dit wordt 'peer-authenticatie' genoemd. Bijvoorbeeld, een servicewil toegang tot de service web db . Service-meshen lossen dergelijke problemen meestal op met behulp van mTLS: certificaten fungeren in dit geval als de noodzakelijke identificatie.Bepaalde gebruikers. Dit wordt 'aanvraag-authenticatie' genoemd.
Bijvoorbeeld, de gebruiker haxor69wil een nieuwe lamp kopen. Service-meshen bieden verschillende mechanismen, zoals JSON Web Tokens. Velen van ons hebben dit al eens in de applicatiecode gedaan. Er komt een aanvraag binnen, we bekijken de tabel , vinden de gebruiker en vergelijken het wachtwoord, en controleren vervolgens de kolom.
. gebruikers, vinden we de gebruiker en vergelijken we het wachtwoord, daarna controleren we de kolom permissions enzovoort. In het geval van service mesh gebeurt dit zelfs voordat het verzoek de service bereikt.

Nadat we hebben vastgesteld van wie het verzoek afkomstig is, moeten we bepalen wat deze entiteit is toegestaan. Sommige service meshes bieden de mogelijkheid om basisbeleid (over wie wat mag doen) op te stellen in de vorm van YAML-bestanden of via de commandoregel, terwijl andere integratie met frameworks zoals bieden. Open Policy Agent. Het uiteindelijke doel is om ervoor te zorgen dat uw services alle aanvragen kunnen aanvaarden, met de veronderstelling dat ze afkomstig zijn uit een betrouwbare bron. en dit is toegestaan.

4. Lastverdeling

TL;DR: Verdeelt de belasting over de service-instanties volgens een bepaald patroon.

Een "service" binnen een servicesectie bestaat vaak uit meerdere identieke instanties. Bijvoorbeeld, vandaag bestaat de service uit 5 kopieën, en morgen kan dat aantal toenemen tot 11. Verzoeken die naar. cache , moeten worden verdeeld volgens een bepaald doel. Bijvoorbeeld, om de latentie te minimaliseren of de kans te maximaliseren om een werkende instantie te bereiken. Vaak wordt de round-robin-algoritme gebruikt, maar er zijn ook vele anderen - bijvoorbeeld de gewogen. cache(weighted) verzoeken (voorkeursdoelen kunnen worden gekozen), ring. (ring) hashing (gebruik van consistente hashing voor upstream-hosts) of het minste aantal verzoeken-methode (voorkeur gaat uit naar de instantie met het minste aantal verzoeken). Traditionele load balancers hebben ook andere functies, zoals HTTP-caching en DDoS-bescherming, maar zijn minder relevant voor east-west verkeer (d.w.z. verkeer binnen het datacenter - red.). (typisch toepassingsgebied van service mesh). Natuurlijk is het niet verplicht om service mesh te gebruiken voor load balancing, maar het maakt het mogelijk om de load balancing-criteria voor elke service vanuit een gecentraliseerde managementlaag in te stellen en te beheren, waardoor het nodig om afzonderlijke load balancers in de netwerklagen te draaien en in te stellen wordt geëlimineerd.

5. Circuit breaking

TL;DR: Stop verkeer naar de problematische service en controleer de schade in de ergste scenario's.

TL;DR: Stop de verkeer naar de problematische service en beheers de schade in de slechtste scenario's.

Als de service om een of andere reden niet met het verkeer omgaat, biedt de service mesh verschillende manieren om dit probleem op te lossen (andere worden in de bijbehorende secties besproken). Circuit breaking is de strengste manier om de service van het verkeer te verwijderen. Echter, op zichzelf heeft het geen zin — er is een back-upplan nodig. Tegenmaatregelen kunnen worden overwogen. (tegenmaatregelen) voor de services die aanvragen doen (vergeet niet uw service mesh hiervoor in te stellen!), of bijvoorbeeld het rood kleuren van de statuspagina en gebruikers doorverwijzen naar een alternatieve pagina met een 'vallende walvis' (Twitter is down).

Service mesh-netwerken maken het mogelijk om niet alleen te bepalen, wanneer de uitschakeling zal plaatsvinden en we gaan laden, kunnen we vertellen hoe we dit gaan doen: wat daaruit voortvloeit. In dit geval kan 'wanneer' elke combinatie van gedefinieerde parameters omvatten: het totale aantal aanvragen over een bepaalde periode, het aantal gelijktijdige verbindingen, hangende aanvragen, actieve herhalingspogingen, enz.

Je wilt circuit breaking waarschijnlijk niet misbruiken, maar het is prettig om te weten dat er een back-upplan is voor noodgevallen.

6. Autoscaling

TL;DR: Verhoog of verlaag het aantal service-instanties afhankelijk van de gedefinieerde criteria.

Service mesh-netwerken zijn geen planners, dus ze voeren geen autoscaling zelfstandig uit. Ze kunnen echter informatie leveren waarop planners hun beslissingen baseren. Aangezien service mesh-netwerken toegang hebben tot al het verkeer tussen services, beschikken ze over uitgebreide informatie over wat er gebeurt: welke services problemen ondervinden, welke nauwelijks belast zijn (de toegewezen middelen worden verspild), enz.

Bijvoorbeeld, Kubernetes schaalt services op basis van het gebruik van CPU en geheugen door pods (Autoscaling en resource management in Kubernetes) — bron: vert., maar als je besluit te schalen op basis van een andere maatstaf (in ons geval gerelateerd aan verkeer), is er een speciale metriek nodig. Een handleiding zoals deze laat zien hoe dit kan worden gedaan met behulp van Envoy, Istio en Prometheus, maar het proces zelf is behoorlijk complex. We wensen dat de service mesh dit vereenvoudigt door gewoon voorwaarden in te stellen zoals 'verhoog het aantal service-instanties' auth, als het aantal verzoeken dat wacht op uitvoering de drempelwaarde gedurende een minuut overschrijdt.

7. Canariedistributies

TL;DR: Test nieuwe functies of versies van de service op een subset van gebruikers.

Stel, je ontwikkelt een SaaS-product en bent van plan om een nieuwe coole versie uit te rollen. Je hebt deze in staging getest en het werkte perfect. Maar toch blijven er bepaalde angsten bestaan over het gedrag ervan onder echte omstandigheden. Met andere woorden, het is nodig om de nieuwe versie te testen met echte taken, zonder het vertrouwen van de gebruikers in gevaar te brengen. Canariedistributies zijn hiervoor perfect. Ze stellen je in staat om een nieuwe functie aan een bepaald subset van gebruikers te demonstreren. Dit subset kan bestaan uit de meest loyale gebruikers of degenen die de gratis versie van het product gebruiken, of gebruikers die hebben aangegeven 'proefkonijnen' te willen zijn.

Service meshes maken dit mogelijk door criteria op te geven die bepalen wie welke versie van de applicatie zal zien, en de trafiek dienovereenkomstig te routeren. Voor de services zelf verandert er niets. Versie 1.0 van de service denkt dat alle verzoeken van gebruikers komen die deze versie moeten zien, terwijl versie 1.1 hetzelfde aanneemt over zijn eigen gebruikers. Ondertussen kun je het percentage trafiek tussen de oude en nieuwe versie wijzigen door een groeiend aantal gebruikers naar de nieuwe versie te leiden, als deze stabiel werkt en je 'proefkonijnen' goedkeuring geven.

8. Blauw-groene distributies

TL;DR: Rol een nieuwe coole functie uit, maar wees voorbereid om alles onmiddellijk terug te draaien.

De essentie van blauw-groene distributies is om een nieuwe 'blauwe' service uit te rollen, deze parallel aan de oude 'groene' te draaien. Als alles soepel verloopt en de nieuwe service goed presteert, kan de oude geleidelijk worden uitgeschakeld. (Helaas zal ook deze nieuwe 'blauwe' service ooit de bestemming van de 'groene' delen...) Blauw-groene distributies verschillen van canariedistributies in die zin dat de nieuwe functie direct aan alle gebruikers wordt aangeboden (en niet aan een deel); het idee hierachter is om een 'backup haven' klaar te hebben, voor het geval dat er iets misgaat.

Service mesh biedt een handige manier om de 'blauwe' service te testen en onmiddellijk over te schakelen naar de operationele 'groene' service in geval van problemen. Niet te vergeten dat ze ook veel informatie bieden (zie het onderdeel 'Telemetry' hieronder) over de werking van de 'blauwe' service, wat helpt te begrijpen of deze klaar is voor volledige implementatie.

Opmerking vertaler.: Meer informatie over verschillende implementatiestrategieën in Kubernetes (inclusief de genoemde canary, blue/green en andere) is te lezen in dit artikel.

9. Gezondheidscontrole

TL;DR: Houd in de gaten welke instanties van services operationeel zijn en reageer op diegene die dat niet meer zijn.

Gezondheidscontrole (health check) helpt bij het nemen van de beslissing of instanties van de service verkeer kunnen ontvangen en verwerken. In het geval van HTTP-services kan een gezondheidscontrole eruitzien als een GET-verzoek naar de endpoint /health. Een antwoord 200 OK zou betekenen dat de instantie gezond is, elk ander antwoord zou betekenen dat hij niet in staat is om verkeer te ontvangen. Service mesh stelt je in staat om zowel de manier aan te geven waarop de werkbaarheid wordt gecontroleerd, als de frequentie waarmee deze controle plaatsvindt. Deze informatie kan vervolgens voor andere doeleinden worden gebruikt — bijvoorbeeld voor load balancing en circuit breaking.

Zo fungeert de gezondheidscontrole niet als een op zichzelf staand gebruiksscenario, maar wordt deze meestal gebruikt om andere doelen te bereiken. Afhankelijk van de resultaten van de health checks kunnen externe acties nodig zijn (ten opzichte van andere doelstellingen binnen service meshes): bijvoorbeeld de statuspagina bijwerken, een issue aanmaken op GitHub of een ticket in JIRA invullen. En service mesh biedt een handige mechanismen voor het automatiseren van dit alles.

10. Load shedding

TL;DR: Leid verkeer om in reactie op een tijdelijke piek in gebruik.

Als een bepaalde service overbelast raakt door verkeer, kun je tijdelijk een deel van dit verkeer omleiden naar een andere bestemming (dat wil zeggen 'afvoeren', 'verplaatsen' (shed) daarheen). Bijvoorbeeld, naar een reserve service of datacenter, of naar een constante Pulsar onderwerp. Hierdoor blijft de service een deel van de verzoeken verwerken in plaats van te crashen en helemaal te stoppen met verwerken. Het resetten van de belasting is te verkiezen boven het verbreken van de keten, maar het is nog steeds ongewenst om dit te misbruiken. Het voorkomt cascade-falingen, die downstream-diensten kunnen laten crashen.

11. Parallelisatie / traffic mirroring

TL;DR: Stuur één verzoek naar meerdere bestemmingen tegelijk.

Soms is het nodig om een verzoek (of een selectie van verzoeken) tegelijkertijd naar meerdere diensten te sturen. Een typisch voorbeeld is het sturen van een deel van de productie-verkeer naar een staging-dienst. De belangrijkste webserver van de productie stuurt een verzoek naar de onderliggende dienst products.production en alleen naar deze. En de service mesh kopieert dit verzoek intelligent en stuurt het naar products.staging, waar de webserver zich niet eens van bewust is.

Een ander gerelateerd scenario voor het gebruik van de service mesh, dat bovenop de parallelisatie van verkeer kan worden geïmplementeerd, is regressietests. Dit houdt in dat dezelfde verzoeken naar verschillende versies van de dienst worden gestuurd en controleert of alle versies zich hetzelfde gedragen. Tot nu toe ben ik geen implementatie van de service mesh tegengekomen met een geïntegreerd systeem voor regressietests zoals Diffy, maar het idee zelf lijkt veelbelovend.

12. Isolatie

TL;DR: Verdeel je service mesh in mini-netwerken.

Ook bekend als segmentatie, isolatie is de kunst van het opdelen van de service mesh in logisch gescheiden segmenten die niets van elkaar weten. Isolatie lijkt enigszins op het creëren van virtuele particuliere netwerken. Het belangrijkste verschil is echter dat je nog steeds alle voordelen van de service mesh kunt benutten (zoals het ontdekken van diensten), maar met extra veiligheid. Bijvoorbeeld, als een aanvaller erin slaagt om in een dienst in een van de subnetwerken door te dringen, kan hij niet zien welke diensten in andere subnetwerken draaien of hun verkeer onderscheppen.

Daarnaast kunnen de voordelen ook organisatorisch zijn. Misschien wil je diensten in subnetwerken opdelen op basis van de structuur van het bedrijf en ontwikkelaars bevrijden van de cognitieve last die voortkomt uit de noodzaak om de hele service mesh in gedachten te houden.

13. Verzoekfrequentiebeperkingen, herhalingen en time-outs

TL;DR: U hoeft geen dringende verzoekbeheer taken meer in de codebasis op te nemen.

Al deze zaken kunnen als aparte gebruiksgevallen worden beschouwd, maar ik heb besloten ze te combineren vanwege één gemeenschappelijk kenmerk: ze nemen de taken van levenscyclusbeheer van verzoeken over, die normaal gesproken worden afgehandeld door applicatiebibliotheken. Als u een webserver ontwikkelt in Ruby on Rails (niet geïntegreerd met een service mesh) die verzoeken naar backend-diensten verzendt via gRPC, moet de applicatie zelf beslissen wat te doen als N verzoeken mislukken. U moet ook uitzoeken hoeveel verkeer deze diensten kunnen verwerken en deze parameters hardcoderen met behulp van een speciale bibliotheek. Bovendien moet de applicatie besluiten wanneer het tijd is om op te geven en het verzoek te laten verouderen (via timeout). En om een van de bovengenoemde parameters te wijzigen, moet de webserver worden gestopt, opnieuw geconfigureerd en opnieuw gestart.

Het overdragen van deze taken aan een service mesh betekent niet alleen dat ontwikkelaars van de diensten zich er geen zorgen meer over hoeven te maken, maar ook dat ze op een meer globale manier kunnen worden beschouwd. Als er een complexe keten van diensten wordt gebruikt, laten we zeggen, A → B → C → D → E, moet de gehele levenscyclus van het verzoek worden overwogen. Als het de bedoeling is om de time-outs in dienst C te verlengen, is het logisch dit allemaal tegelijk te doen, in plaats van in stappen: de code van de dienst bijwerken en wachten tot de pull request wordt goedgekeurd en het CI-systeem de bijgewerkte dienst inzet.

14. Telemetrie

TL;DR: Verzamel alle noodzakelijke (en minder noodzakelijke) informatie van de diensten.

Telemetrie is een algemene term die metrics, gedistribueerde tracing en logs omvat. Service meshes bieden mechanismen voor het verzamelen en verwerken van al deze drie soorten gegevens. Hier wordt het een beetje vaag, omdat het aantal mogelijke varianten te groot is. Voor het verzamelen van metrics zijn er Prometheus en andere tools, voor het verzamelen van logs kan men gebruik maken van fluentd, Loki, Vector enz. (bijvoorbeeld, ClickHouse met onze loghouse voor K8s — vertaler opmerking), voor gedistribueerde tracing zijn er Jaeger en dergelijke. Elke service mesh kan bepaalde tools ondersteunen en niet ondersteunen andere. Het zal interessant zijn om te zien of het project Open Telemetry enige convergentie kan bieden.

In dit geval is het voordeel van de service mesh-technologie dat sidecar-containers in principe alle bovengenoemde gegevens van hun services kunnen verzamelen. Met andere woorden, je krijgt een enkel systeem voor het verzamelen van telemetrie, en de service mesh kan deze informatie op verschillende manieren verwerken. Bijvoorbeeld:

logs van een bepaalde service in de CLI volgen;
de hoeveelheid verzoeken volgen vanaf het dashboard van de service mesh;
verspreide traceringen verzamelen en deze doorsturen naar een systeem zoals Jaeger.

Let op, subjectieve uitspraak: Over het algemeen is telemetrie een gebied waarin sterke inmenging van de service mesh ongewenst is. Het verzamelen van basisinformatie en het in real-time volgen van enkele 'gouden metrics' zoals het percentage succesvolle verzoeken en latencies is prima, maar laten we hopen dat we niet getuige worden van de opkomst van zogenaamde Frankenstein-stacks, die proberen gespecialiseerde systemen te vervangen, waarvan sommige al uitstekend hebben gefunctioneerd en goed zijn bestudeerd.

15. Audit

TL;DR: Wie de lessen uit de geschiedenis vergeet, is gedoemd ze opnieuw te leven.

Audit is de kunst van het observeren van belangrijke gebeurtenissen in het systeem. In het geval van service mesh kan dit betekenen dat wordt gevolgd wie verzoeken heeft gedaan aan specifieke endpoints van bepaalde services of hoe vaak een bepaalde gebeurtenis met betrekking tot veiligheid zich de afgelopen maand heeft voorgedaan.

Het is duidelijk dat audit nauw verbonden is met telemetrie. Het verschil is echter dat telemetrie meestal wordt geassocieerd met zaken zoals prestaties en technische integriteit, terwijl audit kan verwijzen naar juridische en andere kwesties die buiten het strikt technische domein vallen (bijvoorbeeld naleving van de GDPR - Algemene Verordening Gegevensbescherming van de EU).

16. Visualisatie

TL;DR: Lang leve React.js - een onuitputtelijke bron van bizarre interfaces.

Misschien is er een beter passende term, maar ik weet die niet. Ik bedoel gewoon de grafische weergave van de service mesh of enkele van haar componenten. Deze visualisaties kunnen indicaties bevatten zoals gemiddelde latencies, informatie over de configuratie van sidecar-containers, gezondheidschecks en waarschuwingen.

Werken in een service-georiënteerde omgeving gaat gepaard met een veel zwaardere cognitieve belasting in vergelijking met Zijn Koninklijke Hoogheid de Monoliet. Daarom moet de cognitieve druk koste wat het kost worden verlaagd. Een eenvoudige grafische interface voor de service mesh met de mogelijkheid om op een knop te klikken en het gewenste resultaat te krijgen, kan cruciaal zijn voor de populariteit van deze technologie.

Stonden niet op de lijst

In eerste instantie was ik van plan om nog enkele gebruiksscenario's op te nemen, maar besloot dit niet te doen. Hier zijn ze samen met de redenen voor mijn beslissing:

Multi-datacenter. In mijn opzicht is dit niet zozeer een gebruiksscenario, maar eerder een smal en specifiek toepassingsgebied van service meshes of een bepaalde set functies zoals service discovery.
Ingress en egress. Dit is een gerelateerd gebied, maar ik heb mezelf (mogelijk kunstmatig) beperkt tot het gebruiksscenario "oost-west verkeer". Ingress en egress verdienen een apart artikel.

Conclusie

Dat is voorlopig alles! Nogmaals, deze lijst is zeer subjectief en waarschijnlijk incompleet. Als je denkt dat ik iets gemist heb of een fout heb gemaakt, neem dan contact met me op op Twitter (@lucperkins). Houd je alstublieft aan de fatsoensregels.

P.S. van de vertaler

Als basis voor de hoofdfoto bij dit artikel is een afbeelding uit het artikel "What is a Service Mesh (and when to use one)?" (auteur — Gregory MacKinnon) gebruikt. Hierop is te zien hoe een deel van de functionaliteit van de applicaties (groen) is overgedragen aan de service mesh, die de verbindingen tussen hen mogelijk maakt (blauw).