Platform engineering versus DevOps is de verkeerde vraag.
Wat DevOps moest oplossen
DevOps ontstond uit een specifiek probleem: ontwikkelteams leverden code en operationele teams draaiden die, en de grens daartussen produceerde wrijving, storingen en wederzijdse beschuldigingen. De oplossing was de grens op te heffen. Jij bouwt het, jij draait het. Ontwikkelteams nemen operationele verantwoordelijkheid op zich.
Het werkte. Op de teams waar het goed werkte, daalde de mean time to recovery, steeg de deployfrequentie en verkortte de feedbacklus tussen code schrijven en het gedrag ervan in productie waarnemen van weken naar uren. DORA-metrics leverden het meetmodel. De resultaten waren reëel.
Het toil-probleem dat op schaal verscheen
Op schaal verscheen een probleem dat de oorspronkelijke DevOps-formulering niet had voorzien. Als elk ontwikkelteam verantwoordelijk is voor zijn eigen infrastructuur, beveiliging, observability, deployment-pipeline en on-call-rotatie, stapelen die verantwoordelijkheden zich op. Een team van 5 engineers met volledige DevOps-verantwoordelijkheid bij 3 services wordt een team van 8 engineers met gefragmenteerde aandacht over 7 services en een groeiende onderhoudsachterstand voor alle tooling die ze schreven om die services te ondersteunen.
De cognitieve belasting is niet lineair. Elk team repliceert dezelfde Terraform-modules, dezelfde CI-pipeline-patronen, dezelfde Kubernetes-manifests, dezelfde waarschuwingsregels. Sommigen doen het goed. Anderen doen het slecht. De organisatie kan niet zeggen welk welk is totdat er iets breekt in productie.
Het DORA-rapport van 2024 noemde dit expliciet. Cognitieve belasting is een van de sterkste voorspellers van slechte softwareleveringsprestaties. Teams die toil elimineren via gedeelde platforms presteren beter dan teams die toil verdelen via individuele DevOps-verantwoordelijkheid. Dit is de bevinding die het geval voor platform engineering maakt, niet een slide deck.
Wat platform engineering werkelijk is
Platform engineering is geen vervanging voor DevOps. Het is een structureel antwoord op het toil-probleem. Een platformteam bouwt en onderhoudt de gedeelde infrastructuur, tooling en abstracties waarmee ontwikkelteams DevOps kunnen beoefenen zonder telkens hetzelfde wiel opnieuw uit te vinden. De ontwikkelteams bouwen en draaien hun services nog steeds. Het platform verwijdert het niet-gedifferentieerde werk uit hun pad.
Het sleutelbegrip is de geplaveide weg: een goed ondersteund, eigenzinnig standaardpad dat de meeste teams de meeste tijd gebruiken. Geplaveide wegen zijn geen vangrails. Vangrails voorkomen slechte uitkomsten door slechte keuzes te blokkeren. Geplaveide wegen versnellen goede uitkomsten door de goede keuze de gemakkelijke keuze te maken. Een team dat ervoor kiest de geplaveide weg te verlaten kan dat; ze bezitten alleen het extra onderhoud.
In de praktijk bezit het platformteam het containerplatform, deployment-pipeline-templates, observability-stack, secrets-beheer en de landing zone. Ontwikkelteams bezitten hun services, data, feature-beslissingen en SLO's. De grens is duidelijk. De cognitieve belasting aan elke kant is begrensd.
"Platform engineering is hoe DevOps eruitziet als het werkt op schaal. De meeste teams die de vraag stellen, zitten al op het pad."
Sebastiaan van Parijs / Founder
Wat verandert en wat blijft
De overgang naar platform engineering lost de DevOps-cultuur niet op. Ontwikkelteams bezitten hun services nog steeds van begin tot eind. Ze dragen nog steeds de pager. Ze schrijven nog steeds runbooks. Ze nemen nog steeds deel aan on-call. De operationele verantwoordelijkheid is intact.
Wat verandert is wie de steigers bouwt. Op een DevOps-enkel-team bouwt elk team zijn eigen steigers. Op een platform-engineering-team bouwt het platformteam gedeelde steigers die ontwikkelteams uitbreiden. Het werk dat elke developer doet is meer gedifferentieerd, minder repetitief.
De organisatorische overgang duurt 3 tot 9 maanden afhankelijk van de omvang van de estate. De eerste mijlpaal is een geplaveide weg die twee productteams 90 dagen aannemen en op blijven zonder dat het platformteam hoeft in te grijpen. De tweede mijlpaal is dat nieuwe services standaard op de geplaveide weg worden aangemeld. De derde mijlpaal is dat de roadmap van het platformteam wordt aangestuurd door feedback van developers, niet door post-mortems van incidenten.
De meeste bedrijven die de DevOps versus platform engineering-vraag stellen, zitten bij de eerste mijlpaal. De vraag zelf is een signaal dat de toil zichtbaar is. Dat is het juiste moment om te beginnen.