Welkom bij weer een aflevering van Microsoft Knowledge Nuggets op M365FM. Ik ben je gastheer, Mirko Peters. Het onderwerp van vandaag is er een waar bijna iedereen van heeft gehoord, maar weinig een echt begrijpen, platform engineering. Je hebt waarschijnlijk wel gehoord van DevOps, het idee dat ontwikkelaars en operatieteams naadloos samenwerken, maar ergens onderweg raakte die belofte verstrikt. Ontwikkelaars gingen ops werk doen, dat systeem werkte niet. Aan het einde van deze aflevering begrijp je wat er misging met DevOps, wat een intern ontwikkelaarsplatform eigenlijk is, hoe Golden Pets teams een duidelijk pad bieden en waarom de slimste engineering teams er al aan bouwen. De puinhoop die DevOps achterliet, laten we teruggaan naar waar het begon. DevOps was een geweldig idee met een simpel doel, de muren tussen ontwikkelaars en operaties afbreken. Geen code meer over de schutting gooien en hopen op het beste.

Shift-Left verplaatst testen, beveiliging en operaties naar een eerder stadium in het proces. Snellere oplevering, minder overdrachten, meer eigenaarschap. Op papier zag het er perfect uit. In de praktijk ging er iets mis. Shift-Left verplaatste niet alleen verantwoordelijkheden, het stapelde ze op. De ontwikkelaar die vroeger code schreef en een ticket indiende, beheert nu infrastructuur, beveiliging, monitoring, Kubernetes, CI, CD pipelines, geheime beheer en zo'n 15 clouddiensten waar ze nog nooit van hadden gehoord. Eén persoon regelt dat allemaal terwijl diegene ook nog het eigenlijke product moet bouwen. Dit is hoe dat er in het echt uitziet. Een team wil een nieuwe omgeving opzetten om een functie te testen. Voor DevOps dienden ze een ticket in en wachten ze af. Na DevOps zijn ze zelfverantwoordelijk, wat in theorie geweldig klinkt, maar nu moeten ze Terraform modules schrijven, een Kubernetes cluster configureren, netwerkregels opzetten, monitoring koppelen, geheime beheer uitzoeken en zorgen dat beveiligingsbeleid wordt toegepast.

Wat vroeger een ticket was dat iemand anders een uur kostte, kost nu drie dagen van de tijd van een ontwikkelaar. Drie dagen waarin ze geen productcode schrijven. Ze zijn aan het vechten met Griekse Y-AML bestanden en aan het debuggen waarom de loadbalancer het verkeer niet correct routeert. De mentale belasting is hier enorm. Elk team bouwt uiteindelijk zijn eigen pipelines, deployment scripts en monitoring dashboards. En omdat iedereen overbelast is, worden er steken laten vallen. Beveiliging wordt overgeslagen omdat de deadline vrijdag is. Cloud-rekeningen verdubbelen zonder dat iemand het merkt omdat niemand eraan dacht de testomgeving af te sluiten. En als er om twee uur s'nachts iets kapot gaat, is de ontwikkelaar die het gebouwd heeft de enige die het kan repareren. Dit is niet houdbaar en hier is waarom het belangrijker is dan ooit. De complexiteit van de cloud blijft groeien. Elk jaar zijn er meer diensten, meer tools en meer beslissingen om te nemen.

En nu stellen AI Codeert tools ontwikkelaars in staat om sneller dan ooit code op te leveren, 10, 20, zelfs 30 keer meer code per dag. Maar al die code heeft nog steeds infrastructuur, beveiliging en monitoring nodig. Meer code zonder een beter systeem betekent alleen maar snellere chaos. Als je het gevoel hebt dat je verdrinkt in Griekse Y, AML en Terraform, ben je niet alleen. Dit is geen persoonlijk falen, het is systemisch. Het model heeft aangetast wat platform engineering eigenlijk is. Dus, wat is de oplossing? Dat heet platform engineering en dit is de eenvoudigste manier om erover na te denken. Deze discipline creëert een interne laag die complexiteit absorbeert voor ontwikkelaars. Stel je voor dat je een groot kantoorpand binnenloopt. Je hoeft je geen zorgen te maken over wie toegang heeft tot welke verdieping, welke beveiligingspas werkt of waar de nooduitgangen zijn. De receptie regelt dat allemaal voor je en jij loopt gewoon naar binnen om aan het werk te gaan.

