Infrastructure engineering draaide lange tijd vooral om het beheren van servers, netwerken en infrastructuur. Volgens Bart van Benthem, lead architect binnen KPN SI Private Cloud, verschuift het vak steeds verder richting softwareontwikkeling. Handmatige beheeracties maken plaats voor declaratieve configuraties, Kubernetes Operators en een centrale control plane. Daardoor verandert niet alleen de techniek, maar ook het profiel van de platform engineer.
Bart werkt zo’n zestien jaar bij KPN. In die periode vervulde hij verschillende technische rollen en werkte hij langere tijd bij klanten. Automatisering en infrastructuur vormden steeds de rode draad. Tegenwoordig is hij als lead architect betrokken bij de cloud-nativeplatformen van KPN SI, de system integrator die IT-diensten levert aan grootzakelijke klanten en de overheid.
Een belangrijk vraagstuk is hoe een centrale control plane een groeiend aantal cloud- en infrastructuurdiensten kan aansturen. Zo’n laag moet omgevingen over verschillende platformen en leveranciers heen orkestreren, zonder dat iedere nieuwe koppeling extra maatwerk en complexiteit veroorzaakt.
De verandering is al veel langer bezig
De verschuiving van infrastructuurbeheer naar software-engineering is al langer gaande. Kubernetes bestaat ruim tien jaar en vormde een belangrijke aanjager, maar het kostte tijd voordat het ecosysteem volwassen genoeg was om complete infrastructuurlandschappen via dezelfde principes te automatiseren.
Een belangrijke ontwikkeling is de Kubernetes Operator: software die kennis over het beheer van een toepassing of infrastructuurcomponent omzet in code.
Nieuwe technologie volgt vaker zo’n patroon. Eerst is een oplossing ingewikkeld en vooral bruikbaar voor specialisten. Daarna maken abstracties, frameworks en libraries de complexiteit beter beheersbaar en komt brede adoptie op gang. Bart: “Het is natuurlijk niet van gisteren op vandaag gegaan. Over een periode van tien jaar zijn er heel veel dingen bij elkaar gekomen die dit nu mogelijk maken.”
Een belangrijke ontwikkeling is de Kubernetes Operator: software die kennis over het beheer van een toepassing of infrastructuurcomponent omzet in code. Een operator kan niet alleen een resource aanmaken, maar ook blijven controleren of de werkelijkheid overeenkomt met de gewenste situatie. Zo verschuift automatisering van eenmalige provisioning naar de volledige levenscyclus, inclusief dagelijks beheer, foutafhandeling en herstel.
Het runbook wordt uitvoerbare software
Beheerders werkten nog niet zo lang geleden vaak met scripts en runbooks. Bij een storing stelde een engineer vast wat er aan de hand was, hij zocht de juiste herstelactie in een draaiboek, startte een script en controleerde het resultaat. Dat was al beter dan zonder scripts door logs zoeken en commando’s op gevoel uitvoeren, maar het bleef interactief: een mens bepaalde stap voor stap wat het systeem moest doen.
“Niet alleen de provisioning, maar ook de day-two operations worden softwaregedreven.”
Bij een Kubernetes Operator wordt die kennis in software vastgelegd. De operator vergelijkt continu de werkelijke toestand van een resource met de gewenste situatie en probeert verschillen weg te werken. De geprogrammeerde regels daarvoor heten de reconcile logic.
Een team kan onmogelijk ieder incident vooraf voorzien. Wel kan het na een nieuw probleem een herstelactie aan de operator toevoegen. Bij dezelfde afwijking hoeft een engineer dan niet opnieuw handmatig in te grijpen. De oplossing is onderdeel van het platform geworden. Volgens Bart is dat het punt waarop infrastructuurbeheer echt een softwarediscipline wordt: “Niet alleen de provisioning, maar ook de day-two operations worden softwaregedreven.”
Van opdrachten geven naar een gewenste situatie beschrijven
Onder deze werkwijze ligt het verschil tussen imperatief en declaratief beheer. In een imperatief model schrijft een engineer alle stappen voor: eerst A, daarna B en vervolgens C. In een declaratief model beschrijft hij vooral de gewenste eindsituatie. Softwarecomponenten bepalen zelf welke stappen nodig zijn om die te bereiken en te behouden. “Je specificeert de truth”, zegt Bart. “Die componenten houden de daadwerkelijke runtime vervolgens in sync met die state.”
Binnen Kubernetes wordt de gewenste staat opgeslagen in etcd. Controllers en operators vergelijken die informatie met wat er werkelijk draait. Als een component ontbreekt, uitvalt of verkeerd is geconfigureerd, kan het platform de afwijking automatisch proberen te corrigeren. Zo ontstaan mogelijkheden voor self healing, waarbij detectie, analyse en een vooraf geprogrammeerde herstelactie zonder menselijke tussenkomst plaatsvinden. “Dit is nog geen AI. Het zijn gewoon geprogrammeerde routines die heel goed op elkaar aansluiten.”
Declaratief werken maakt ook hergebruik mogelijk. Een leverancier of opensource-community kan de logica bouwen waarmee een product wordt uitgerold en beheerd. Gebruikers hoeven niet iedere configuratie, afhankelijkheid en implementatie-volgorde zelf te bepalen, maar voegen vooral parameters voor hun eigen omgeving toe. Maatwerk verdwijnt niet, maar neemt wel af.
/i/2008430086.png?f=imagegallery)
Een control plane verplaatst complexiteit
Wanneer steeds meer infrastructuur declaratief wordt aangestuurd, ontstaat behoefte aan een overkoepelende control plane. Die vormt de centrale orkestratielaag voor verschillende cloudomgevingen, platformen en infrastructuurdiensten. Daarmee verplaatst een organisatie wel degelijk complexiteit naar één component, erkent Bart: “Je accepteert dat je een component neerzet waar de complexiteit naartoe gaat. Het verschil is dat deze complexiteit centraal kan worden gestandaardiseerd. Zonder control plane krijgt ieder platform of team een eigen verzameling scripts, koppelingen en processen die apart moeten worden ontwikkeld, onderhouden en beveiligd.” Door gemeenschappelijke logica centraal op te lossen, verdwijnt elders in het landschap juist complexiteit.
“Ook moet ons volledige tooling-ecosysteem meer autonomie kunnen ondersteunen. Tot die tijd blijven menselijke controle en validatie nodig.”
Dat stelt hoge eisen aan beschikbaarheid, beveiliging, logging en controleerbaarheid. De control plane mag geen black box of kwetsbaar knelpunt worden. Daarom worden veranderingen niet volledig aan autonome systemen overgelaten. Software kan automatisch een afwijking herkennen en een bekende storing herstellen, maar als de gewenste configuratie zelf moet veranderen, blijft bij KPN vooralsnog een mens betrokken. AI kan adviseren over een declaratie; een engineer beoordeelt en verwerkt de pull request in Git. “Dat is deels een veiligheidskeuze”, licht Bart toe. “Ook moet ons volledige tooling-ecosysteem meer autonomie kunnen ondersteunen. Tot die tijd blijven menselijke controle en validatie nodig.”
Open protocollen beperken afhankelijkheid
De control plane moet verschillende producten op protocolniveau koppelen. KPN gebruikt zowel opensourcesoftware als commerciële infrastructuurproducten van leveranciers zoals Red Hat, VMware en Oracle. Aanvullende diensten moeten zo veel mogelijk uniform via de control plane beschikbaar komen. Bart wil die laag daarom leveranciersneutraal bouwen, met open tools, api’s en protocollen waar mogelijk. Als specifieke logica niet in ieder afzonderlijk product zit, wordt het eenvoudiger om later van Kubernetes-distributie, databaseleverancier of infrastructuurplatform te wisselen.
Vendor lock-in verdwijnt daarmee niet. Leveranciers binden klanten nog steeds via extra diensten, abstractielagen en licentiemodellen. Volledig gesloten producten worden echter minder gemakkelijk toegelaten. “Als een product geen open protocollen of REST-api heeft, wordt het bijna niet meer geaccepteerd. IT’ers willen niet vastzitten in een gesloten systeem waar ze niet meer uit kunnen.”
Dat verschilt van traditionele enterprise-IT, waarin organisaties sterk op leveranciers leunen en moeten wachten wanneer een functie ontbreekt. Opensource-bouwblokken, communities en open api’s geven engineers meer ruimte om zelf integraties te bouwen. Die vrijheid vraagt wel dat zij api-specificaties kunnen lezen en begrijpen hoe verschillende systemen samenwerken.
AI schuift de rol van de engineer ‘omhoog’
AI kan deze ontwikkeling versnellen. De reconcile logic bevat alleen scenario’s die ontwikkelaars vooraf hebben bedacht. Omdat niemand iedere mogelijke situatie handmatig kan uitwerken, kan AI helpen om scenario’s te analyseren, ontbrekende situaties te herkennen en voorstellen om te zetten in code.
“De waarde van de mens schuift omhoog. Je komt veel meer uit bij design, de juiste designpatterns en het beoordelen of de code daarbij past.”
Bart gebruikt taalmodellen al bij het onderzoeken van logbestanden, binnen de daarvoor geldende beveiligings- en privacykaders. “Taalmodellen kunnen helpen om sneller patronen in grote hoeveelheden logdata te herkennen.” Ook bij softwareontwikkeling neemt AI uitvoerend werk over. Menselijke kennis wordt daardoor niet direct overbodig, maar verschuift naar een hoger niveau in de stack. Engineers besteden minder tijd aan losse functies en meer aan architectuur, ontwerppatronen en validatie van gegenereerde code. “De waarde van de mens schuift omhoog. Je komt veel meer uit bij design, de juiste designpatterns en het beoordelen of de code daarbij past.”
Testen wordt daardoor juist belangrijker. Infrastructuurcode moet worden gecontroleerd met unit- en integratietests, maar teams moeten ook onderzoeken hoe componenten zich in staging en productie gedragen. Dankzij extra ontwikkelcapaciteit kunnen ze meer aandacht besteden aan testdekking voor infrastructuurcomponenten en PaaS-bouwblokken. De engineer blijft verantwoordelijk voor de uitkomst en controleert of code past bij architectuur, beveiliging en organisatiedoelen.
De platform engineer krijgt een developermindset
Softwaregestuurde infrastructuur maakt niet van iedere engineer een traditionele applicatieontwikkelaar. Een developermindset wordt wel steeds belangrijker en omvat meer dan code schrijven. Engineers moeten abstract denken, herbruikbare oplossingen herkennen, creatief naar integraties kijken, api’s begrijpen en code kunnen beoordelen. Zeker wanneer oplossingen meerdere systemen en leveranciers overstijgen, blijft menselijk inzicht belangrijk.
Ook kennis van Kubernetes speelt een grotere rol. Bart vergelijkt het belang ervan met Linux: niet iedereen hoeft alle details ervan te kennen, maar voor veel moderne infrastructuurfuncties wordt basiskennis vanzelfsprekend.
Tegelijk ontstaat een organisatorische uitdaging. Een hostingorganisatie is ingericht rond beheer, vaste producten en processen; een engineeringorganisatie ontwikkelt platformen als softwareproducten die continu veranderen. Medewerkers moeten meer zelf bouwen, api-specificaties doorgronden en verantwoordelijkheid nemen voor ontwerpkeuzes. Organisaties moeten daarom het verwachte kennisniveau duidelijk maken, ontwikkeltijd bieden en bepalen wat de nieuwe standaard binnen teams wordt. Stefan vult aan: “Dat is het voordeel van onze organisatie. KPN biedt mogelijkheden om door te groeien; daar word je ook uitgebreid in gefaciliteerd. Veel collega’s veranderen door de jaren heen van teams of van rol. Zo blijft iedereen zich ontwikkelen en gemotiveerd.”
:strip_exif()/i/2008430092.jpeg?f=imagenormal)
Het profiel van de toekomst ligt nog niet vast, de mens blijft centraal
Hoe het werk van platform engineers er over twee, vijf of tien jaar uitziet, durft Bart niet te voorspellen. Wel ziet hij een profiel ontstaan waarin techniek, ontwerp en productdenken dichter bij elkaar komen. De professional van de toekomst moet klantbehoeften vertalen naar technische keuzes, begrijpen hoe een platform als product wordt ontwikkeld, en code en architectuur kritisch kunnen beoordelen.
Dat profiel vraagt technische diepgang zonder vast te blijven zitten in één product, programmeerkennis zonder uitsluitend code te schrijven, en voldoende inzicht in de business om te begrijpen waarom een platform bestaat. Wie over die hele linie waarde toevoegt, blijft volgens Bart voorlopig relevant.
De overgang van hosting naar engineering is daarmee veel meer dan een verandering van tooling. Cloudplatformen worden software, operationele kennis wordt programmeerbare logica en engineers schuiven op van uitvoerend beheer naar ontwerp en regie. De control plane neemt steeds meer werk over, maar de mens blijft bepalen welke werkelijkheid het systeem uiteindelijk moet nastreven.
Dit artikel is geen redactioneel artikel, maar gesponsord en tot stand gekomen dankzij KPN en Tweakers Partners. Tweakers Partners is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers events zoals meet-ups, Developers Summit, Testfest en meer. Bekijk hier het overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
/u/27299/hoofd.png?f=community)
:strip_exif()/u/136823/noooo.gif?f=community)