Wat is platform engineering en hoe bouw je een team

Wat is platform engineering

Het is 22:10 en een nieuw teamlid probeert al twee dagen een staging-omgeving aan de praat te krijgen. Ze heeft drie tickets ingediend, dezelfde Terraform-foutmelding twee keer in Slack geplakt en weet nog steeds niet welke van de vier CI-templates de echte is. Dat tafereel is het hele antwoord op "wat is platform engineering": het is het werk om de interne weg aan te leggen zodat niemand alleen door dat oerwoud hoeft te hackken, en die weg als product met gebruikers behandelen.

In de praktijk bouwt een platform team een internal developer platform (IDP): self-service tooling waarmee andere developers services kunnen maken, deployen en zien wat er draait zonder op een mens te wachten. Dit breekt in de praktijk als je het overslaat: elk team vindt opnieuw een manier om te deployen, en die kennis zit in drie mensen hun hoofd.

Wat platform engineering eigenlijk is, zonder de buzzwords

De schoonste definitie die ik ken komt van de platformengineering.org community: het ontwerpen en bouwen van platforms die teams self-service mogelijkheden geven voor het repetitieve werk. Strip de woordenschat eraf en je hebt drie bewegende delen.

Ten eerste: een internal developer platform. Dit is niet één product dat je koopt. Het is een dunne laag templates, pipelines, APIs en documentatie die bovenop je bestaande gereedschap zit (cloud account, Kubernetes, CI, secrets, monitoring) en de scherpe randen verbergt.

Ten tweede: een platform team. Een klein groepje engineers wiens klanten andere engineers zijn. Hun output is geen features voor end users. Hun output is hoe snel iedereen anders iets kan shippen.

Ten derde: een product mindset. Het platform heeft gebruikers, een backlog, adoption metrics en een on-call rotation. Als niemand het gebruikt, is het mislukt, hoe elegant de architectuur ook is.

Gartner voorspelde dat 80% van grote software engineering organisaties tegen 2026 platform teams zou hebben, omhoog van 45% in 2022. Zie dit als markeringsignaal, niet als belofte. De branche zegt ook dat veel van die teams moeite hebben impact aan te tonen, en dat is precies waarom de rest van dit artikel in detail ingaat op wat misgaat.

Hoe is het anders dan DevOps en SRE?

Korte versie: DevOps is een cultuur, SRE is een reliability discipline, platform engineering is een teamstructuur die beide productisiert.

DevOps zei dat developers en operations gezamenlijk software moeten runnen. Goed idee. Bij 15 mensen ziet iedereen alles. Bij 300 mensen wordt het stiekem "elk team moet ook een Kubernetes expert worden", wat niemand heeft afgesproken.

SRE focust op reliability targets: error budgets, incident response, capaciteit. Een platform team voelt ook aan voor reliability, maar de belangrijkste metric is anders. Het meet hoe lang een dev wacht van "ik heb een idee voor een service" naar "het draait in productie met logs en alerts".

Platform engineering is het antwoord op de cognitive load die DevOps heeft achtergelaten. In plaats van elk dev de hele toolchain te laten leren, geef je hen een ondersteund default en hou je de expert kennis binnen het platform. Drie redenen om het te doen, één reden om niet: het loont pas als het aantal teams of services groot genoeg is dat duplicatie pijn doet. Hieronder verder op die drempel.

Wat shipped een platform team eigenlijk?

Vergeet de architectuurdiagrammen. Dit ziet de backlog van een werkend platform team uit op een normale dinsdag.

Een service template. Eén commando, of één knop in een portal, maakt een repository aan met een werkende pipeline, een Dockerfile, health checks, logging setup en een basis dashboard. De dev verandert de bedrijfslogica, niet de leidingen.

Een deployment path. Push naar main, tests draaien, het artefact wordt gebouwd en gepromoveerd door omgevingen met dezelfde stappen telkens. Geen per-team snowflakes.

Environment on demand. Een preview omgeving per pull request, automatisch afgebroken. Dit is de feature waarvoor developers je eigenlijk bedanken.

Secrets en access. Short-lived credentials, één plaats om ze aan te vragen, audit trail. Saai, en het ding dat je redt bij een security review.

Observability by default. Elk service gemaakt uit de template shipping metrics, logs en traces zonder dat iemand eraan hoeft te solderen. Een stack als Grafana zit meestal achter deze laag, en de free tier en open-source optie passen bij een klein team.

Merk op wat ontbreekt uit die lijst: een zelf gebouwd portal met een drie-maanden roadmap. De portal is het laatste wat je toevoegt, niet het eerste.

Golden paths: het idee dat de rest mogelijk maakt

Een golden path is de ondersteunde, doordachte manier om een common task te doen. Het is sneller dan handmatig en veiliger dan improviseren, en cruciaal: het is optioneel. Developers kunnen van het pad af gaan als ze een echte reden hebben. Ze nemen dan wel de verantwoordelijkheid mee.

Er is een nuttig onderscheid in de Octopus write-up over paved versus golden paths: een paved road is het brede, goed onderhouden oppervlak, een golden path is de specifieke aanbevolen route voor een gegeven taak. In mijn ervaring maakt het verschil minder uit dan het principe eronder. Je wint door de juiste manier de makkelijke manier te maken, niet door andere manieren te verbannen.

Dit ziet de kleinste mogelijke golden path eruit. Het is één scaffold commando dat een dev eenmalig draait:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Achter die ene lijn zitten een repo, pipeline, DNS, een database stub, alerts en een ownership record. Het commando is triviaal. Het lastige is zes maanden consensus over wat "node-api" betekent, en het actueel houden als Node, je base image of je cloud provider verandert.