Dat is precies wat platform engineering voor jouw ontwikkelaars doet. In plaats van dat elke ontwikkelaar een expert moet worden in Kubernetes, Terraform, netwerken en beveiliging, creëert een centraal platform team een laag die al die complexiteit beheert. De ontwikkelaar krijgt een eenvoudige interface, klik op een knop, voer een commando uit, vul een formulier in en het platform regelt de rest. Maar dit is belangrijk, dit is niet hetzelfde als DevOps. DevOps vertelde elk team dat ze hun eigen infrastructuur moesten beheren, maar platform engineering zegt dat dit een recept voor een burn-out is. In plaats daarvan biedt het platform team gebaande paden, standaard, geteste en veilige manieren om algemene taken af te handelen. Zij bouwen en onderhouden de weg, terwijl productteams er gewoon overheen rijden. Het belangrijkste resultaat van platform engineering is een internal developer platform of kortweg IDP.

Zie het als een self-service systeem dat al dat repetitieve werk automatiseert. Infrastructuurvoorzieningen, CI, CD pipelines, beveiligingschecks, monitoring, allemaal ingebouwd en gestandardiseerd. Hier is een concreet voorbeeld. Wanneer een ontwikkelaar een nieuwe service wil implementeren zonder platform, is hij dagen bezig met het opzetten van infrastructuur, het schrijven van pipelines en het configureren van monitoring. Met een IDP klikken ze op deploy in een UI of voeren ze één commando uit en het platform regelt alles, provisioning, tests, monitoring, deployment, allemaal in minuten in plaats van dagen. Dus, wat betekent dit voor jou? Je stopt met het zijn van een alleskunner in infrastructuur en wordt weer een specialist in je eigen product. Je werk gaat weer over het bouwen van functies die belangrijk zijn voor je klanten, in plaats van debuggen waarom je Terraform staten file corrupt is.

Dat is het hele punt. Het internal developer platform in begrijpelijke taal. Dus, laten we eens kijken wat een internal developer platform nu eigenlijk is. Het is de motor die alles combineert in één systeem. Je CI, CD pipelines, infrastructuurschablonen, beveiligingsbeleid, monitoring en logging. In plaats van zes losse tools die je aan elkaar moet knopen. Hier is een vergelijking. Zie het als koken vanaf nul versus een automaat gebruiken. Koken vanaf nul betekent ingrediënten kopen, groenten snijden, kruiden afmeten, het voor nuis in de gaten houden. Veel beslissingen, veel stappen, veel manieren om fouten te maken. Een automaat geeft je resultaat met één druk op de knop. Minder beslissingen, sneller resultaat, consistente kwaliteit. Een IDP is die automaat. De ontwikkelaar hoeft niet te weten hoe infrastructuur wordt opgezet of waar geheimen worden opgeslagen. Ze drukken gewoon op de knop.

Wat zit er in die automaat? De kerncomponenten zijn vrij standaard. CI, CD-schablonen voor consistente beelds, infrastructuurvoorzieningen voor automatische omgevingen, geheime beheer zodat inloggegevens niet rondslingeren in configuratiebestanden, en logging met ingebouwde observability zodat je kunt troubleshooten zonder paniek. Alles vooraf geconfigureerd, getest en onderhouden door het platformteam. Hier is een concreet voorbeeld. Een ontwikkelaar typt Create new service in de command line of klikt op een knop in een portaal. Achter de schermen start het IDP een nieuwe repository met de juiste structuur, zet een build pipeline op die automatisch test draait, de deployt de service naar een ontwikkelomgeving en voegt health check-end points met logging toe. Dat gebeurt allemaal binnen enkele minuten. De ontwikkelaar heeft nooit een terraformbestand aangeraakt of een Kubernetes manifest geconfigureerd.

