Interne ontwikkelplatforms bouwen op Azure: de basis leggen

By Mirko Peters · 2026-08-13

Welkom terug bij de podcast-companion-blog! In de deep dive van vandaag bouwen we verder op een onderwerp dat de afgelopen tijd in de techwereld over de hele linie architectuurdiscussies domineert: Internal Developer Platforms, of kortweg IDP's. Als je onze laatste aflevering hebt beluisterd, weet je dat we het hebben gehad over hoe cognitieve belasting stilletjes de snelheid van ontwikkelaars ond

Automatically translated with AI from the original post. Read the English original

Welkom terug bij de podcast-companion-blog! In de deep dive van vandaag bouwen we verder op een onderwerp dat de afgelopen tijd in de techwereld over de hele linie architectuurdiscussies domineert: Internal Developer Platforms, of kortweg IDP's. Als je onze laatste aflevering hebt beluisterd, weet je dat we het hebben gehad over hoe cognitieve belasting stilletjes de snelheid van ontwikkelaars ondermijnt. Vandaag gaan we een stap verder. We kijken hoe je een robuust, schaalbaar en veilig IDP native op Microsoft Azure kunt bouwen, met gebruik van moderne cloudparadigma's, containerstrategieën en infrastructure-as-code-principes.

De moderne engineeringorganisatie staat voor een paradox. We geven ontwikkelaars via de cloud ongekende mogelijkheden, maar tegelijkertijd overladen we ze met operationele complexiteit. Ze besteden meer tijd aan het worstelen met netwerktopologieën, configuraties voor identity- en toegangsbeheer en deploymentpipelines dan aan het schrijven van bedrijfslogica. Een Internal Developer Platform lost dit op door als een samengestelde abstractielaag te fungeren. Het beperkt ontwikkelaars niet; het versterkt hen juist door golden paths aan te bieden die snel en veilig naar productie leiden. Laten we eens kijken hoe je deze basis op Azure architectureert.

Inleiding tot Internal Developer Platforms op Azure

Voordat we ons in de technische details van Azure-diensten verdiepen, eerst even wat een IDP eigenlijk is en waarom Azure zich bijzonder goed leent om er een te hosten. Een IDP is geen softwarepakket dat je kant-en-klaar aanschaft. Het is een geproductiseerde verzameling interne tools, services en infrastructuurworkflows die samen een coherent developerportaal vormen. Het zit tussen je ontwikkelaars en de onderliggende cloudinfrastructuur in en vertaalt high-level intenties van ontwikkelaars naar veilige, compliante en productieklare cloudresources.

Azure biedt een uitgebreid ecosysteem aan enterprisewaardige bouwblokken. Deze ruwe bouwblokken rechtstreeks aan ontwikkelaars blootstellen leidt echter vaak tot configuratiedrift, beveiligingslekken en verweesde resources. Door een IDP op Azure te architecteren, kunnen platformengineers deze native diensten inpakken in eigenzinnige, gestandaardiseerde templates. Dat betekent dat een ontwikkelaar een volledig geconfigureerde microservice-omgeving met een gekoppelde database en cachinglaag kan aanvragen, zonder dat hij of zij een masterdiploma in Azure-netwerken of Role-Based Access Control nodig heeft.

Kernpijlers van een modern IDP

Wanneer je je platform gaat ontwerpen, moet je je beslissingen verankeren in vier kernpijlers: self-service, golden paths, abstractie en guardrails. Zonder deze pijlers dreigt je IDP gewoon een nieuw ticketsysteem of een ongedocumenteerde wikipagina te worden.

Self-service zonder operationele overhead

Self-service is het kloppende hart van elk IDP. In een traditionele opzet dient een ontwikkelaar, wanneer hij of zij een nieuwe stagingomgeving of een Cosmos DB-instantie nodig heeft, eerst een Jira-ticket in, wacht het op de beoordeling door het platformteam, wacht vervolgens op de provisioning door operations en hoopt ten slotte dat de configuratie overeenkomt met productie. Een IDP op Azure automatiseert deze hele levenscyclus. Via een centraal portaal kunnen ontwikkelaars self-serviceworkflows starten die resources binnen enkele minuten inrichten, waardoor de doorlooptijd voor wijzigingen drastisch korter wordt.

Golden paths en abstractielagen

Golden paths zijn eigenzinnige, ondersteunde manieren om binnen je organisatie dingen voor elkaar te krijgen. Ze nemen de flexibiliteit niet weg; ze nemen de wrijving weg. Door de onderliggende Azure-complexiteit te abstraheren achter eenvoudige configuratiebestanden, zoals één applicatiemanifest, kunnen ontwikkelaars aangeven wat ze willen deployen, terwijl het IDP bepaalt hoe dat op Azure wordt uitgerold.

