Platform Engineering: waarom je infrastructuur geen bijzaak is

Elk groeiend techbedrijf komt op een punt waar de infrastructuur begint te kraken. Deployments duren te lang. Niemand weet precies wat er in productie draait. Er is één persoon die 'het cluster snapt' — en die heeft volgende maand vakantie. Platform Engineering is het vakgebied dat dit oplost. Niet door meer tools te stapelen, maar door een fundament te bouwen waarop teams autonoom en veilig kunnen deployen.

Het probleem dat niemand hardop zegt

De meeste infrastructuur is organisch gegroeid. Een server hier, een container daar, een Jenkins-pipeline die ooit 'tijdelijk' was. Het werkt — tot het niet meer werkt. En dan blijkt dat niemand weet hoe het in elkaar zit, dat er geen documentatie is, en dat de enige die het snapt net op vakantie is.

Dit is geen edge case. Dit is de norm bij bedrijven die snel zijn gegroeid zonder dedicated platform-team. De symptomen zijn herkenbaar: deployments die uren duren, angst om iets aan te raken, en developers die wachten op 'iemand van ops' om hun code live te krijgen.

Wat Platform Engineering eigenlijk is

Platform Engineering is niet 'DevOps met een nieuwe naam'. Het is een discipline gericht op het bouwen van een intern platform waarop development teams zelfstandig kunnen werken. Dat platform omvat alles van Kubernetes-clusters tot CI/CD-pipelines, van observability-stacks tot self-service portals.

Het doel: developers autonoom maken zonder dat je controle verliest. Geen bottleneck bij één DevOps-engineer. Geen handmatige stappen bij elke deployment. Geen 'het werkt op mijn machine' meer.

De bouwblokken

• Kubernetes als orkestratielaag — niet omdat het hip is, maar omdat het de standaard is geworden voor schaalbare, reproduceerbare workloads
• GitOps voor deployments — elke wijziging in Git, elke deployment auditeerbaar, rollbacks triviaal
• Infrastructure as Code — geen handmatige configuratie, alles in Terraform of Pulumi, reviewbaar en herhaalbaar
• Observability — metrics, logs en traces zodat je weet wat er gebeurt voordat gebruikers klagen
• Self-service — developers kunnen zelf omgevingen spinnen, secrets beheren en deployments triggeren binnen veilige guardrails

Wanneer je het nodig hebt

Niet elk bedrijf heeft een volledig platform-team nodig. Maar er zijn duidelijke signalen dat je infrastructuur aandacht verdient:

• Deployments duren langer dan een koffiepauze
• Je hebt één persoon die 'de infra doet' en niemand anders snapt het
• Developers wachten op ops voor elke omgeving of configuratiewijziging
• Je weet niet precies wat er in productie draait
• Rollbacks zijn eng of onmogelijk
• Je hebt compliance-eisen (ISO 27001, NEN 7510) en geen idee hoe je dat bewijst

Wat ik heb gebouwd

Bij Alliander verving ik trage Jenkins-pipelines door ArgoCD en GitHub Actions — deployments gingen van onvoorspelbaar naar reproduceerbaar. Lokale dev-omgevingen migreerden van Docker Compose naar K3d, identiek aan de AWS DTAP-setup. Het team kon eindelijk lokaal testen met vertrouwen dat het in productie hetzelfde zou doen.

Bij NIPV bouwde ik een Internal Developer Platform met GitLab CI waarmee developers autonoom van test naar productie konden promoten. De afhankelijkheid van het DevOps-team verdween — niet door mensen te vervangen, maar door ze te ontzorgen.

Bij de Volksbank en ASN Bank zette ik een enterprise observability-platform op: Prometheus, Grafana Enterprise, Loki, Thanos, Jaeger. Van scratch tot volledige zichtbaarheid in de stack, inclusief geautomatiseerde dashboard-migratie.

Nu bij TenneT werk ik aan beheer en migratie van mission-critical applicaties naar Kubernetes voor het Nederlandse hoogspanningsnet. Infrastructuur waar je niet mee experimenteert.

De investering vs. de kost van niets doen

Platform Engineering kost tijd en geld. Maar de vraag is niet 'kunnen we het betalen?' — de vraag is 'wat kost het als we het niet doen?'

Elke uur dat developers wachten op deployments is productiviteitsverlies. Elke outage door een config-fout is omzetverlies. Elke audit die je niet haalt omdat je niet kunt aantonen wat er draait is een risico. Het platform betaalt zichzelf terug, maar alleen als je het goed neerzet.

Hoe ik werk

Ik bouw geen platforms om vervolgens te verdwijnen. Kennisoverdracht is onderdeel van elke opdracht. Documentatie, pair-programming met je team, runbooks — zodat je na afloop niet afhankelijk bent van mij, maar van een platform dat je team zelf kan beheren.

Beschikbaar voor opdrachten via detachering of project. Van greenfield Kubernetes-platform tot migratie van legacy infrastructure. Van observability-setup tot GitOps-implementatie.

Interesse? Neem contact op voor een vrijblijvend gesprek over je platform-uitdagingen: [email protected] of via webforged.nl/platform.