Met de spectaculaire opkomst en groei van (publieke) Cloud-platforms is het mogelijk geworden om de manier waarop met IT-infrastructuur wordt omgegaan radicaal te veranderen. Denk bijvoorbeeld aan infrastructure-as-code.
Omdat de schaal van publieke Clouds zo groot is, zijn er weinig beperkingen aan het aantal resources dat kan worden aangevraagd. Omdat veel fysieke componenten (servers, netwerken) virtueel beschikbaar zijn, is het opzetten en afbreken van resources veel minder arbeidsintensief geworden.
Waar voorheen tickets werden aangemaakt bij een beheerpartij die vervolgens hardware bestelde en soms handmatig configureerde en beschikbaar stelde, kan het hele proces nu met een paar klikken en in slechts enkele minuten worden afgehandeld.
Deze radicale versnelling heeft geleid tot een andere manier van omgaan met infrastructuur. Omdat de kosten (in tijd en geld) voor het opzetten en ontmantelen van infrastructuur aanzienlijk zijn gedaald, is de drempel om nieuwe infrastructuur aan te vragen en oude te ontmantelen verlaagd.
Sterke groei van het aantal infrastructurele componenten
In veel gevallen is het resultaat een grote toename van het aantal infrastructuurcomponenten, met een gemiddeld kortere levensduur. Bovendien kan de infrastructuur veel beter worden afgestemd op de behoeften van het moment, omdat het nu mogelijk is aanpassingen door te voeren op het moment dat ze nodig zijn, in plaats van ver van tevoren.
Wat is het nadeel?
De combinatie van de groei van de infrastructuur en de kortere levenscyclus heeft ook een keerzijde. Het handmatig onderhouden van configuraties en het beheren van infrastructuurcomponenten wordt complexer naarmate het aantal uit te voeren acties toeneemt. Het is bijvoorbeeld eenvoudiger om de configuratie van drie gelijke servers handmatig synchroon te houden dan van 100 virtuele machines. Een configuratiewijziging drie keer of honderd keer uitvoeren maakt een groot verschil in de benodigde beheercapaciteit. Het is ook niet verwonderlijk dat er al geruime tijd diverse tools beschikbaar zijn om bijvoorbeeld configuraties uit te rollen naar meerdere (virtuele) machines.
De volgende stap: infrastructure-as-code
In een (publieke) Cloud-omgeving is het mogelijk de volgende stap te zetten. Hiermee wordt niet alleen de configuratie van infrastructuurcomponenten geautomatiseerd, maar ook het aanmaken ervan. Een volledige omgeving kan dan worden gedefinieerd in een of meer bestanden, die leesbaar zijn voor een systeem dat met deze definitie de infrastructuurcomponenten kan instellen. Deze volgende stap in het automatiseringsproces van de IT-infrastructuur staat bekend als “infrastructure-as-code”, en de systemen die deze code kunnen omzetten in acties worden “Resource Managers” genoemd.
Voordelen
Snelheid en betrouwbaarheid
Een van de meest voor de hand liggende voordelen van het toepassen van infrastructure-as-code is speed gain. In plaats van elke resource met de hand in elkaar te moeten “klikken”, kan een configuratiebestand worden gepresenteerd, waarna de Resource Manager de rest doet. Deze speed gain kan ook leiden tot kostenbesparing, omdat er minder beheercapaciteit nodig is. Vermindering van het aantal handmatige handelingen verkleint ook de kans op fouten.
Meer tijd voor ander werk
Door infrastructure-as-code vast te leggen, en deze door een Resource Manager te laten uitrollen, kan tijd worden bespaard op het beheer van deze infrastructuur. In plaats van (meerdere keren) handmatig wijzigingen door te moeten voeren, worden deze nu volledig in de code gedaan. Dat betekent dat er meer tijd overblijft voor werk dat meer waarde toevoegt.
Voorspelbaarheid en onderhoudbaarheid
Net als bij applicatiecode is het ook bij infrastructure-as-code zo dat dezelfde input altijd dezelfde output geeft. Als er bijvoorbeeld 20 Kubernetes clusters worden aangemaakt op basis van een template, dan is het zeker dat deze 20 clusters ook aan exact dezelfde specificaties voldoen. Door gebruik te maken van infra-as code kan ook worden voorkomen dat verschillende omgevingen die op elkaar zouden moeten lijken, op den duur uit elkaar drijven. Wijzigingen in infrastructurele componenten kunnen ook snel en betrouwbaar worden doorgevoerd.
Versiebeheer
De code die wordt gebruikt om infrastructuur te definiëren kan worden opgenomen in versiebeheer, net als applicatiecode. Wijzigingen kunnen bijvoorbeeld worden bijgehouden, acties kunnen worden teruggedraaid als er problemen optreden, en bijbehorende infrastructuur kan worden gedefinieerd voor specifieke applicatiecode.
Gevolgen voor mensen, processen en technologie
Nieuwe tooling
Doordat infrastructuur in gestructureerde bestanden kan worden vastgelegd, is het ook mogelijk geworden om deze codebestanden door software te laten lezen. AWS en Azure hebben beide hun eigen op JSON en YAML gebaseerde infrastructuur deployment mechanisme met CloudFormation en ARM-templates. Hashicorp Terraform gaat nog een stap verder en stelt gebruikers zelfs in staat om templates te maken die op AWS, Azure en GCP ingezet kunnen worden. Het is dus niet nodig om zelf software te schrijven die infra-as code leest en omzet in de juiste commando’s naar Cloud providers.
Infrastructuurlicenties volgens het “pay as you go”-principe
Infrastructuur is grotendeels virtueel geworden door abstractielagen van cloudproviders, en het gebruik van infrastructure-as-code stelt klanten in staat infrastructuur voor zowel korte als lange termijn te provisioneren. Licentiestructuren zijn ook veranderd; waar vroeger een aankoopprijs per hardware werd gerekend met daarbovenop een periodiek terugkerend bedrag, wordt nu per uur of per minuut betaald. Deze manier van kostenberekening kan goedkoper of duurder zijn, afhankelijk van het gebruik. Het wordt echter steeds moeilijker om de kosten van IT-infrastructuur te voorspellen. Immers, de kosten kunnen elke minuut anders zijn.
Anders werken
Een overstap van traditioneel infrastructuurbeheer naar infrastructure-as-code vergt een andere aanpak van de beherende partij. In plaats van te werken aan de infrastructuur zelf, is het nu de code die deze infrastructuur definieert waar het werk moet worden gedaan. Het veranderen van een instelling op een server, of het openen van een poort in een firewall is niet langer een probleem, omdat bij een volgende run van de Resource Manager deze handmatige wijzigingen allemaal worden overschreven met wat er in de infrastructure-as-code is opgenomen. Dit betekent dat de traditionele rol van de infrastructuurbeheerder zal moeten worden geherstructureerd, of zelfs gedeeltelijk verdwijnen.
Een overstap naar infrastructure-as-code biedt de mogelijkheid om anders te denken over de scheiding tussen beheer en ontwikkeling. Omdat de vaardigheden die nodig zijn om infrastructuurcode te onderhouden meer op één lijn liggen met de vaardigheden van softwareontwikkelaars dan het traditionele infrastructuurbeheer, wordt het voor ontwikkelingsteams gemakkelijker om ook hun eigen infrastructuur te onderhouden. Dit is in lijn met de DevOps-gedachte, waarbij degene die een systeem bouwt ook verantwoordelijk is voor het operationele werk aan dat systeem.
Bestuurswijzigingen
Het snellere tempo van veranderingen en de mogelijkheid om infrastructuurbeheer te decentraliseren, vormen uitdagingen voor organisaties die infrastructure-as-code omarmen. Er kan minder controle zijn over welke infrastructuurcomponenten worden opgezet en welke correct worden geconfigureerd. De verdeling van verantwoordelijkheden moet worden heroverwogen. Als er geen centrale afdeling is die de infrastructuur beheert, hoe kan er dan voor worden gezorgd dat aan alle normen en (beveiligings)eisen wordt voldaan?
Conclusie
Een overstap van fysieke infrastructuur, of apart geconfigureerde Cloud-infrastructuur, naar infrastructure-as-code roept vragen op over werkwijze en bestuur. Als deze vraagstukken zijn opgelost, stelt het gebruik van infra-as-code gebruikers in staat de mogelijkheden van een (publieke) Cloud beter te benutten. Door te definiëren welke infrastructuur beschikbaar moet zijn, en hoe deze geconfigureerd moet worden, is het eenvoudiger om grote hoeveelheden resources te beheren. Door gebruik te maken van beschikbare tools kan een heel landschap met één druk op de knop worden uitgerold, bijgewerkt, of afgebroken.
Het is wel belangrijk om te bedenken dat een overstap van een centraal beheerde infrastructuur naar een infrastructuur die in code is vastgelegd, vraagstukken over werkwijze en governance met zich meebrengt. Wie snel en accuraat wil kunnen handelen in een (groot) Cloud landschap, kan niet om de voordelen van het vastleggen van infrastructuur in code heen.