Om DevOps og Snowflakes

Man kan knapt bevege seg i IT-bransjen for tiden uten å høre folk snakke om DevOps. DevOps er det hete nye temaet i bransjen, og tar over der praten om cloud slapp – og å høre folk snakke om det kan man tro at tradisjonell systemadministrasjon allerede er død og begravet.

Først må vi snakke om hva vi mener med DevOps. Dette kan være forvirrende fordi, som med cloud, et eldre begrep ofte stjeles for å bety noe annet eller, i beste fall, relatert til noe som allerede eksisterte. Tradisjonell DevOps var sammenslåingen av utvikler- og driftsroller. Fra 1960-tallet til 1990-tallet var dette standardmåten å drive systemer på. I denne verden var menneskene som skrev programvaren generelt de samme som deployet og vedlikeholdt den. Derav sammenslåingen av «developer» og «operations» – operations er et halv-standard begrep for rollen som systemadministrator. Disse rollene ble ikke vanligvis atskilt før fremveksten av «IT-avdelingen» på 1990- og 2000-tallet. Siden da har tilbakevendingen til sammenslåingen av de to rollene begynt å stige i popularitet igjen, primært på grunn av den måten de to kan operere sammen med stor verdi i mange moderne, hostede web-applikasjonssituasjoner.

Der DevOps ofte omtales i dag er ikke som en streng sammenslåing av utviklerne og driftspersonalet, men som en modifikasjon av driftspersonalet med et mye høyere fokus på koding – ikke av selve applikasjonen, men i å definere applikasjonsinfrastrukturer som kode som en naturlig utvidelse av cloud-arkitekturer. Dette kan være ganske forvirrende i begynnelsen. Det som er viktig å merke seg er at tradisjonell DevOps ikke er det som vanligvis skjer i dag, men en ny «falsk» DevOps der utviklere fortsatt er utviklere og operations fortsatt er operations, men der operations har utviklet seg til en ny «kode-tung» rolle som fortsetter å fokusere på å administrere servere som kjører kode levert av utviklerne.

Det som er betydelig i dag er at rollen som systemadministrator har begynt å forgrene seg til to beslektede, men betydelig forskjellige roller – hvorav én feilaktig kalles DevOps av det meste av bransjen i dag (det meste av bransjen er for ung til å huske da DevOps var normen, ikke unntaket, og absolutt ikke noe nytt og originalt). Jeg refererer til disse to aspektene av systemadministratorrollen her som DevOps- og Snowflake-tilnærmingene.

Jeg bruker begrepet Snowflake for å referere til tradisjonelle arkitekturer for systemer fordi hver enkelt server kan sees som et «unikt Snowflake». De er alle forskjellige – i hvert fall i den forstand at de ikke på noen måte administreres slik at de holdes identiske. Dette betyr ikke at de alle trenger å være unike, bare at de beholder potensialet til å være det. I tradisjonelle miljøer vil en systemadministrator logge inn på hver server individuelt for å jobbe med dem. En viss grad av scripting er vanlig for å lette administrasjonsoppgaver, men i kjernen involverer rollen mye tid med å jobbe på individuelle systemer.

Å lette administrasjonen av Snowflake-arkitekturer involverte ofte forsøk på å minimere forskjeller mellom systemer på fornuftige måter. Dette starter generelt med ting som å velge ett enkelt standard operativsystem og versjon (Windows 2012 R2 eller Red Hat Enterprise Linux 7) fremfor å la hver serverinstallasjon være et annet OS eller versjon. Denne standardiseringen kan virke grunnleggende, men mange miljøer mangler denne standardiseringen selv i dag.

Et neste steg er vanligvis å opprette en standard deployeringsmetodikk eller et gull-masterimage som brukes til å lage alle systemer, slik at basisoperativsystemet og alle basispakker – ofte inkludert systemtilpasning, overvåkingspakker, sikkerhetspakker, autentiseringskonfigurasjon og lignende modifikasjoner – er standard og deployet ensartet. Dette gir et felles utgangspunkt for alle systemer for å minimere avvik. Men teknisk sett sikrer de bare et standard startpunkt, og over tid må avvik i konfigurasjon forventes.

