Wat is platform engineering en wanneer loont het zich?

Wat is platform engineering en wanneer loont het zich?

Platform engineering is de discipline van het ontwerpen en bedrijven van een interne developer platform (IDP) - een self-service laag tussen productteams en ruwe infrastructuur. De zoekopdracht "wat is platform engineering" wordt wereldwijd ongeveer 18.000 keer per maand ingevoerd. Dit vertelt je iets: veel ingenieurs zijn nog onduidelijk of dit een hernoem van DevOps is, een promotie voor SRE's, of een werkelijk architecturale verschuiving in hoe engineeringorganisaties werken. Het is het derde.

Dit is geen beginner's gids voor CI/CD. Dit is een roadmap voor platform engineers, SRE leads en engineeringmanagers die ofwel een platformteam opbouwen, ofwel de investering naar leiderschap moeten rechtvaardigen.

Platform engineering is niet DevOps met een nieuwe naam

DevOps is een set van werkpraktijken en culturele normen. Platform engineering is een teamtopologie met een product.

Het verschil heeft praktische gevolgen. Een DevOps-cultuur moedigt developers aan hun deployments zelf te beheren. Een platformteam bouwt de infrastructuur die eigenaarschap op schaal praktisch maakt: CI/CD pipeline templates, deployment abstracties, observability stacks, secrets management, cost guardrails - en levert dit alles als een intern product dat productteams via self-service interfaces gebruiken.

Bij een organisatie van 20 engineers is dit verschil academisch. Bij 80 engineers is het het verschil tussen infrastructuurkennis gebottlenecked bij twee ops-mensen en een gepaved road die elk team zonder ticket kan gebruiken.

De relatie met SRE is complementair, niet competitief. SRE verbetert hoe systemen in productie zich gedragen. Platform engineering verbetert hoe organisaties het shippen van software opschalen. In de praktijk groeien veel platformteams uit SRE-teams voort, en de SLO-gebaseerde reliability patterns die SRE's toepassen op productiesystemen worden vaak direct in platform deployment gates ingebouwd.

De interne developer platform: wat zit er eigenlijk in

Een IDP is niet een enkel tool. Het is een samenstelling van systemen, doorgaans:

• Een deployment mechanisme (Kubernetes, serverless runtime, of een managed abstractie bovenop een van beide)

• CI/CD pipeline templates met vooraf goedgekeurde configuraties

• Een secrets manager met scoped access en rotation

• Een observability stack (metrics, logs, traces) met voorgeconfigureerde dashboards per service type

• Een service catalog die documenteert wat draait, waar, en wie het bezit

• Een developer portal - Backstage is de de-facto standaard in 2026 - die dit alles via een enkel interface aanbiedt

De kritieke designbeslissing is het abstractieniveau. Expose raw Kubernetes en developers besteden hun tijd aan het debuggen van Helm charts. Abstract te veel en je verliest het vermogen om edge cases en non-standaard workloads op te vangen.

Het werk van het platformteam is het abstractieniveau vinden dat 80% van de use cases zonder aanpassingen dekt, en de escape hatch documenteren voor teams die onder de abstractie moeten gaan. De escape hatch zou schriftelijke verantwoording vereisen, geen platformteam approval bij elke instantie.

Welke teamgrootte rechtvaardigt platform engineering investering?

Er is geen universele drempel, maar post-mortems en DORA-onderzoek wijzen op een consistent bereik.

Onder 30 engineers: de overhead van een dedicated platformteam overschrijdt de waarde. Een paar SRE-gerichte engineers ingebed in feature teams is voldoende.

Tussen 30 en 80 engineers: cognitieve belasting op individuele teams begint op te stapelen. Deploymentkennis concentreert zich bij een handvol mensen. On-call rotaties worden dunner. Een veelvoorkomend incident patroon ontstaat: een developer raakt geblokkeerd op een gedeelde infrastrucuur-issue - permissions, networking configuratie, secrets rotation - en wacht tot de ops-adjacent persoon beschikbaar is. Die wachttijd is het signaal.

Boven 80 engineers: een dedicated platformteam is niet langer optioneel. De DORA State of DevOps 2025 vond dat teams met interne developer platforms 3.5x vaker deployed dan teams zonder, en 25% lagere change failure rates hadden. Die resultaten ontstaan niet per ongeluk. Ze ontstaan omdat het platform de coördinatie-overhead opzoog.

Wat zeggen DORA-gegevens over platformteams

DORA metrics zijn nuttig hier omdat ze resultaten meten, niet activiteit.

High-performing platformteams beweging twee DORA metrics consistent: deployment frequency en change failure rate. Het mechanisme is direct. Gestandaardiseerde deployment pipelines verminderen de variantie hoe code productie bereikt. Geautomatiseerde rollback gates - geactiveerd door SLO breaches in plaats van menselijk oordeel om 3 uur 's nachts - comprimeren MTTR door de tijd tussen detectie en respons te korten.

Het 2025 DORA rapport identificeerde ook een subtieler patroon: teams met hoge platformadoptie hadden lagere rates onplanned work. Onplanned work is de stille degrader van deployment frequency. Het verschijnt niet in sprint velocity. Het toont zich in de kloof tussen wat het team van plan was te shippen en wat werkelijk shipped. Een week waarin twee engineers drie dagen doorbrachten met debuggen van een gedeelde permissions misconfiguratie is een platformbetrouwbaarheidsfailure, zelfs als geen user-facing incident optrad.

Waar platformteams vaak tekort komen op DORA is lead time voor changes. Een platform bouwen voegt proces toe. Slecht ontworpen processen voegen lead time toe. Als je platformteam lead time verhoogt terwijl je deployment frequency verbetert, is die tradeoff het moeite waard om doelbewust te onderzoeken in plaats van het achteraf in een quarterly review te ontdekken.