Gewoon een commando getypt en een draaiende service gekregen. Waarom is dit belangrijk? Consistentie is de belangrijkste reden. Wanneer elk team zijn eigen pipelines bouwt en eigen deploymentscript schrijft, eindig je met unieke, snowflake, configuraties. 50 verschillende services, 50 verschillende manieren van werken. Als er iets kapot gaat, kan niemand het debuwen behalve degene die het gebouwd heeft. En als die persoon het bedrijf heeft verlaten, veel succes. Een IDP elimineert dat door elke service dezelfde patronen te laten volgen, elke deployment dezelfde pipeline te laten gebruiken en elk team dezelfde standaardwaarde te geven. Wanneer er iets kapot gaat, zijn de patronen bekend en is de oplossing gedocumenteerd. Dus dit is wat dit voor jou betekent. Als jouw organisatie 50 teams heeft die op 50 verschillende manieren deployen, dan is een IDP de oplossing. Het betekent niet dat teams hun autonomie verliezen.

Het betekent dat de saaie, repetitieve, foutgevoelige delen worden gestandardiseerd, zodat het interessante, creatieve werk kan variëren. Dat is een afweging die het waard is. Golden Pets, de weg, geen kooi. Laten we het over Golden Pets hebben. Je hebt de term waarschijnlijk al eens gehoord, maar het idee is simpel. Een Golden Pet is een aanbevolen, voorafgebouwde workflow die de juiste manier de makkelijkste manier maakt. Je platform Team zegt, dit is hoe we voorstellen dat je dit aanpakt. We hebben het getest, het werkt en we ondersteunen je als er iets misgaat. Aanhaling steken, let op het woord voorstellen. Gouden paden zijn niet verplicht. Ontwikkelaars kunnen van het pad afwijken als dat nodig is, maar het pad is de snelle en veilige standaard. Het draait al, wordt ondersteund en is gedocumenteerd. Je hoeft niet alles vanaf nul uit te zoeken. Zie het als spoorrails in plaats van vangrails.

Vangrails vangen je op als je crash. Ze reageren, ze voorkomen dat je van een klif rijdt, maar ze helpen je niet bij het sturen. Spoorrails leiden je soepel langs de route, zodat je niet zelf hoeft te beslissen waar je afslaat. Ze helpen je vooruit, in plaats van je alleen op te vangen als je faalt. Hier gaan veel teams de mist in. Ze bouwen gouden paden voor het platformteam, niet voor de ontwikkelaars. Ze optimaliseren voor architecturale zuiverheid, beveiligingscompliance of interne regels die niemand buiten het platformteam begrijpt. Het resultaat ziet er geweldig uit op een whiteboard, maar werkt vreselijk in de praktijk. Ontwikkelaars zoeken stilletjes naar omwegen, de adoptie daalt en het platformteam vraagt zich af waarom niemand hun inspanningen waardeert. De oplossing is simpel, maar lastig uit te voeren. Je hebt ontsnappingsroutes nodig. Als het pad niet past bij de use case van een ontwikkelaar, hebben ze een uitweg nodig.

Een manier om een standaardinstelling te overschrijven, een eigen pipeline mee te brengen of het platform volledig te verlaten. En dit is het belangrijkste deel. Wanneer ze van het pad afwijken, is dat geen falen, maar feedback. Elke keer dat een ontwikkelaar het gouden pad verlaat, vertelt het je iets concreets. Of het pad mist een functie die het zou moeten hebben, of de use case hoort er simpelweg niet thuis. Beide signalen zijn waardevol. Een goed gouden pad in de praktijk ziet er zo uit. Een team wil een nieuwe back-end service uitrollen. Ze gebruiken het pad. Het geeft ze een template repository met de juiste structuur, een standaard CI-CD pipeline die al getest is, ingebouwde logging en monitoring, en een one-click rowback voor als er iets misgaat. Het hele proces duurt minuten in plaats van dagen, en omdat het platform team het pad beheert, lossen zij het op als er iets kapot gaat.

