Waarom dit begon

Ik werk dagelijks met organisaties die digitaal willen groeien. Bedrijven die hun processen willen automatiseren, hun teams willen versterken, en hun toekomst willen veiligstellen. En steeds vaker stuit ik op dezelfde frustratie: ze zijn afhankelijk. Afhankelijk van één cloudprovider, één leverancier, één platform dat op een dag zijn prijzen verdubbelt, zijn API’s wijzigt, of besluit dat jouw use case niet meer past bij hun roadmap.

Ik wilde mijn relaties iets beters laten zien.

Geen abstracte presentatie met buzzwords. Geen whitepaper vol architectuurtekeningen die nooit gebouwd worden. Maar een concreet, werkend platform — iets dat ik letterlijk aan ze kon laten zien en zeggen: “Dit is hoe je grip houdt op je eigen infrastructuur, ongeacht welke cloud je gebruikt.”

Dat werd het Multi-Cloud Control Plane project — het derde deel in een reeks over digitale soevereiniteit die ik de afgelopen tijd heb opgebouwd. Als je de reis vanaf het begin wilt volgen: in De weg naar digitale vrijheid schreef ik over de Europese context en het waarom achter soevereiniteit. In Van idee naar soevereine cloud beschreef ik hoe ik een volledig autonome cloudworkspace bouwde op Europese infrastructuur. Dit artikel gaat een stap verder: niet alleen soeverein werken, maar soeverein blijven — ook als de infrastructuur om je heen beweegt.

Het idee: soevereiniteit is een keuze

Digitale soevereiniteit klinkt groot. Maar in de kern is het een simpele vraag: wie beslist er over jouw infrastructuur?

Als het antwoord “Amazon” is, of “Microsoft”, of “Google” — dan heb je een afhankelijkheidsrelatie die je misschien niet volledig overziet. Dat is niet per se fout. Maar het is een keuze die je bewust moet maken, en die je altijd open moet kunnen herzien.

Wat ik wilde bouwen, was een platform waarbij die keuze bij de organisatie zelf ligt. Waarbij je morgen kunt zeggen: “We gaan van provider A naar provider B”, en waarbij de spelregels — de policies, de veiligheidsregels, de naamgevingsconventies — gewoon meegaan. Niet opnieuw bouwen. Niet opnieuw onderhandelen. Gewoon meenemen.

Open source maakt dat mogelijk. Niet omdat open source altijd makkelijker is — dat is het zeker niet — maar omdat je nooit vastzit. De code is van jou. De kennis is van jou. De controle is van jou.

Wat ik bouwde

Het platform bestaat uit vijf repositories die samenwerken als één geheel:

• Een beleidsmotor (OPA — Open Policy Agent) die regels definieert voor alle infrastructuur, ongeacht de cloud
• Een infrastructuurlaag die de centrale VM opzet via Terraform
• Een configuratielaag die alles op de VM instelt via Ansible
• Een Europese cloudwerkbelasting — een landing platform op een Europese provider
• Een tweede cloudwerkbelasting — hetzelfde landing platform, maar bij een andere provider

Het bijzondere: dezelfde beleidsregels die ik voor de ene cloud schreef, gelden automatisch ook voor de andere. Als een engineer probeert een VM aan te maken zonder de verplichte labels, of in een verboden regio, of met SSH open naar het internet — dan blokkeert het systeem dat. Automatisch. Voor elke cloud. Zonder dat er een mens aan te pas komt.

Dat is het punt. Niet de techniek zelf, maar wat de techniek mogelijk maakt: een organisatie die zelf de regie voert.

Wat dit onderscheidt van een traditionele aanpak is de bewuste scheiding van verantwoordelijkheden. Infrastructuur en configuratie worden apart beheerd — niet omdat het technisch moet, maar omdat het organisatorisch verstandig is. Een server uitrollen en een gebruiker configureren zijn fundamenteel verschillende handelingen met verschillende risicoprofielen. Wie die twee door elkaar mengt, bouwt breekbaarheid in.

De architectuur achter het idee

Een platform als dit rust op een aantal principes die ik ook in mijn advieswerk consequent toepas.