Azure-diensten gebruiken voor native infrastructuur

Een IDP op Azure bouwen betekent dat je de juiste fundamentele diensten kiest voor compute, opslag, netwerken en identity. Laten we eens kijken hoe je platformvereisten kunt koppelen aan native Azure-diensten.

Identity- en toegangsbeheer met Microsoft Entra ID

Beveiliging begint bij identiteit. Microsoft Entra ID (voorheen Azure Active Directory) vormt de beveiligingsruggengraat van je IDP. Door je platformportaal te integreren met Entra ID kun je Single Sign-On (SSO) afdwingen en ontwikkelaarsgroepen koppelen aan specifieke platformfunctionaliteiten. Met Azure Managed Identities kunnen je gedeployde applicaties veilig toegang krijgen tot andere Azure-resources, zoals Azure Key Vault of Azure SQL, zonder dat je credentials hardcoded in configuratiebestanden of repositories zet.

Abstracties voor data en opslag

Applicaties hebben data nodig, maar platformteams hoeven niet telkens handmatig databases op te zetten zodra een team een nieuw project start. Je kunt Azure Service Operator for Kubernetes of Azure Resource Manager (ARM)-templates, verpakt in self-servicewerkstromen, gebruiken om beheerde services zoals Azure Database for PostgreSQL, Azure Cosmos DB of Azure Cache for Redis on demand te provisioneren. Het IDP zorgt ervoor dat deze databases worden aangemaakt met versleuteling in rust, goed ingestelde firewallregels en standaard ingeschakelde geautomatiseerde back-ups.

Strategieën voor containerisatie en orkestratie

Containers zijn de lingua franca van moderne cloud-native applicaties. Het standaardiseren van hoe applicaties worden verpakt en uitgevoerd is essentieel voor een succesvol IDP.

Azure Kubernetes Service als rekenengine

Voor de meeste moderne ondernemingen fungeert Azure Kubernetes Service (AKS) als de primaire rekenengine van het IDP. AKS biedt de schaalbaarheid, portabiliteit en orkestratiemogelijkheden die nodig zijn om microservices op schaal te draaien. Ontwikkelaars hoeven echter geen ruwe Kubernetes YAML-manifesten te schrijven. Je IDP moet de complexiteit van Ingress-controllers, netwerkbeleid en persistent volume claims verbergen achter abstracties op hoger niveau voor workloads.

Containerregisters en beveiliging van de supply chain

Azure Container Registry (ACR) integreert naadloos met AKS en vormt een cruciaal onderdeel van je containerstrategie. Je IDP moet de pipeline van code-commit tot het bouwen van containerimages automatiseren, en gebruikmaken van tools zoals Microsoft Defender for Containers om images op kwetsbaarheden te scannen voordat ze ooit een cluster bereiken. Door ACR in je platformwerkstromen in te bedden, zorg je ervoor dat alleen vertrouwde, gescande images naar productieomgevingen kunnen worden uitgerold.

Infrastructure-as-Code-principes voor platform engineering

Infrastructure-as-Code (IaC) is onverhandelbaar bij het bouwen van een IDP. Elk onderdeel van de infrastructuur die door je platform wordt beheerd, moet worden gedefinieerd, versiebeheerd en via geautomatiseerde pipelines worden uitgerold.

Je IaC-tooling kiezen in het Azure-ecosysteem

Azure ondersteunt een breed scala aan IaC-tools. Bicep is de domeinspecifieke taal van Microsoft voor het declaratief uitrollen van Azure-resources, met een schonere syntaxis dan traditionele ARM-templates en native ondersteuning voor Azure-functies. Als alternatief is Terraform (of OpenTofu) wijd verspreid in multi-cloud- en enterpriseomgevingen. Welke tool je ook kiest, je IDP moet deze scripts voor de ontwikkelaar abstraheren en ze op de achtergrond uitvoeren zodra een provisioningaanvraag is goedgekeurd.

Statusbeheer en modulair ontwerp

Om je platform onderhoudbaar te houden, bouw je een bibliotheek met herbruikbare infrastructuurmodules. Maak bijvoorbeeld een standaard "web-api-module" die een App Service- of AKS-deployment bundelt met een bijbehorende database en monitoringinstantie. Bewaar je IaC-status veilig in Azure Storage-accounts met blob-versiebeheer ingeschakeld, zodat je platform engineeringteam een betrouwbaar auditspoor behoudt van alle infrastructuurwijzigingen over alle abonnementen heen.