De ontwikkelaar hoeft geen expert te worden in het debuggen van pipelines. Wat dit voor jou betekent? Minder verrassingen. Je levert sneller omdat het pad getest is. Je levert veiliger omdat beveiliging en monitoring zijn ingebouwd. Je levert met vertrouwen omdat terugdraaien met één klik gebeurt. Het pad is er om je te helpen, niet om je tegen te houden. Gebruik het. Het verminderen van de cognitieve belasting. Dat is waar de echte winst zit. Wanneer een platform het zware werk opknapt, kunnen ontwikkelaars zich eindelijk op de code concentreren. Ze hoeven niet te weten welke Kubernetes-versie er draait. Ze hoeven geen Terraform-modules bij te werken telkens als een cloud provider een API wijzigt. Zij schrijven gewoon features. Platform-engineers vangen die complexiteit op. Zij bepalen wat ontwikkelaars moeten zien en wat verborgen moet blijven. Dat is een bewuste ontwerpkeuze, niet zomaar een technische.

Het gaat erom te bepalen welke details ertoe doen voor de gebruiker van het platform en welke alleen maar ruis toevoegen. Hier is een concreet voorbeeld. Een ontwikkelaar die een nieuwe service uitrolt, geeft niet om cluster-nood-groottes, instancetypen of autoscilling-drempels. Ze geven erom of hun service draait en hoe snel deze reageert. De spray configureert het platform dat alles op basis van de app tier. Kleine service, hier is de juiste instelling. Drukbezochte service, hier is een andere configuratie. De ontwikkelaar maakt die keuzes niet, omdat dat niet nodig is. Waarom is dit belangrijk? Omdat een burn-out minder snel optreedt wanneer ontwikkelaars niet met 15 verschillende zaken tegelijk jongleren. Sommige volwassen platformteams hebben de cognitieve belasting met bijna de helft verminderd. 40 tot 50 procent minder mentale overhead. Dat is een enorme verschuiving. Het is het verschil tussen met energie naar huis gaan en om 10 uur s'avonds naar een terminal staren, afvragend waarom je pipeline faalde.

Maar hier is de waarschuwing. Creëer geen illusies. Sommige platformteams trappen in een valkuil. Ze verbergen instellingen zonder ontwikkelaars inzicht te geven in wat er onder de motorkap gebeurt. Dat is geen abstractie, dat is misleiding en het keert zich tegen je zodra er iets misgaat. Ontwikkelaars lopen tegen een muur waar ze niet doorheen kunnen kijken en plotseling voelt het platform als een blackbox die hen tegenwerkt. De term hiervoor is een leaky abstraction. Je verbergt complexiteit, maar uiteindelijk lekt die complexiteit er toch uit. Een database wordt traag, een deployment faalt, een beveiligingsbeleid blokkeert iets onverwachts. En de ontwikkelaar heeft geen mentaal model van wat er gebeurt, omdat het platform er nooit een heeft aangereikt. Transparantie is belangrijk. Laat ontwikkelaars zien wat ze moeten weten, op het moment dat ze het moeten weten. Verberg niet alles en hoop er maar het beste van.

Wat dit voor jou betekent, minder contextwisselingen en meer flowstaten. Je begint je ochtend niet met de vraag of het Kubernetes cluster een update nodig heeft. Je begint je ochtend met het werken aan de feature die volgende week af moet. Je baan wordt weer je eigenlijke werk. Het platform behandelen als een product. Vandaag praten we over iets dat de werking van interne tools volledig verandert. De meeste mensen denken dat een platformteam gewoon een infrastructuurteam is. Dat is het niet. Een platformteam is een productteam en de ontwikkelaars die dat platform gebruiken zijn hun klanten, geen mensen die tickets indienen. Dat verandert alles. Een productteam praat met zijn klanten, ontdekt wat echt vervelend is, prioriteert functies op basis van werkelijke behoeften, meet de adoptie, bouwt niet zomaar iets om daarna te vertrekken, maar blijft itereren. Dus, hoe ziet een productteamer in de praktijk uit?