Utover disse stegene bruker Snowflake-miljøer typisk tilpassede, skreddersydde administrasjonsskripter eller administrasjonsverktøy for å opprettholde en viss standardisering mellom systemer over tid. Jo mer fellesskap som eksisterer mellom systemer, jo enklere er de å vedlikeholde og feilsøke, og jo mindre kunnskap trengs av administrasjonspersonalet. Mer standardisering betyr færre overraskelser, færre ukjente faktorer og mye bedre testemuligheter.

I et enkelt systemadministratormiljø med gode praksiser og verktøy kan Snowflake-miljøer oppnå en høy grad av standardisering. Men i miljøer med mange systemadministratorer – spesielt de som støttes døgnet rundt fra mange regioner – og med et stort antall systemer, kan standardisering, selv med svært flittige praksiser, bli svært vanskelig. Og det er selv før vi tar tak i de åpenbare problemene med det faktum at forskjellige pakker og muligens pakkeversioner er nødvendige på systemer som utfører forskjellige roller.

DevOps-tilnærmingen vokser organisk ut av cloud-arkitekturmodellen. Cloud-arkitektur er designet rundt automatisk opprettede og automatisk ødelagte, bredt identiske systemer (i hvert fall i grupper) som kontrolleres gjennom et programmatisk grensesnitt eller API. Denne modellen egner seg, ganske åpenbart, til å kontrolleres sentralt gjennom et administrasjonssystem fremfor gjennom de manuelle innsatsene til en systemadministrator. Manuell administrasjon er effektivt umulig og fullstendig upraktisk under denne modellen. Individuelle systemer er ikke unike som i Snowflake-modellen, og ethvert avvik vil skape alvorlige problemer.

Ideen som har oppstått fra cloud-arkitekturverdenen er at systemsarkitektur bør defineres sentralt «i kode» fremfor på selve serverne. Dette høres forvirrende ut i begynnelsen, men gir mye mening når vi ser på det mer dyptgående. For å støtte denne modellen har det begynt å vokse frem en ny type systemadministrasjonsverktøy som ennå ikke har fått et virkelig standardnavn, men som ofte kalles et systemautomatiseringsverktøy, DevOps-rammeverk, IT-automatiseringsverktøy eller rett og slett «infrastructure as code»-verktøy. Vanlige verktøysett i dette området inkluderer Puppet, Chef, CFEngine og SaltStack.

Ideen bak disse automatiseringsverktøysettene er at en sentral tjeneste brukes til å administrere og kontrollere alle systemer. Denne sentrale autoriteten administrerer individuelle servere ved hjelp av kodebaserte beskrivelser av hvordan systemet skal se ut og oppføre seg. I Chef-verdenen kalles disse «recipes» for å være søt, men analogien fungerer godt. Koden for hvert system kan inkludere informasjon som en liste over hvilke pakker og pakkeversjoner som skal installeres, hvilke systemkonfigurasjoner som skal endres og filer som skal kopieres til boksen. I mange tilfeller håndteres beslutninger om disse deployeringene eller endringene gjennom potensielt kompleks logikk – og derav behovet for faktisk kode fremfor noe mer forenklet som markup eller maler. Systemer grupperes deretter etter rolle og administreres som grupper. «Web server»-rollen kan fortelle et sett med systemer å installere Apache og PHP og konfigurere minne til å bruke lite swap. «SQL Server»-rollen kan installere MS SQL Server og spesielle backupverktøy som kun brukes for den applikasjonen, og konfigurere minne til å justeres etter ønske for en pool av SQL Server-maskiner. Dette er bare eksempler. Typisk vil en organisasjon ha svært mange roller – noen kan være generiske som «web server» og andre mye mer spesifikke for å støtte svært spesifikke applikasjoner. Roller kan generelt lagres, slik at et system kan være både en «web server» og en «java server» som får de kombinerte behovene til begge oppfylt.

