Wat is Infrastructure as Code?

Als we terugkijken in tijd, dan zagen we dezelfde vragen ontstaan bij mensen die werkten in infrastructuur (operatie) en software ontwikkeling. Door dit apart te benaderen was het moeilijk voor een software team om een planning af te geven omdat de werkzaamheden buiten het team lagen. Ook voor het infrastructuur team (ook wel het huidige Ops) was het lastig dat de infrastructuur kennis niet in het software team zat. Veel bedrijven hebben dit ervaren en daardoor zagen we in de loop van te tijd de term DevOps ontstaan. Een integratie van infrastructuur kennis en development kennis.

Nu zien we de grens tussen operationeel (infrastructuur) en software ontwikkeling verder vervagen. Infrastructuur wordt namelijk programmeerbaar met code: Infrastructure as Code. Dat betekent een nieuw niveau van het uitrollen van software, in minder tijd, met minder fouten en een stuk schaalbaarder.

Wat is Infrastructure as Code?

Als software bedrijf ben je afhankelijk van IT-infrastructuur en de software zal op hardware moeten draaien. Software wordt gemaakt met code. Hardware draait tegenwoordig veelal in de cloud. Dat is vaak zelfs virtueel. Dit opent deuren, want de infrastructuur wordt zo programmeerbaar. Dat wordt een hele belangrijke manier van werken om diverse redenen die we in dit artikel toelichten.

Infrastructure as Code (IaC) of programmeerbare infrastructuur betekent het definiëren en beheren van infrastructuur door middel van code. Zo'n infrastructuur wordt beschreven als objecten met eigenschappen. Vaak worden deze objecten omschreven in YAML, XML of JSON, maar vaak is er ook ondersteuning om dit in je favoriete programmeertaal te doen als Kotlin, Python etc.

De objecten worden vervolgens tegen een omgeving aangehouden en de state wordt dan gesynchroniseerd. Op deze manier worden IT componenten aangemaakt, ge-update of verwijderd. Je programmeert dus wat je wilt en synchroniseert dat naar de omgeving, bijvoorbeeld AWS, Google Cloud of Microsoft Azure.

In dit artikel verstaan wij onder infrastructuur alle hardware. Dat wil zeggen, servers, netwerk configuraties, permissies en alles wat erbij komt kijken om je applicatie uit te rollen in cloud of on-premise.

Laten we een voorbeeld geven:
Stel je wil een S3 Bucket met bepaalde permissies waarborgen in AWS cloud dan zijn er verschillende manieren om dit te realiseren in IaC. In AWS kun je hiervoor Cloudformation gebruiken, dit is een IaC provisioning service. AWS heeft hier frameworks bovenop gebouwd om het eenvoudiger maken: SAM en AWS CDK. Beide frameworks geven output in Cloudformation, waarmee je een stack creëert in de cloud op een AWS account. Afhankelijk van de status van deze stack, worden acties uitgevoerd. Zo zal de eerste keer de bucket worden aangemaakt en bij de tweede keer niet meer. Bij een volgende iteratie met andere wijzigingen, dan dienen deze in IaC worden gedefinieerd. Met het uitrollen, zal de bestaande bucket worden gebruiken en alleen deze nieuwe wijzigingen worden doorgevoerd. De cloudformation stack bevat de laatste versie en kan zo zelf bepalen welke acties er gedaan moeten worden. Anders gezegd: we programmeren wat we willen hebben, voeren dit aan cloudformation en krijgen bericht terug. We loggen dus niet in op een console om instellingen te wijzigen.

Imperatief vs. Declaratief

Voor IaC is het van belang, dat je de verschillen begrijpt tussen “imperatief vs declaratief” en “mutable vs immutable”. Dit filmpje van IBM legt dit mooi uit:

Met een imperatieve stijl beschrijf je elke stap, die gedaan moet worden. Declaratief beschrijft alleen de gewenste eind status. (Je legt niet de stappen vast hoe je van A naar B moet komen)

Declaratief is bijzonder handig als je bijvoorbeeld een dev, test en live omgeving hebt. Je wilt hetzelfde qua infrastructuur om zeker te weten dat het hetzelfde werkt. Als je dat zou doen met een beschrijving of steeds nieuwe omgevingen opzetten sluipen er vanzelf fouten in. Dat gaat tijd kosten en kan vervelende situaties creëren. Maar ook: Als je voor elke wijziging in infrastructuur een ticket moet inschieten kost dat veel tijd. En de infrastructuur specialist moet kennis hebben van jouw software en hoe je dat gemaakt hebt om het juiste te leveren. Met IaC wordt dit geautomatiseerd wat een stap voorwaarts betekent in snelheid en risicoverlaging.

Mutable vs. Immutable

Mutable IT-infrastructure is meer de aanpak zonder IaC. Meerdere personen kunnen wijzigingen aanbrengen in de infrastructuur en als er iets omvalt is het een duur en mogelijk tijdrovend proces om te analyseren wat, wanneer en door wie dit is veroorzaakt.

Met Immutable kun je de infrastructuur niet aanpassen. Dat klinkt als onhandig, maar is het niet. In plaats van elke keer je omgeving te upgraden en te documenteren wat je doet als je van v1 naar v2 (etc) gaat definieer je een hele nieuwe omgeving. Je laat v1 en v2 even naast elkaar draaien en stopt v1 dan en gaat verder met v2 als die goed bevonden is. Zo leg je eigenlijk elke keer veranderingen/instructies op elkaar en worden als een tape elke keer op dezelfde manier afgedraaid. Startpunt is dan afhankelijk van de state waar het IT-component(en) zich bevind(t)(en). Immutable Infrastructure as Code is de aanpak om infrastructuur traceerbaar te houden en speelt ook een groot belang bij het beter borgen van veiligheid. Alles is volgens een exacte specificatie automatisch uitgerold, zonder aanpassingen door personen.