Beveiligingsguardrails en compliance inbedden

Een veelgehoorde zorg bij het management wanneer organisaties self-serviceplatformen adopteren, is het verlies van controle over beveiliging en compliance. Een effectief IDP keert dit verhaal om door security naar links te verschuiven en guardrails direct in de platformwerkstromen in te bouwen.

Azure Policy als geautomatiseerde handhaver

Azure Policy is je beste vriend bij het ontwerpen van platformguardrails. In plaats van resources handmatig te controleren, kun je Azure Policy gebruiken om organisatienormen automatisch af te dwingen, zoals het beperken van resourcecreatie tot specifieke Azure-regio's, het vereisen van versleuteling op alle opslagaccounts of het verplichten van specifieke netwerktags. Als een ontwikkelaar probeert een resource te provisioneren die tegen deze beleidsregels ingaat, vangt het IDP dit op in de validatiefase en geeft het direct feedback.

Secretbeheer en integratie met Key Vault

Hardcoded secrets blijven een terugkerend beveiligingsprobleem. Je IDP moet veilig geheimenbeheer standaard afdwingen. Integreer Azure Key Vault in je deployment-workflows, zodat applicatiegeheimen, API-sleutels en verbindingsreeksen veilig tijdens runtime worden ingevoegd en volledig buiten het zicht van ontwikkelaars en source control-repositories blijven.

Het zelfbedieningsportaal voor ontwikkelaars bouwen

Al deze fundamentele onderdelen, identiteit, compute, IaC en beveiliging, moeten samenkomen in één centraal overzicht: het ontwikkelaarsportaal. Dit is de gebruikersinterface van je IDP.

Backstage gebruiken voor Azure-georiënteerde portalen

Open-sourceframeworks zoals Spotify’s Backstage zijn de facto de standaard geworden voor het bouwen van ontwikkelaarsportalen. Met Backstage maak je een softwarecatalogus, beheer je sjablonen (bekend als software templates) en integreer je plug-ins. Je kunt eigen Backstage-plug-ins bouwen die rechtstreeks met Azure-API’s communiceren, zodat ontwikkelaars Azure-resources kunnen aanmaken, de servicestatus kunnen bekijken en deploymentpipelines kunnen volgen, allemaal vanuit één dashboard.

Een intuïtieve ontwikkelervaring ontwerpen

Behandel je ontwikkelaars bij het ontwerpen van je portaal als klanten. De gebruikerservaring moet soepel verlopen. Een ontwikkelaar moet naar het portaal kunnen navigeren, een sjabloon "Microservice met SQL-backend" kunnen selecteren, een eenvoudig formulier invullen met de naam van de service en het eigenaarsteam, en op verzenden klikken. Binnen enkele minuten moet het IDP de Azure-infrastructuur inrichten, de GitHub-repository met standaardcode genereren, de CI/CD-pipeline configureren en de service registreren in de interne catalogus.

Succes meten en volgende stappen

Een IDP bouwen is geen project met een vaste einddatum, maar een doorlopende productreis. Zodra je platform live is, moet je de impact meten om de investering te rechtvaardigen en de ontwikkelervaring voortdurend verbeteren.

Belangrijkste metrics om te volgen

Richt je op metrics die de snelheid van ontwikkelaars en de stabiliteit van het platform weerspiegelen. Volg de tijd tot de eerste hello world voor nieuwe ontwikkelaars in het bedrijf, de deploymentfrequentie, het foutpercentage bij wijzigingen en de gemiddelde hersteltijd (MTTR). Voer daarnaast regelmatig tevredenheidsonderzoeken onder ontwikkelaars uit om te begrijpen waar de wrijvingspunten in de platformworkflows nog zitten.

Waar je hierna naartoe gaat

Begin klein. Probeer op dag één geen enorm enterpriseplatform te bouwen. Kies één use case, bijvoorbeeld het standaardiseren van containerdeployments of het automatiseren van databasevoorziening, en bouw daar een minimaal levensvatbaar platform omheen. Verzamel feedback van je vroege adopterende teams, verbeter je golden paths en breid de mogelijkheden van je platform geleidelijk uit over de hele organisatie.

Door je Internal Developer Platform native op Azure te ontwerpen, automatiseer je niet alleen deployments; je bouwt een motor voor duurzame engineeringgroei. Bedankt voor het lezen, en bekijk zeker de podcastaflevering voor een diepgaander audiogesprek over dit onderwerp. Veel succes met het ontwerpen!