Bij PeterConnects kreeg ik een vraag die ik vaker zou horen in mijn carrière: “Kan dit modern?”
Het “dit” was de Management Service — een monolithische Windows-applicatie met 19 services erin verweven. Ding draaide al jaren. Deed wat het moest doen. Maar schaalbaarheid was een zorgenkind, en de vraag of dit toekomstbestendig was hing in de lucht.
Mijn opdracht: uitzoeken of je dit ding kon ombouwen naar cloud-native microservices op Kubernetes. En als het kon — hoe dan?
Eerst begrijpen wat je hebt
Voor ik ook maar aan Kubernetes dacht, moest ik snappen wat die 19 services eigenlijk deden. Hoe praatten ze met elkaar? Waar zaten de single points of failure? Wat gebeurde er als er eentje omviel?
Monolieten hebben een slechte reputatie, maar ze hebben ook een voordeel: alles zit bij elkaar. Alles is vindbaar. Een monoliet van 19 services ontwarren is als een kerstboom van vorig jaar uit de doos halen — je weet dat het ooit logisch in elkaar zat, maar nu moet je uitvogelen welke kabel waarheen ging en waarom iemand dacht dat duct tape een permanente oplossing was.
Ik bracht de hele dependency chain in kaart. Welke services waren kritisch, welke konden onafhankelijk schalen, en welke waren stiekem aan elkaar vastgelijmd op manieren die niet in de documentatie stonden.
De PoC
Ik bouwde een proof of concept. Kubernetes-cluster, Service Mesh (Linkerd), API Gateway (nginx). Eén voor één trok ik services los uit de monoliet en gaf ze een eigen plek in het cluster.
Het mooie van een PoC is dat je niet meteen alles perfect hoeft te doen. Je hoeft alleen aan te tonen: dit kan. De eerste service die zelfstandig draaide op Kubernetes — met de monoliet er nog gewoon naast — was het bewijs dat het kon.
Wat me verraste: de compatibiliteit met bestaande applicaties bleef intact. Je kon de monoliet laten draaien terwijl de microservices ernaast opkwamen. Geen big-bang migratie. Gewoon één voor één, met een rollback voor elke stap.
Het moeilijkste deel was niet technisch
Ik had een werkende PoC. Ik had een gefaseerd migratieplan. Ik had een vergelijkende analyse tussen de oude en nieuwe architectuur — schaalbaarheid, interoperabiliteit, toekomstbestendigheid. Ik had een adviesrapport.
En toen moest ik de Product Owner overtuigen.
Dit was het echte werk. Niet de techniek — die was uit te leggen. Maar iemand die al jaren met deze applicatie leefde, moest geloven dat een fundamenteel andere architectuur beter was dan wat er nu stond. En terecht: het was zijn verantwoordelijkheid als het misging.
Wat hielp: ik had geen mening, ik had bewijs. De PoC was niet een PowerPoint — het was een draaiend cluster. Ik kon laten zien: hier draait service A, los van de monoliet, en hij praat nog steeds met de rest. Ik kon laten zien wat er gebeurde als je een service uitschakelde en de rest doordraaide. Ik kon de schaalbaarheid demonstreren door een extra replica toe te voegen zonder dat iemand er last van had.
Uiteindelijk ging hij mee. Niet omdat ik gelijk had — maar omdat het bewijs sterker was dan de twijfel.
Wat ik leerde
Architectuurkeuzes zijn mensenwerk. Je kunt de mooiste oplossing bouwen, maar als je de mensen die ermee moeten leven niet meeneemt, blijft het een hobbyproject.
Een PoC is een communicatiemiddel, geen technisch hoogstandje. Het hoeft niet productie-klaar te zijn. Het moet een verhaal vertellen dat iemand zonder Kubernetes-achtergrond kan volgen.
Monolieten zijn niet de vijand. Ze zijn vaak ontstaan omdat iemand ooit een pragmatische keuze maakte. De vraag is niet “is dit slecht” maar “past dit nog bij waar we naartoe gaan”. Soms is het antwoord ja. Soms nee. En soms is het: nog niet, maar we moeten wel een plan hebben.
Dit project was voor mij het moment waarop ik besefte dat Platform Engineering niet alleen over techniek gaat. Het gaat over de brug slaan tussen wat technisch mogelijk is en wat organisatorisch haalbaar is.
Die brug bouw je niet met YAML.