Om DevOps og Snowflakes

Man kan næppe røre sig i IT-verdenen i dag uden at høre folk tale om DevOps. DevOps er det varme nye emne i branchen, som viderefører, hvor snakken om cloud slap, og at høre folk tale om det, kan man tro, at traditionel systemadministration allerede er død og begravet.

Først skal vi tale om, hvad vi mener med DevOps. Dette kan være forvirrende, fordi ligesom cloud bliver et ældre udtryk ofte stjålet til at betyde noget andet eller i bedste fald relateret til noget, der allerede eksisterede. Traditionel DevOps var sammenlægningen af udvikler- og driftsroller. Fra 1960'erne til 1990'erne var dette standardmåden at drive systemer på. I denne verden var de mennesker, der skrev softwaren, generelt de samme, der deployede og vedligeholdt den. Deraf sammenlægningen af "developer" og "operations" – operations er et halvstandardiseret udtryk for rollen som systemadministrator. Disse roller var ikke almindeligt adskilt, før "IT-afdelingen" opstod i 1990'erne og 2000'erne. Siden da er tilbagevendelsen til sammenlægningen af de to roller begyndt at stige i popularitet igen, primært på grund af den måde, de to kan fungere sammen med stor værdi i mange moderne, hostede webapplikationssituationer.

Hvor DevOps ofte tales om i dag, er ikke som en streng sammenlægning af udviklerne og driftspersonalet, men som en ændring af driftspersonalet med et meget større fokus på kodning – ikke af selve applikationen, men på at definere applikationsinfrastrukturer som kode som en naturlig forlængelse af cloudarkitekturer. Dette kan virke ret forvirrende i starten. Det er vigtigt at bemærke, at traditionel DevOps ikke er det, der almindeligvis sker i dag, men en ny "falsk" DevOps, hvor udviklere forbliver udviklere og drift forbliver drift, men drift har udviklet sig til en ny "kode-tung" rolle, der fortsat fokuserer på at administrere servere, der kører kode leveret af udviklerne.

Det, der er betydningsfuldt i dag, er, at systemadministratorens rolle er begyndt at opdele sig i to relaterede, men betydeligt forskellige roller, hvoraf den ene fejlagtigt kaldes DevOps af det meste af branchen i dag (det meste af branchen er for ung til at huske, da DevOps var normen, ikke undtagelsen, og bestemt ikke noget nyt og nyt). Jeg refererer til disse to aspekter af systemadministratorrollen her som DevOps- og Snowflake-tilgangene.

Jeg bruger udtrykket Snowflake til at referere til traditionelle arkitekturer for systemer, fordi hver individuel server kan ses som et "unikt snefnug." De er alle forskellige, i hvert fald i det omfang de ikke administreres på en måde, der holder dem identiske. Det betyder ikke, at de alle behøver at være unikke, blot at de bevarer potentialet til at være det. I traditionelle miljøer logger en systemadministrator individuelt ind på hver server for at arbejde på dem. En vis mængde scripting er almindeligt for at lette administrationsopgaver, men i sin kerne involverer rollen en masse tid på at arbejde på individuelle systemer.

At lette administrationen af Snowflake-arkitekturer involverede ofte forsøg på at minimere forskelle mellem systemer på rimelige måder. Dette starter generelt med ting som at vælge et enkelt standardoperativsystem og version (Windows 2012 R2 eller Red Hat Enterprise Linux 7) frem for at tillade, at hver serverinstallation er et andet OS eller version. Denne standardisering kan virke grundlæggende, men mange shops mangler denne standardisering selv i dag.

Et næste skridt er almindeligvis at skabe en standard deploymentmetodologi eller et gold master-image, der bruges til at lave alle systemer, så basisoperativsystemet og alle basispakker, ofte inklusive systemtilpasning, overvågningspakker, sikkerhedspakker, godkendelseskonfiguration og lignende ændringer, er standardiserede og deployet ensartet. Dette giver et fælles udgangspunkt for alle systemer for at minimere divergens. Men teknisk set sikrer de kun et standardudgangspunkt, og over tid skal divergens i konfiguration forudses.

