Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
De fleste, der beskæftiger sig professionelt med softwareudvikling, har stødt på ordet “DevOps”.
Et absolut uvidenskabeligt bud herfra er, at de fleste også vil vide, at ordet “DevOps” er en sammentrækning af ordene “Development” og “Operations”.
Nogle vil formentligt mene, at det er smart marketing for at italesætte det forholdsvis banale: At softwareudvikling af en dims og drift af software-dimsen er forskellige discipliner.
De hænger uløseligt sammen, da begge discipliner er hinandens forudsætning, udvikling og drift smelter sammen - derfor “DevOps”.
Det agile manifest
Jeg har dyb respekt for marketing, så jeg vil ikke gøre mig til dommer over, om det er popsmart eller ej.
Jeg kan blot konstatere, at termen “DevOps” har vundet indpas og at en industri ved at bruge ordet DevOps har fundet en anden og for nogen bedre måde at italesætte de samme værdier, som der står i det agile manifest skrevet tilbage i 2001.
“Mennesker og interaktion over processer og værktøj”, som manifestet blandt andet slår fast, kan man opfatte som en abstrakt ikke-sætning, medmindre du er intimt bekendt med faldgruberne i et softwareudviklingsprojekt.
Så er det for nogle teams og organisationer måske nemmere at forstå et paradigme som DevOps, der krystalklart udtrykker med sit eget navn og identitet, at udvikling og drift hænger sammen, og at man derfor skal indrette sig derefter i sin planlægning, i sin organisation og i sin forventningsafstemning blandt folkene på gulvet til, hvem der skal gøre hvad og hvornår.
Kan godt blive lidt forvirret her
Det er min oplevelse, at ikke alle, der kender til DevOps, har hørt om site reliability engineering (SRE).
Når man støder ind i begrebet og graver en smule, så kan man godt blive lidt forvirret, for det ligner, lugter og smager til forveksling DevOps, men er det ikke.
Forvirringen er forståelig, for DevOps og SRE lapper ind over hinanden.
Jeg vil her gøre mit bedste for at kridte banen op og forhåbentligt opklare et par mysterier for de nysgerrige.
I slipstrømmen
DevOps er opstået i slipstrømmen af den agile bevægelse, der for alvor tog fart i 00’erne.
DevOps begrebet daterer sig jf. Wikipedia tilbage til 2009.
Et hold af forfattere har sammen med virksomheder, der sælger DevOps-software siden 2014 udgivet en “State of DevOps” rapport, der giver deres bud på, hvordan DevOps bliver implementeret af virksomheder kloden rundt.
Hvis man leder efter et manifest for DevOps, så vil man lede forgæves.
Jeg vil nok nærmere kalde DevOps for en slags industri-standard, som alle er enige om giver mening og som er åben for fortolkning, hvorimod man principielt “bare” kan gå ind på www.agilemanifesto.org for at læse konklusionerne på, hvad en flok voldsomt intelligente mennesker i softwarebranchen fik ud af en forlænget weekend i Utah tilbage i 2001.
Indrammer et sæt værdier
DevOps indrammer et sæt værdier, der differentierer sig fra agile, men som alle trækker tråde tilbage til det agile manifest og LEAN.
Men det er vigtigt at forstå, at der ikke findes en facitliste på de værdier, som DevOps “er” eller ikke “er” - der findes ikke et manifest.
I stedet er værdierne i DevOps kommet til verden ved at store virksomheder, der udviklede software i 00’erne, havde behov for værktøjer og metodikker, der kunne hjælpe dem til at skalere deres organisation og den software, der skulle understøtte hypervækst i firmaer som Google, Amazon, Netflix m.fl..
De havde kort sagt brug for metoder og procesmæssige rammer, der kunne udkrystallisere det agile manifestos abstrakte paradigmer til forståelige og mere handlingsorienterede størrelser, som man kunne tage og implementere i sin organisation.
Værktøj og discipliner såsom continuous integration, continuous deployment, continuous testing, configuration management, application performance monitoring m/venner er alle begreber, der er forankret i agile værdier.
De er som sådan ikke nye discipliner, men disciplinerne og værktøjerne er blevet fortolket, modnet og videreudviklet af frontløberne for DevOps til at matche behov, der hurtigt vil blive konsekvensen af, at en organisation vælger at gå DevOps vejen.
Agile og DevOps har fokus både på organisation og på softwareudviklingsdiscipliner, hvorimod SRE primært koncentrerer sig om udvikling og drift af software uden at underkende eller nedvurdere værdierne bag DevOps og agil udvikling.
Da alting hænger sammen, så vil det være helt misforstået af nogen at påstå, at “vi er et SRE team/hus, det der DevOps og agile er ikke noget for os”.
For SRE giver ikke voldsomt meget mening, hvis organisationen eller teamet ikke anerkender og forsøger at leve efter agile værdier - lidt på samme måde som DevOps heller ikke giver mening, hvis man etablerer en “DevOps”-afdeling, der skal binde udvikling og driftsafdelingerne sammen.
Så ender man bare med tre afdelinger, der ikke taler sammen.
Og den slags organisatoriske kortslutninger øger overhovedet ikke kvaliteten af slutproduktet.
Uden at vide det
Du kan sagtens have et team, der laver SRE uden rigtigt at vide det, for SRE er som bekendt det, der sker, når du sætter en softwareudvikler til at lave det, der engang hed “operations”.
Hvis du er softwareudvikler/systemadmin og er ansat i en DevOps-lignende stilling, så kan du roligt også skrive SRE på din Linkedin-profil også, når du har brugt et par aftener på at studere emnet og forstår de små, men ikke uvæsentlige forskelle.
For SRE er et arbejde og nogle kompetencer, du i så fald allerede bestrider i dit daglige virke.
Som Google selv skriver, så er den ideelle SRE-kandidat en dygtig systemadministrator med flair og interesse i at scripte og programmere.
Her er en af de små forskelle
En af de små forskelle mellem DevOps og SRE ligger i det, som man måler på.
For både DevOps og SRE vil måle på alting (measure everything), men hver disciplin interesserer sig mere for visse metrikker end deres medpart.
En god metrik i et team kunne for eksempel være lead time på at rette en fejl - hvor lang tid går der, fra jeg tjekker et bugfix ind i sourcekontrollen til, at fejlen er rettet i produktion?
Ikke i et udviklingsmiljø, et testmiljø eller et ligeved-og-næsten produktionsmiljø, men produktionsmiljøet. Er leadtime på 10 minutter? 10 timer? tre uger? Mere end seks uger?
Når man diskuterer, hvorfor ting tager lang tid, det vil sige hvor der er spild i værdikæden, så vil pilen på et tidspunkt pege over mod organisationen.
Det vil ske samtidig med, at teamet ikke længere har indflydelse eller mandat til at træffe de beslutninger, der kan minimere et potentielt spild.
Når kurven for leadtime på en aktivitet knækker eller flatliner, er teamet så i en position, hvor de selv kan gøre noget ved problemet eller rammer de glasloftet på grund af forhindringer, de ikke selv kan løse, fordi roden til problemet ligger i den måde, organisationen har indrettet sig på?
Mere målrettet driften
SRE og DevOps ligner hinanden, men SRE-metrikker er modsat DevOps mere målrettet driften af en applikation, hvorimod DevOps også fokuserer på organisationen og organisatorisk friktion.
Der findes jf. Googles egen bog om SRE 4 gyldne metrikker: Svartider, trafik, fejl og mætning/udsultning af ressourcer.
Ingen af disse peger udad mod organisationen umiddelbart, men en fortolkning af dem på et retrospective vil naturligvis hurtigt få dem til at pege på de ydre rammer som en forhindring, som teamet ikke selv kan fixe.
Det kan for eksempel være, hvis teamet har vedvarende problemer med svartider, fordi organisationen af forskellige årsager ikke ser sig i stand til at allokere den nødvendige hardware til den trafikmængde, man modtager.
Større del af værdikæden
Jeg vil argumentere for, at den lille forskel mellem SRE og DevOps også ligger i, at DevOps måler på en større del af værdikæden modsat SRE, der har et mere snævert fokus tættere på deployment af koden til produktion.
Om du laver DevOps eller SRE på et job er både i en pragmatikers og i mine øjne to sider af den samme sag afhængig af kontekst.
Sidder du og fixer en fejl i infrastrukturen eller automatiserer en manuel proces, vil jeg kalde det SRE.
Hvis du arbejder på at overbevise organisationen om, at den bør investere i for eksempel automatiserede regressionstests, så vil jeg kalde det DevOps.
Hvis du laver lidt af begge dele og skal vælge, så vil jeg kalde det DevOps, om ikke andet fordi det er det, som lest mennesker kan relatere til, og DevOps dækker hele spektret.
Den grundlæggende forskel er, at DevOps har både et strategisk, taktisk og operationelt fokus, hvorimod SRE-disciplinerne fokuserer primært operationelt og føder via sin overvågning input ind i det feedback loop, der er en integreret del af en sund DevOps kultur og organisation.
Det vigtigste for den enkelte udvikler er trods alt at vide, at der faktisk er forskel og optimalt set også lidt om, hvad de hver især dækker over.
Er du nysgerrig og har små fem minutter til en overspringshandling, kan jeg anbefale What's the Difference Between DevOps and SRE på YouTube.
Er du mere til det skrevne ord og til en uddybende forklaring på SRE, kan du finde Googles egen bog om emnet gratis lige her: “SRE Book”.
Vil du vide mere om DevOps, så skynd dig at købe “Accelerate: The Science of Lean Software and DevOps”, der konkluderer på fore års forskning i DevOps og fører bevis for, hvordan en sund agil kultur og continuous deployment-discipliner korrelerer med høj kvalitet og slutbrugertilfredshed i de leverancer, som udviklingsorganisationen leverer.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.