5 redenen om Infrastructure as Code (IaC) te gebruiken

Wat is Infrastructure as Code?

IaC is het starten en beheren van IT-infrastructuur met code. Er zijn technieken die zich specifiek toeleggen op één aanbieder, zoals Cloudformation voor Amazon Web Services (AWS), Deployment Manager voor Google Cloud Platform (GCP) of Bicep voor Microsoft Azure. Een veelgebruikte techniek is Terraform die API’s aanbiedt voor alle grote cloudpartijen.

Wil je meer weten over de betekenis van IaC? Lees dit artikel van RedHat

Omdat wij bij Digital Power specialisten zijn op het gebied van data, is de inhoud van dit artikel van toepassing voor het bouwen van een dataplatform. Bijvoorbeeld een datawarehouse, of een machine learning toepassing van een bestaande applicatie.

IaC kan zowel binnen on-premises als cloud omgevingen gebruikt worden. Als specialisten op het gebied van Azure, GCP en AWS gaan wij uit van een cloud omgeving voor de context van dit artikel.

Overweeg je IaC te gebruiken? Dit zijn de 5 voordelen

1: Je omgevingen zijn makkelijk te dupliceren

Dit punt is om twee redenen zeer relevant: ten eerste kun je IaC gebruiken om je OTAP (ontwikkel, test, acceptatie en productie) omgevingen van elkaar te scheiden. Je gebruikt hetzelfde template voor alle omgevingen en gebruikt variabelen voor de factoren die je anders wil hebben. Voor je testomgeving stel je bijvoorbeeld een kleinere database in dan voor je productie-omgeving.

Een andere toepassing van dit punt is het scheiden van verschillende ontwikkelomgevingen. Wanneer je met meerdere ontwikkelaars een platform opbouwt, kan elke ontwikkelaar zijn of haar eigen platform opstarten. Zo zit je elkaar niet in de weg. Aan het einde van elke dag kan elk dev-platform weer worden afgesloten.

2: Je hebt beter inzicht in platformstatus en heldere documentatie

In IaC staan niet alleen de infrastructuur en software zelf benoemd, maar ook de configuratie. Denk hierbij aan user access en firewalls. Wil je weten welk ip-adres toegankelijk is binnen het subnet van je Business Intelligence team? Ook een analist of product owner kan dit terugvinden in de code!

3: Code checkouts en versiebeheer op de infrastructuur

Dit is een punt voor de ontwikkelaars. Omdat de configuratie van je infrastructuur staat opgeslagen in een Git repository kan je eenvoudig samenwerken en alle code laten reviewen door je teamgenoten. Dit is ook goed voor de business stakeholders: zo worden er foutjes uit de code gehaald. Dankzij het versiebeheer is het platform ook goed auditeerbaar, wat steeds vaker als randvoorwaarde voor een nieuw platform wordt meegenomen.

4: Je bespaart kosten

Werken met IaC zorgt ervoor dat alles wat live staat, ook in de code aanwezig is. Dit maakt het minder waarschijnlijk dat er diensten blijven draaien die niet meer gebruikt worden. Omdat je Infrastructure as Code staat opgeslagen in Git worden onnodige diensten er snel uitgehaald door ontwikkelaars bij code checkouts. Ook wordt IaC vaak gebruikt in de cloud, waarmee het eenvoudig op- en afschalen is.

IaC dwingt je om transparant te werken, wat ook het risico op shadow IT (niet zichtbare aanpassingen en configuratie) aanzienlijk verlaagt.

5: Je kunt snel naar productie

Infrastructure as Code geïntegreerd in CI/CD sluit goed aan bij de DevOps werkwijze. Omdat je infrastructuur volledig geautomatiseerd is ingeregeld, wordt het eenvoudig om een nieuwe module te realiseren in productie. Bovendien kun je snel terugschakelen naar een vorige versie met behulp van zowel de IaC techniek als het versiebeheer van Git.

Nadelen Infrastructure as Code

Zijn er dan geen nadelen voor het gebruik van IaC? Die zijn er zeker wel, al zijn ze relatief klein. De nadelen van IaC op een rijtje:

• De kennis van developers is niet altijd toereikend. Het is nog steeds een relatief nieuwe techniek waar niet iedereen bekend mee is. Ook stappen Data Engineers en Applicatieontwikkelaars hiermee in de rol van Infra Engineers. Dit vraagt om flexibiliteit in de werkwijze van IT-afdelingen.
• Om Infrastructure as Code goed te kunnen gebruiken moet ook een CI/CD pipeline worden ingericht. De initiële investering voor je project wordt hiermee groter.
• Sommige kleine veranderingen kunnen juist langer duren. Wanneer je bijvoorbeeld een Ontwikkelaar extra rechten wilt geven op je productieplatform, moet je dit eerst door de rest van je OTAP-straat halen. Hiermee is het overigens wel meteen goed getest en gedocumenteerd.
• Je codebase groeit in omvang. Je zult nu ook je IaC moeten gaan debuggen, en de praktijk leert dat niet alle documentatie van de grote cloud providers altijd op orde is.

Voor welk project gebruik je IaC?

Overweeg je IaC te gebruiken? De voordelen wegen doorgaans op tegen de nadelen. De voordelen zijn alleen niet altijd van toepassing. Leg de voorwaarden van jouw project daarom naast de voor- en nadelen uit dit artikel en trek je eigen conclusies.

Weet ook dat IaC vooral goed werkt voor nieuwe platformen. Ben je eenmaal gestart, dan is het een slecht idee om veranderingen buiten de code door te voeren. Je committeert je dus ook voor de toekomst.

Benieuwd hoe IaC toegepast kan worden in de praktijk? Lees hier hoe we The Neuron hielpen het aantal verwachte impressies voor digitale advertenties op billboards op een schaalbare en efficiënte manier te voorspellen.

Onze Data Engineers denken graag met je mee over de inzet van Infrastructure as Code voor jouw project. Neem contact met ons op voor advies of solliciteer naar een plek in ons Data Engineering team.

1x per maand data insights, praktijkcases en een kijkje achter de schermen ontvangen?

Meld je aan voor onze maillijst en blijf 'up to data':