De inner platform trap: wanneer je platform de bottleneck wordt

Het inner platform effect is de faaluitmodus die niemand discussieert tijdens platform engineering conference presentaties.

Het werkt zo: een platformteam, dat al interne use cases probeert te serveren, bouwt steeds meer algemene abstracties. Elke nieuwe requirement van een productteam wordt ondergebracht. Over tijd wordt het platform een general-purpose infrastructuur systeem - eigenlijk een slechter versie van Kubernetes of Terraform, nu ook onderhouden door een klein team met beperkte bandbreedte en geen dedicated on-call rotatie.

Het resultaat: een platform dat langzamer en moeilijker is om te gebruiken dan de open-source alternatieven die het verving. Het platformteam wordt een ticket queue. Time to production neemt toe. Engineers omzeilen het platform.

De diagnostische vraag is: bouwt het platformteam een product of een service? Een product heeft een opinionated interface, accepteert expliciet sommige use cases als out of scope, en meet adoption rate. Een service probeert elk request te voldoen en wordt gemeten op ticket resolution time. Producten schalen. Services niet.

De praktische test: als het backlog van het platformteam gedomineerd wordt door one-off requests van individuele applicatieteams in plaats van platform-brede verbeteringen, is het team in service mode gedreven. De correctie is definiëren wat het platform doet en niet doet, dat bereik publiceren, en out-of-scope requests naar de escape hatch documentatie leiden.

Self-service vs golden path: de designbeslissing die je platform definieert

Deze twee termen zijn verwant maar niet identiek, en ze verwarren produceert slecht platform design.

Self-service betekent dat een developer kan inrichten wat ze nodig hebben zonder een ticket te openen. Golden path betekent dat er een aanbevolen, pre-tested route van code naar productie is die security scanning, compliance checks en observability configuratie standaard afhandelt.

Self-service zonder een golden path produceert chaos op schaal. Elk team bedenkt zijn eigen deployment topologie. De blast radius van een misconfiguratie wordt onvoorspelbaar omdat niemand een gedeelde map heeft van wat iemand anders draait.

Een golden path zonder betekenisvolle self-service produceert wrijving. Developers wachten op platformteam reviews bij elke afwijking. Het platform wordt waargenomen als een compliance bureaucratie in plaats van een enablend team.

De productieve combinatie: een goed gemarkeerde golden path die het gros van productie workloads dekt, met gedocumenteerde escape hatches voor teams die legitieme redenen hebben om af te wijken. De escape hatch zou schriftelijke verantwoording vereisen, niet approval. Het platformteam herbezoekt escape hatch patronen driemaandelijks en beslist welke in de golden path moeten worden opgenomen op basis van adoptie.

Hoe meet je of je platformteam levert

Een platformteam dat zijn waarde niet kan aantonen zal uiteindelijk ontvoogd of terug in feature teams geabsorbeerd worden. Dit zijn de metrics die traction hebben bij engineeringleiderschap.

Adoptie rate: welk percentage van applicatieteams gebruikt de golden path van het platform voor productie deployments? Een rate onder 60% na 12 maanden is een signaal dat het platform geen echte problemen oplost.

Deployment frequency delta: vergelijk deployment frequency voor teams op het platform versus teams die nog hun eigen pipelines beheren. Een positieve delta binnen zes maanden is het duidelijkste ROI signaal beschikbaar.

Time to first deployment (TF1D): hoe lang duurt het voor een nieuwe service voor het eerst productie bereikt via het platform? Een goed gebouwde IDP zou een standard service onder twee uur naar productie moeten krijgen vanaf initiële setup. Dit is de metric die het meest voor nieuwe hires en team velocity telt.

Ops ticket ratio: welk deel van platformteam werk is het beantwoorden van requests van applicatieteams versus het bouwen van platformcapaciteiten? Boven 40% reactief werk is een waarschuwingsbord. Het betekent dat het platform een service desk is, niet een productteam.

P99 time-to-restore: wanneer iets in productie breekt, hoe lang voordat het ofwel opgelost of teruggezet is? SLO-gated deployment automatisering beïnvloedt direct dit getal. Als je platform geen geautomatiseerde rollback op SLO breach heeft, hangt MTTR helemaal af van wie beschikbaar en wakker is. Om 3 uur 's nachts is dat geen berekening die je handmatig wilt doen.

Wat ziet een goed functionerend platformteam er op schaal uit

Een platform engineering team bij een Series B-D bedrijf (50-500 engineers) werkt doorgaans met:

• Een platform lead of staff engineer die eigenaar is van architecturale richting

• 2-4 senior engineers met infra- of distributed systems achtergrond

• Gedefinieerde SLA's voor het platform zelf

• Een regelmatig contactpunt met application team leads

Het team meet zijn succes door application team uitkomsten - deployment frequency, MTTR, tijd besteed aan ongeplande infrastructuurwerk - niet door de uptime van zijn eigen infrastructuur.

De vraag die het waard is om te stellen voordat je de investering start: besteden jouw applicatieteams meer dan 20% van hun sprint capaciteit aan infrastructuurkwesties die niets met jouw product te maken hebben? Ja, dan is de platform ROI berekening simpel. Nee, dan bouw je organisatorische overhead voordat het probleem dat het oplost bestaat.

Platform engineering goed gedaan is onzichtbaar. De post-mortem zegt 'auto-rollback geactiveerd om 03:47, incident opgelost om 03:47.' De engineeringmanager wordt niet gebeld. Niemand let op. Dat is het doel.