Disse standarddefinisjonene betyr at systemer, når de er utpekt som tilhørende én rolle eller en annen, kan «bygge seg selv» automatisk. Et nytt system kan opprettes av en administrator som ber om et system, eller et kapasitetsovervåkningssystem kan bestemme at ytterligere kapasitet er nødvendig for en rolle og spawn nye serverinstanser automatisk uten noen menneskelig intervensjon overhodet. På det tidspunktet systemet etterspørres – av et menneske eller automatisk – utpekes rollen og systemet vil, ved hjelp av automatiseringsrammeverket, transformere seg til en fullt konfigurert og oppdatert «node». Ingen menneskelig systemadministrasjonsintervensjon nødvendig. Prosessen er rask, enkel og, viktigst av alt, fullstendig repeterbar.

Å definere systemer i kode har noen ikke-åpenbare konsekvenser. En er at backup av komplette systemer ikke lenger er nødvendig. Hvorfor ta backup av et system du kan gjenskape, med minimal innsats, nesten umiddelbart? Lokale data fra databasesystemer ville trenge å bli tatt backup av, men kun databasedataene, ikke hele systemet. Dette kan i stor grad redusere belastningen på backup-infrastrukturer og gjøre gjenopprettingsprosesser raskere og mer pålitelige.

Mengden dokumentasjon som trengs for systemer allerede definert i kode er svært minimal. I Snowflake-miljøer må systemadministratoren vedlikeholde dokumentasjon spesifikk for hver vert og vedlikeholde denne dokumentasjonen manuelt. Dette er svært tidkrevende og feiltilbøyelig. Systemer definert ved hjelp av sentral kode trenger lite til ingen dokumentasjon, og dokumentasjonen kan håndteres på gruppenivå, ikke det individuelle nodenivået.

Testing av systemer som er definert i kode er også enkelt å gjøre. Du kan opprette et system via kode, teste det og vite at når du flytter den definisjonen til produksjon, vil produksjonssystemet bli opprettet repeterbart akkurat slik det ble opprettet under testing. I Snowflake-miljøer er det svært vanlig å ha testpraksiser som forsøker å gjøre dette, men gjør det gjennom manuelle innsatser og er tilbøyelige til å være slurvete og ikke nøyaktig repeterbare, og svært ofte vil politikk diktere at det er raskere å etterligne repeterbarhet enn å faktisk strebe etter det. Kodedefinerte systemer omgår disse problemene og gjør testing langt mer verdifull.

Utover behovet for å definere et antall noder som skal eksistere innenfor hver rolle, kan systemet reprovisionere en hel arkitektur, fra bunnen av, automatisk. Gjenoppbygging etter en katastrofe eller å bringe opp et sekundært nettsted kan gjøres svært raskt og enkelt. Også å flytte mellom lokalt hostede systemer og eksternt hostede systemer – inkludert de fra selskaper som Amazon, Microsoft, IBM, Rackspace og andre – er ekstremt enkelt.

Selvfølgelig har det i DevOps-verdenen stor verdi å bruke cloud-arkitekturer for å muliggjøre det mest ekstreme nivået av automatisering, men bruk av cloud-arkitekturer er unødvendig for å utnytte disse typene verktøy. Og selvfølgelig kan det å ha en kodedefinert arkitektur brukes delvis mens manuell administrasjon også kan implementeres for en hybrid-tilnærming, men dette anbefales sjelden for individuelle systemer. Det er generelt langt bedre å ha to miljøer – ett som administreres som Snowflakes og ett som administreres som DevOps – når de to tilnærmingene er påkrevd. Dette skaper en langt bedre hybridisering. Jeg har sett dette fungere ekstremt godt i et enterprise-miljø med mer enn titusenvis av «Snowflake»-servere, hver svært unik, men med et dedikert miljø med titusenvis av noder som ble administrert på en DevOps-måte fordi alle nodene skulle være identiske og utskiftbare ved hjelp av én av to mulige konfigurasjoner. Hybridisering var svært effektivt.

