De rol van IaC binnen data platforms
Infrastructure as Code draait om het beheren van infrastructuur zoals je ook software ontwikkelt: met versiebeheer, code reviews, geautomatiseerde deployments en reproduceerbare configuraties. Hierdoor worden omgevingen consistenter, wijzigingen beter beheersbaar en deployments betrouwbaarder.
Voor data platforms is dit essentieel. Een wijziging in netwerkconfiguratie, toegangsrechten of storage kan grote gevolgen hebben voor de beschikbaarheid en veiligheid van data. Door infrastructuur als code te beheren, verklein je de kans op configuratiefouten en zorg je ervoor dat ontwikkel-, test- en productieomgevingen identiek zijn ingericht.
Bij Blenddata zien we IaC dan ook niet als een handige automatisering, maar als een fundamenteel onderdeel van een volwassen data platform. Stabiele infrastructuur vormt immers de basis voor stabiele datastromen.
Terraform of Bicep: wat zijn de verschillen?
Terraform en Bicep hebben hetzelfde doel: infrastructuur automatisch uitrollen. Het verschil zit vooral in de manier waarop ze wijzigingen bepalen en beheren.
Terraform is een Infrastructure as Code-tool van HashiCorp die honderden providers ondersteunt. Naast Azure kun je er ook Databricks, Kubernetes, GitHub, AWS, Google Cloud en vele andere platformen mee beheren. Daardoor kun je de volledige infrastructuur vanuit één centrale IaC-oplossing beheren.
Bicep is Microsofts Infrastructure as Code-taal en volledig gericht op Azure. Het is een vereenvoudigde laag boven Azure Resource Manager (ARM) en biedt daardoor een zeer nauwe integratie met Azure. Nieuwe Azure-functionaliteiten zijn hierdoor vaak direct beschikbaar.
Het grootste verschil zit echter niet in de syntax of de ondersteunde platformen, maar in de manier waarop beide oplossingen wijzigingen bepalen.
State management: het fundamentele verschil
Terraform werkt met een state file. Hierin wordt vastgelegd welke infrastructuur door Terraform wordt beheerd en in welke toestand deze zich bevindt. Bij iedere deployment vergelijkt Terraform drie zaken:
- de gewenste infrastructuur uit de code;
- de actuele infrastructuur;
- de opgeslagen state.
Op basis daarvan bepaalt Terraform exact welke wijzigingen nodig zijn. Voordat deze wijzigingen worden uitgevoerd, kun je met terraform plan eerst zien wat er gaat gebeuren.
Een plan kan bijvoorbeeld laten zien dat er drie nieuwe resources worden aangemaakt en er twee worden verwijderd. Pas nadat dit plan is gecontroleerd en goedgekeurd, worden de wijzigingen daadwerkelijk uitgevoerd met terraform apply.
Dit maakt deployments zeer voorspelbaar. Zeker in productieomgevingen is dat een groot voordeel, omdat wijzigingen vooraf inzichtelijk zijn en ongewenste aanpassingen kunnen worden voorkomen.
Daarnaast kan Terraform eenvoudiger detecteren wanneer infrastructuur buiten Terraform om is aangepast (drift). Omdat Terraform tijdens een terraform plan de gewenste configuratie, de actuele infrastructuur en de opgeslagen state met elkaar vergelijkt, worden onverwachte wijzigingen zichtbaar. Dit helpt om omgevingen consistent te houden en ongewenste afwijkingen tijdig te corrigeren.
Bicep werkt fundamenteel anders. Bicep gebruikt geen eigen statebestand. In plaats daarvan stuurt Bicep de gewenste configuratie naar Azure Resource Manager, dat vervolgens bepaalt welke resources moeten worden aangemaakt of bijgewerkt.
Daardoor hoef je geen statebestand te beheren, maar beschik je ook niet over dezelfde uitgebreide planningsfase als bij Terraform. Welke aanpak het beste past, hangt af van de gewenste balans tussen eenvoud en controle.
