Hoe: een aantal pragmatische tips en suggesties

Eerst de fundering, dan pas de verbouwing: de secure landing zone

Voordat je ook maar één applicatie richting een soevereine (cloud)omgeving beweegt, moet er iets anders staan: een veilige, gestandaardiseerde landing zone. Zie het als de voorbereide fundering waarop je gaat bouwen. Beleid en richtlijnen, netwerkarchitectuur, centrale logging en identity- en access management moeten op orde zijn vóórdat de eerste workload verhuist.

Sla je deze stap over, dan wordt elke migratie een eigen geïsoleerd projectje met eigen, vaak afwijkende beveiligingsregels. Dat levert geen soevereiniteit op, maar onbeheersbaar maatwerk — precies het tegenovergestelde van waar je naartoe wilt.

Twee bouwstenen zijn hierbij onmisbaar:

Policy as Code. In plaats van beveiligingsrichtlijnen als een lijvig PDF-document bij de security officer te laten liggen, vertaal je ze naar uitvoerbare regels in je pipeline. Met een tool als Open Policy Agent (OPA) kun je bijvoorbeeld afdwingen dat opslag alleen binnen de EU mag landen, of dat een storage-bucket nooit publiek toegankelijk mag worden gemaakt:

package cloud.policy

deny[msg] {
  input.resource_type == "storage_bucket"
  input.public_access == true
  msg := "Publieke toegang tot storage is niet toegestaan"
}

deny[msg] {
  input.resource_type == "storage_bucket"
  input.region != "eu-west-1"
  msg := "Opslag moet binnen een EU-regio landen"
}

Schendt een wijziging deze regel, dan breekt de pipeline automatisch af — nog vóórdat er iets live staat. Dat is "shift left": beveiliging verplaatst van een handmatige controle achteraf naar een ingebakken voorwaarde vooraf.

CI/CD als ruggengraat. Zonder gedegen orchestratie en versiebeheer van je pipelines wordt elke wijziging weer een individuele actie met individueel risico. Juist in een transformatietraject, waarin oud en nieuw langere tijd naast elkaar bestaan, is een voorspelbare, geautomatiseerde manier om te bouwen, testen en uitrollen geen luxe maar een keiharde randvoorwaarde. Zonder die basis wordt het al snel chaos, en verlies je precies de grip die je met soevereiniteit juist probeerde terug te winnen.

IAM: wie mag wat, waterdicht geregeld

Een landing zone staat of valt met identity- en access management. Wie mag bij welke systemen, met welke rechten, en hoe wordt dat aantoonbaar gemaakt? In mijn eigen lab gebruik ik hiervoor Keycloak als centrale identity-portal: één plek waar authenticatie en autorisatie voor meerdere applicaties samenkomen, in plaats van dat elk systeem zijn eigen gebruikersbeheer bijhoudt.

Voor een transformatietraject is dit niet alleen een technisch vraagstuk. Elke nieuwe service die je uit een monoliet trekt, moet vanaf dag één aansluiten op hetzelfde IAM-fundament. Doe je dat niet, dan bouw je bij elke stap een nieuw eilandje met eigen inlogregels — en daarmee juist meer risico, niet minder.

OpenTofu in plaats van Terraform

Een detail dat in gesprekken over infrastructure as code nog weleens onderbelicht blijft, maar in het licht van soevereiniteit relevant is: Terraform is sinds de licentiewijziging niet meer open source. Voor organisaties die bewust sturen op "open, tenzij" — en die willen voorkomen dat ze afhankelijk worden van één commerciële partij met een licentiemodel dat kan veranderen — is dat een reden om over te stappen op OpenTofu, de open-source fork.

Functioneel verandert er weinig; de manier van werken met infrastructure as code blijft grotendeels hetzelfde:

resource "keycloak_realm" "sovereign_realm" {
  realm   = "deneveit-lab"
  enabled = true
}

Wat wél verandert, is de zekerheid dat je fundament zelf ook soeverein is: geen verrassingen in licentievoorwaarden, en volledige transparantie over wat de tooling doet. Voor mij was dit ook in mijn eigen lab-omgeving reden genoeg om Terraform volledig uit te faseren en direct met OpenTofu verder te gaan. De overstap was vlot, redelijk eenvoudig en zonder downtime.

Het Strangler Fig-patroon: verbouwen terwijl de winkel openblijft

Dit is misschien wel het meest tastbare concept als het gaat om moderniseren zonder stilstand. De naam komt uit de natuur: een wurgvijg nestelt zich in de takken van een bestaande boom en laat zijn wortels langzaam naar beneden groeien. Uiteindelijk omhult hij de hele boom, die afsterft, terwijl de wurgvijg zelfstandig blijft staan.