DevOps-tilnærmingen kommer imidlertid med store forbehold. Ferdighetene som er nødvendige for å administrere et system på denne måten er langt større enn de som trengs for tradisjonell systemadministrasjon, ettersom all tradisjonell systemadministrasjonskunnskap fortsatt er nødvendig som et minimum, pluss solid programmeringskunnskap typisk av moderne språk som Python og Ruby og kunnskap om de spesifikke rammeverkene i spørsmålet. Dette utvidede kunnskapsbasekravet betyr at DevOps-utøvere ikke bare er sjeldne men også dyre. Det betyr også at universitetsutdanning – allerede langt unna å forberede enten systemadministratorer eller utviklere til den profesjonelle verden – nå er enda lenger unna å forberede nyutdannede til å jobbe under en DevOps-modell.

Systemadministratorer som jobber i hver av disse to leirene har en tendens til å se alle systemer som å måtte passe inn i sin egen form. Nye DevOps-utøvere tror ofte at Snowflake-systemer er legacy og trenger å oppdateres. Snowflake (tradisjonelle) admins har en tendens til å se «infrastructure as code»-bevegelsen som tåpelig, fylt med unødvendig overhead, altfor komplisert og svært nisje-preget.

Realiteten er at begge tilnærmingene har en enorm mengde meritter og begge vil forbli ekstremt levedyktige. Begge gir mening for svært forskjellige arbeidsbelastninger, og store organisasjoner vil, mistenker jeg, ofte se begge på plass via en form for hybridisering. I SMB-markedet der det typisk er bare et lite antall servere, ingen skaleringshendel til å rettferdiggjøre cloud-arkitekturer og høy spredning mellom systemer, mistenker jeg at DevOps vil forbli nesten på ubestemt tid utenfor normen, ettersom overhead og de ekstra ferdighetene som er nødvendige for å få det til å fungere er upraktiske eller til og med umulige å skaffe. Større organisasjoner må se på sine arbeidsbelastninger. Mange tradisjonelle arbeidsbelastninger og mye av tradisjonell programvare er ikke godt egnet til DevOps-tilnærmingen, spesielt cloud-automatisering, og vil enten kreve hybridisering eller et upraktisk høyt kodingsnivå på per-system-basis som gjør DevOps-modellen umulig å rettferdiggjøre. Men arbeidsbelastninger bygget på web-arkitekturer eller som kan skalere horisontalt ekstremt godt, vil ha stor nytte av DevOps-modellen i skala. Dette kan gjelde store enterprise-selskaper eller mindre selskaper som sannsynligvis produserer hostede applikasjoner for eksternt forbruk.

Denne forskjellen i tilnærming betyr at, i USA for eksempel, er det meste av USA bestående av selskaper som vil forbli fokusert på Snowflake-administrasjonsmodellen, mens noen østkystselskaper effektivt kan evaluere DevOps-modellen og begynne å bevege seg i den retningen. Men på vestkysten – der mer moderne arkitekturer og et mye større fokus på hostede applikasjoner og applikasjoner for eksternt forbruk er de drivende økonomiske faktorene – beveger DevOps seg allerede fra nykommer til moden, etablert normalitet. DevOps- og Snowflake-tilnærmingene vil sannsynligvis forbli sterkt segregert etter regioner på denne måten, akkurat som IT generelt ser forskjellige ferdigheter migrere til forskjellige regioner. Det ville ikke overraske å se DevOps begynne å feste seg i markeder som Austin, der tradisjonell IT har prestert ganske dårlig.

Ingen tilnærming er bedre eller verre – de er to forskjellige tilnærminger som betjener to svært forskjellige måter å provisjonere systemer på og to fundamentalt forskjellige behov for disse systemene. Med fremveksten av cloud-arkitekturer og DevOps-modellen er det imidlertid kritisk viktig at eksisterende systemadministratorer forstår hva DevOps-modellen betyr og når den gjelder, slik at de korrekt kan evaluere sine egne arbeidsbelastninger og unike behov. En stor del av den tradisjonelle Snowflake-systemadministrasjonsverdenen vil migrere over tid til DevOps-modellen. Vi er svært langt fra å nå en stabil tilstand i bransjen med hensyn til balansen mellom disse to modellene.

Opprinnelig publisert på StorageCraft-bloggen.