Infrastruktur som vi kender i dag, står overfor et paradigmeskifte. Traditionelle datacentre er snart forældet, og nye og mere effektive måder tages i brug for at levere ydelser i et datacenter.
Begreber som Hyper-Converged Infrastructure (Hybrid-)Cloud og “Infrastructure as Code” er helt centrale for denne omvæltning – og alle er defineret som disruptive teknologier. Denne gang ønsker jeg at fokusere på sidstnævnte begreb, da jeg mener, det ikke får nok opmærksomhed; “Infrastructure as Code” – et begreb, der kan ses som et subset af begrebet “DevOps”.
Hvad er DevOps?
DevOps er sammensætningen af ordene “Developer” og “Operations”, og defineres som skæringspunktet mellem “IT Pro” (Infrastructure Engineer) og Developer. DevOps begrebet kan også forstås som en leverance, som både personer med IT Pro baggrund og udviklere kan levere sammen gennem en forståelse for hinandens, og ikke mindst kundens, behov for at levere en skræddersyet service fra A til Z. Fra et udviklerperspektiv forbinder man gerne DevOps begrebet med en udviklers evne til at forstå og automatisere opsætningen af et udviklings- og produktionsmiljø på en given infrastrukturplatform.
En lidt anden tilgang kan være at se DevOps begrebet fra infrastrukturverden; den evne en “IT Pro” har til at forstå og gøre brug af kode og testning af kode for at implementere, dokumentere og drive IT-systemer. Det er ofte her, man taler om “Infrastructure as Code”.
Fordelene ved “Infrastructure as Code” er mange
For at nævne et par stykker:
- Koden dokumenterer systemet, hvilket gør, at systemdokumentationen er helt dynamisk, og man undgår afvigelser mellem dokumentation og system
- Man har mulighed for at opbygge systemet til enhver tid med et enkelt tastetryk
- Man kan bruge “Blue”/”Grøn” metode til implementering af systemer uden nedetid:
- 2 systemer køres parallelt, hvor det grønne system altid er i produktion. Skrot/slet det blå system og byg det op igen. Skift til det blå system og definer det som grønt, hvis alle test er OK. Definer det gamle som blåt.
- Kan gentages efter behov – eller på faste tidspunkter i løbet af året.
- Man kan se alle sine systemkomponenter som forbrugsartikler. Er der noget, der ikke fungerer, kan man erstatte det ved at køre kode igen
- ” Backup and recovery ” er en naturlig del af leverancen
- Undgå alle manuelle fejl
- Undgå konfigurationsdrift
- Højeffektiv set-up tid
Nogle af disse punkter afhænger selvfølgelig af, hvor langt man ønsker at strække begrebet. Måske man i første omgang kun ønsker at definere testmiljøet som kode? Det er jo typisk et miljø, som ofte ridses i og genopbygges. Udfordringen er uanset hvad, at det ofte kræver en del af en IT Pro for at opbygge kompetencer inden for kode og kode testning, og det kræver ligeledes oplæring af de personer, der senere hen skal drifte systemet. Uanset hvad mener jeg, at det er en god investering i fremtiden!
PowerShell Desired State Configuration som DevOps værktøj
For dem der er fortrolig med Microsoft-teknologier, er PowerShell Desired State Configuration en enkel indgangsbillet til DevOps tankegang. DSC bruges til at automatisere opsætning af systemer og komponenter, og for at undgå konfigurationsdrift. Det anvendte sprog er PowerShell, og der findes i dag over 500 unikke DSC ressourcer, hvilket igen betyder, at der findes over 500 komponenter og systemer, som kan automatiseres og oprettes igen ved hjælp af DSC! Finder man ikke den ressource, man leder efter, er det ligeledes meget enkelt at oprette egne.
Desired State Configuration er enkelt at forstå og let at komme i gang med for alle. Værktøjet vil være helt centralt i Microsoft infrastruktur (og andre systemer!) i fremtiden, og er på mange måder en af de vigtigste teknologier til det paradigmeskifte traditionel infrastruktur på nuværende tidspunkt står overfor – specielt med tanke på DevOps og “Infrastructure as Code”.
PS: Har du hørt om den nye Microsoft Nano Server? Den har hverken GUI eller RDP. Hvordan tror du, den skal håndteres? Korrekt, DSC!
Af Eirik Holgernes