Je hebt waarschijnlijk al een platformfunctie
Platformwerk is veel breder dan Kubernetes beheren. Het omvat cloudaccounts en subscriptions, networking, identity en toegang, Infrastructure as Code, pipelines, deployments, secrets, DNS en certificaten, databases en storage, observability, backups, omgevingen, incidenten en upgrades. Zodra developers dit structureel uitvoeren, vervullen zij samen een platformfunctie — ook als die nergens zo heet.
Het verschil met een bewuste platformfunctie zit meestal in de organisatie eromheen. Er is geen duidelijke eigenaar of gereserveerde tijd, standaarden verschillen per applicatie en kennis zit in hoofden. Operationele taken concurreren rechtstreeks met productontwikkeling; verbeteringen blijven liggen tot een incident ze urgent maakt.
Het developmentteam is dan ongemerkt zelf het platformteam geworden, alleen zonder de tijd, focus en verantwoordelijkheid die daarbij horen. Dat kan tijdelijk werken, maar wordt kwetsbaar zodra het product en het aantal omgevingen doorgroeien.
Zodra developers platformwerk structureel ‘erbij’ doen, bestaat de platformfunctie al. Alleen zonder focus, eigenaarschap en tijd.
Zeven signalen dat het geen bijzaak meer is
Niet ieder los incident is een platformprobleem. De combinatie en herhaling van deze signalen laten zien dat informeel beheer structureel werk is geworden.
1. Slechts één of twee mensen begrijpen de volledige omgeving
Zij kennen de afwijkende DNS-records, handmatige herstelstappen en bijzondere pipelinevolgorde. Hun afwezigheid wordt een operationeel risico en vrijwel iedere infrastructuurvraag komt bij hen terecht.
2. Nieuwe omgevingen worden gekopieerd en handmatig aangepast
Elke kopie krijgt eigen verschillen in netwerkregels, secrets, sizing en monitoring. Na enkele rondes is niet meer duidelijk welke omgeving de bedoelde standaard vertegenwoordigt.
3. Terraform dekt maar een deel van de infrastructuur
Resources buiten code, verschillende state-afspraken en afwijkende modules maken routinewijzigingen onnodig spannend. Infrastructure as Code is aanwezig, maar levert nog geen reproduceerbare basis.
4. Applicaties gebruiken verschillende deploymentroutes
De ene service gaat via een pipeline, de andere via een script en een derde vraagt om handmatige stappen. Releasen wordt daardoor kennis van uitzonderingen in plaats van een voorspelbaar proces.
5. Productietoegang is permanent of breder dan nodig
Het is niet snel te reconstrueren wie toegang heeft, waarom die nodig is en wat ermee is gedaan. Dat bemoeilijkt audits, incidentwerk en normaal dagelijks beheer.
6. Developers verliezen tijd aan terugkerende infrastructuurproblemen
Certificaten, falende pipelinestappen en afwijkende testomgevingen blijven terugkomen. Los lijken het kleine storingen; samen veroorzaken ze structurele onderbrekingen en contextwissels.
7. Groei, securityvragen of incidenten leggen de kwetsbaarheid bloot
Eisen rond herstel, logging, toegang of omgevingsscheiding blijken niet met één instelling op te lossen. Het externe moment veroorzaakt het probleem niet, maar maakt zichtbaar wat al langer informeel was.
Waarom “we zijn nog te klein” gedeeltelijk klopt
Niet ieder softwarebedrijf heeft meerdere fulltime platform engineers nodig. Een overzichtelijke applicatie met weinig deployments en één eenvoudige cloudomgeving kan prima zonder apart platformteam. Kubernetes, een intern developer platform, tientallen golden paths of complexe enterprisegovernance zouden daar vooral extra beheer introduceren.
Platform engineering serieus nemen betekent niet automatisch een team aannemen of een zwaar platform bouwen. Het betekent bewust kiezen wat wordt gestandaardiseerd, wie eigenaar is, wat geautomatiseerd moet zijn en hoe security, herstelbaarheid en beheer zijn geregeld. Soms zijn goed beheerde Terraform en één betrouwbare pipeline precies genoeg.
De relevante vraag is hoeveel platformverantwoordelijkheid de organisatie al draagt. Meerdere omgevingen, klantspecifieke eisen of strengere toegang kunnen ook in een compact developmentteam structureel platformwerk veroorzaken.
- Geen Kubernetes zonder passende workload en beheercapaciteit
- Geen self-service bouwen voor handelingen die zelden voorkomen
- Wel ownership, reproduceerbaarheid en herstel expliciet organiseren
Wat een externe platform engineer kan toevoegen
Een externe platform engineer is niet alleen extra uitvoeringscapaciteit. De waarde zit vaak in tijdelijk focus en eigenaarschap aanbrengen: de bestaande infrastructuur inventariseren, afhankelijkheden en risico’s zichtbaar maken en een passende doelrichting bepalen. Zo voorkom je dat alles uit frustratie wordt vervangen terwijl een gerichte verbetering voldoende is.
Vervolgens kan het werk concreet worden: bestaande Terraform verbeteren, delivery standaardiseren, toegang en secrets veiliger regelen, observability versterken en provisioning automatiseren. Documentatie, runbooks en duidelijke afspraken maken de gekozen werkwijze overdraagbaar.
Het doel is niet om kennis permanent buiten de organisatie te houden of onbeperkt capaciteit toe te voegen. Het developmentteam wordt meegenomen, ownership wordt bewust belegd en na afloop is duidelijk wat het team zelf beheert en waar structurele support passend is.
Een gerichte inventarisatie helpt daarbij eerst prioriteiten te scheiden: wat vraagt directe aandacht, wat kan bewust blijven staan en welke doelrichting past bij product, team en beheerlast.
Vier herkenbare startsituaties
De technische oplossing verschilt, maar in iedere situatie remt infrastructuur het team, is zij onvoldoende reproduceerbaar of hangt te veel kennis bij enkele personen. De startsituatie bepaalt welke verbetering logisch is en welke complexiteit juist kan wachten.
Organisch gegroeide AWS- of Azure-infrastructuur
Losse resources, gedeeltelijke Terraform en afwijkende keuzes per project maken veranderingen steeds lastiger te overzien.
Een nieuw product zonder platformbasis
Er is een solide basis nodig voor delivery, toegang en beheer, zonder al te ontwerpen voor schaal of complexiteit die nog niet bestaat.
Een VM-gebaseerd landschap
Applicaties en omgevingen vragen steeds meer handmatig beheer. Betere automation of gefaseerde containerisatie kan passend zijn.
Containers zonder volwassen platform
Applicaties draaien via Docker Compose, eigen scripts of op één server, terwijl deployment, herstel en operations nog onvoldoende zijn georganiseerd.
Platform engineering is niet hetzelfde als Kubernetes
Een goede platform engineer begint niet met de vraag waar het cluster moet komen, maar met wat developers dagelijks afremt, welke workloads en beschikbaarheidseisen er zijn en wat het team zelf kan beheren. De techniek volgt uit die context.
Kubernetes kan passend zijn, maar betere Terraform, CI/CD, identity, secrets of observability leveren soms sneller waarde. Ook VM’s, Docker Compose of een managed containerdienst kunnen een bewuste uitkomst zijn. De kwaliteit zit in de verhouding tussen probleem, oplossing en beheercapaciteit.
Dat betekent ook dat niet alles vervangen hoeft te worden. Bestaande onderdelen die betrouwbaar en uitlegbaar zijn kunnen blijven, terwijl juist de terugkerende uitzonderingen en handmatige stappen worden aangepakt.
- Wat remt developers nu werkelijk af?
- Wat kan veilig blijven en wat veroorzaakt structureel risico?
- Welke oplossing kan het team na oplevering zelf beheren?
Je hoeft nog geen platformteam te hebben om platform engineering serieus te nemen.
Het omslagpunt
Een praktische vuistregel: wanneer meerdere developers iedere week tijd verliezen aan dezelfde infrastructuur-, deployment- of omgevingsproblemen, is platform engineering waarschijnlijk geen luxe meer. Herhaling laat zien dat de werkwijze niet meer schaalt.
Het wordt structureel wanneer verbeteringen steeds worden uitgesteld, kennisconcentratie risico veroorzaakt en productontwikkeling vertraagt. Ook onboarding, securityvragen en nieuwe projecten gaan dan steeds langs dezelfde mensen en uitzonderingen.
De passende stap kan nog steeds klein zijn: een eerste gesprek, gerichte Platform Discovery of tijdelijk eigenaarschap is iets anders dan direct een nieuw team optuigen.
Wat het oplevert
Je hoeft geen volledig platformteam aan te nemen om platform engineering serieus te nemen. Bewust eigenaarschap maakt omgevingen reproduceerbaarder, deployments voorspelbaarder en beheer minder afhankelijk van enkele personen.
De vraag is meestal niet meer óf je een platform hebt. De vraag is of het bewust is ontworpen en beheerd, of vooral bestaat uit alle keuzes die onderweg zijn blijven liggen.