Infrastructure as Code in 2026: Drift, Policy en de Keuze tussen Terraform en OpenTofu

De meeste organisaties zeggen inmiddels dat ze "aan Infrastructure as Code doen", en de meeste vertellen daarmee maar de halve waarheid. Firefly's State of Infrastructure as Code 2025 stelde vast dat hoewel 72% van de organisaties IaC gebruikt, slechts ongeveer een derde meer dan 75% van hun infrastructuur in code heeft vastgelegd (Firefly, 2025). Het gat tussen die twee cijfers is waar storingen, mislukte audits en onverwachte cloudrekeningen ontstaan. Voor een engineering director bij een gereguleerd Benelux-team is de interessante vraag niet langer "moeten we IaC invoeren", maar "wat vereist volwassen IaC werkelijk, en welke tool standaardiseren we nu het ecosysteem is gesplitst". Dit artikel beantwoordt de vragen die teams daadwerkelijk stellen.

Interieur van een datacenter met meerdere rijen hoge metalen serverracks - de fysieke infrastructuur die Infrastructure as Code declaratief provisioneert en beheert.

Wat is Infrastructure as Code eigenlijk?

Infrastructure as Code betekent dat je je servers, netwerken, databases en cloudresources definieert in machineleesbare definitiebestanden die je versiebeheert, reviewt en via automatisering toepast - in plaats van door een console te klikken. Het onderscheid dat in de praktijk telt, is declaratief versus imperatief. Een imperatieve aanpak scripst de stappen ("maak deze VPC, dan dit subnet, koppel dan deze gateway"). Een declaratieve aanpak beschrijft de gewenste eindstaat en laat de tool het verschil berekenen tussen wat bestaat en wat je hebt gevraagd. Terraform, OpenTofu, AWS CloudFormation en Pulumi zijn allemaal primair declaratief, en dat is precies waarom ze domineren: de tool bezit de reconciliatielogica, niet jouw runbook.

Dat declaratieve model is de hele kern. Het levert je een enkele bron van waarheid die tegelijk als documentatie dient, een pull-requestworkflow voor infrastructuurwijzigingen, en een reproduceerbare manier om identieke staging- en productieomgevingen op te zetten. Het is ook wat het volgende probleem - drift - zowel detecteerbaar als oplosbaar maakt, wat het simpelweg niet is wanneer infrastructuur in iemands geheugen en een reeks handmatige consoleclicks leeft.

Waarom blijft configuratiedrift productie breken?

Configuratiedrift is de afwijking tussen de staat die je code declareert en de staat die werkelijk in de cloud draait. Het ontstaat om alledaagse redenen: een engineer maakt tijdens een incident een spoedwijziging in de console, een auto-scaling group herschrijft een waarde, een managed service werkt een default bij, of twee teams bewerken overlappende resources. Elke afzonderlijke wijziging is klein. Het cumulatieve effect is een omgeving die je IaC niet langer beschrijft - zodat de volgende `apply` ofwel een handmatig aangebrachte fix terugdraait, ofwel ronduit faalt.

Drift is juist gevaarlijk omdat het onzichtbaar is totdat je handelt op verouderde aannames. De verdediging is continue driftdetectie: een geplande taak die de gedeclareerde staat vergelijkt met de live staat en elke afwijking signaleert, in plaats van die te ontdekken tijdens een deploy onder hoge druk. Hier bijt ook de statistiek dat "slechts een derde het merendeel van hun omgeving in code heeft vastgelegd". Als twee derde van je infrastructuur handmatig is aangemaakt en nooit in code is geimporteerd, heeft driftdetectie niets om mee te vergelijken, en het handmatig provisioneren dat Firefly's rapport aanwijst - ruwweg 30% van de teams deployt Terraform nog handmatig in plaats van via een pipeline - is precies het gedrag dat drift sneller herintroduceert dan je kunt herstellen (Firefly, 2025). De oplossing is weinig glamoureus: importeer bestaande resources in code, leid elke wijziging via CI/CD, en behandel een driftmelding als een defect, niet als een curiositeit.

Wat levert policy as code een gereguleerd team werkelijk op?

Voor een gereguleerd team is het sterkste argument voor IaC niet snelheid - het is governance. Omdat infrastructuur nu code in een pull request is, kun je er policy as code aan koppelen: machinaal afgedwongen regels die in de pipeline draaien voordat er iets in productie belandt. Open Policy Agent (OPA) en HashiCorp Sentinel zijn de gangbare engines. Een policy kan elke storage bucket zonder encryptie at rest weigeren, een security group blokkeren die poort 22 naar het internet openzet, resources weigeren die buiten EU-regio's worden uitgerold, of een cost-centre tag op alles verplichten. De regel wordt automatisch geevalueerd bij elke wijziging, en het resultaat wordt vastgelegd.