Ud over disse trin bruger Snowflake-miljøer typisk tilpassede, bespoke administrationsskripts eller administrationværktøjer til at opretholde en vis standardisering mellem systemer over tid. Jo flere fælles træk der er mellem systemer, jo lettere er de at vedligeholde og fejlsøge, og jo mindre viden er nødvendig fra administrationspersonalet. Mere standardisering betyder færre overraskelser, færre ukendte og meget bedre testmuligheder.

I et enkelt systemadministratormiljø med god praksis og værktøjer kan Snowflake-miljøer opnå en høj grad af standardisering. Men i miljøer med mange systemadministratorer, især dem, der understøttes døgnet rundt fra mange regioner, og med et stort antal systemer, kan standardisering, selv med meget omhyggelig praksis, blive meget vanskelig. Og det er endda inden vi tackler de åbenlyse problemer omkring det faktum, at forskellige pakker og muligvis pakkeversioner er nødvendige på systemer, der udfører forskellige roller.

DevOps-tilgangen vokser organisk ud af cloudarkitekturmodellen. Cloudarkitektur er designet around automatisk oprettede og automatisk ødelagte, bredt identiske systemer (i det mindste i grupper), der styres via en programmatisk grænseflade eller API. Denne model egner sig ganske åbenlyst til at blive styret centralt via et styringssystem frem for via manuelle bestræbelser fra en systemadministrator. Manuel administration er effektivt umulig og fuldstændig upraktisk under denne model. Individuelle systemer er ikke unikke som i Snowflake-modellen, og enhver divergens vil skabe alvorlige problemer.

Ideen, der er opstået fra cloudarkitekturverdenen, er, at systemarkitektur bør defineres centralt "i kode" frem for på selve serverne. Dette lyder forvirrende i starten, men giver meget mening, når vi ser nærmere på det. For at understøtte denne model er en ny type systemstyringsværktøj, der endnu ikke har fået et rigtig standardnavn, men ofte kaldes et systemautomatiseringsværktøj, DevOps-framework, IT-automatiseringsværktøj eller simpelthen "infrastructure as code"-værktøj, begyndt at opstå. Almindelige værktøjssæt i dette område inkluderer Puppet, Chef, CFEngine og SaltStack.

Ideen bag disse automatiseringsværktøjssæt er, at en central tjeneste bruges til at administrere og styre alle systemer. Denne centrale autoritet administrerer individuelle servere ved hjælp af kodebaserede beskrivelser af, hvordan systemet skal se ud og opføre sig. I Chef-verdenen kaldes disse "opskrifter" for at være sjove, men analogien fungerer godt. Hver systems kode kan indeholde oplysninger som en liste over, hvilke pakker og pakkeversioner der skal installeres, hvilke systemkonfigurationer der skal ændres, og filer der skal kopieres til maskinen. I mange tilfælde håndteres beslutninger om disse deployments eller ændringer gennem potentielt kompleks logik, og deraf behovet for faktisk kode frem for noget mere simplistisk som markup eller skabeloner. Systemer grupperes derefter efter rolle og administreres som grupper. "Webserver"-rollen kan fortælle et sæt systemer at installere Apache og PHP og konfigurere hukommelsen til at swappe meget lidt. "SQL Server"-rollen kan installere MS SQL Server og specielle backupværktøjer, der kun bruges til den applikation, og konfigurere hukommelsen til at være tunet som ønsket for en pool af SQL Server-maskiner. Disse er blot eksempler. Typisk vil en organisation have et stort antal roller, nogle kan være generiske som "webserver" og andre meget mere specifikke for at understøtte meget specifikke applikationer. Roller kan generelt lagdeles, så et system kan være både en "webserver" og en "java-server" og få de kombinerede behov for begge opfyldt.

