🥇Gebruiksscenario's voor service mesh

Opmerking. vert.: De auteur van dit artikel (Luc Perkins) is pleitbezorger voor ontwikkelaars bij de CNCF-organisatie, die de thuisbasis is van Open Source-projecten als Linkerd, SMI (Service Mesh Interface) en Kuma (heb je je trouwens ook afgevraagd waarom Istio niet op deze lijst.). Opnieuw probeert hij de DevOps-gemeenschap een beter begrip te geven van de trendy hype die ‘service mesh’ wordt genoemd. Hij somt 16 karakteristieke mogelijkheden op die dergelijke oplossingen bieden.

Vandaag servicegaas – een van de populairste onderwerpen op het gebied van software-engineering (en terecht!). Ik denk dat deze technologie ongelooflijk veelbelovend is en zou graag zien dat deze op grote schaal wordt toegepast (als het logisch is, natuurlijk). Voor de meeste mensen hangt er echter nog steeds een aura van mysterie omheen. Tegelijkertijd zelfs degenen die dat wel doen bekend daarmee is het vaak moeilijk om de voordelen ervan onder woorden te brengen en wat het precies is (inclusief de ondergetekende). In dit artikel zal ik proberen de situatie te corrigeren door er verschillende op te sommen gebruiksgevallen "servicenetten"*.

* Opmerking vert.: hier en verder in het artikel zal precies deze vertaling (“service mesh”) worden gebruikt voor de nog nieuwe term service mesh.

Maar eerst wil ik een paar opmerkingen maken:

Ik heb nog nooit met service meshes gewerkt of deze gebruikt buiten projecten die voor mijn eigen opleiding zijn gestart. Aan de andere kant was ik degene die in 2015 een heleboel documentatie schreef voor de interne service mesh van Twitter (het heette toen nog niet eens een "service mesh") en nam deel aan de ontwikkeling van de website en documentatie voor Linkerd, dus dat betekent iets.
Mijn lijst is bij benadering en onvolledig. Het kan zijn dat er gebruiksscenario's zijn die mij onbekend zijn, en er zullen waarschijnlijk in de loop van de tijd nieuwe opties ontstaan naarmate de technologie zich ontwikkelt en de populariteit ervan groeit.
Tegelijkertijd ondersteunt niet elke bestaande service mesh-implementatie alle genoemde gebruiksscenario's. Daarom moeten mijn uitspraken als “service mesh can...” worden gelezen als “individueel, en misschien kunnen alle populaire service mesh-implementaties...”.
De volgorde van de voorbeelden maakt geen enkel verschil.

Korte lijst:

ontdekking van diensten;
encryptie;
authenticatie en authorisatie;
taakverdeling;
circuitonderbreking;
automatisch schalen;
kanarie-implementaties;
blauw-groene implementaties;
gezondheids controle;
belastingafschakeling;
verkeersspiegeling;
isolatie;
beperking van de verzoeksnelheid, nieuwe pogingen en time-outs;
telemetrie;
audit;
visualisatie.

1. Ontdekking van diensten

TL;DR: Maak verbinding met andere services op het netwerk met behulp van eenvoudige namen.

Diensten moeten elkaar automatisch kunnen ‘vinden’ met behulp van adequate namen, bijvoorbeeld service.api.production, pets/staging of cassandra. Cloudomgevingen zijn elastisch en één enkele naam kan veel exemplaren van een service verbergen. Het is duidelijk dat het in een dergelijke situatie fysiek onmogelijk is om alle IP-adressen hard te coderen.

Bovendien zou de ene dienst, wanneer de ene dienst een andere vindt, verzoeken naar die dienst moeten kunnen sturen zonder bang te hoeven zijn dat deze bij de ingang van het defecte exemplaar terechtkomen. Met andere woorden: de service mesh moet de gezondheid van alle service-instances bewaken en de lijst met hosts zo actueel mogelijk houden.

Elke servicemesh implementeert het servicedetectiemechanisme anders. Op dit moment is de meest gebruikelijke manier om te delegeren aan externe processen zoals Kubernetes DNS. In het verleden gebruikten we hiervoor op Twitter een naamgevingssysteem Finaal. Bovendien maakt service mesh-technologie het mogelijk dat aangepaste naamgevingsmechanismen ontstaan (hoewel ik nog geen enkele SM-implementatie met dergelijke functionaliteit heb gezien).

