Infrastructure as Code (IaC) forenkler bruk av skyinfrastruktur
Med Infrastructure as Code (IaC) fullfører du skrittet fra en fysisk infrastruktur til en skyinfrastruktur som utnytter fordelene ved skytjenester til det fulle.
Hos offentlige skyleverandører som Azure, AWS og GCP og private skyleverandører som Basefarm Cloud, kan en stor mengde tjenester settes opp.
Tjenestene kan slås av og på i et webgrensesnitt hos skyleverandørene. Mengde tjeneste som blir levert kan også reguleres på samme måte.
Infrastructure as Code innebærer en effektivisering av disse oppgavene. Koden er maskin-leselige definisjonsfiler som støtter og regulerer hvilke applikasjoner og tjenester som skal endres kontinuerlig.
IaC går på tvers av enkelttjenester, og kan derfor koble inn og ut tjenester ut fra langt flere parametre enn for én enkelt tjeneste.
En første grunn til å implementere Infrastructure as Code er at du med koden beskriver hva du vil oppnå, ikke nødvendigvis hvordan du vil oppnå det.
IaC standardiserer oppsettet slik at faren for feil og avvik blir redusert. Dette vil i neste omgang kunne redusere utfordringer med inkompatibilitet i forhold til infrastrukturen.
Ved siden av å automatisere prosesser, gir IaC også en beskrivelse av hvordan infrastrukturen skal bygges.
Hvordan infrastukturen er satt opp er noe som ofte kan være mangelfullt dokumentert og eller kanskje befinne seg i hodene på enkeltpersoner som kan slutte, eller ha litt sviktende hukommelse i forhold til innstillinger som de gjorde for lenge siden.
IaC er derfor som en identisk kopi av et datasenter som kan provisjoneres og behandles som all annen kode. (Ofte blir JSON valgt som format for Infrastructure as Code, for øvrig).
I en verden som vi definerer som multicloud kan det dessuten være aktuelt å bruke skytjenester hos flere skyleverandører. Komponenter fra en velskrevet Infrasctructrue as Code kan flyttes til andre leverandører, altså ikke nødvendigvis hele IaC-koden.
Innenfor programvareutvikling er gjenbruk gull verdt, og med IaC gjelder dette også for infrastruktur.
Lett å sette opp test- og produksjonsmiljøer
For eksempel kan du bruke samme kode for testmiljøer og produksjonsmiljøer. Så lenge dette skjer hos samme skyleverandør, bør det være fullt mulig å gjenbruke koden med relativt små modifikasjoner. Når infrastrukturen blir godt definert er det lettere for utviklere og driftsansvarlige å samarbeide om etableringen av en felles, ønsket infrastruktur – faktisk før de oppretter den i skytjenesten.
Infrastructure as Code bidrar også til at virksomheten i mindre grad blir innelåst hos én leverandør.
For eksempel har ulike offentlige og private skyleverandører ulike tjenestetilbud. Derfor kan det hende at man ønsker å flytte fra en leverandør til en annen.
En vanlig grunn til å flytte særlig i offentlig sektor, er at leveranser regelmessig skal settes ut på anbud. Hvis en virksomhet er innelåst hos én skyleverandør, kan det innebære at flytting er veldig kostbart eller praktisk umulig.
IaC bidrar til en løsning på dette. Det starter ut med en leverandør som Basefarm som har kjennskap til tjenester og muligheter hos ulike skyleverandører. Ut i fra dette kan Basefarm og oppdragsgiver velge tjenester som flere skyleverandører leverer fremfor proprietære tjenester.
Et vanlig eksempel på dette er containersystemet Docker og containerstyringssystemet Kubernetes. Ved å sette opp IaC riktig, vil koden relativt enkelt kunne provisjoneres hos en hvilken som helst skyleverandør av disse tjenestene.
Helt rett frem er det fortsatt ikke. Men, gjennom kombinasjonen av god rådgivning om hva Infrastructure as Code kan bidra til å oppnå, kan virksomheter få en stor forenkling som i praksis også fungerer mot innelåsing.
Bedrifter ønsker ikke å bruke kostbar utviklertid på manuelle oppgaver som kan utføres like godt eller bedre gjennom automatisering. Infrastructure as Code bidrar til automatisering. Utviklerne kan gjøre endringer i kode fremfor å logge seg på og lete seg frem til de riktige parametersidene på nettet.