In software werkt dit vergelijkbaar. Je plaatst een API gateway vóór je legacy-applicatie — een soort slimme voordeur. In het begin stuurt die voordeur al het verkeer nog gewoon door naar het oude systeem; er verandert functioneel niets. Vervolgens bouw je één afgebakend stuk functionaliteit opnieuw op als moderne service, en pas je de routering in de gateway aan zodat alleen dát specifieke verkeer naar de nieuwe service gaat. De rest blijft naar het oude systeem gaan. Stukje bij beetje wordt de oude kern zo uitgehold, tot je hem uiteindelijk veilig kunt uitschakelen.

De valkuil zit in de data: die nieuwe service moet vaak nog steeds gegevens ophalen uit de oude, complexe database. Koppel je daar direct op aan, dan bouw je in feite een nieuw jasje om hetzelfde oude probleem — een gedistribueerde monoliet in plaats van een moderne architectuur. Dat is precies waarom dit patroon zelden op zichzelf staat, en waarom een heldere scheiding tussen oude en nieuwe datastructuren (bijvoorbeeld via een expand-contract-aanpak bij databasewijzigingen) net zo belangrijk is als de gateway zelf.

Photo by Armand Mckenzie on Unsplash

Tip: een ander super concreet voorbeeld zie artikel: Hoe je een verouderde ketenkoppeling moderniseert zonder de keten stil te leggen

ACID versus robuustheid: wat verlies je, wat win je?

Een monolitische applicatie met één relationele database heeft vaak iets moois en heel belangrijk: ACID-garanties. Een transactie lukt volledig, of hij faalt volledig — er is geen grijze tussenzone. Zodra je functionaliteit opknipt in microservices, met elk hun eigen database, verlies je dat comfort. Een aanvraag kan nu over meerdere services lopen, en als er eentje halverwege faalt, is er geen enkele "rollback-knop" meer die alles in één keer terugdraait.

Dat betekent niet dat je zonder garanties komt te zitten — het betekent dat je robuustheid op een andere manier moet organiseren. In plaats van één grote transactie werk je met een keten van kleine, lokale transacties, waarbij elke stap weet hoe hij zichzelf kan terugdraaien als een latere stap faalt. Dat vraagt om bewust ontwerp: welke processen zijn zo kritisch en auditplichtig dat je expliciete regie nodig hebt over de volgorde van stappen, en welke processen kunnen prima losser, asynchroon, gebeurtenis-gedreven verlopen?

Dat onderscheid is niet alleen technisch, maar ook een compliance-vraagstuk: kun je op elk moment reconstrueren wat er met een aanvraag of transactie is gebeurd? Zelfherstellend vermogen — een service die automatisch herstelt van een tijdelijke storing, retries die netjes worden afgehandeld, duidelijke foutmeldingen die een keten niet laten "hangen" — is in een gedistribueerde architectuur geen bijzaak, maar een kernonderdeel van het ontwerp zelf.

Wat

De rode draad door al deze onderwerpen is steeds hetzelfde: transformatie naar soevereiniteit is geen big-bang-project. Het is een reeks bewuste, kleine stappen, met op elk moment een werkende winkel.

• Zonder een secure landing zone met policy as code en solide CI/CD-proces wordt elke stap een risico in plaats van vooruitgang.
• IAM, centraal en waterdicht geregeld, is de basis waarop elke nieuwe service moet aansluiten.
• De keuze voor OpenTofu boven Terraform is een klein voorbeeld van een principe dat je op veel plekken terugziet: soevereiniteit begint bij de tooling die je zelf gebruikt.
• Het Strangler Fig-patroon geeft je een manier om legacy stap voor stap uit te faseren, zonder de dienstverlening te onderbreken.
• En het loslaten van ACID-zekerheden vraagt om nieuwe manieren van robuustheid en zelfherstel, expliciet ontworpen in plaats van impliciet aangenomen.

Dit zijn precies de vraagstukken waar ik dagelijks mee bezig ben — niet alleen in de theorie, maar beproefd in mijn eigen lab-omgeving, van SSO-koppelingen tot infrastructure as code. Herken je deze uitdagingen in je eigen organisatie, of loop je vast op een specifiek onderdeel van je transformatie? Neem gerust contact met me op. Ik denk graag mee.

Bertrand de Neve

Contactformulier >.

 

Uitgelichte titel foto: Tropisch regenwoud in Oeganda, gemaakt door mij in juni 2026.

Disclaimer: dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden en bevat mijn persoonlijke ervaringen en inzichten rond soevereine architectuur, opgedaan in de praktijk en in mijn eigen lab-omgeving. De genoemde tools en patronen — waaronder Open Policy Agent, Keycloak, OpenTofu, NextCloud en het Strangler Fig-patroon — dienen ter illustratie van de onderliggende principes en zijn geen exclusieve aanbevelingen; ik ben niet gelieerd aan deze partijen, en er bestaan vergelijkbare alternatieven die afhankelijk van context beter kunnen passen. Dit artikel is tot stand gekomen met assistentie van een AI-systeem; de technische implementatie, inhoudelijke keuzes, conclusies en eindredactie zijn volledig door mij gedaan.