Dat laatste punt is waar auditors om geven. In plaats van "we hebben een beleid dat zegt dat encryptie verplicht is", kun je aantonen "deze control is in code afgedwongen, elke voorgestelde wijziging wordt eraan getoetst, en hier is de onveranderlijke geschiedenis van elke pass en fail". Het verandert een geschreven beleid in een uitgevoerde control met een audittrail - het verschil tussen een compliance-ambitie en een compliance-feit. Aangezien 45% van de respondenten in Firefly's onderzoek beveiligings- en compliancerisico aanwees als een belangrijke IaC-uitdaging, is policy as code het onderdeel van de discipline dat dat risico omzet van een last in een sterkte.

Terraform versus OpenTofu: waarop moet je standaardiseren?

Dit is de vraag die is veranderd sinds de meeste teams hun IaC-strategie voor het laatst herzagen, en hij verdient een helder antwoord. In 2023 herlicentieerde HashiCorp Terraform van een open-sourcelicentie naar de Business Source License. De community reageerde door de laatste open-sourceversie te forken tot OpenTofu, nu ondergebracht bij de Linux Foundation. OpenTofu bereikte in januari 2024 een stabiele release en is snel volwassen geworden: begin 2025 rapporteerde het meer dan 300% jaar-op-jaar groei in registrygebruik en een verdrievoudiging van het aantal contributors tot meer dan 160, terwijl het functies leverde waar Terraform-gebruikers jaren om hadden gevraagd - met name native end-to-end state-encryptie (InfoWorld, 2025).

Het bedrijfsplaatje verschoof eveneens: IBM rondde op 27 februari 2025 zijn overname van HashiCorp ter waarde van 6,4 miljard dollar af, waarmee Terraform werd opgenomen in een grotere hybride-cloudportefeuille (IBM, 2025). Terraform blijft met grote voorsprong de gevestigde keuze - het werd gebruikt door 17,8% van alle ontwikkelaars in de Stack Overflow Developer Survey 2025, ruim voor elke andere specifieke IaC-tool (Stack Overflow, 2025) - dus dit is geen verhaal waarin de ene tool de andere vervangt.

De pragmatische beslisregel: de twee zijn op HCL-niveau nog grotendeels uitwisselbaar, dus de keuze hangt af van je randvoorwaarden, niet van syntax. Als je al HCP Terraform draait of afhankelijk bent van Sentinel en enterprise-ondersteuning, is blijven redelijk en laag-risico. Als je greenfield begint, de BSL en elke toekomstige licentieverrassing wilt vermijden, of specifiek waarde hecht aan functies als native state-encryptie voor een DevSecOps-houding, is OpenTofu nu een geloofwaardige default in plaats van een gok. Het enige wat je niet moet doen, is de fork als irrelevant behandelen: kies bewust, documenteer waarom, en voorkom dat je afdrijft naar een gemengde omgeving waarin de helft van je modules de ene tool veronderstelt en de helft de andere.

Is Infrastructure as Code de moeite waard, en hoe ziet "goed" eruit?

De data beantwoordt de vraag of het de moeite waard is door wat ze weglaat: als 72% van de organisaties IaC gebruikt en 80% multi-cloudomgevingen draait, is IaC opgehouden een concurrentievoordeel te zijn en table stakes geworden (Firefly, 2025). De teams die voorlopen zijn niet degene die "Terraform hebben" - het zijn degene die het dekkingsgat hebben gedicht. Volwassen IaC ziet er concreet zo uit: vrijwel alle infrastructuur is in code vastgelegd en onder versiebeheer; elke wijziging loopt via een pull request en een pipeline, nooit via de console; driftdetectie draait continu en een afwijking wordt als een bug behandeld; policy as code dwingt beveiligings-, residentie- en kostenregels automatisch af met een vastgelegde audittrail; en de keuze voor Terraform of OpenTofu is een bewuste, gedocumenteerde standaard in plaats van een toevalligheid van wie de eerste module opzette.

Niets daarvan is exotisch. Het is het verschil tussen infrastructuur waarover je kunt redeneren, die je aan een auditor kunt aantonen en na een ramp kunt herbouwen, en infrastructuur die nu eenmaal toevallig vandaag draait. Voor grootschalige teams onder regelgeving is dat verschil het volledige rendement op de investering.