Internal developer platform: bouwen, kopen of samenstellen.

Wat je werkelijk beslist

Een internal developer platform is geen product. Het is een reeks capaciteiten: service-provisionering, omgevingsbeheer, deployment-automatisering, observability-integratie, secrets-beheer, kostenzichtbaarheid. De beslissing bouwen/kopen/samenstellen geldt voor elke capaciteit afzonderlijk. In de praktijk combineert bijna elk platformteam de aanpakken: het CI-systeem kopen, de service-provisioneringslaag bovenop Terraform-modules bouwen, en de developerportal samenstellen uit Backstage met eigen plugins.

De vraag is dus niet 'moeten we het platform bouwen of kopen?' Het is: 'voor welke capaciteiten levert elke aanpak het beste resultaat op onze huidige schaal?' Het antwoord verandert naarmate het team groeit, de OSS-tooling rijpt en commerciële leveranciers hun capaciteiten uitbreiden.

Bouwen: wanneer het klopt en wanneer niet

Zelf platformcapaciteiten bouwen is zinvol wanneer de vereiste werkelijk gedifferentieerd is: wanneer standaard-tooling de behoefte niet kan vervullen tegen redelijke integratiekosten, en wanneer de capaciteit een bron van concurrentievoordeel is voor de engineeringorganisatie.

In de praktijk is dit zelden het geval op de platformlaag. Service-provisionering, deployment-pipelines en developerportals zijn geen concurrentievoordelen. Een eigen Kubernetes-operator bouwen terwijl Crossplane bestaat, of een eigen developerportal terwijl Backstage bestaat, produceert een capaciteit die het engineeringteam voor onbepaalde tijd moet onderhouden zonder externe community-ondersteuning.

Bouwen is de juiste keuze voor capaciteiten die werkelijk specifiek zijn voor jouw domein: aangepaste workflow-automatisering die jouw engineeringproces weerspiegelt, interne productregisterlogica, gespecialiseerde compliance-controles. Niet voor de generieke platformprimitieven die OSS al goed dekt.

Kopen: de commerciële platforms en hun afwegingen

Commerciële IDP-leveranciers bieden snellere time-to-value dan zelf bouwen, een onderhouden UI en kant-en-klare integraties. De afwegingen zijn leveranciersafhankelijkheid, per-seat-prijsstelling die lineair schaalt met hoofdtellingen, en capaciteitslimieten wanneer jouw vereisten afwijken van de roadmap van de leverancier.

Kopen is zinvol voor teams die een werkende developerportal in weken nodig hebben in plaats van maanden, die geen platform-engineering-capaciteit hebben om OSS-tooling te onderhouden, en die binnen het capaciteitsmodel van de leverancier kunnen leven voor de voorzienbare roadmap. Het waarschuwingssignaal is wanneer het team vaker aangepaste integraties bij de leverancier aanvraagt dan de leverancier ze levert. Dat is het plafond.

Voor EU-bedrijven: verifieer dataresidentie voordat je een leverancier selecteert. De meeste enterprise-tier-overeenkomsten omvatten EU-regio-deploymentopties voor het control plane. Verifieer dit voor het ondertekenen van het contract, niet erna.

"De meeste teams die zeggen dat ze hun platform bouwen, stellen het feitelijk samen. Het onderscheid telt omdat de onderhoudskosten heel anders zijn."

Maikel Vlasman / Cloud Architect

Samenstellen: het pad dat de meeste teams bewandelen

De meeste teams die zeggen dat ze hun platform bouwen, stellen het feitelijk samen: Backstage als developerportal, Crossplane of Terraform-modules als provisioneringslaag, Argo CD of Flux voor deployment-automatisering, de bestaande observability-stack voor kosten- en gezondheidszichtbaarheid. Het resultaat is een capable platform waarvoor geen greenfield-ontwikkeling nodig was voor een afzonderlijke capaciteit.

Samenstellen heeft een hogere integratiebelasting dan kopen en een lager onderhoudsplafond dan volledig zelf bouwen. Elk OSS-component heeft zijn eigen upgradecyclus, breaking changes en kwaliteit van community-ondersteuning. Het platformteam integreert in plaats van bouwt, maar integratie is nog steeds engineeringwerk.

Het besliscriterium: als je team 2 tot 4 platform-engineers heeft en developers vragen om een geplaveide weg in plaats van een feature-rijke portal, is samenstellen het juiste startpunt. De OSS-componenten zijn productiekwaliteit en breed geadopteerd. Het integratiewerk is reëel maar begrensd. Het capaciteitsplafond is hoog genoeg voor de meeste mid-market-organisaties gedurende meerdere groeijaren.