IaC – Når ledninger udskiftes med kode!
Hvad er IaC for noget? Hvorfor kan du ikke komme udenom at vide det og hvordan skaber IaC værdi for jer? Det afdækker vi i en snak med Morten Hoffmann, CEO og Christian Møller Klintemark, Software Craftsman i STRONGMINDS. Læs med, hvis pludselig skalerbarhed, gennemsigtighed, sikkerhed og stabilitet er på din dagsorden og kan bidrage til en sundere driftsøkonomi.
Hvad er idéen eller konceptet bag infrastruktur som kode?
Morten:
– IaC er den egentlige revolution inden for cloud. Billedet på den traditionelle infrastruktur er fysiske datacentre med ledninger og hardware, der vedligeholdes manuelt. Når infrastruktur formuleres som kode, muliggøres vedligehold, flyt, kopiering og skalering af IT, så vi sparer tid og ressourcer.
– Samtidig kan software services, der er bygget ovenpå den underliggende infrastruktur også destilleres som kodebeskrivelser. Alt i alt, giver det muligheden for at designe kodeklumper, som bærer sig selv og nedbryder det traditionelle skel mellem IT- og udviklingsafdelingen. Som sidegevinst ryddes der op i manuel konfiguration og man sætter løsningen på formel.
Hvordan skaber IaC værdi for organisationen?
Morten:
– Skalerbarhed er nøgleordet her. Vi får langt lettere ved at skalere vores løsning – både op og ned i takt med ændrede behov og inden for utrolig kort tid. Med nogle få kodelinjer kan vi skalere vertikalt, med f.eks. diskplads, memory og processorkraft, eller vi kan vælge at skalere horisontalt og tilføje flere instanser af f.eks. en virtuel maskine. Det er et kvantespring, der muliggør beregninger, som før har krævet måneders planlægning i indkøb og set-up. De fleste cloud leverandører kan “auto-scale” brugen af ressourcer som f.eks. virtuelle maskiner, RAM eller CPU kraft.
– I forhold til driftssiden har vi også gevinster i form af komplet gennemsigtighed i den implementerede IT-løsning. Mængden af hardware konfiguration/patches kan nu beskrives minutiøst og svarer een-til-een til det faktiske set-up.
– Den præcise fastholdelse af løsninger som kodebeskrivelser gør det let at reviewe, versionere og videreudvikle løsningen. Det er f.eks. let at se ændringer i et par kode-linjers konfiguration samlet i en fil med beskrivelser af det øvrige set-up.
Christian:
– Ja, gennemsigtigheden gør det tydeligt for alle, f.eks. nye folk man får med på sit team, hvad der egentligt er lavet, og man kan videreudvikle på det. Det er også nemmere at vedligeholde ældre systemer, fordi man kan se, hvordan det er lavet direkte i koden. Man har den samlede viden om hvordan systemet fungerer, direkte i sin kode. Man undgår den velkendte situation med, at én person, en it-administrator, har en viden om, hvordan alting har fungeret siden tidernes morgen. Det er en skrøbelig situation, når vedkommende forlader organisationen. Men når det hele er lavet i kode, kan hvem som helst hoppe ind og overtage. Der vil selvfølgelig altid være viden, der går tabt, men man kan lettere overtage og læse, hvordan det er sat op. Så alt i alt er det nemmere at have flere til at arbejde på det. Det er lettere at dele viden og at have overblik over adgangen til de forskellige systemer. Dokumentationen af det, gør det mere synligt.
Er kode nemmere at overtage end et fysisk set-up?
Morten:
– Kode kan bestemt også være vanskelig at overtage, så det kræver at koden er velstruktureret og dokumenteret. Men igen, det er et stort skridt fremad at kunne beskrive ændringer til et system, ikke som mundtlige overleveringer eller i logbøger, men med den faktiske implementation selv.
Hvilken indflydelse har IaC på den generelle sikkerhed?
Morten:
– Sikkerhedsmæssigt både rummer og kræver kodebeskrivelsen muligheden for at få ryddet op i støvede hjørner af infrastrukturen. Måske har man tidligere ikke haft det komplette overblik over brugere/rettigheder på enkelte maskiner, men med muligheden for at rive IT set-up’et ned og hurtigt bygge det op igen (f.eks. indenfor minutter) kan vi sikre, at der ryddes op, og eventuelle uautoriserede tilføjelser fjernes. Det kræver dog også, at vi adresserer og designer løsninger, ikke som metalkasser med bund- og netværkskort og lange kabler, men som f.eks. virtual private networks med begrænset adgang til specifikke brugere/roller.
Christian:
– Ja, en stor fordel ved at hele infrastrukturen er kodet er, at man kan reetablere den rimelig hurtigt hvis man får brug for det. Det vil sige, at hvis man bliver ramt af nedbrud, noget malware eller ransom ware, så kan man få lagt alt ned og få det genoprettet fra bunden rimelig hurtigt. Man kan simpelthen bare fjerne den betændte del af løsningen, trykke på deploy, og så bliver det hele kørt op igen. Det har vi prøvet at gøre indenfor for et par timer. Det er noget sværere, hvis man manuelt har sat hver enkelt server op til det, den nu skal kunne. Det bliver lige pludselig en manuel proces at gennemgå alt, hvis du bliver angrebet af malware, ransomware eller hvad vi ellers ser for tiden. Så det er en af de gode forcer ved det. Det er så en helt anden problemstilling med data og backup, men selve det at få infrastrukturen op og få genoptaget driften det kan gøres ekstremt hurtig, hvis man har det her på plads.
En ny rollefordeling
Morten:
– Vi ser også, at IaC giver et skifte i rollefordelingen. Hvor vi før har haft en traditionel ”viceværtsrolle” for IT driftsfolk (sammen med andre roller) udvides denne rolle til også at have udviklingsmæssig karakter. Det opgør med tidligere tiders skisme kaldes populært for DevOps (en understregning af sammensmeltningen mellem development og operations). Behovet for at løse opgaver som f.eks. at vedligeholde kabler, skifte netværkskort, kontrollere rumtemperaturer eller opsætte databaser, varetages i stedet af Cloud-leverandøren, og vi får frigjort ressourcer til at arbejde på den samlede løsning.
Hastighed og fleksibilitet i udviklingsmiljøer
Christian:
– Det, at man kan skubbe flere miljøer ud samtidig, er en stor fordel. Udviklerne træder ikke hinanden over tæerne og flere kan teste features på samme tid.
– Hvis du har mange servere, er det nemmere at ændre en værdi i kode, end at skulle logge på hver eneste maskine og lave ændringer eller lave et automatiserings-script. Hvis ændringerne laves i koden, er det jo bare at tilpasse det og smide det ud. Så det er hurtigere at lave ændringer – specielt også, hvis du har flere miljøer. Når vi sidder med vores systemer, så har vi som regel tre miljøer, nogle gange flere; udviklingsmiljø, testmiljø og produktionsmiljø. Og der skal miljøerne være ens, for at det giver mening. Men har vi den samme kode vi deployer på hvert miljø, så får vi samme opsætning. Det gør det noget nemmere at være sikker på, at det er det rigtige, man har på alle sine miljøer. Når man laver website udvikling – så kan det også være rart, at man hurtigt kan opsætte et miljø til én udvikler. – At han kan deploye hele sin løsning, og derefter har et helt ”sandkasse miljø” for sig selv. Når han er færdig, kan det lukkes ned lynhurtigt. Hvis man kun har ét udviklingsmiljø, og man er 10 udviklere, der sidder og skubber til det, så sidder man og overskriver hinandens ting. Der er det rart, når man skubber kode ud, at man har sit eget område at arbejde på – uden at blive forstyrret af andre. Det er en mulighed man har med en kodet infrastruktur.
Hvad skal der til, for at skabe en god, kodet infrastruktur?
Morten:
– Først og fremmest bør du vælge en Cloud leverandør med velafprøvede og dokumenterede snitflader. Alle de store spillere: Amazon, Microsoft, Google, IBM kan levere her, men det er vores erfaring, at AWS med sit forspring endnu er den “my” bedre. En god tekst editor (a la Visual Studio Code) med support for IaC “sproget” (typisk JSON) er en forudsætning, og de fleste udviklingsomgivelser rummer i dag et hav af integrationer mod de forskellige Cloud vendors.
Christian:
– Der skal lægges en indsats i at få det hele beskrevet rigtigt i stedet for, at man lige prøver sig frem hurtigt. Men til gengæld får man en anden fleksibilitet ved, at det er nemmere at hyre flere folk ind, og det er nok nemmere at flytte rundt på folk, så man ikke behøver at have en med speciale i at opdatere databaser, og en anden med ansvar for at opdatere windows-maskiner. – Det kan være mere flydende. Der er ikke på samme måde behov for at have specialister.
Morten:
– Flere virksomheder kaster mange ressourcer i at tænke multi/hybrid-Cloud. En hybrid-Cloud er ideen om at kunne sammenstykke sin samlede Cloud løsning af elementer fra flere Cloud-leverandører samtidigt. Terraform er et eksempel på et meta-IaC sprog, som gør det transparent, hvilken underliggende Cloud som faktisk benyttes. Det er lidt et religiøst spørgsmål om tilgangen giver umiddelbar værdi? ”It depends” er nok svaret, men generelt kan man nok sige, at illusionen, at man kan udskifte den underliggende Cloud-leverandør, i hvert fald på sigt, forbliver en illusion. Men altså, det er en vurdering mere end fakta.
Hvordan vælger man den rette løsning?
Christian:
Hvis man kun skal være på én Cloud, så giver det mening at vælge det som Cloud-udbyderen tilbyder. Hvis man er meget stærk i Terraform og ikke lige kender Amazons CloudFormation, så kan det godt være, det er bedre at bruge Terraform. Hvis man har tanker om at gå ind på flere udbydere, så giver det måske bedre mening at bruge Terraform. For at bruge flere udbydere på én gang, skal man dog stille højere krav til oppetid, end det en enkelt udbyder kan garantere. Det kan f.eks være streamingtjenester, eller andre der har brug for særlig høj availability. Ellers giver det ikke mening at sprede sig ud over flere. Netflix bruger fx både Google, Azure og AWS. De har enorme mængder af data og store brugertal, så de vælger at gå med livrem og seler. Det er selvfølgeligt ikke billigt, men i forhold til lige streaming-tjenester, kan der være lokale geografiske fordele ved at sprede det. Nogle udbydere har bedre dækning i visse områder end andre. Så for dem er det en kombination af, hvor høj oppetid de vil garantere, og hvor meget data de skal sende ud til brugeren.
Hvordan kommer man i gang?
Morten:
– Just do it. Experiment-Fail-Learn.
Christian:
– Ja, det kan man, hvis man er softwareudvikler. Man skal undgå at tænke klassisk hardware opsætning, hvor man på forhånd vil konfigurere 10 servere, og i stedet sige, vi kan måske køre op til 10 hvis vi har brug for det. Pointen er netop, at cloud er dynamisk og hurtigt kan skalere op og ned, så man skal sørge for kun lige at have den kapacitet, man har brug for. Det er ekstremt vigtigt, at man lokalt i datacentret er bevidst om at tænke i cloud, så man opnår fordelene. Ellers kan ’Just do it’ blive dyrt.
Hvad kræver det af ressourcer?
Morten:
– Svaret på det, er vist en artikel for sig. Generelt kan man sige, at inddrages beskrivelsen af infrastrukturen i den samlede løsning får man ikke blot fordelene ved DevOps tilgangen, men også de mange fordele ved at kunne etablere et continous deployment set-up. Tankerne bag continous integration/deployment (CI/CD) er også et emne for sig. Ligesom det har taget tid at opbygge tidligere tiders abstraktioner, så vil det tage tid at opbygge erfaringer med IaC + DevOps + CI/CD. Men, sikkert er det at undlader din virksomhed at kigge den vej, overhales du at virksomheder som gør. De byggesten, som er til rådighed, rummer et potentiale, som det vil tage dig mange år selv at opbygge.
– Skiftet har selvfølgelig en pris, og virksomheder, som forsøger at lave regnestykket, finder tit den første ”lift-and-shift” (ud af kælderen) øvelse dyr og ikke besværet værd. Det er først, når hele løsninger bygges af de byggeklodser, som er til rådighed i skyen, at de egentlige gevinster viser sig på den rå IT-ydelse – men husk her de mange andre fordele, som kommer med gratis.
Opsummering
IaC og Cloud er en investering, der stiller krav til ressourcer og indsats ved den egentlige omlægning. Samtidig kalder det på et skifte i mind-set i forhold til den løbende drift. Men, når infrastrukturen er på plads, har man en lang række fordele, der indirekte vil afspejles positivt på driftsbudgettet. Skalerbarhed, fleksibilitet og sikkerhed, er væsentlige temaer for de fleste beslutningstagere. Samtidig er der et vigtigt aspekt omkring rettidig omhu, i forhold til at tage stilling til sin infrastruktur og fremtidssikre både IT og ressourcer.
Eksempel
Nedenfor vises små eksempler på kode, der er taget ud af en meget større konfiguration.
- Oprettelse af et SSL Certifikat, der kan benyttes, når man rammer websitet, og som viser den grønne hængelås i browseren.
- Lagring af data er vist med eksempel på en database af typen MySQL.
- Til hosting af websitet er der defineret en Container Service og en definition af det Docker image der skal bruges i container servicen.
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Infrastructure",
"Parameters": {},
"Resources": {
"Certificate": {
"Type": "AWS::CertificateManager::Certificate",
"Properties": {
"DomainName": "www.strongminds.dk"
}
},
"DBInstanc": {
"Type": "AWS::RDS::DBInstance",
"Properties": {
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.08.0",
"AllowMajorVersionUpgrade": true,
"AutoMinorVersionUpgrade": true,
"PubliclyAccessible": false,
"DBInstanceClass": "db.t3.medium",
"StorageEncrypted": true,
"PreferredMaintenanceWindow": "mon:04:00-mon:04:30"
}
},
"Service": {
"Type": "AWS::ECS::Service",
"Properties": {
"ServiceName": "website",
"LaunchType": "FARGATE",
"HealthCheckGracePeriodSeconds": 30,
"NetworkConfiguration": {
"AwsvpcConfiguration": {
"AssignPublicIp": "DISABLED",
"SecurityGroups": [
{ "Fn::ImportValue": "WebSiteGroup" },
{ "Fn::ImportValue": "DbGroup" }
]
}
},
"Cluster": "Strongminds",
"DesiredCount": 6,
"TaskDefinition": {
"Ref": "TaskDefinition"
},
"DeploymentConfiguration": {
"MaximumPercent": 200,
"MinimumHealthyPercent": 100
},
"LoadBalancers": [
{
"ContainerName": "website",
"ContainerPort": 80,
"TargetGroupArn": {
"Ref": "TargetGroup"
}
}
]
}
},
"TaskDefinition": {
"Type": "AWS::ECS::TaskDefinition",
"Properties": {
"Family": "website",
"RequiresCompatibilities": [
"FARGATE"
],
"Cpu": 1024,
"Memory": 1024,
"NetworkMode": "awsvpc",
"ContainerDefinitions": [
{
"Name": "website",
"Essential": true,
"Image": {
"Ref": "Image"
},
"Memory": 1024,
"PortMappings": [
{
"ContainerPort": 80
}
],
"Environment": [
{
"Name": "ASPNETCORE_ENVIRONMENT",
"Value": "Production"
}
]
}
]
}
}
}
}