2. Encryptie

TL;DR: Elimineer ongecodeerd verkeer tussen services en maak dit proces geautomatiseerd en schaalbaar.

Het is prettig om te weten dat aanvallers uw interne netwerk niet kunnen binnendringen. Firewalls doen dit uitstekend. Maar wat gebeurt er als een hacker toch binnenkomt? Zal hij met het intraserviceverkeer kunnen doen wat hij wil? Laten we hopen dat dit uiteindelijk niet gebeurt. Om dit scenario te voorkomen, moet u een zero-trust netwerk implementeren waarin al het verkeer tussen services wordt gecodeerd. De meeste moderne servicenetwerken bereiken dit via wederzijdse dienstverlening TLS (wederzijdse TLS, mTLS). In sommige gevallen werkt mTLS in hele wolken en clusters (ik denk dat interplanetaire communicatie ooit op dezelfde manier zal verlopen).

Natuurlijk voor mTLS-servicemesh optioneel. Elke service kan voor zijn eigen TLS zorgen, maar dit betekent dat u een manier moet vinden om certificaten te genereren, deze over servicehosts te distribueren en code in de toepassing op te nemen die deze certificaten uit bestanden laadt. Ja, vergeet niet deze certificaten regelmatig te vernieuwen. Service meshes automatiseren mTLS met systemen zoals SPIFFE, die op hun beurt het proces van uitgifte en rotatie van certificaten automatiseren.

3. Authenticatie en autorisatie

TL;DR: Stel vast wie de aanvrager is en definieer wat deze mag doen voordat het verzoek zelfs maar de dienst bereikt.

Diensten willen het vaak weten die voert het verzoek uit (authenticatie) en beslist op basis van deze informatie dat een bepaalde entiteit mag doen (autorisatie). In dit geval kan het voornaamwoord "wie" zich verbergen:

Andere diensten. Dit heet "authenticatie" gelijke" Dienstverlening bijvoorbeeld web wil toegang tot de dienst db. Service meshes lossen dergelijke problemen meestal op met behulp van mTLS: certificaten fungeren in dit geval als de noodzakelijke identificatie.
Sommige menselijke gebruikers. Dit heet "authenticatie" verzoek" Bijvoorbeeld gebruiker haxor69 wil een nieuwe lamp kopen. Service meshes bieden verschillende mechanismen, b.v. JSON-webtokens.
Velen van ons hebben dit in applicatiecode gedaan. Er komt een verzoek binnen, we kijken door de tabel users, zoek de gebruiker, vergelijk het wachtwoord en controleer vervolgens de kolom permissions enz. In het geval van een service mesh gebeurt dit voordat het verzoek zelfs maar de dienst bereikt.

Nadat we hebben vastgesteld van wie het verzoek afkomstig is, moeten we bepalen wat deze entiteit mag doen. Met sommige servicemeshes kunt u basisbeleid instellen (over wie wat kan doen) als YAML-bestanden of op de opdrachtregel, terwijl andere integratie bieden met frameworks zoals Beleidsagent openen. Het uiteindelijke doel is dat uw services elk verzoek accepteren, ervan uitgaande dat het afkomstig is van een vertrouwde bron и deze actie is toegestaan.

4. Belastingverdeling

TL;DR: Verdeel de belasting over service-instanties volgens een specifiek patroon.

Een “Service” binnen een servicesectie bestaat vaak uit veel identieke instanties. Vandaag bijvoorbeeld de dienst cache bestaat uit 5 exemplaren, en morgen kan hun aantal toenemen tot 11. Verzoeken verzonden naar cache, moet worden verspreid in overeenstemming met een specifiek doel. Minimaliseer bijvoorbeeld de latentie of maximaliseer de kans dat u een werkend exemplaar bereikt. Het meest gebruikte algoritme is Round-robin, maar er zijn er nog veel meer, bijvoorbeeld de gewogen methode (gewogen) zoekopdrachten (u kunt voorkeursdoelen selecteren), bel (ring) hashing (met behulp van consistente hashing over upstream-hosts) of minste verzoekmethode (de voorkeur wordt gegeven aan de instantie met de minste verzoeken).