Ze werken niet als een helpdesk. Een ontwikkelaar opent een ticket en het platformteam voert het handmatig uit. Dat is geen platformengineering, dat is gewoon gecentraliseerde operatie met een nieuwe naam. Het schaalt niet, het vermindert de cognitieve belasting niet, het verplaatst de bottleneck alleen maar van het ene team naar het andere. Dit is wat ze in plaats daarvan doen. Ze meten de juiste dingen, tijd tot eerste deplooi, onboardingssnelheid voor nieuwe teamleden, tevredeheidsscores van ontwikkelaars. Dit zijn de statistieken die je vertellen of het platform mensen echt helpt of gewoon een extra laag complexiteit toevoegt. Spotify is een goed voorbeeld. Hun platformteam draait als een echte productorganisatie. Ze hebben roadmaps, ze hebben OKR's, ze praten met ontwikkelaars over wat wel en niet werkt. Ze behandelen het platform als iets dat elke dag opnieuw zijn adoptie moet verdienen en dat is het kernidee.

Een platform dat niemand gebruikt is slechts een project. Het staat stof te verzamelen in een hoek. Adoptie is de ultieme validatie. Als ontwikkelaars voor jouw platform kiezen in plaats van hun eigen tools te bouwen, dan ben je geslaagd. Als ze het vermijden, kan geen enkele hoeveelheid technische uitmuntendheid dat repareren. Wat betekent dit voor jou? Het betekent dat als je een platform bouwt, begin niet met architectuurdiagrammen, begin niet met Kubernetes clusters of Terraform modules. Begin met gebruikersinterviews, praat met de ontwikkelaars die je platform gaan gebruiken. Ontdek wat echt pijnlijk is. Bouw één ding dat een echt probleem oplost en itereer daarna. Dat is hoe je iets bouwt dat mensen ook echt willen gebruiken. Waarom juist nu de AI-golf? Dus waarom praten we hier nu over? Waarom niet vijf jaar geleden? Het antwoord is AI. AI-codeertools zoals GitHub Copilot laten ontwikkelaars code opleveren in een tempo dat we nog nooit eerder hebben gezien.

Tien keer, twintig keer meer code per dag dan wat een paar jaar geleden mogelijk was. Dat klinkt geweldig en dat is het ook. Maar dit is het addertje onder het gras. Al die code heeft nog steeds infrastructuur nodig. Het heeft nog steeds beveiliging nodig. Het moet nog steeds worden uitgerold, getest en beheerd. Meer code zonder een beter systeem maakt je niet sneller. Het zorgt er alleen maar voor dat de chaos sneller gaat. Als je ontwikkelaars al verdrinken in Griekse Y, AML en Terraform, lost AI dat niet op. Het betekent alleen dat ze sneller verdrinken terwijl ze meer code produceren die ondersteund moet worden. Op dit moment heeft ongeveer 55% van de organisatie's platform engineering al in enige vorm geadopteerd. Bartner voorspelt dat dit aantal eind 2026 de 80% zal bereiken. Dat is geen langzame trend. Dat is een verschuiving die nu gaande is. Bedrijven realiseren zich dat ze hun engineering teams niet kunnen schalen zonder een platformlaag.

De oude aanpak waarbij elk team alles zelf doet, werkt gewoon niet als je code verstuurt op AI-snelheid. Dit is wat veel mensen over het hoofd zien. AI creëert niet alleen de behoefte aan platforms. Het helpt ze ook bouwen. Platformteams gebruiken AI om Terraform modules te genereren, documentatie te schrijven en pipelines te debuggen. Dezelfde technologie die de urgentie creëert, biedt ook de tools om het op te lossen. Nu, een woord van waarschuwing. AI versterkt wat je al hebt. Als je fundamenten solide zijn, zoals een goede architectuur en een goed ontworpen platform, maakt AI je twee tot drie keer productiever. Maar als je fundamenten zwak zijn, helpt AI je alleen maar om sneller grotere fouten te maken. Slechte configuraties, beveiligingslekken, kapotte infrastructuur, allemaal naar productie verstuurd voordat iemand het merkt. AI lost slechte fundamenten niet op. Het legt ze bloot.