Dit aspect helpt enorm met een vaak voorkomende term “configuration drift”, problemen waar je tegenaan gaat lopen met een IT-infrastructuur die regelmatig wijzigt. Zeker als je een infrastructuur hebt die enige omvang heeft én steeds in beweging is. Je moet dan niet alleen je versies allemaal beheren en documenteren, maar vaak ook de hele geschiedenis daarvan. Dat gaat snel(ler) tot problemen leiden en is een stuk minder schaalbaar.

Het mag helder zijn dat IaC bedrijven in staat stelt om wijzigingen en configuraties in een operatie efficiënter te beheren. Maar er zijn meer redenen om Infrastructure as Code te omarmen.

Waarom Infrastructure as Code?

• Software Development Best Practises zijn toepasbaar op infrastructuur
• Code reviews
• Schaalbaar / Snelheid:  IT-infrastructuur eenvoudig uit te rollen op meerdere omgevingen (test, accept, productie. Maar ook b.v. meerdere klanten)
• Door het gebruik van versiebeheer, zijn infrastructuur veranderingen traceerbaar
• Herbruikbaarheid van code
• Mogelijkheid tot uitvoeren van rollbacks
• Toezicht en review op veiligheid
• Declaratief
• Bouwstenen voor het automatiseren van processen

Controle en inzicht

Zonder Infrastructure as Code worden wijzigingen in infrastructuur met de hand gedaan. Bijvoorbeeld via de terminal of met UI interface/ portal zoals bijvoorbeeld de webconsole van AWS, Google en Azure. Op deze manier worden veranderingen wel gedaan, maar niet vastgelegd. Het is niet centraal gemakkelijk en snel goed te traceren wat precies gewijzigd is.
Als je de bestanden van IaC in een versiebeheer vastlegt (zoals je in Git doet) worden deze wijzigingen traceerbaar. Je wilt deze veranderingen graag vastleggen om een geschiedenis te kunnen inzien. Mocht er iets fout gaan, dan kan je analyseren door welke verandering er een fout is ontstaan.

Security by design

Vanuit best practises van ontwikkelaars kunnen nu ook reviews worden gedaan over de veranderingen op infrastructuur. Dit zal de kwaliteit verbeteren, is goed voor kennisdeling en draagt bij aan de veiligheid en kwaliteit. Omdat het inzichtelijk is welke verandering door wie is uitgevoerd kan je hierover met elkaar in gesprek. Dit proces noemen we ook wel ‘security by design’.

We zien een grote toename in cybercrime en elke bedrijf is in feite een target. Controle hierover is dus erg belangrijk. IaC kan hierbij helpen en risico's verlagen.

Kwaliteit en snelheid

Met IaC kun je sneller werken en met hogere kwaliteit. De kans dat er iets mis gaat is kleiner en als er iets mis gaat kan dit snel hersteld worden. Dit levert voor de gebruikers van de infrastructuur en de software omgevingen op die goed presteren en hoge beschikbaarheid hebben.

Welke implementaties zijn er?

Er zijn veel cloudplatformen en frameworks om uit te kiezen bij een implementatie, dit maakt het niet altijd even makkelijk. Om hier een beeld van te krijgen hebben we hieronder een lijst gemaakt met een aantal mogelijke frameworks. In de praktijk zul je al snel gaan werken met meerdere frameworks.

NaamDoelAWS cloudformation & SAM & CDKManager van AWS infrastructuur tot uitrollen/configureren van applicaties. Op basis van AWS cloudformation.Azure resource managerManager van Azure infrastructuur tot uitrollen/configureren van applicatiesGoogle cloud deployment managerManager van Google infrastructuur tot uitrollen/configureren van applicatiesTerraformConfiguratie-orkestratie. Coördineren van configuratie in complexe omgevingen en clusters. Terraform is een orkestratie framework b.v. m.b.v. modules/providers worden zaken gedelegeerd naar frameworks (de experts).HelmManage Kubernetes applicationsAnsible / ChefBouwen van infrastructuur en het implementeren en configureren van applicatiesPuppetMet Puppet kun je het beheer van servers en geïnstalleerde software automatiseren met de beschrijvende programmeertaal RubyPulumiMulti cloud solutionSaltStack/SaltConfiguration manager

Mindset

Infrastructure as Code is net als DevOps ook een state of mind. Je moet geloven dat je elkaar nodig hebt om tot succes te komen. Zeker als er snel geïnnoveerd wordt en wijzigingen elkaar snel opvolgen. Een situatie die voor veel bedrijven steeds meer de regel is als we het hebben over portals, websites, apps, koppelingen en andere software die kritisch zijn voor processen en inkomsten.
Het is niet alleen een inhoudelijk of procesmatig gebeuren, het is ook een mindset en dezelfde taal (willen) spreken. Foutloos samenwerken, security by design, elkaar begrijpen en oog voor kwaliteit en resultaat spelen mee.

Naast de genoemde voordelen van IaC, is dit voor ons bij Little Rocket een reden om IaC binnen Little Rocket zoveel mogelijk toe te passen. Dezelfde taal (willen) spreken maakt integratie veel makkelijker en het resultaat beter. Het proces verloopt sneller en de kwaliteit is hoger. Dat levert voordelen op voor ons team en onze klanten!