Klassieke balancers hebben andere functies, zoals HTTP-caching en DDoS-bescherming, maar ze zijn niet erg relevant voor oost-west-verkeer (dat wil zeggen, voor verkeer dat binnen een datacenter stroomt - ongeveer vert.) (typische reikwijdte van service mesh). Het is uiteraard niet nodig om een service mesh te gebruiken voor taakverdeling, maar je kunt hiermee wel het evenwichtsbeleid voor elke dienst instellen en controleren vanuit een gecentraliseerde controlelaag, waardoor de noodzaak wordt geëlimineerd om afzonderlijke taakverdelingen in de netwerkstack uit te voeren en te configureren. .

5. Circuitonderbreking

TL;DR: Stop het verkeer naar de problematische dienst en beheers de schade in het ergste geval.

Als de service om de een of andere reden het verkeer niet aankan, biedt de service mesh verschillende opties om dit probleem op te lossen (andere zullen in de betreffende secties worden besproken). Het verbreken van een circuit is de meest ernstige optie om een dienst los te koppelen van het verkeer. Op zichzelf heeft het echter geen zin: er is een back-upplan nodig. Er kan tegendruk worden geboden (tegendruk) naar diensten die verzoeken doen (vergeet alleen niet je service mesh hiervoor in te stellen!), of bijvoorbeeld de statuspagina rood kleuren en gebruikers doorverwijzen naar een andere versie van de pagina met een “vallende walvis” (“Twitter is omlaag").

Met servicemeshes kunt u niet alleen definiëren wanneer afsluiting zal volgen en dat dit zal volgen. In dit geval kan “wanneer” elke combinatie van gespecificeerde parameters omvatten: het totale aantal verzoeken voor een bepaalde periode, het aantal parallelle verbindingen, openstaande verzoeken, actieve nieuwe pogingen, enz.

Je wilt waarschijnlijk geen misbruik maken van het onderbreken van circuits, maar het is fijn om te weten dat je een back-upplan hebt voor geval van nood.

6. Automatisch schalen

TL;DR: Verhoog of verlaag het aantal service-exemplaren, afhankelijk van de opgegeven criteria.

Servicemeshes zijn geen planners, dus dat is ook niet het geval uitvoeren jezelf opschalen. Ze kunnen echter wel informatie verschaffen waarop planners hun beslissingen zullen baseren. Omdat service meshes toegang hebben tot al het verkeer tussen diensten, hebben ze uitgebreide informatie over wat er gebeurt: welke diensten ondervinden problemen, welke diensten zijn zeer licht belast (de toegewezen capaciteit gaat verloren), enz.

Kubernetes schaalt services bijvoorbeeld op basis van het CPU- en geheugengebruik van de pods (zie ons rapport "Automatisch schalen en resourcebeheer in Kubernetes" - ca. vert.), maar als u besluit te schalen op basis van een andere statistiek (in ons geval verkeersgerelateerd), heeft u een speciale statistiek nodig. Beheer soortgelijk laat zien hoe je dit kunt doen Gezant, Istio и Prometheus, maar het proces zelf is behoorlijk ingewikkeld. We zouden graag zien dat de service mesh dit vereenvoudigt door ons in staat te stellen eenvoudigweg voorwaarden te stellen zoals “het aantal service-instances verhogen auth, als het aantal openstaande verzoeken binnen een minuut de drempel overschrijdt."

7. Kanarie-implementaties

TL;DR: Test nieuwe functies of serviceversies op een subset van gebruikers.

Stel dat u een SaaS-product ontwikkelt en van plan bent er een coole nieuwe versie van uit te rollen. Je hebt het in enscenering getest en het werkte prima. Maar er zijn nog steeds bepaalde zorgen over haar gedrag in reële omstandigheden. Met andere woorden: u moet de nieuwe versie testen op echte problemen zonder het vertrouwen van de gebruiker in gevaar te brengen. Kanarie-implementaties zijn hier geweldig voor. Hiermee kunt u een nieuwe functie aan een subset van gebruikers demonstreren. Deze subgroep kan bestaan uit de meest loyale gebruikers of degenen die met de gratis versie van het product werken, of uit gebruikers die de wens hebben geuit om “proefkonijnen” te zijn.

Service meshes implementeren dit door u in staat te stellen criteria op te geven die bepalen wie welke versie van de applicatie te zien krijgt, en het verkeer dienovereenkomstig te routeren. Voor de diensten zelf verandert er echter niets. Versie 1.0 van de dienst is van mening dat alle verzoeken afkomstig zijn van gebruikers die de dienst zouden moeten zien, en versie 1.1 gelooft hetzelfde voor zijn gebruikers. Ondertussen kunt u het percentage verkeer tussen de oude en de nieuwe versie wijzigen, waardoor een groeiend aantal gebruikers naar de nieuwe versie wordt omgeleid als deze stabiel werkt en uw “proefkonijnen” groen licht geven.

8. Blauw-groene implementaties

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

betekenis blauwgroene implementaties is om een nieuwe “blauwe” dienst uit te rollen, parallel aan de oude, “groene” dienst. Als alles soepel verloopt en de nieuwe dienst goed presteert, kan de oude geleidelijk worden uitgeschakeld. (Helaas, op een dag zal deze nieuwe “blauwe” dienst het lot van de “groene” dienst herhalen en verdwijnen...) Blauw-groene implementaties verschillen van kanarie-implementaties doordat de nieuwe functie betrekking heeft op iedereen tegelijk gebruikers (geen onderdeel); Het punt hier is om een ‘veilige haven’ klaar te hebben als er iets misgaat.

Service meshes bieden een zeer handige manier om een ‘blauwe’ service te testen en bij problemen direct over te schakelen naar een werkende ‘groene’ service. Om nog maar te zwijgen van het feit dat ze onderweg veel informatie geven (zie 'Telemetrie' hieronder) over het werk van de 'blauwe', wat helpt te begrijpen of deze klaar is voor volledige werking.

Opmerking. vert.: U kunt meer lezen over verschillende implementatiestrategieën in Kubernetes (waaronder de genoemde kanarie, blauw/groen en andere) in dit artikel.

9. Gezondheidscontrole

TL;DR: Houd bij welke service-instances functioneel zijn en reageer op de service-instances die niet langer functioneel zijn.

Gezondheids controle (gezondheids controle) helpt beslissen of service-instances klaar zijn om verkeer te accepteren en te verwerken. In het geval van HTTP-services kan een statuscontrole er bijvoorbeeld uitzien als een GET-verzoek aan het eindpunt /health. Antwoord 200 OK zal betekenen dat de instantie gezond is, en elke andere - dat deze niet gereed is om verkeer te ontvangen. Met service meshes kunt u zowel de manier specificeren waarop de functionaliteit wordt gecontroleerd als de frequentie waarmee deze controle wordt uitgevoerd. Deze informatie kan vervolgens voor andere doeleinden worden gebruikt, bijvoorbeeld voor taakverdeling en circuitonderbreking.

Gezondheidscontrole is dus geen op zichzelf staand gebruik, maar wordt meestal gebruikt om andere doelen te bereiken. Afhankelijk van de resultaten van de statuscontroles kunnen er ook acties buiten andere service mesh-doelen nodig zijn: bijvoorbeeld het bijwerken van de statuspagina, het aanmaken van een issue op GitHub of het invullen van een JIRA-ticket. En service mesh biedt een handig mechanisme om dit allemaal te automatiseren.

10. Lastafschakeling

TL;DR: Verkeer omleiden als reactie op een tijdelijke piek in gebruik.

Als een bepaalde dienst overbelast is met verkeer, kunt u een deel van dit verkeer tijdelijk omleiden naar een andere locatie (dat wil zeggen “dumpen”, “overbrengen” (schuur) hij daar). Bijvoorbeeld naar een back-upservice of datacenter, of naar een permanent pers onderwerp. Als gevolg hiervan zal de service sommige verzoeken blijven verwerken in plaats van te crashen en de verwerking van alles helemaal stop te zetten. Het afschaffen van de belasting verdient de voorkeur boven het onderbreken van het circuit, maar het is nog steeds niet aan te raden hier misbruik van te maken. Het helpt trapsgewijze fouten te voorkomen die ervoor zorgen dat downstream-services vastlopen.

11. Parallellisatie/spiegeling van verkeer

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

Soms is het nodig om een verzoek (of een bepaalde selectie van verzoeken) tegelijk naar meerdere diensten te sturen. Een typisch voorbeeld is het sturen van een deel van het productieverkeer naar een stagingservice. De hoofdproductiewebserver stuurt een verzoek naar de downstreamservice products.production en alleen voor hem. En de service mesh kopieert dit verzoek op intelligente wijze en stuurt het naar products.staging, waarvan de webserver zich niet eens bewust is.

Een ander gerelateerd servicemesh-gebruiksscenario dat kan worden geïmplementeerd bovenop verkeersparallelisatie is regressie testen. Hierbij worden dezelfde verzoeken naar verschillende versies van de dienst gestuurd en wordt gecontroleerd of alle versies zich hetzelfde gedragen. Ik ben nog geen service mesh-implementatie tegengekomen met een geïntegreerd regressietestsysteem zoals Diffy, maar het idee zelf lijkt veelbelovend.

12. Isolatie

TL;DR: Verdeel uw servicegaas in mininetwerken.

Ook gekend als segmentatieIsolatie is de kunst van het verdelen van een servicenetwerk in logisch gescheiden segmenten die niets van elkaar weten. Isolatie lijkt een beetje op het creëren van virtuele privénetwerken. Het fundamentele verschil is dat u nog steeds kunt profiteren van alle voordelen van een servicemesh (zoals servicedetectie), maar dan met extra beveiliging. Als een aanvaller bijvoorbeeld een dienst op het ene subnet kan binnendringen, kan hij niet zien welke diensten op andere subnetten draaien en kan hij hun verkeer niet onderscheppen.

Daarnaast kunnen de voordelen ook organisatorisch van aard zijn. Misschien wilt u uw services subnetten op basis van uw bedrijfsstructuur en ontwikkelaars ontlasten van de cognitieve belasting die gepaard gaat met het in gedachten houden van de hele service mesh.

13. Verzoek om snelheidsbeperking, nieuwe pogingen en time-outs

TL;DR: U hoeft niet langer de kerntaken voor verzoekbeheer in uw codebase op te nemen.

Al deze dingen kunnen als afzonderlijke gebruiksscenario's worden beschouwd, maar ik heb besloten ze te combineren vanwege één gemeenschappelijk kenmerk: ze nemen de beheertaken van de levenscyclus van aanvragen over die doorgaans door applicatiebibliotheken worden afgehandeld. Als u een webserver ontwikkelt in Ruby on Rails (niet geïntegreerd met een servicemesh) die verzoeken doet om backend-services te maken via gRPC, zal de toepassing moeten beslissen wat er moet gebeuren als N verzoeken mislukken. U zult ook moeten uitzoeken hoeveel verkeer deze services kunnen verwerken en deze parameters hardcoderen met behulp van een speciale bibliotheek. Bovendien zal de applicatie moeten beslissen wanneer het tijd is om op te geven en het verzoek te laten verlopen (op basis van een time-out). En om een van de bovenstaande parameters te wijzigen, zal de webserver moeten worden gestopt, opnieuw geconfigureerd en opnieuw gestart.

Het overbrengen van deze taken naar een service mesh betekent niet alleen dat service-ontwikkelaars er niet meer over hoeven na te denken, maar ook dat ze op een meer mondiale manier kunnen worden bekeken. Als er gebruik wordt gemaakt van een complexe keten van diensten, bijvoorbeeld A -> B -> C -> D -> E, moet rekening worden gehouden met de gehele levenscyclus van het verzoek. Als het de taak is om time-outs in service C te verlengen, is het logisch om dit in één keer te doen, en niet in delen: door de servicecode bij te werken en te wachten tot het pull-verzoek wordt geaccepteerd en het CI-systeem de bijgewerkte service implementeert.

14. Telemetrie

TL;DR: Verzamel alle noodzakelijke (en niet helemaal) informatie van services.

Telemetrie is een algemene term die metrische gegevens, gedistribueerde tracering en logboeken omvat. Service meshes bieden mechanismen voor het verzamelen en verwerken van alle drie soorten gegevens. Dit is waar de zaken een beetje wazig worden omdat het aantal mogelijke opties te groot is. Om statistieken te verzamelen is er Prometheus en andere tools die kunnen worden gebruikt om logbestanden te verzamelen vloeiend, Loki, vector и др. (bijvoorbeeld ClickHouse met onze blokhut voor K8's - ca. vert.), voor gedistribueerde tracering is er Jager enzovoort. Elke service mesh ondersteunt mogelijk bepaalde tools en andere niet. Het zal interessant zijn om te zien of het project dat kan Telemetrie openen zorgen voor enige convergentie.

Het voordeel van service mesh-technologie is in dit geval dat zijspancontainers in principe alle bovenstaande gegevens van hun diensten kunnen verzamelen. Met andere woorden, u beschikt over één telemetrieverzamelsysteem en de service mesh kan al deze informatie op verschillende manieren verwerken. Bijvoorbeeld:

staartlogboeken van een bepaalde service in de CLI;
het aantal verzoeken vanuit het service mesh-dashboard bewaken;
verzamel gedistribueerde sporen en stuur deze door naar een systeem zoals Jaeger.

Aandacht, subjectief oordeel: Over het algemeen is telemetrie een gebied waarin sterke interferentie van de service mesh ongewenst is. Het verzamelen van basisinformatie en het on-the-fly volgen van een aantal gouden statistieken, zoals het succespercentage van verzoeken en de latentie, is prima, maar laten we hopen dat we geen Frankenstein-stacks zien verschijnen die gespecialiseerde systemen proberen te vervangen, waarvan sommige zichzelf al hebben bewezen en goed bestudeerd zijn. .

15. Controle

TL;DR: Degenen die de lessen van de geschiedenis vergeten, zijn gedoemd ze te herhalen.

Auditing is de kunst van het observeren van belangrijke gebeurtenissen in een systeem. In het geval van een servicemesh kan dit betekenen dat wordt bijgehouden wie verzoeken heeft ingediend bij specifieke eindpunten voor specifieke services, of hoe vaak een beveiligingsgerelateerde gebeurtenis heeft plaatsgevonden in de afgelopen maand.

Het is duidelijk dat auditing zeer nauw verwant is aan telemetrie. Het verschil is dat telemetrie doorgaans wordt geassocieerd met zaken als productiviteit en technische integriteit, terwijl auditing betrekking kan hebben op juridische en andere kwesties die verder gaan dan de strikt technische sfeer (bijvoorbeeld naleving van de AVG – de Algemene Verordening van de EU inzake gegevensbescherming).

16. Visualisatie

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

Misschien bestaat er een betere term, maar die ken ik niet. Ik bedoel eenvoudigweg een grafische weergave van een servicemesh of enkele componenten ervan. Deze visualisaties kunnen indicatoren bevatten zoals gemiddelde latenties, zijspanconfiguratie-informatie, resultaten van gezondheidscontroles en waarschuwingen.

Werken in een servicegerichte omgeving brengt een veel hogere cognitieve belasting met zich mee vergeleken met Zijne Majesteit de Monoliet. Daarom moet de cognitieve druk koste wat het kost worden verminderd. Een eenvoudige grafische interface voor een servicemesh met de mogelijkheid om op een knop te klikken en het gewenste resultaat te krijgen, zou doorslaggevend kunnen zijn voor de groei en populariteit van deze technologie.

Staan niet in de lijst

Oorspronkelijk was ik van plan nog een paar gebruiksscenario's in de lijst op te nemen, maar besloot toen dat niet te doen. Hier zijn ze, samen met de redenen voor mijn beslissing:

Multi-datacenter. Naar mijn mening is dit niet zozeer een use-case als wel een smal en specifiek toepassingsgebied van servicemeshes of een reeks functies zoals service-ontdekking.
In- en uitgang. Dit is een gerelateerd gebied, maar ik heb mezelf (misschien kunstmatig) beperkt tot de gebruikssituatie van "oost-westverkeer". Ingress en egress verdienen een apart artikel.

Conclusie

Dat is het voor nu! Nogmaals, deze lijst is zeer willekeurig en hoogstwaarschijnlijk onvolledig. Als je denkt dat ik iets heb gemist of iets verkeerd heb gedaan, neem dan contact met mij op via Twitter (@luckerkins). Respecteer alstublieft de fatsoensregels.

PS van vertaler

De titelillustratie voor het artikel is gebaseerd op een afbeelding uit het artikel “Wat is een Service Mesh (en wanneer moet u er een gebruiken)?"(door Gregory MacKinnon). Het laat zien hoe sommige functionaliteit van applicaties (in groen) is verplaatst naar een servicegaas dat onderlinge verbindingen biedt (in blauw).