Wanneer je Workspace-integraties uitgroeien tot een verzameling microservices, wordt het netwerk tussen die services een eigen uitdaging. Welke service mag wat aanroepen? Hoe handel je retries en timeouts consistent af? Hoe beveilig je het interne verkeer? Een service mesh beantwoordt deze vragen op infrastructuurniveau, los van je applicatiecode. In dit artikel zie je hoe een mesh past bij Workspace-integraties.
Wat een service mesh doet
Een service mesh schuift een netwerklaag tussen je services. Al het verkeer loopt via die laag, die het beheert. In het klassieke model staat er een proxy naast elke service, een zogenoemde sidecar.
- Retries en timeouts centraal afgedwongen, niet per service gecodeerd.
- Circuit breaking om een falende afhankelijkheid te isoleren.
- Onderlinge mTLS-encryptie tussen al je services.
- Uniforme observability: latency, foutpercentages en tracing.
Beleid in configuratie, niet in code
Het mooie van een mesh is dat deze functies buiten je applicatiecode leven. Je past beleid aan in configuratie, niet door elke service opnieuw te bouwen. Dat is vooral waardevol als veel services dezelfde Workspace-API's aanroepen.
Sidecar of ambient mode?
Sinds 2024 kent Istio naast de klassieke sidecar ook een ambient mode zonder sidecar per pod, die in 2026 voor single-cluster productie als stabiel geldt en multi-cluster in beta heeft. Ambient mode verlaagt geheugen- en CPU-verbruik fors omdat de mesh-laag niet meer in elke pod draait. Voor nieuwe meshes is dit het overwegen waard; bestaande sidecar-meshes blijven volledig ondersteund.
Waar het helpt bij Workspace-calls
Workspace-API's zitten achter het netwerk, en netwerken falen soms. Een mesh maakt dat verkeer robuuster. Drie situaties waarin het echt loont:
- Veel services, dezelfde API's. Roepen meerdere services dezelfde Workspace-API's aan? Centraliseer retry- en timeout-beleid in de mesh in plaats van het overal te dupliceren.
- Vertrouwelijk intern verkeer. Wil je service-naar-service communicatie versleutelen? mTLS uit de mesh regelt dat automatisch, zonder dat elke service zijn eigen certificaten beheert.
- Inzicht richting Google. Heb je zicht nodig op latency en fouten richting de API's? De observability van de mesh levert dat zonder extra code.
Uitgaand verkeer beheren
Workspace-endpoints zijn extern. In een mesh modelleer je die als een externe bestemming met een eigen beleid.
Uitgaand Workspace-verkeer configureren
- Definieer de Google-API-endpoints als externe services in je mesh-configuratie.
- Stel een timeout in die past bij de verwachte responstijd.
- Configureer een beperkt aantal retries, alleen voor veilige, idempotente calls.
- Voeg circuit breaking toe om te stoppen met proberen bij aanhoudende fouten.
- Activeer tracing om de volledige keten tot aan de API te volgen.
Geen blinde retries op schrijfacties
Wees voorzichtig met automatische retries op niet-idempotente operaties zoals het aanmaken van een gebruiker. Een retry kan een dubbele actie veroorzaken. Beperk mesh-retries tot lees-operaties, en regel idempotentie voor schrijfacties expliciet in je applicatie met unieke sleutels.
Observability als grootste winst
Begin bij observability
De observability van een mesh is vaak het eerste dat loont. Je ziet direct welke service traag is richting welke Workspace-API, waar fouten ontstaan en hoe latency zich opstapelt. Dat inzicht maakt het opsporen van problemen in een verdeeld systeem aanzienlijk sneller.
Wie doet wat
Een mesh raakt meerdere rollen in een team. Een heldere verdeling voorkomt dat beleid en code door elkaar lopen.
| Rol | Verantwoordelijkheid |
|---|---|
| Platform-team | Beheert de mesh-configuratie en het beleid voor uitgaand verkeer. |
| Ontwikkelaars | Bouwen services zonder zich druk te maken over retries en mTLS. |
| Security | Stelt mTLS-eisen en autorisatiebeleid tussen services in. |
| SRE | Gebruikt de observability voor monitoring en incidentanalyse. |
Niet voor elk project
Een mesh voegt complexiteit toe. Voor een enkel script of een paar functies is het overkill. Pas als je een echt netwerk van services hebt, wegen de voordelen op tegen de operationele last.
Veelgestelde vragen
Heb ik echt een service mesh nodig voor Workspace-integraties?
Alleen bij een groter netwerk van microservices. Voor losse scripts of een paar functies is een mesh onnodig zware infrastructuur. Begin dan met retry- en timeout-logica in de applicatie zelf.
Vervangt een mesh mijn backoff-logica?
Voor lees-operaties kan de mesh retries afhandelen. Voor schrijfacties houd je idempotentie en gerichte backoff beter in je applicatie, zodat een herhaalde call geen dubbele actie veroorzaakt.
Werkt mTLS ook richting de API's van Google?
mTLS regel je tussen je eigen services. Richting Google gebruik je gewone TLS en OAuth. De mesh beheert vooral je interne verkeer en het uitgaande beleid, zoals timeouts en circuit breaking.
Welke mesh kies ik?
Istio is het bekendst en biedt sinds 2024 ook ambient mode zonder sidecar per pod. Er zijn lichtere alternatieven zoals Linkerd. Kies op basis van je platform en de operationele capaciteit van je team.
Wat is het verschil tussen sidecar en ambient mode?
In sidecar mode draait een proxy naast elke service-pod. In ambient mode verschuift die laag naar een gedeelde component per node, wat geheugen en CPU bespaart. De functionaliteit voor verkeer, mTLS en observability blijft vergelijkbaar.
Een service mesh tilt grootschalige Workspace-integraties naar een hoger niveau van betrouwbaarheid, beveiliging en inzicht, mits je de complexiteit echt nodig hebt.