Infrastructure as Code als fundament. Niets bestaat buiten de repository om. Elke server, elk netwerk, elke beveiligingsregel is beschreven als leesbare code, versioned en reproduceerbaar. Dat is niet alleen technisch handig — het is een organisatorische discipline. Het dwingt teams om keuzes expliciet te maken en te documenteren. Een nieuwe omgeving opzetten is daarmee geen geheugenoefening maar een geautomatiseerde stap.

GitOps als operationeel model. De repository is de enige bron van waarheid. Geautomatiseerde pipelines bewaken continu of de werkelijke situatie overeenkomt met de beschreven situatie. Afwijkingen worden automatisch gecorrigeerd. Handmatige wijzigingen worden teruggedraaid. Dit klinkt streng, maar het is juist bevrijdend: teams weten precies wat er draait, hoe het draait, en waarom. De pipeline is volledig gelogd en auditeerbaar — iets wat steeds meer een eis wordt onder NIS2 en vergelijkbare kaders. In Missie digitale soevereiniteit: doeltreffende IT delivery ga ik dieper in op hoe deze principes vertaald worden naar een werkende DevOps-organisatie.

Policy as Code als vangrail. In plaats van beveiligingsregels op te schrijven in een document dat niemand leest, zijn ze gecodeerd in OPA. Ze worden gecontroleerd vóórdat er iets uitgerold wordt, niet erna. Dat is het verschil tussen een architect die tekent en een architect die bouwt: de regels zitten in het systeem, niet in de hoofden van de mensen.

Self-service als doel. Een platform is pas volwassen wanneer teams er zelfstandig op kunnen werken — zonder elke keer een ticket in te dienen of op goedkeuring te wachten. De beleidsmotor maakt dat mogelijk: teams krijgen de vrijheid om te experimenteren binnen duidelijke kaders. De vangrails zijn er, maar de weg is open.

De reis was niet rechttoe rechtaan

Ik wil eerlijk zijn: dit was geen soepel traject. Ik leerde veel, en leren gaat met vallen en opstaan.

Het eerste struikelblok: ik dacht te snel

In een vroege versie van het platform besloot ik de policy-bundel — een pakketje met alle beleidsregels — via SSH naar de server te sturen. Snel, voor de hand liggend, het werkte.

Tot ik me realiseerde dat ik daarmee één van mijn eigen principes schond: je mag een draaiende server niet aanpassen via SSH. Dat is precies het soort onbeheerste, niet-traceerbare ingreep dat je probeert te vermijden. De oplossing was eleganter: de server zelf laten pollen. De beleidsregels staan in een object store, en de server haalt ze elke minuut op. Geen SSH nodig. Geen push. Geen mens die iets hoeft te doen.

Dat correctiemoment leerde me meer dan het oorspronkelijke ontwerp. Het is ook een les die ik herken uit mijn advieswerk: de mooiste architectuur is niet de meest complexe, maar de meest eerlijke. De aanpak die je over zes maanden nog begrijpt, die een nieuwe collega zonder briefing kan oppakken, en die faalt op een manier die je kunt zien.

De beschikbaarheidsillusie

Het uitrollen van de tweede cloudwerkbelasting was een geduldsoefening. Meerdere regio’s geprobeerd. Meerdere VM-groottes geprobeerd. Steeds dezelfde melding: “niet beschikbaar voor uw abonnement.”

Ik had verwacht dat een grote cloudprovider altijd capaciteit heeft. Dat klopt niet. Beschikbaarheid hangt af van de regio, het abonnementstype, het moment van de dag. De les is duidelijk: vendor-onafhankelijkheid betekent ook dat je moet kunnen omgaan met de beperkingen van elke vendor. Een hybride strategie is niet alleen een filosofische keuze — het is een operationele noodzaak.

Dit is precies waarom ik in mijn architectuurwerk altijd aandring op een warme standby buiten de primaire cloud. In Van kwetsbaarheid naar continuïteit heb ik dat principe uitgewerkt tot een volautomatische failover-architectuur: een systeem dat binnen drie minuten overschakelt naar een Europese omgeving, zonder dat een mens iets hoeft te doen. Dit Control Plane project en dat failover-project versterken elkaar — het ene regelt de policies, het andere regelt de continuïteit.