Getest. Niet optimaal. En hier is waarom we het toch doen: een middelmatige golden path die 80% van de teams gebruikt beat een perfecte die 10% adopteert, omdat de eerste je leverage geeft om alles tegelijk te verbeteren.

Wanneer is het het waard, en wanneer is het afleidend?

Dit is het gedeelte dat de meeste posts overslaan. Platform engineering is niet gratis, en voor veel teams is het de verkeerde zet.

De platformengineering.org overview suggereert dat organisaties typisch baat hebben wanneer ze ergens 20 tot 30 platform users passeren. Ik lees dat als grove ondergrens, niet als regel. Eronder volstaat een gedeelde README, goed CI template en één persoon die erom geeft meer dan een formeel platform team.

Waard wanneer je:

• Meer dan een handvol teams hebt, elk met een eigen deploy pipeline.

• Nieuwe devs weken nodig hebben, niet dagen, om hun eerste wijziging te shippen.

• Dezelfde incident type repeats omdat elk service zijn eigen alerts heeft bedraden.

• Security of compliance vraagt om consistentie die je niet door vragen kan afleggen.

Skip wanneer je:

• Één team van vijf bent. Schrijf een script, niet een platform.

• Nog niet weet hoe je services eruit zien. Te vroeg standaardiseren bevriest de verkeerde keuzes.

• Het voorstel luidt "bouw een portal" zonder lijst van pijnpunten die het wegneemt.

Voor solo builders en kleine side-project crews is de eerlijke conclusie eenvoudiger. Je hebt geen platform team nodig, maar je hebt de gewoontes nodig: één herhaalbaar deploy script, één template voor nieuwe projecten, één dashboard dat je checkt. Dat is een platform van één, en het bespaart je een weekend per maand.

De gereedschappen die teams werkelijk combineren

Er is geen enkel "platform engineering product". Teams assembleren een stack, en de stukken vallen in enkele categorieën.

Voor de portal en catalog gebruiken veel teams Backstage of een hosted alternatief, wat een doorzoekbare lijst van services, owners en docs geeft. Voor provisioning: Terraform of OpenTofu plus een GitOps tool als Argo CD of Flux. Voor CI en delivery: wat je al hebt, verpakt in shared templates.

Twee buckets verdienen nader onderzoek, omdat ze bepalen of het platform vertrouwen voelt.

Observability. Als developers niet kunnen zien wat hun service doet, vertrouwen ze het platform niet dat het heeft gedeployed. Datadog geeft je een gepolijste single pane over infra, APM en logs, tegen een per-host prijs die snel oploopt. Grafana's open-source stack kost je bedrijfsvoering in plaats van licentiekosten. Kies op basis van wat je schaarse resource is: geld of aandacht.

Docs en quality. Een platform zonder goede docs is een ticket queue in vermomming. Docs-as-code tools houden gidsen naast de repo die ze beschrijven, en code-quality gates in CI houden de templates eerlijk.

Geen hiervan is nodig. Het zijn voorbeelden van de laag waar een platform team zijn tijd doorgebracht: een default kiezen, het in de template draden, en het upgrade path eigenaar zijn.

Hoe beginnen zonder het verkeerde te bouwen

De meeste mislukte platform efforts delen hetzelfde patroon. Ze starten te groot, bouwen maanden voor één team eraan raakt, en optimaliseren voor de roadmap slide in plaats van adoption. De fix is onglorieus.

Kies één pijnlijk, frequent taak. "Maak een nieuwe service" en "krijg een preview omgeving" zijn meestal winnaars. Interview drie developers en kijk ze doen. Tel de stappen en minuten.

Bouw de dunste versie die de meeste pijn weghaalt. Een template repo en gedeeld pipeline file tellen. Geef het aan één vriendelijk team en ga ernaast zitten terwijl zij het gebruiken. Fix wat breekt, bied het dan aan een tweede team aan.

Volg twee nummers: hoe lang van "nieuwe service" naar "draait in productie", en hoeveel teams het path voluntair gebruiken. Als het tweede getal vlak is, is het platform een mandate, en mandates rotten.

Staff het als product team. Platform engineers zijn geen DevOps met een nieuwe titel. Het platformengineering.org materiaal noteert dat platform engineers ongeveer 27% meer verdienen dan DevOps professionals, wat je vertelt dat de markt het product-en-engineering mix ziet als unieke, moeilijker job.

Nog een reden dit nu te doen: de nieuwste wending is dat de "user" van een platform niet meer alleen een mens is. Coding agents openen pull requests, draaien tests en vragen om omgevingen. Een platform met schone templates, duidelijke permissions en machine-readable docs is veel veiliger voor een agent dan een hoop snowflake repos.

Short-lived credentials, preview omgevingen en een consistent pipeline zijn wat de fouten van een agent beperkt tot een wegwerp branch. Als je platform geen human deploy van een automated onderscheid kan maken, voeg dat toe voor je iets anders toevoegt.

Wat bouw je volgende?

Als je een team van 30 devs leidt en elk squad heeft zijn eigen pipeline, een klein platform team met één golden path is waarschijnlijk je meest impactvolle hire. Ben je een solo dev met drie side projects, kopieer je beste project zijn pipeline in een template repo dit weekend en je bent klaar.

Hoe dan ook, de vraag het waard naar je volgende planning session mee te nemen is concreet: welke enkele taak doen je developers het meest herhalen, en wat zou het nemen die een eenregels commando te maken?