Disse standarddefinitioner betyder, at systemer, når de er udpeget til at tilhøre en rolle eller en anden, kan "bygge sig selv" automatisk. Et nyt system kan oprettes af en administrator, der anmoder om et system, eller et kapacitetsovervågningssystem kan afgøre, at der er behov for yderligere kapacitet til en rolle og starte nye serverinstanser automatisk uden nogen menneskelig indgriben overhovedet. På det tidspunkt, systemet anmodes om, af en menneskelig eller automatisk, udpeges rollen, og systemet vil, via automatiseringsframeworket, forvandle sig til en fuldt konfigureret og opdateret "node." Ingen menneskelig systemadministrationsindgriben er nødvendig. Processen er hurtig, enkel og, vigtigst af alt, fuldstændig gentagelig.

At definere systemer i kode har nogle ikke-åbenlyse konsekvenser. En er, at sikkerhedskopier af komplette systemer ikke længere er nødvendige. Hvorfor sikkerhedskopiere et system, som du kan genskabe med minimal indsats næsten øjeblikkeligt? Lokale data fra databasesystemer skal sikkerhedskopieres, men kun databasedataene, ikke hele systemet. Dette kan i høj grad reducere belastningen på backupinfrastrukturer og gøre gendannelsesprocesser hurtigere og mere pålidelige.

Mængden af dokumentation, der er nødvendig for systemer, der allerede er defineret i kode, er meget minimal. I Snowflake-miljøer er systemadministratoren nødt til at vedligeholde dokumentation specifik for hver host og vedligeholde denne dokumentation manuelt. Dette er meget tidskrævende og fejlbehæftet. Systemer defineret via central kode behøver lidt til ingen dokumentation, og dokumentationen kan håndteres på gruppeniveau, ikke det individuelle nodeniveau.

Det er også let at teste systemer, der er defineret i kode. Du kan oprette et system via kode, teste det og vide, at når du flytter den definition til produktion, vil produktionssystemet blive oprettet gentageligt nøjagtigt som det blev oprettet i test. I Snowflake-miljøer er det meget almindeligt at have testpraksis, der forsøger at gøre dette, men gør det via manuelle bestræbelser og er tilbøjelige til at være sløsede og ikke præcis gentagelige, og meget ofte vil politik diktere, at det er hurtigere at efterligne gentagelighed end faktisk at stræbe efter det. Kodedefinerede systemer omgår disse problemer og gør testning langt mere værdifuld.

Ud over at definere et antal noder til at eksistere inden for hver rolle kan systemet reprovisionere en hel arkitektur fra bunden automatisk. At genopbygge efter en katastrofe eller etablere et sekundært site kan gøres meget hurtigt og nemt. Ligeledes er flytning mellem lokalt hostede systemer og fjernt hostede systemer, herunder dem fra virksomheder som Amazon, Microsoft, IBM, Rackspace og andre, ekstremt nem.

Selvfølgelig er der i DevOps-verdenen stor værdi i at bruge cloudarkitekturer til at muliggøre det mest ekstreme niveau af automatisering, men at bruge cloudarkitekturer er unødvendigt for at udnytte disse typer værktøjer. Og selvfølgelig kunne en kodedefineret arkitektur bruges delvist, mens manuel administration også kunne implementeres til en hybrid-tilgang, men dette anbefales sjældent på individuelle systemer. Det er generelt langt bedre at have to miljøer, et der administreres som Snowflakes og et der administreres som DevOps, når de to tilgange er påkrævet. Dette gør en langt bedre hybridisering. Jeg har set dette fungere ekstremt godt i et enterprise-miljø med mere end titusindvis af "Snowflake"-servere, hver meget unik, men med et dedikeret miljø af titusindvis af noder, der administreres på en DevOps-måde, fordi alle noderne skulle være identiske og udskiftelige med en af to mulige konfigurationer. Hybridisering var meget effektiv.