Hier is een echt voorbeeld. Een bedrijf met een goed intern ontwikkelaarsplatform kan een niet-engineer veilig AI-tools laten implementeren. Het platform biedt vangrails. Het dwingt beveiligingsbeleid af. Het beheert de infrastructuur. Zo kan een productmanager een AI-gestuurd prototype opzetten zonder Kubernetes of cloudnetwerken te hoeven begrijpen. Dat is krachtig. Dat is het soort ding dat teams die klaar zijn voor het AI-tijdperk onderscheidt van teams die achterblijven. Wat betekent dit voor jou? Het venster om een platform te bouwen sluit zich. Niet omdat de technologie verdwijnt, maar omdat de kloof tussen teams met platforms en teams zonder platforms snel groter wordt. Elke maand dat je wacht, lopen de teams die al platforms hebben verder uit. Ze leveren sneller, raken minder opgebrand en passen zich sneller aan nieuwe tools aan. De teams zonder platforms raken steeds verder achterop.

De keuze is aan jou. Begin met één golden pet. Dus, waar begin je eigenlijk? Als je denkt dat je vanaf nul een heel intern ontwikkelaarsplatform moet bouwen, stop dan. Dat is de snelste manier om je projectennek om te draaien voordat het begint. De grootste fout die teams maken, is proberen alles tegelijk te bouwen. Ze besteden maanden aan het ontwerpen van het perfecte platform, volgepropt met elke functie die ze kunnen bedenken. Dan lanceren ze het en horen ze niets. Niemand gebruikt het. Waarom? Omdat het probleem een oplost waar niemand om vroeg en je voor de start al een handleiding moet lezen. Hier is het punt. Doe dat niet. Begin in plaats daarvan klein. Praat echt met developers, niet met de architecten, niet met de managers, niet met je eigen aannames. Zoek de mensen die elke dag aan functies werken. Vraag hen waar het knelt. Zoek de workflow die het langs duurt, de meeste mensen frustreert of vaker wordt overgeslagen dan zou moeten.

Bouw vervolgens precies één golden pad, van begin tot eind. Misschien is het het maken en uitrollen van een nieuwe microservice. Misschien is het het vanaf nul opzetten van een ontwikkelomgeving. Misschien is het het uitrollen van een hotfix naar productie zonder iets te breken. Kies degene die het meest pijn doet en bouw een pad dat die pijn wegneemt. Bouw het, test het met echte gebruikers, verzamel feedback, itereer. Voeg daarna een ander pad toe en daarna weer een. Probeer niet elk probleem tegelijk op te lossen. Los één probleem echt goed op en laat het momentum je vooruit helpen. Hoe weet je of het werkt? Meet de juiste dingen. Tijd van idee tot eerste deploy. Het aantal handmatige stappen dat je hebt geëlimineerd en vrijwillige adoptiecijfers. Als developers jouw pad kiezen in plaats van hun eigen oplossing, dan win je. Als ze het vermijden, luister dan en verander van koers. Dit is de valkuil die je moet vermijden.

Maak het platform niet verplicht. Dwing developers op jouw pad en ze zullen het gaan haten. Ze zullen manieren vinden om eromheen te werken. Ze zullen hun eigen scripts bouwen en deze voor je verbergen. Maak het pad in plaats daarvan gemakkelijk. Maak het sneller dan het alternatief. Maak het de voor de hand liggende keuze, maar nooit de enige. Het eerste pad is altijd het moeilijkst. Het leert je alles over productdenken. Je leert praten met gebruikers, prioriteiten stellen en dat iets bouwen waar mensen echt op zitten te wachten veel moeilijker is dan iets bouwen dat gewoon werkt. Maar zodra je het één keer hebt gedaan, wordt het tweede pad makkelijker en het derde nog makkelijker. Je bouwt een platform niet in één keer. Je bouwt het één pad per keer. Dat is dus het systeem. Platform Engineering draait om de geplavijden wegbouwen, zodat developers zich kunnen concentreren op het rijden in plaats van op het repareren van gaten in de weg.

Als je het zat bent om te vechten met infrastructuur, begin dan met het vinden van één golden pad binnen je team, slechts één. Deel dit met iemand die dit moet horen en abonneer je voor meer analyses zoals deze.