X as Code

Infrastructure as Code (IaC) åbnede døren til en ny måde at tænke på: hvis servere og netværk kan beskrives i filer og committes til et repository, hvorfor så ikke alt andet? “As Code”-mønstret har siden bredt sig langt ud over infrastruktur - og med god grund.

Infrastructure as Code

Det hele startede her. Værktøjer som Terraform, Bicep og Pulumi lader dig beskrive dine cloud-ressourcer i deklarative filer. Resultatet er reproducerbare miljøer, versionsstyrede ændringer og ingen flere “det virker i staging”-mysterier forårsaget af manuelle afvigelser.

Andre værktøjer - som fx Ansible - kan hjælpe med at automatisere processer på tværs af en større maskinpark. Formålet er typisk at sætte hastigheden op og reducere risikoen for menneskelige fejl.

Valget af tool afhænger ofte af præferencer - og der er fordele og ulemper ved alle tilgangene. I et rent Azure miljø vil Bicep ofte være et glimrende valg - men mange vælger at bruge Terraform fordi det er platformsuafhængigt eller fordi det bliver betragtet som den mest almindelige løsning.

Configuration as Code

Applikationskonfiguration håndteret via filer i kildekoden - frem for miljøspecifikke dashboards eller manuelle indstillinger. Kubernetes ConfigMaps, Helm values-filer og .env-drevne pipelines følger alle dette mønster. Ændringer kan spores og fortrydes.

Evnen til at skelne mellem infrastruktur og konfiguration kan være afgørende for, hvor let implementeringen af IaC bliver. Udgangspunktet er at alt skal defineres i kode - men det betyder ikke at alt skal afvikles på én gang. Hvis man forsøger at proppe for meget konfiguration ind i den rå infrastrukturdefinition, støder man ofte på catch-22 situationer, hvor provisionering fejler fordi afhængighederne ikke er tilstede. En typisk årsag til lange svære forløb med IaC er altså manglende fokus på, hvor infrastruktur stopper og konfiguration begynder.

Pipeline as Code

CI/CD-pipelines defineret i YAML eller lignende formater side om side med applikationskoden. Azure Pipelines, GitHub Actions og GitLab CI følger alle denne model. Pipelinen er en del af kodebasen - reviewed, versioneret og deployet ligesom alt andet.

Der findes en række forskellige tilgange til at strukturere sine pipelines ift. at bygge, teste og deployere på forskellige miljøer. Virksomhedskultur, governance og risikovillighed spiller i høj grad ind på, hvilken løsning, der er bedst i en given situation. Værktøjerne udvikler sig også løbende og kan påvirke de valg man træffer.

Der er mange fordele ved at anvende pipelines - og én af de mere avancerede er bl.a. at man kan reducere adgange til produktionsmiljøer og secrets væsentligt ved at lade pipelines være den eneste vej til produktion.

Policy as Code

Cloud-miljøer er en kilde til kæmpe muligheder - og derfor også til store risici.

Sikkerheds- og compliance-regler kan defineres som kode mhp. at blive håndhævet automatisk og løbende. Funktioner som Azure Policy lader platformsejeren definere rammerne. På den måde er det muligt på forhånd at afgøre, hvad der er tilladt i et deployment, inden noget når produktion.

Policies kan dog også skabe udfordringer for andre dele af økosystemet, så det bør anvendes med omtanke.

Monitoring as Code

Dashboards, alarmer og SLO’er defineret i kode kan deployes sammen med de services, de overvåger. Grafana-as-code, Datadog-monitors i Terraform og Prometheus alerting-regler er udmærkede eksempler på at de kendte leverandører har taget “as Code” til sig. Når en service deployes, følger observability med.

Documentation as Code

Det er måske lidt søgt - men dokumentation skrevet i Markdown og gemt i repositoriet sammen med koden kan løse mange udfordringer med egenudviklede løsninger. Ved at skrive dokumentation i de samme værktøjer som selve koden, får udviklerne mulighed for at benytte deres normale værktøjer - og dokumentationen kan automatisk udstilles via fx en intern hjemmeside som en fantastisk støtte til andre teams.

Architecture Decision Records (ADR’er), API-specifikationer (OpenAPI / Swagger) og alverdens .md filer kan leve tæt på den kode, de beskriver - og med en smule disciplin kan dokumentationen være opdateret i samme pull request.

Den røde tråd

Alle disse mønstre deler de samme fordele: versionsstyring, code review, automatisering og reproducerbarhed. Når noget er defineret som kode, bliver det sporbart, delbart og testbart. Spørgsmålet er ikke længere om man skal anvende mønstret, men hvilket værktøj der passer til opgaven.