DevOps-tilgangen kommer dog også med store forbehold. De kompetencer, der er nødvendige for at administrere et system på denne måde, er langt større end dem, der er nødvendige til traditionel systemadministration, da som minimum al traditionel systemadministrationsviden stadig er nødvendig plus solid programmeringsviden typisk af moderne sprog som Python og Ruby og kendskab til de specifikke frameworks. Dette udvidede vidensbasekrav betyder, at DevOps-udøvere ikke kun er sjældne, men også dyre. Det betyder også, at universitetsuddannelse, der allerede er langt fra at forberede enten systemadministratorer eller udviklere til den professionelle verden, nu er endnu længere fra at forberede dimittender til at arbejde under en DevOps-model.

Systemadministratorer, der arbejder i hver af disse to lejre, har en tendens til at se alle systemer som havende behov for at passe ind i deres egen form. Nye DevOps-udøvere tror ofte, at Snowflake-systemer er arv og skal opdateres. Snowflake (traditionelle) administratorer har en tendens til at se "infrastructure as code"-bevægelsen som tåbelig, fyldt med unødvendig overhead, alt for kompliceret og meget niche.

Virkeligheden er, at begge tilgange har en enorm mængde fortjeneste, og begge vil forblive ekstremt levedygtige. Begge giver mening for meget forskellige arbejdsbelastninger, og store organisationer vil, formoder jeg, almindeligvis se begge på plads via en form for hybridisering. På SMB-markedet, hvor der typisk kun er et meget lille antal servere, ingen skaleringsfordel til at begrunde cloudarkitekturer og en høj forskel mellem systemer, formoder jeg, at DevOps næsten på ubestemt tid vil forblive uden for normen, da den overhead og de yderligere kompetencer, der er nødvendige for at få det til at fungere, er upraktiske eller endda umulige at anskaffe. Større organisationer er nødt til at se på deres arbejdsbelastninger. Mange traditionelle arbejdsbelastninger og meget traditionel software er ikke godt egnet til DevOps-tilgangen, især cloudautomatisering, og vil enten kræve hybridisering eller et upraktisk højt niveau af kodning på en per-system-basis, der gør DevOps-modellen umulig at begrunde. Men arbejdsbelastninger, der er bygget på webarkitekturer, eller som kan skalere horisontalt ekstremt godt, vil drage stor fordel af DevOps-modellen i stor skala. Dette kan gælde for store enterprise-virksomheder eller mindre virksomheder, der sandsynligvis producerer hostede applikationer til ekstern brug.

Denne forskel i tilgang betyder, at f.eks. i USA er det meste af USA sammensat af virksomheder, der vil forblive fokuserede på Snowflake-forvaltningsmodellen, mens nogle østkystvirksomheder effektivt kan evaluere DevOps-modellen og begynde at bevæge sig i den retning. Men på vestkysten, hvor mere moderne arkitekturer og et meget større fokus på hostede applikationer og applikationer til ekstern brug er de drivende økonomiske faktorer, bevæger DevOps sig allerede fra nybegynder til moden, etableret normalitet. DevOps- og Snowflake-tilgange vil sandsynligvis forblive stærkt adskilt af regioner på denne måde, ligesom IT generelt ser forskellige kompetencer migrere til forskellige regioner. Det ville ikke overraske at se DevOps begynde at få fodfæste på markeder som Austin, hvor traditionel IT har klaret sig temmelig dårligt.

Ingen tilgang er bedre eller værre – de er to forskellige tilgange, der betjener to meget forskellige måder at provisionere systemer på og to grundlæggende forskellige behov for disse systemer. Med fremkomsten af cloudarkitekturer og DevOps-modellen er det imidlertid afgørende vigtigt, at eksisterende systemadministratorer forstår, hvad DevOps-modellen betyder, og hvornår den gælder, så de korrekt kan evaluere deres egne arbejdsbelastninger og unikke behov. En stor del af den traditionelle Snowflake-systemadministrationsverden vil over tid migrere til DevOps-modellen. Vi er meget langt fra at nå en stabil tilstand i branchen med hensyn til balancen af disse to modeller.

Oprindeligt publiceret på StorageCraft Blog.