Wat is platform engineering? Uitleg voor tech leads
Samenvatting
Wat is platform engineering? Het is het bouwen en beheren van een intern platform dat ontwikkelaars zelfservice geeft voor omgevingen, pipelines, services, documentatie en guardrails. Een klein team behandelt het pad van idee naar productie als product, en de ontwikkelaars zijn de klanten. Het doel is minder wachten, minder tickets en minder tools om te leren. Hieronder lees je wat een platformteam bouwt, wanneer het de moeite waard is en waar het misgaat.
Wat is platform engineering? In de praktijk is het het bouwen en beheren van een intern platform dat ontwikkelaars zelfservice geeft voor alles wat ze nodig hebben om software uit te leveren: omgevingen, pipelines, services, documentatie en guardrails. Een klein team behandelt het pad tussen "ik heb een idee" en "het draait in productie" als een product, en de ontwikkelaars zijn de klanten. Het doel is minder wachten, minder tickets en minder tools om te leren.
Je hebt dit probleem waarschijnlijk al gezien. Een nieuwe service heeft een repo nodig, een pipeline, een database, secrets, dashboards en een on-call rooster, en elk daarvan zit achter een andere wikipagina of een andere collega op Slack.
Waarom is platform engineering eigenlijk ontstaan?
"You build it, you run it" werkte prima zolang een team een service en een handvol tools beheerde. Het hield op te schalen toen de toolchain groeide naar Kubernetes, Terraform, drie CI-systemen, een secrets manager, een service mesh en een observability-stack. Elke productontwikkelaar werd geacht een deeltijd-infrastructuurengineer te zijn.
De kosten zie je niet als regel op een budget, maar als cognitieve belasting. Een ontwikkelaar die 90 minuten nodig heeft om uit te zoeken welke Helm-chart de "juiste" is, is niet vertraagd door een gebrek aan vaardigheid. Die is vertraagd door een gebrek aan standaarden.
Platform engineering is de correctie. In plaats van elk team dezelfde stack te laten samenstellen, bouwt een apart team die stack een keer en maakt het de makkelijke optie en houdt het gezond. Analisten zien dezelfde trend: Gartner verwacht dat 80% van de grote software-engineeringorganisaties tegen 2026 een platformengineeringteam heeft, tegen 45% in 2022.
Wat bouwt een platformteam eigenlijk?
Negeer de diagrammen van de leveranciers even. In de meeste bedrijven levert een platformteam vier dingen op.
Een interne developer platform (IDP). De verzameling self-service tools en workflows bovenop je cloud en CI. Dat kan een Backstage-portaal zijn, een productpakket van een leverancier of een goed bijgehouden repo met templates en een CLI.
Golden paths. Opinionated, ondersteunde routes voor veelvoorkomende taken, zoals "maak een nieuwe API-service" of "voeg een queue toe".
Guardrails. Beleid, scanning en kostenlimieten die standaard gelden, zodat de veilige optie ook de makkelijke is.
Documentatie en vindbaarheid. Een catalogus die antwoord geeft op "wie is eigenaar van deze service, waar staat de runbook en wat hangt ervan af?"
Voor geen van deze dingen heb je een nieuwe productcategorie nodig. Veel goede platforms begonnen als een cookiecutter-template en een README die iemand actueel hield.
Wat is een golden path, en waarom negeren teams ze?
De CNCF omschrijft een golden path als "templated composition of well-integrated code and capabilities for rapid project development". Die definitie loopt Google Cloud door aan de hand van een Spring Boot-voorbeeld. Simpel gezegd is het een template die een nieuwe service op dag één een repo, een pipeline, logging en deployconfiguratie geeft.
Het faalpatroon is net zo simpel. Een pad waar niemand om vroeg, gebouwd zonder te praten met de teams die het moeten gebruiken, blijft steken op enkele procenten adoptie, terwijl het platformteam zich afvraagt waarom ontwikkelaars steeds tickets openen. Het pad moet korter zijn dan de workaround, anders kiezen mensen de workaround.
Twee regels houden golden paths levend:
Bestraat, niet omheind. Ontwikkelaars mogen het pad verlaten, maar dan nemen ze de ondersteuning over van wat ze daarbuiten bouwen.
Beheerd als product. Iemand leest de feedback, volgt het gebruik en verwijdert paden die niemand gebruikt.
Is platform engineering gewoon DevOps met een nieuwe naam?
Gedeeltelijk, en het eerlijke antwoord is nuttiger dan het marketingantwoord. DevOps is een cultuur: gedeelde verantwoordelijkheid tussen ontwikkeling en operations, en korte feedbackloops. Platform engineering is een manier om die cultuur op schaal houdbaar te maken door herhaald operationeel werk om te zetten in een product.
SRE is weer een ander vak. SRE's bepalen betrouwbaarheidsdoelen, meten ze en beslissen wanneer je stopt met uitrollen om ze te beschermen. Een platformteam levert de geplaveide weg. Een SRE-team vertelt je hoeveel risico je op die weg kunt veroorloven.
DevOps is een cultuur en een set praktijken. De output is gedeelde verantwoordelijkheid en automatisering. Het faalt meestal doordat het een functietitel en een ticketwachtrij wordt.
SRE is een betrouwbaarheidsdiscipline. De output is SLO's, foutbudgetten en een incidentproces. Het faalt meestal doordat het een pager-rooster wordt zonder enige zeggenschap.
Platform engineering is een intern producteam. De output is een self-service platform en golden paths. Het faalt meestal doordat het een platform wordt dat niemand gebruikt.
De faalpatronen verdienen een tweede lezing. Een platformteam dat tickets aanneemt en bouwt wat gevraagd wordt, is een hernoemd ops-team en erft alle oude wachtrijproblemen.
Wanneer is een platformteam de bezetting waard?
Sla het over als je minder dan ongeveer 30 engineers hebt en één of twee services. Op die schaal volstaan een goede template-repo en een gedeelde Terraform-module. Een voltijds platformteam is dan overhead. Een paar mensen in een team van tien worden stilletjes het platform, en dat is prima.
Het begint zich uit te betalen als je dezelfde signalen steeds ziet terugkomen:
Nieuwe services doen er weken over om in productie te komen, vooral omdat ze op anderen wachten.
Drie teams hebben hetzelfde deployprobleem op drie verschillende manieren opgelost.
Een nieuwe engineer inwerken betekent een stapel impliciete kennis en veel "vraag maar aan Priya, zij weet het".
Security- en compliancereviews komen aan het eind, per team, handmatig.
De kleinste nuttige versie is wat Team Topologies de thinnest viable platform noemt: net genoeg om de grootste herhaalde pijn weg te nemen, goed gedocumenteerd, en verder niets. Begin met de ene workflow die tussen teams de meeste uren kost, meestal "maak een nieuwe service aan" of "krijg een preview-omgeving".
Feature management is een goed voorbeeld van een functie die goedkoper is als gedeelde service dan als tien eigen varianten.
Een flag-service die elk team kan aanroepen, met dezelfde audittrail en dezelfde opruimregels, bespaart elk team het schrijven van een half werkend toggle-systeem. Of je het nu koopt of bouwt, het hoort op het platform thuis en niet in elke repo.
Wat heeft een platform met het lezen van code te maken?
Meer dan de diagrammen toegeven. Een platform is pas bruikbaar als de kennis eromheen klopt. Als een ontwikkelaar vraagt "hoe authenticeert service A bij service B?", staat het antwoord in code, config en een runbook die misschien zes maanden oud is.
Hier verliest een platformteam stilletjes veel tijd. Het krijgt de Slack-vraag die begint met "waar is X geconfigureerd?" en beantwoordt die uit het hoofd, voor de vijfde keer deze week. Je ziet het effect zodra een repo voorbij de 80.000 regels groeit en het platformteam een menselijke zoekindex wordt.
Een paar tools helpen hier, en ze lossen verschillende helften van het probleem op. Docs-as-code-tools houden het geschreven deel dicht bij de bron.
Code-aware assistenten beantwoorden vragen over de code zelf. De assistent van Sourcegraph richt zich op grote, multi-repo organisaties en wordt aan enterprises op offertebasis verkocht. Dat past beter bij platformteams in grote omgevingen dan bij een team van vijftien.
Voor het dagelijkse werk in de editor dekt een algemene assistent veel terrein, met als kanttekening dat hij alleen de context kent die jij hem geeft.
Het patroon dat we zouden kopiëren: zet de golden path-templates, de eigenaarscatalogus en een doorzoekbare index van de code op dezelfde plek, en laat nieuwe engineers daar vragen stellen voordat ze een collega aanspreken. Ook dat is meetbaar in uren. Beantwoordt je platformteam na de invoering minder dan tien "waar is dit geconfigureerd"-vragen per week, dan werkt het.
Hoe begin je zonder een kathedraal te bouwen?
De meeste platforminitiatieven die mislukken, beginnen met het tool. De betere volgorde is eerst mensen, dan paden, dan tooling.
Interview tien ontwikkelaars. Vraag waar ze tijd verliezen tussen een gemergede PR en een draaiende feature. Je hoort dezelfde drie antwoorden.
Kies één pad en lever het binnen een maand op. Eén template voor "nieuwe service" die van begin tot eind werkt, is beter dan een portaal met veertig lege tegels.
Meet voor en na. Houd bij hoe lang een nieuwe service nodig heeft tot de eerste deploy en hoe lang een nieuwe collega doet tot de eerste gemergede wijziging. Die twee getallen zeggen meer dan elke tevredenheidsenquête.
Publiceer een roadmap en een changelog. Platformwerk is onzichtbaar tenzij je het zichtbaar maakt.
Verwijder dingen. Haal paden en tools weg die niemand gebruikt. Een kleiner platform dat mensen vertrouwen, verslaat een groter platform waar ze omheen werken.
Koop niet meteen een portaal. Een portaal bovenop een rommelige set workflows geeft je een mooiere rommel. In een voorbeeld van Harness telde de catalogus 247 items, waarvan de helft verouderd was. Dat is erger dan geen catalogus.
Wat gaat er mis, en hoe herken je het vroeg?
Drie faalpatronen komen steeds terug.
Het helpdesk-platform. Verzoeken komen binnen via tickets, het team voert ze handmatig uit en noemt dat zelfservice. De toets: kan een ontwikkelaar de gangbare taak afronden zonder met iemand te praten?
Het verplichte platform. Het management zet elk team op het platform voordat het goed is. De adoptiecijfers zien er geweldig uit en het sentiment stort in. Laat het gebruik de eerste zes maanden verdiend worden.
Het alles-platform. Elk verzoek wordt een feature, het oppervlak groeit en de kwaliteit daalt. Zeg nee, schriftelijk, met redenen.
Een nuttige vroege waarschuwing is de verhouding tussen Slack-vragen en gedocumenteerde antwoorden. Als dezelfde vraag drie keer in een maand opduikt en er is geen doc, geen template en geen automatisering voor, dan is dat je volgende backlogitem.
Wat zouden we op maandag concreet doen?
Kies de ene taak die tussen teams de meeste tijd kost en maak die saai. Voor de meeste bedrijven is dat een nieuwe service aanmaken of een testomgeving krijgen. Schrijf het pad, zet het op een plek waar mensen het vinden, tel de uren die het bespaart en beslis daarna pas of je een groter team nodig hebt.
Platform engineering is geen toolchain die je installeert. Het is een besluit om interne ontwikkelaars als klanten te behandelen. Het bewijs dat je die keuze hebt gemaakt, is een kortere afstand tussen de eerste dag van een nieuwe collega en de eerste wijziging die die collega naar productie brengt.