Infrastructure-as-Code

Artikel uit SDN Magazine 145

Inleiding

Het is 2002, je bent programmeur. Na maanden zwoegen ben je eindelijk zover om dat stuk software uit te rollen naar productie. Je brandt een gecompileerde versie, inclusief een MSI installatiebestand en uitgebreide installatie documentatie op een CD waarop je met een marker hebt geschreven: “versie 1.0”. Je loopt langs bij de systeembeheer afdeling om de CD af te geven en bij het afgeven krijg je de terugkoppeling dat ze pas over een week tijd hebben om de software uit te rollen naar de server en alle werkstations. Na een week krijg je een telefoontje van systeembeheer met de boodschap dat ze niet genoeg capaciteit hebben op de server. Daarom hebben ze een nieuwe server besteld waarop een levertijd van ongeveer een maand zit! Enzovoort, enzovoort.

Fast-forward naar 2022, je bent software ontwikkelaar. Je hebt zojuist een nieuw stukje functionaliteit ontwikkeld. Alle testen slagen lokaal, je ‘commit’ de code en ‘pushed’ deze naar de Azure DevOps omgeving. Je gaat koffie halen en voordat je je eerste slok neemt, is de nieuwe functionaliteit uitgerold en wereldwijd beschikbaar voor de eindgebruiker.

We zijn van ver gekomen en in die 20 jaar is de gereedschapskist van de software ontwikkelaar steeds meer voorzien van indrukwekkende hulpmiddelen waarvan we 20 jaar geleden niet eens wisten dat het mogelijk zou zijn. In deze blog zoomen we graag in op één van deze hulpmiddelen en dat is Infrastructure-as-Code.

Definitie

Wat is Infrastructure-as-Code precies? In principe dekt de term al veel lading, maar een stukje extra definitie is nog wel benodigd:

 

Infrastructure-as-Code is het proces voor het opzetten en onderhouden van infrastructuur middels declaratieve of imperatieve code, op een geautomatiseerde manier in plaats van handmatig.

 

Vooral de termen ‘code’ en ‘geautomatiseerd’ zijn de sleutel in de definitie. In de code wordt exact gespecificeerd door de ontwikkelaar waaraan de infrastructuur moet voldoen (declaratief) of wordt geprogrammeerd welke stappen uitgevoerd moeten worden om de infrastructuur op te zetten (imperatief). Deze code wordt op een geautomatiseerde manier geïnterpreteerd en uitgevoerd, met als resultaat functionerende infrastructuur die toegespitst is op de vooraf gestelde requirements.

Aangezien de declaratieve or imperatieve code leesbare tekst is, is deze makkelijk op te slaan in een Sourcecode Repository, met alle gemakken daarvan zoals versiebeheer, de mogelijkheid om gemakkelijk samen te werken op dezelfde code en dat elke versie van je applicatie onlosmakelijk verbonden is met een versie van de infrastructuur.

Dit heeft deuren geopend om Infrastructure-as-Code te integreren met bestaande CI/CD (Continuous Integration/Continuous Deployment) processen.

 

 

Geschiedenis

In principe verklappen de twee inleidende verhaaltjes waar Infrastructure-as-Code vandaan komt. Het is onder andere ontstaan uit een behoefte om sneller feedback te krijgen, een snellere time-to-market te hebben en minder te hoeven bekommeren over de infrastructuur.

Verder hebben virtualisatie van computers en applicaties ook een grote rol gespeeld in de opkomst van Infrastructure-as-Code, vanwege het feit dat het opzetten van virtuele servers en/of applicaties zich heel goed laat automatiseren. Dat in tegenstelling van het onderhouden van fysieke hardware waar de software zonder virtualisatie op draait. Het fysiek uitbreiden van hardware is toch echt een handmatige klus.

De opkomst van Cloud Computing heeft Infrastructure-as-Code verder op de kaart gezet. Bij alle grote Cloud platforms speelt Infrastructure-as-Code een grote rol en is het dan ook goed geïmplementeerd.

De rol in DevOps

Infrastructure-as-Code speelt een belangrijke rol in een DevOps team wanneer er gebruik gemaakt wordt van virtuele hardware. Door deze code en/of definitie bestanden op te nemen in de Sourcecode Repository en in de CI/CD pipelines, wordt de feedback-loop kleiner gemaakt. Dit komt omdat de infrastructuur op een consistente en herhaalbare manier geautomatiseerd in wordt voorzien. Aangezien er geen handen aan te pas komen, maakt dit de tijdslijnen van idee tot implementatie veel korter. Hierdoor krijg je dus veel snellere terugkoppeling of het idee ook daadwerkelijk een goed idee blijkt te zijn.

