How to provide the Netherlands with 5G internet using bare-metal air-gapped clusters?

Tijdens Red Hat Summit 2024 stonden Wouter Bouvy (VodafoneZiggo) en Chris Lips (HCS Company) samen op het podium met een titel die meteen de wenkbrauwen optrekt: How to provide the Netherlands with 5G internet using bare-metal air-gapped clusters? Dat klinkt als een technisch verhaal voor insiders. En dat is het ook, een beetje. Maar onder die titel zit een veel bredere en menselijkere vraag. Want achter 5G zit niet alleen technologie. Daarachter zitten keuzes, afhankelijkheden, teams, leveranciers, procedures en één terugkerende worsteling: hoe houd je iets dat zó kritisch is ook echt beheersbaar?

Hoe bouw je een modern platform voor een superkritische omgeving zonder te verdrinken in complexiteit?

Dat was in feite de echte vraag achter de presentatie. Niet alleen hoe je een Red Hat OpenShift-platform neerzet. Maar hoe je dat doet in een telco-omgeving waar de lat genadeloos hoog ligt, de randvoorwaarden keihard zijn en de praktijk zich zelden gedraagt zoals het plaatje op de architectuurslide.

Als 5G gewoon moet werken, is “goed genoeg” gewoon niet goed genoeg.

Voor miljoenen verbindingen moet de onderliggende infrastructuur simpelweg doen wat die moet doen. Altijd. Zonder hapering. Zonder vertraging. Zonder gedoe. Pas als je dat even op je laat inwerken, voel je hoe serieus deze opgave eigenlijk is. Dit ging niet over een gewoon IT-platform. Dit ging over telco. Over nationale kritische infrastructuur. Over een omgeving waar public cloud om security- en latency redenen geen optie is, waar N+2 en geo-redundantie geen luxe zijn maar randvoorwaarde en waar je zoveel mogelijk uit bare metal wilt persen omdat performance ertoe doet. Lage latency. Hoge throughput. Hoge security posture. Air-gapped clusters. Regelmatige pentests. Wet- en regelgeving die niet vraagt of het uitkomt.

En precies daar begint het verhaal interessant te worden. Want op papier kun je dan denken: modern platform, cloud native principes, goede mensen erop, klaar. Maar de praktijk had andere plannen.

Het leek eerst vooral een platformvraagstuk.

De opgave leek aanvankelijk overzichtelijk in zijn soort. Bouw een toekomstvast platform waarop leveranciers zoals Nokia en Ericsson hun 5G-workloads stabiel kunnen draaien, terwijl het platformteam de zorgen rond security, beschikbaarheid, monitoring en observability uit handen neemt. Dat is ook precies de rol die het Container-as-a-Service-team bij VodafoneZiggo vervult: de verbindende laag tussen hardware en applicaties, zodat tenants niet in de volle complexiteit hoeven te zwemmen.

Maar wie goed kijkt, ziet dat hier al iets onder de oppervlakte broeit. Want zodra jij de last bij de gebruiker wilt weghalen, komt die last ergens anders terecht. Bij het platform. Bij de operatie. Bij de manier van samenwerken. Bij de vraag hoe je voorkomt dat slimme mensen hun dagen kwijtraken aan repetitief werk, afstemming, handwerk en foutgevoelige uitzonderingen.

Toen beet de werkelijkheid terug.

Een van de sterkste lessen uit dit verhaal is dat moderne technologie niet automatisch een moderne werkelijkheid oplevert. Cloud native op papier is nog geen cloud native in de praktijk. Dat werd in deze omgeving pijnlijk concreet. Telco-vendors bewegen niet in hetzelfde tempo als Kubernetes. Validaties duren lang. Grote applicaties blijken lang niet altijd elegante microservices. Operations moet mee veranderen. Procedures moeten mee veranderen. Zelfs de changekalender kan een rem worden als de wereld om je heen juist sneller beweegt.

Daar kwam nog iets bij. Wat architectonisch logisch leek, bleek operationeel niet houdbaar. Het oorspronkelijke idee van namespace-as-a-service, met één groot cluster per datacenter en logische scheiding tussen tenants, liep in de praktijk vast. Niet omdat het concept dom was, maar omdat Kubernetes snel beweegt en telco-vendors die snelheid lang niet altijd kunnen bijbenen in hun validaties. Dan ontstaat het risico dat je wordt gegijzeld door versies, supportissues en moeizame upgradepaden. Daarom is er gekozen voor cluster-as-a-service. Geen cosmetische bijsturing, maar een fundamentele erkenning dat de werkelijkheid iets anders vroeg dan het eerste ontwerp.

Daar werd beheersbaarheid het echte thema.

En precies op dat punt verschuift het verhaal. Dan gaat het niet meer alleen over platformengineering. Dan gaat het over beheersbaarheid. Over de vraag of je een omgeving kunt bouwen die niet alleen technisch klopt, maar ook operationeel leefbaar blijft. Een omgeving waarin teams kunnen doorontwikkelen zonder vast te lopen in hun eigen succes.

