Platform Engineering 101: voorbij traditionele ticketingsystemen in Azure

By Mirko Peters · 2026-08-13

Welkom terug, luisteraars en lezers, bij weer een diepgaande duik in de voortdurend veranderende wereld van clou… [Note: the segment [[D]] is truncated in the source; I cannot translate it fully.]

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

Welkom terug, luisteraars en lezers, bij weer een diepgaande duik in de voortdurend veranderende wereld van cloudarchitectuur, developer experience en moderne DevOps. Als je onze recente podcastaflevering hebt gehoord, weet je dat we een flink deel van de tijd besteedden aan het aanpakken van een van de meest frustrerende knelpunten in moderne softwarelevering: het traditionele IT-ticketingsysteem. Je kent het wel. Een developer heeft een nieuwe database, een staging-omgeving of een simpele DNS-wijziging nodig. Hij opent een ticket. Het ticket blijft in een wachtrij staan. Het wordt getriageerd, toegewezen, opnieuw toegewezen en uiteindelijk, dagen of zelfs weken later, worden de handmatige handelingen uitgevoerd. Tegen de tijd dat die infrastructuur er staat, is de sprint voorbij, is het momentum verdwenen en is iedereen uitgeput.

In deze blogpost bij de podcast gaan we de kernconcepten die we op de radio bespraken uitgebreid verder uitwerken. We onderzoeken hoe organisaties die Microsoft Azure gebruiken zich kunnen losmaken van deze zielloze handmatige cyclus door de transformerende discipline van Platform Engineering toe te passen en robuuste Internal Developer Platforms (IDP's) te bouwen.

Inleiding: het knelpunt van traditionele ticketing in Azure

Laten we een herkenbaar beeld schetsen. Je organisatie heeft haar workloads naar Microsoft Azure gemigreerd. Je hebt de cloud omarmd, je gebruikt Azure Kubernetes Service (AKS), Azure SQL, Cosmos DB en App Services. Op papier ben je modern. Maar als je goed kijkt naar je werkwijze, behandelen je developers Azure nog steeds zoals ze vroeger de serverruimte on-premises behandelden: via een muur van bureaucratie en ticketwachtrijen.

Wanneer een team een resource wil inrichten, kan het dat niet zelf doen. Vangrails zijn geïmplementeerd als blokkades in plaats van als trottoirs. Ze dienen een ticket in bij het centrale platform- of operationsteam. Dat zorgt voor een enorme cognitieve belasting en ondermijnt volledig de wendbaarheid die cloudcomputing had moeten bieden. Azure biedt ongelooflijke snelheid en programmatische controle, maar developers worden er vaak buiten gehouden. Het traditionele ticketingsysteem werkt als een belasting op innovatie. Elk verzoek vereist menselijke tussenkomst, met menselijke fouten, miscommunicatie en pijnlijke vertragingen als gevolg. We moeten ermee stoppen developers te behandelen als kinderen die niet vertrouwd kunnen worden met infrastructuur, en hen gaan zien als bevoegde makers die self-service nodig hebben, ondersteund door geautomatiseerde vangrails.

Wat is Platform Engineering en waarom doet het ertoe?

Hoe lossen we dit op? Dat is waar Platform Engineering om de hoek komt kijken. De afgelopen jaren heeft Platform Engineering zich ontwikkeld tot de definitieve evolutie van DevOps. DevOps heeft in theorie de muur tussen development en operations afgebroken, maar in de praktijk hebben veel organisaties de volledige operationele last simpelweg bij de developers neergelegd. Van developers werd ineens verwacht dat ze experts waren in Kubernetes, Terraform, netwerkbeveiliging en Azure IAM-beleid, terwijl ze ook nog business logic moesten schrijven.

Platform Engineering erkent dat dit niet houdbaar is. In plaats van developers te dwingen infrastructuurexpert te worden, of ze in een ticketwachtrij te laten wachten, behandelt Platform Engineering de developer experience als product. Een speciaal platformteam bouwt een Internal Developer Platform (IDP) dat de onderliggende complexiteit van Azure abstraheert.

Waarom is dit belangrijk? Omdat cognitieve belasting de stille killer van engineeringproductiviteit is. Wanneer developers 40 procent van hun tijd kwijt zijn aan worstelen met infrastructuurconfiguraties, compliancechecklists en wachten op goedkeuringen, bouwen ze geen functies waar klanten blij van worden. Platform Engineering is belangrijk omdat het de flow terugbrengt bij engineeringteams. Het biedt golden paths: vooraf goedgekeurde, zeer veilige en compliant architecturen die developers met één klik of commando kunnen opzetten.

Voorbij handmatige operations: de visie van Internal Developer Platforms

Om echt voorbij handmatige operations in Azure te komen, moeten we onze mindset verschuiven van het beheren van infrastructuur naar het bouwen van platforms. Een Internal Developer Platform is niet zomaar één tool; het is een samenhangende laag bovenop je Azure-cloudinfrastructuur die services en tools samenbrengt om software met nul wrijving op te leveren.

Het probleem met ad-hocscripts en wild-westprovisioning

Sommige organisaties beseffen dat ticketing traag is, en delen daarom contributor-toegang tot Azure-abonnementen uit, zodat ontwikkelaars zelf kunnen aanmaken wat ze willen. Dit is het tegenovergestelde uiterste, en even rampzalig. Al snel heb je onbeheerde resources, explosief stijgende cloudkosten, grote beveiligingsproblemen en geen standaardmanier om iets te monitoren of bij te werken. Het is het Wilde Westen.

De gouden middenweg met een IDP

Een IDP zorgt voor het perfecte evenwicht. Het biedt self-servicemogelijkheden en verwerkt tegelijkertijd beveiliging, compliance, kostenbeheer en architectuurstandaarden rechtstreeks in de workflow. Ontwikkelaars krijgen de autonomie waar ze naar verlangen, terwijl operations- en beveiligingsteams de governance en compliance krijgen die ze nodig hebben. Het is een win-winscenario, mogelijk gemaakt door automatisering.

Kernpijlers van een Azure-gebaseerd developerplatform

Wanneer je je Internal Developer Platform op Microsoft Azure bouwt, heb je een solide architectonische basis nodig. Laten we de kernpijlers bespreken die een Azure-platform succesvol maken.

1. Infrastructure as Code (IaC) en modulecatalogi

Het hart van elk cloudplatform is Infrastructure as Code. In het Azure-ecosysteem betekent dit meestal Terraform, Bicep of Azure Resource Manager (ARM)-templates. Het alleen schrijven van Bicep-bestanden is echter niet genoeg. Je platformteam moet een samengestelde catalogus maken van modulaire, herbruikbare en veilige templates. In plaats van dat een ontwikkelaar zelf een databaseconfiguratie vanaf nul schrijft, biedt het platform bijvoorbeeld een Azure SQL-module die al voorzien is van enterprise-niveau encryptie, goede netwerkintegratie en vooraf ingestelde back-upbeleidsregels. De ontwikkelaar geeft alleen de applicatienaam en het niveau op.

2. Policy as Code met Azure Policy

Governance kan niet afhangen van mensen die vinkjes zetten. Het moet geautomatiseerd zijn. Door Azure Policy en Azure Blueprints in je platform te integreren, zorg je ervoor dat elke resource die via het IDP wordt geprovisioneerd automatisch voldoet aan regelgevende kaders en interne bedrijfsstandaarden. Als een ontwikkelaar een opslagaccount zonder encryptie tijdens transport probeert te provisioneren, vangt het platform dit meteen op en wijst het af voordat het Azure ook maar raakt.

3. Naadloze CI/CD- en GitOps-integratie

Je IDP mag niet op zichzelf staan. Het moet native integreren met je versiebeheer en deployment-pipelines. Of je nu GitHub Actions, Azure DevOps of ArgoCD voor GitOps gebruikt, het platform moet de pipeline van code-commit tot Azure-deployment naadloos orkestreren. Ontwikkelaars moeten omgevingen rechtstreeks vanuit hun pull requests kunnen laten opstarten of afbreken.

4. Geïntegreerde observability en monitoring

Je kunt niet beheren wat je niet kunt meten. Een goed platform biedt observability out-of-the-box door applicaties rechtstreeks te koppelen aan Azure Monitor, Application Insights en Azure Log Analytics. Wanneer een ontwikkelaar via het platform een nieuwe microservice opstart, worden logging, metrics en tracing automatisch ingesteld en aangesloten, zonder handmatige instrumentatie.

Sneller leveren en minder frictie voor ontwikkelaars

Laten we het hebben over de concrete impact van deze architectuur. Wanneer je een ticketproces van twee weken vervangt door een self-serviceportaal van twee minuten, veranderen de cijfers drastisch.

Time-to-market en deploymentfrequentie

De ontwikkelsnelheid schiet omhoog. Features die vroeger vastliepen in staging-omgevingen, wachtend op handmatige netwerkconfiguraties, kunnen nu direct worden uitgerold. Teams kunnen voor elke afzonderlijke pull request tijdelijke omgevingen opzetten, hun code testen in een omgeving die een exacte kopie van productie is, en die weer opruimen zodra de PR is samengevoegd. Dit niveau van wendbaarheid is in een handmatige ticketwereld onmogelijk.

Ontwikkelaarsburn-out voorkomen

Tevredenheid van ontwikkelaars is een cruciale metric die te veel organisaties negeren. Voortdurend vechten tegen bureaucratie, wachten op andere teams en omgaan met repetitieve taken met weinig waarde leidt rechtstreeks tot burn-out en hoog verloop. Door frictie weg te nemen en het saaie werk te automatiseren, creëer je een omgeving waarin engineers zich creatief, productief en gewaardeerd voelen. Gelukkige ontwikkelaars schrijven betere code.

Best practices voor het invoeren van platform engineering in je organisatie

Een Internal Developer Platform op Azure bouwen klinkt geweldig, maar hoe voer je het echt uit zonder enorme verstoring? Hier zijn enkele best practices die we onze luisteraars en consultancyklanten aanraden.

Behandel het platform als een product

Dit is de belangrijkste regel van platform engineering. Je interne ontwikkelaars zijn je klanten. Je moet gebruikersonderzoek doen, feedback verzamelen, documentatie schrijven en voortdurend itereren op basis van hun behoeften. Als je platform omslachtig is en moeilijk te gebruiken, zoeken ontwikkelaars naar omwegen en mislukt je initiatief.

Begin klein met een Minimum Viable Platform (MVP)

Probeer niet op dag één een monolithisch, alomvattend platform te bouwen. Begin met één use case die een grote pijnpunt oplost. Begin bijvoorbeeld met het automatiseren van de provisioning van standaardmicroservices op Azure Kubernetes Service, met ingebouwde logging en databases. Zodra dat succesvol is en wordt gebruikt, breid je de mogelijkheden van het platform stap voor stap uit.

Zet sterk in op ontwikkelaarsdocumentatie en de portalervaring

Zelfs de krachtigste backend-automatisering is nutteloos als ontwikkelaars niet weten hoe ze die moeten gebruiken. Investeer in een developer portal. Tools zoals Backstage van Spotify zijn precies voor dit doel enorm populair geworden. Combineer Backstage met Azure-integraties en je geeft je teams één centraal overzicht om documentatie te bekijken, servicecatalogi te verkennen en zelfbedieningsacties te starten.

Conclusie: moderne ontwikkelteams klaarmaken voor de toekomst

Traditionele ticketingsystemen zijn overblijfselen uit een vervlogen tijd. Ze vertragen innovatie, frustreren technisch talent en benutten de echte kracht en wendbaarheid van clouddiensten zoals Microsoft Azure niet. Door Platform Engineering te omarmen en doordachte, veilige en geautomatiseerde Internal Developer Platforms te bouwen, kunnen organisaties knelpunten wegnemen, stevig governance afdwingen en het volledige potentieel van hun ontwikkelteams ontketenen.

Onthoud: het doel van moderne clouddesign is niet alleen je servers naar het datacenter van iemand anders verhuizen, maar je mensen in staat stellen sneller en veiliger dan ooit waarde te leveren. Bedankt voor het luisteren naar deze uitgebreide blogpost. Abonneer je zeker op de podcast, deel dit artikel met je platform- en DevOps-teams, en luister volgende keer weer mee terwijl we de nieuwste ontwikkelingen in cloudtechnologie blijven verkennen!