De stille fout

Het meest leerzame moment was er één waarbij het systeem deed alsof alles goed ging.

Ik had de policy-gate zo geconfigureerd dat ze Terraform-plannen controleerde vóór de uitrol. Maar door een subtiel technisch detail — policies gebruiken een andere package-naam dan het standaard zoekpad van het tool — werd er helemaal niets gecontroleerd. Het systeem zei “geslaagd” terwijl het in feite niets had gedaan.

Dat is het gevaarlijkste soort fout: niet een fout die rood wordt, maar een fout die onzichtbaar is. Een security control die je niet kunt testen op falen, is geen security control.

Het vinden en oplossen van die fout — het toevoegen van expliciete namespace-vlaggen aan elk commando — gaf me meer vertrouwen in het systeem dan tien succesvolle uitrollingen. Dit principe vertaal ik ook naar teams: bouw je pipeline zo dat een falende controle zichtbaar faalt. Shift-left security is geen slogan — het is een ontwerpkeuze die je elke dag opnieuw moet maken.

Volwassenheid groeit van binnenuit

Eén van de dingen die ik het meest tegenkom bij organisaties in transformatie, is de neiging om volwassenheid te meten aan tools. “We gebruiken Kubernetes, dus we zijn cloud-native.” “We hebben GitLab, dus we doen GitOps.”

Dat klopt niet. Volwassenheid herken je aan gedrag, niet aan gereedschap.

Een volwassen platformomgeving herken je doordat teams om features vragen in plaats van uitzonderingen. Doordat incidenten worden opgelost via de standaard tooling. Doordat een nieuwe engineer binnen een dag productief is, omdat de omgeving zichzelf uitlegt.

Dat groeit langs een herkenbaar pad. Eerst is er chaos: elke omgeving is uniek, elke wijziging is handmatig en risicovol. Dan komt standaardisatie: Infrastructure as Code, gestandaardiseerde pipelines, Ansible voor configuratiemanagement. Daarna self-service: het platform biedt kant-en-klare bouwblokken die teams zelfstandig kunnen combineren. En ten slotte observability-gedreven verbetering: je meet hoe het platform gebruikt wordt en optimaliseert op basis van echte data.

In De weg naar toekomstvastheid schreef ik al over de principes die organisaties veerkrachtig maken in een snel veranderend landschap. Dit project is voor mij het bewijs dat die principes ook in de praktijk werken — zelfs als je hem alleen begint, stap voor stap, met vallen en opstaan.

Wat dit betekent voor jouw organisatie

Ik bouw dit platform niet voor mezelf. Ik bouw het als demonstratie, als blauwdruk, als gespreksonderwerp.

Voor (inhurende) managers: wat ik je wil laten zien, is dat de keuze voor vendor-onafhankelijkheid niet betekent dat je meer moet bouwen of meer risico loopt. Het betekent dat je bewust ontwerpt. Dat je de spelregels vastlegt vóórdat je bouwt, niet erna. Dat je teams kunt loslaten omdat de vangrails er zijn. Een platform dat teams maximale autonomie geeft binnen duidelijke kaders — dat is geen technisch ideaal, dat is een organisatorische keuze.

Voor DevOps-teams en platform engineers: een landing platform zoals dit geeft je vrijheid. Vrijheid om te experimenteren, te itereren, te migreren — zonder elke keer opnieuw de basisveiligheid te moeten doordenken. De policies reizen mee. De principes reizen mee. Jij kunt je concentreren op wat je wil bouwen, niet op het bewaken van wat je al hebt. DORA-metrics geven je de taal om te laten zien dat de transformatie werkt: deployment frequency, lead time, change failure rate — niet als managementrapportage, maar als spiegel voor het team zelf.