In veel organisaties leeft nog altijd het oude model waarin development iets maakt en operations het daarna mag uitzoeken. In dit soort omgevingen werkt dat niet. Hier moet je veel dichter op elkaar zitten. Platformteams, operations, leveranciers en partners moeten samen bewegen. Niet uit gezelligheid, maar uit noodzaak. Want als verantwoordelijkheden uit elkaar lopen terwijl de afhankelijkheden juist dichter op elkaar kruipen, dan krijg je ruis. Dan krijg je wachttijd. Dan krijg je handwerk waar je eigenlijk automatisering wilt. En voor je het weet, is niet de technologie je grootste probleem, maar de frictie eromheen.

Hier kwam de echte les bovendrijven.

En dan kom je uit bij de takeaway die tijdens de presentatie niet voor niets zo prominent op de slide stond: Automate everything. Niet als stoere sticker op een laptop. Niet als een hip DevOps-kreet. Maar als een nuchtere conclusie uit alles wat onderweg zichtbaar werd. Zodra je iets voor de tweede keer doet, moet je je afvragen waarom het nog geen pipeline is. Zodra je nog afhankelijk bent van losse documenten, handmatige configuratie of Excel-lijsten voor onderliggende connectiviteit, weet je dat je kwetsbaarheid aan het organiseren bent. Zodra repetitieve taken tijd vreten van je beste mensen, weet je dat je eigenlijk geld en aandacht aan het verbranden bent.

Dat gold in deze case voor veel meer dan alleen deployments. Het gold ook voor patching, releases, incidentafhandeling, monitoring en zelfs voor de samenwerking met een managed service partner. Want ook daar zat een volwassen inzicht achter: als je wilt versnellen, moet je niet alleen automatiseren voor jezelf, maar ook processen zo inrichten dat anderen daarop kunnen aansluiten. Daarom was een andere les uit de presentatie ook logisch: haal repetitieve first- en second-line taken weg bij je kernteam, zodat DevOps-teams tijd overhouden voor verbetering, feature delivery en nog méér automatisering met onder andere Ansible en Gitlab.

Slimme mensen moet je niet laten verdrinken in dom werk.

Dat is misschien wel een van de meest sympathieke en tegelijk meest praktische lijnen in dit verhaal. Je wilt slimme mensen geen domme dingen laten doen. Niet omdat repetitief werk beneden hun stand zou zijn, maar omdat schaarse expertise te kostbaar is om op te sluiten in werk dat voorspelbaar te automatiseren of slim te beleggen is. In deze case betekende dat ook: werk waar mogelijk samen met een managed service partner voor de repeterende operatie, zodat interne mensen en HCS hun tijd kunnen steken in nieuwe initiatieven, verbeteringen en de vraagstukken die er echt toe doen.

Daar zit ook iets heel ‘Let;s Get Real’-achtigs in. Geen romantiek over druk zijn. Geen heldendom om het heldendom. Gewoon eerlijk kijken waar je mensen het meeste waarde leveren en de rest zo slim mogelijk organiseren.

Daarom is dit verhaal groter dan VodafoneZiggo alleen.

Op het eerste gezicht gaat dit verhaal over 5G, telco en disconnected bare-metal Red Hat OpenShift-platformen. Maar dat is eigenlijk te smal. In essentie gaat dit verhaal over iets waar steeds meer organisaties tegenaan lopen. Moderne platformen bouwen is één ding. Ze zó bouwen dat ze ook schaalbaar, veilig, onderhoudbaar en leefbaar blijven, is iets anders. Naarmate omgevingen kritischer worden, verdwijnt de luxe van vrijblijvendheid. Dan worden ontwerpkeuzes harder. Dan telt operatie zwaarder mee. Dan blijkt dat volwassenheid niet zit in de hoeveelheid technologie die je hebt, maar in de mate waarin je grip houdt op complexiteit.

En precies daarom blijft dit verhaal hangen. Niet omdat het alleen technisch indrukwekkend is, maar omdat het zo herkenbaar eerlijk is. De technologie is modern, maar de worsteling is oeroud: hoe voorkom je dat groei, afhankelijkheden en ambitie je eigen organisatie verzwaren?

De takeaway die bleef staan toen de slides alweer weg waren.

Aan het einde van de presentatie bleven meerdere lessen overeind. Denk vooraf goed na over je workload deployment strategy. Realiseer je dat cloud native ook voor vendors een reis is. Organiseer support slim. En onderschat on-premise connectivity vooral niet. Maar als je de sprekers zou vragen welke les erbovenuit steekt, dan is het antwoord eigenlijk opvallend eenvoudig: investeer in automatisering, want dat betaalt zich terug. Dat stond ook zo op de takeaways-slide en terecht.

Niet omdat automatisering een doel op zichzelf is. Maar omdat het in dit soort omgevingen het verschil maakt tussen een platform dat indrukwekkend oogt en een platform dat het in de praktijk ook volhoudt. Tussen een team dat voortdurend achter de feiten aanloopt en een team dat ruimte houdt om vooruit te bouwen. Tussen complexiteit die je ondersteunt en complexiteit die je opslokt.