Declaratief versus imperatief

De code die gebruikt wordt om in de infrastructuur te voorzien heb je in twee smaken, declaratief en imperatief. Imperatief is als een recept voor het maken van bijvoorbeeld een chocolade cake; het bevat de uitgebreide instructies om de cake te maken. Declaratief is als een boodschappenlijstje waarop staat: “Koop 500gr Chocolade Cake”.

Je zou kunnen zeggen dat imperatieve code de complexiteit van het opzetten van de infrastructuur (de chocolade cake) deels bij de ontwikkelaar legt, waarbij de complexiteit bij declaratieve code wordt verlegd naar de tooling die gebruikt wordt om de code te interpreteren en uit te voeren.

Imperatief geeft meer controle over hoe in de infrastructuur wordt voorzien, waarbij je bij declaratief weinig tot geen invloed hebt over hoe dit gedaan wordt; je hoeft slechts aan te geven wat je wilt hebben en hoe dit gedaan wordt, is onbelangrijk voor de ontwikkelaar.

Tools

De code die de infrastructuur definieert is niet het enige wat nodig is om Infrastructure-as-Code mogelijk te maken. Er zijn ook tools nodig die deze code kunnen lezen en uitvoeren. Gelukkig zijn er genoeg tools beschikbaar die dit mogelijk maken. Hieronder staat een (niet definitieve) lijst met populaire tools, inclusief een code voorbeeld.

 

 

ARM

ARM staat voor Azure Resource Manager en is het mechanisme van Microsoft’s Cloud platform voor het automatisch opzetten (maar ook afbreken) van resources in Azure. Waar ARM de tool is, zijn ARM templates de code waarin gedefinieerd wordt hoe de infrastructuur er uit moet komen te zien. ARM templates zijn declaratief van aard, dus geven de gewenste staat van de infrastructuur aan.

Figuur 1: ARM Template voorbeeld

Het grote voordeel van ARM templates is dat elke Azure resource tot in elk kleinste detail gespecificeerd kan worden. Dit is overigens ook tegelijkertijd het grootste nadeel; ARM templates zijn vaak langdradig en moeilijk te lezen. Om dit nadeel te overwinnen heeft Microsoft Bicep geïntroduceerd.

Meer informatie over ARM is hier te vinden: https://tinyurl.com/ycxfjc2w.

 

 

Bicep

Bicep is een feitelijk een vertaler tussen de Bicep syntax naar ARM templates en heeft als doel om de Infastructure-as-Code veel minder langdradig en dus beter leesbaar te maken. In tegenstelling tot ARM templates is het ook mogelijk in Bicep om control-of-flow structuren zoals if- en for-statements te gebruiken. De Bicep syntax is declaratief van aard.

Wanneer een Bicep file uitgerold word, wordt het eerst vertaald naar een ARM template om deze vervolgens door de ARM uit te laten voeren.x

Figuur 2: Bicep syntax voorbeeld

Meer information over Bicep is hier te vinden: https://tinyurl.com/3vwvcczt.

Pulumi

Pulumi is een vreemde eend in de bijt als het gaat om tools voor Infrastructure-as-Code. Het heeft geen eigen syntax definitie, maar maakt juist gebruik van bestaande programmeertalen. Dit heeft als voordeel dat ontwikkelaars hun bestaande kennis van hun favoriete programmeertaal kunnen hergebruiken om in de infrastructuur te voorzien.

Pulumi gebruikt eigenlijk een mix van declaratieve en imperatieve Infrastructure-as-Code, juist vanwege het feit dat het bestaande programmeertalen gebruikt. Hierdoor kun je je eigen logica implementeren in de code, maar je kunt ook gewoon definiëren hoe in de infrastructuur voorzien moet worden.

Figuur 3: JavaScript code dat gebruikt maakt van de Pulumi API

Meer informatie over Pulumi is te vinden op: https://tinyurl.com/5662f24n.

Tot slot

Infrastructure-as-Code is een waardevolle tool in de gereedschapskist van een software ontwikkelaar. Het brengt de werelden van het ontwikkelen van software en het operationele aspect van het uitvoeren van software dichter bij elkaar.

 

Bio

Patrick Vroegh is Technical Lead Consultant voor Bergler Software Solutions. Hij helpt organisaties bij het toekomstbestendig maken van hun software en ontwikkelprocessen.