Voor de organisatie als geheel: digitale soevereiniteit is geen technisch project. Het is een strategische keuze. De techniek is het bewijs dat de keuze haalbaar is. De EU Data Act, NIS2, en de bredere verschuiving naar Europese digitale autonomie geven die keuze ook een juridische en politieke urgentie. Contractuele garanties van een cloudprovider beschermen je niet als de feitelijke technische afhankelijkheid te diep zit. Dat heeft de praktijk al aangetoond — en ik schreef er uitgebreid over in De weg naar digitale vrijheid.

Wat ik heb geleerd over mezelf

Ik ben geen pure theoreticus. Ik leer door te doen, en ik leer het meest van de momenten waarop iets niet werkt zoals verwacht.

Dit project heeft me dingen geleerd over cloudarchitectuur, over open source tooling, over het schrijven van policies in een declaratieve taal. Maar de diepste les is simpeler: goed ontwerp is eerlijk ontwerp. Eerlijk over wat je weet, eerlijk over wat je niet weet, en eerlijk over de keuzes die je maakt en waarom.

Elk struikelblok in dit project is gedocumenteerd. Niet verstopt, maar expliciet opgeschreven. Zodat de volgende engineer — of ikzelf over zes maanden — begrijpt waarom iets zo gemaakt is, en niet anders.

Dat is de cultuur die ik wil overbrengen aan de teams waarmee ik werk. Niet de architect die alles weet en het antwoord klaar heeft. Maar de architect die zichtbaar is in de uitvoering, die moeilijke vragen stelt die niemand anders durft te stellen, en die kennis deelt — niet als bewijs van expertise, maar als bijdrage aan het team.

Wat nu?

Het platform is een levend leerproject. Op mijn To Do staat:

• Observability: elke policy-beslissing wordt gelogd. Die logs wil ik zichtbaar maken in een dashboard — zodat je niet alleen kunt zien dat iets geblokkeerd werd, maar ook wanneer, hoe vaak, en door wie. Grafana en Prometheus liggen al klaar als fundament.
• Een derde cloud: hetzelfde platform, dezelfde policies, een derde provider. Dat is het ultieme bewijs van vendor-neutraliteit — en de ultieme test van de architectuur.
• Identiteits- en toegangsbeheer: Keycloak staat al klaar als uitgeschakelde component. Activeren kost één configuratiewijziging. Cloud-agnostisch identiteitsbeheer is in mijn ogen de meest onderschatte bouwsteen van digitale soevereiniteit: als je identiteitsplatform bij dezelfde provider draait als je applicaties, ben je bij een blokkade ook je toegang tot de hersteltools kwijt. Hoe dat werkt in de praktijk beschreef ik al in het failover-artikel.

Maar belangrijker dan de techniek: ik wil het gesprek voeren. Met jou, met jouw team, met jouw organisatie. Over wat digitale soevereiniteit voor jullie betekent, en hoe een platform als dit jullie daarbij kan helpen.

Tot slot

Ik begon dit project met een vraag: kan ik mijn relaties laten zien hoe ze de regie over hun eigen infrastructuur kunnen houden?

Het antwoord is ja. Niet makkelijk, niet zonder fouten, maar ja.

En dat is precies de boodschap die ik wil meegeven: soevereiniteit is niet iets wat je koopt. Het is iets wat je bouwt, bewust, stap voor stap.

Ik help je daar graag bij.

Bertrand de Neve

Dit artikel is het derde deel in een reeks over digitale soevereiniteit. Eerder verschenen: De weg naar digitale vrijheid · Van idee naar soevereine cloud · Van kwetsbaarheid naar continuïteit · Missie digitale soevereiniteit · De weg naar toekomstvastheid

Disclaimer: Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. De beschreven architectuur weerspiegelt ervaringen opgedaan tijdens een specifiek leertraject. De genoemde cloudproviders zijn willekeurig gekozen als illustratie van het principe; de auteur is niet gelieerd aan welke provider dan ook. Prijsindicaties zijn indicatief en gebaseerd op tarieven ten tijde van publicatie. Voor toepassing in uw specifieke situatie wordt professioneel advies aanbevolen. Dit artikel is tot stand gekomen met assistentie van een AI-systeem. De technische implementatie, inhoudelijke keuzes, conclusies en eindredactie zijn volledig van de auteur.

Photo by Christian Lue on Unsplash