Om DevOps och Snowflakes

Man kan knappt svinga en ordspråklig katt inom IT nuförtiden utan att höra människor tala om DevOps. DevOps är det heta nya ämnet i branschen som tar vid där pratet om molnet slutade, och när man hör människor tala om det skulle man kunna tro att traditionell systemadministration redan är död och begraven.

Först måste vi tala om vad vi menar med DevOps. Detta kan vara förvirrande eftersom, precis som med molnet, en äldre term ofta stjäls för att betyda något annat eller, i bästa fall, något relaterat till något som redan existerade. Traditionell DevOps var sammanslagningen av utvecklar- och driftroller. Från 1960-talet till och med 1990-talet var detta det normala sättet att driva system. I denna värld var de personer som skrev mjukvaran i allmänhet samma personer som driftsatte och underhöll den. Därav sammanslagningen av “developer” (utvecklare) och “operations” (drift), där operations är en halvstandardiserad term för rollen som systemadministratör. Dessa roller var inte vanligen åtskilda förrän framväxten av “IT-avdelningen” på 1990- och 2000-talet. Sedan dess har återgången till sammanslagningen av de två rollerna börjat öka i popularitet igen, främst på grund av det sätt på vilket de två kan samverka med stort värde i många moderna, hostade webbapplikationssituationer.

Där DevOps ofta talas om i dag är inte som en strikt sammanslagning av utvecklarna och driftpersonalen, utan som en modifiering av driftpersonalen med ett mycket högre fokus på att koda inte själva applikationen utan på att definiera applikationsinfrastrukturer som kod, som en naturlig förlängning av molnarkitekturer. Detta kan vara ganska förvirrande till en början. Det som är viktigt att notera är att traditionell DevOps inte är vad som vanligen sker i dag, utan en ny “falsk” DevOps där utvecklare förblir utvecklare och drift förblir drift, men där drift har utvecklats till en ny “kodtung” roll som fortsätter att fokusera på att hantera servrar som kör kod som tillhandahålls av utvecklarna.

Det som är betydelsefullt i dag är att rollen som systemadministratör har börjat delas upp i två relaterade, men betydligt olika roller, varav den ena felaktigt kallas DevOps av merparten av branschen i dag (där merparten av branschen är för ung för att minnas när DevOps var normen, inte undantaget, och förvisso inte något nytt och nyskapande). Jag refererar till dessa två aspekter av systemadministratörsrollen här som tillvägagångssätten DevOps och Snowflake.

Jag använder termen Snowflake (snöflinga) för att referera till traditionella arkitekturer för system, eftersom varje enskild server kan ses som en “unik Snowflake”. De är alla olika, åtminstone i den mån som de inte på något sätt hanteras på ett sådant sätt att de hålls identiska. Detta betyder inte att de måste vara alla unika, bara att de behåller potentialen att vara det. I traditionella miljöer loggar en systemadministratör in på varje server individuellt för att arbeta på dem. En viss mängd skriptning är vanlig för att underlätta administrationsuppgifter, men i grunden innebär rollen mycket tid med att arbeta på enskilda system.

Att underlätta administration av Snowflake-arkitekturer innebar ofta försök att minimera skillnader mellan system på rimliga sätt. Detta börjar i allmänhet med saker som att välja ett enda standardoperativsystem och en standardversion (Windows 2012 R2 eller Red Hat Enterprise Linux 7) i stället för att tillåta varje serverinstallation att vara ett annat OS eller en annan version. Denna standardisering kan tyckas grundläggande, men många verksamheter saknar denna standardisering än i dag.

Ett nästa steg är vanligen att skapa en standardmetodik för driftsättning eller en gold master-avbild som används för att skapa alla system, så att basoperativsystemet och alla baspaket, ofta inklusive systemanpassning, övervakningspaket, säkerhetspaket, autentiseringskonfiguration och liknande modifieringar är standardiserade och driftsätts enhetligt. Detta tillhandahåller en gemensam utgångspunkt för alla system för att minimera divergens. Men tekniskt sett säkerställer de endast en standardiserad utgångspunkt, och över tid måste divergens i konfiguration förutses.

Bortom dessa steg använder Snowflake-miljöer vanligtvis specialanpassade, skräddarsydda administrationsskript eller hanteringsverktyg för att upprätthålla en viss standardisering mellan systemen över tid. Ju fler likheter som existerar mellan systemen, desto lättare är de att underhålla och felsöka och desto mindre kunskap krävs av administrationspersonalen. Mer standardisering innebär färre överraskningar, färre okända faktorer och mycket bättre testningsförmåga.

I en miljö med en enda systemadministratör med god praxis och goda verktyg kan Snowflake-miljöer anta en hög grad av standardisering. Men i miljöer med många systemadministratörer, särskilt sådana som stöds dygnet runt från många regioner, och med ett stort antal system, kan standardisering, även med mycket samvetsgrann praxis, bli mycket svår. Och det är till och med innan vi tar itu med de uppenbara frågorna kring det faktum att olika paket och möjligen paketversioner behövs på system som utför olika roller.

Tillvägagångssättet DevOps växer organiskt fram ur molnarkitekturmodellen. Molnarkitektur är utformad kring automatiskt skapade och automatiskt förstörda, i stort sett identiska system (åtminstone i grupper) som kontrolleras genom ett programmatiskt gränssnitt eller API. Denna modell lämpar sig, ganska uppenbart, för att kontrolleras centralt genom ett hanteringssystem snarare än genom de manuella ansträngningarna hos en systemadministratör. Manuell administration är i praktiken omöjlig och fullständigt opraktisk under denna modell. Enskilda system är inte unika som i Snowflake-modellen och varje divergens kommer att skapa allvarliga problem.

Idén som har vuxit fram ur molnarkitekturvärlden är att systemarkitektur bör definieras centralt “i kod” snarare än på själva servrarna. Detta låter förvirrande till en början, men blir mycket logiskt när vi ser på det mer ingående. För att stödja denna modell har en ny typ av systemhanteringsverktyg, som ännu inte antagit ett riktigt standardiserat namn men som ofta kallas systemautomatiseringsverktyg, DevOps-ramverk, IT-automatiseringsverktyg eller helt enkelt “infrastruktur som kod”-verktyg, börjat framträda. Vanliga verktygsuppsättningar i detta område inkluderar Puppet, Chef, CFEngine och SaltStack.

Idén bakom dessa automatiseringsverktygsuppsättningar är att en central tjänst används för att hantera och kontrollera alla system. Denna centrala auktoritet hanterar enskilda servrar med hjälp av kodbaserade beskrivningar av hur systemet bör se ut och bete sig. I Chef-världen kallas dessa “recept” för att vara fyndiga, men analogin fungerar väl. Varje systems kod kan inkludera information såsom en lista över vilka paket och paketversioner som bör installeras, vilka systemkonfigurationer som bör modifieras och filer som ska kopieras till maskinen. I många fall hanteras beslut om dessa driftsättningar eller modifieringar genom potentiellt komplex logik, och därav behovet av faktisk kod snarare än något mer förenklat såsom markup eller mallar. System grupperas sedan efter roll och hanteras som grupper. Rollen “webbserver” kan tala om för en uppsättning system att installera Apache och PHP och konfigurera minnet att växla (swappa) mycket lite. Rollen “SQL Server” kan installera MS SQL Server och särskilda säkerhetskopieringsverktyg som endast används för den applikationen och konfigurera minnet att trimmas som önskat för en pool av SQL Server-maskiner. Detta är bara exempel. Vanligtvis skulle en organisation ha ett stort antal roller, vissa kan vara generiska såsom “webbserver” och andra mycket mer specifika för att stödja mycket specifika applikationer. Roller kan i allmänhet skiktas, så ett system kan vara både en “webbserver” och en “java-server” och få de kombinerade behoven hos båda tillgodosedda.

Dessa standardiserade definitioner innebär att system, när de väl utsetts att tillhöra den ena eller andra rollen, kan “bygga sig själva” automatiskt. Ett nytt system kan skapas genom att en administratör begär ett system, eller också kan ett kapacitetsövervakningssystem besluta att ytterligare kapacitet behövs för en roll och automatiskt starta nya serverinstanser utan någon som helst mänsklig inblandning. Vid den tidpunkt då systemet begärs, av en människa eller automatiskt, utses rollen och systemet kommer, med hjälp av automatiseringsramverket, att förvandla sig självt till en fullständigt konfigurerad och uppdaterad “nod”. Ingen mänsklig systemadministrationsinblandning krävs. Processen är snabb, enkel och, allra viktigast, fullständigt repeterbar.

Att definiera system i kod har vissa icke-uppenbara konsekvenser. En är att säkerhetskopior av kompletta system inte längre behövs. Varför säkerhetskopiera ett system som du kan återskapa, med minimal ansträngning, nästan omedelbart? Lokala data från databassystem skulle behöva säkerhetskopieras, men endast databasdata, inte hela systemet. Detta kan i hög grad minska belastningen på säkerhetskopieringsinfrastrukturer och göra återställningsprocesser snabbare och mer tillförlitliga.

Mängden dokumentation som behövs för system som redan är definierade i kod är mycket minimal. I Snowflake-miljöer behöver systemadministratören upprätthålla dokumentation som är specifik för varje värd och underhålla den dokumentationen manuellt. Detta är mycket tidskrävande och felbenäget. System som definieras med hjälp av central kod behöver lite eller ingen dokumentation, och dokumentationen kan hanteras på gruppnivå, inte på den enskilda nodnivån.

Att testa system som är definierade i kod är lätt att göra också. Du kan skapa ett system med hjälp av kod, testa det och veta att när du flyttar den definitionen till produktion kommer produktionssystemet att skapas repeterbart exakt som det skapades i testning. I Snowflake-miljöer är det mycket vanligt att ha testningsrutiner som försöker göra detta men gör det genom manuella ansträngningar och är benägna att vara slarviga och inte exakt repeterbara, och mycket ofta kommer politiken att diktera att det är snabbare att efterlikna repeterbarhet än att faktiskt sträva efter den. Koddefinierade system kringgår dessa problem och gör testning långt mer värdefull.

Bortsett från att behöva definiera ett antal noder som ska existera inom varje roll, kan systemet återförse en hel arkitektur, från grunden, automatiskt. Att återuppbygga efter en katastrof eller att resa en sekundär plats kan göras mycket snabbt och enkelt. Att förflytta sig mellan lokalt hostade system och fjärrhostade system, inklusive sådana från företag som Amazon, Microsoft, IBM, Rackspace och andra, är dessutom extremt enkelt.

Naturligtvis finns det i DevOps-världen ett stort värde i att använda molnarkitekturer för att möjliggöra den mest extrema nivån av automatisering, men att använda molnarkitekturer är onödigt för att dra nytta av dessa typer av verktyg. Och, naturligtvis, skulle en koddefinierad arkitektur kunna användas delvis medan manuell administration också skulle kunna implementeras för ett hybridtillvägagångssätt, men detta rekommenderas sällan på enskilda system. Det är i allmänhet långt bättre att ha två miljöer, en som hanteras som Snowflakes och en som hanteras som DevOps, när de två tillvägagångssätten är påbjudna. Detta utgör en långt bättre hybridisering. Jag har sett detta fungera extremt väl i en företagsmiljö med åtskilliga tiotusentals “Snowflake”-servrar, var och en mycket unik, men med en dedikerad miljö om tiotusentals noder som hanterades på ett DevOps-sätt eftersom alla noderna skulle vara identiska och utbytbara med hjälp av en av två möjliga konfigurationer. Hybridisering var mycket effektiv.

Tillvägagångssättet DevOps kommer emellertid också med betydande förbehåll. De kompetensuppsättningar som är nödvändiga för att hantera ett system på detta sätt är långt större än de som behövs för traditionell systemadministration, eftersom, som ett minimum, all traditionell systemadministrationskunskap fortfarande behövs plus gedigen programmeringskunskap, vanligen i moderna språk som Python och Ruby, samt kunskap om de specifika ramverken i fråga. Detta krav på en utökad kunskapsbas innebär att DevOps-utövare inte bara är sällsynta utan dyra också. Det innebär också att universitetsutbildning, som redan är långt ifrån att förbereda vare sig systemadministratörer eller utvecklare för den professionella världen, nu är ännu längre ifrån att förbereda utexaminerade för att arbeta under en DevOps-modell.

Systemadministratörer som arbetar i vart och ett av dessa två läger har en tendens att se alla system som om de behöver passa in i deras egen form. Nya DevOps-utövare tror ofta att Snowflake-system är föråldrade och behöver uppdateras. Snowflake-administratörer (traditionella) tenderar att se “infrastruktur som kod”-rörelsen som fånig, fylld med onödig omkostnad, alltför komplicerad och mycket nischad.

Verkligheten är att båda tillvägagångssätten har ett enormt mått av förtjänst och båda kommer att förbli extremt gångbara. Båda är vettiga för mycket olika arbetslaster, och stora organisationer kommer, misstänker jag, vanligen att se båda på plats via någon form av hybridisering. På SMB-marknaden, där det vanligtvis bara finns ett litet antal servrar, ingen skalningshävstång som rättfärdigar molnarkitekturer och en hög disparitet mellan systemen, misstänker jag att DevOps kommer att förbli nästintill på obestämd tid utanför normen, eftersom omkostnaden och de ytterligare färdigheter som är nödvändiga för att få det att fungera är opraktiska eller till och med omöjliga att förvärva. Större organisationer måste se på sina arbetslaster. Många traditionella arbetslaster och mycket av traditionell mjukvara är inte väl lämpade för DevOps-tillvägagångssättet, särskilt molnautomatisering, och kommer antingen att kräva hybridisering eller en opraktiskt hög nivå av kodning per system, vilket gör DevOps-modellen omöjlig att rättfärdiga. Men arbetslaster byggda på webbarkitekturer eller som kan skala horisontellt extremt väl kommer att dra stor nytta av DevOps-modellen i stor skala. Detta skulle kunna gälla stora företag eller mindre företag som sannolikt producerar hostade applikationer för extern konsumtion.

Denna skillnad i tillvägagångssätt innebär att, i exempelvis USA, större delen av USA består av företag som kommer att förbli fokuserade på Snowflake-hanteringsmodellen, medan vissa företag på östkusten skulle kunna utvärdera DevOps-modellen effektivt och börja röra sig i den riktningen. Men på västkusten, där modernare arkitekturer och ett mycket större fokus på hostade applikationer och applikationer för extern konsumtion är de drivande ekonomiska faktorerna, rör sig DevOps redan från nykomling till mogen, etablerad normalitet. Tillvägagångssätten DevOps och Snowflake kommer sannolikt att förbli kraftigt segregerade efter regioner på detta sätt, precis som IT, i allmänhet, ser olika kompetensuppsättningar migrera till olika regioner. Det skulle inte vara förvånande att se DevOps börja få fäste på marknader såsom Austin, där traditionell IT har presterat ganska dåligt.

Ingendera tillvägagångssättet är bättre eller sämre, de är två olika tillvägagångssätt som betjänar två mycket olika sätt att förse system och två olika fundamentala behov hos dessa system. Med framväxten av molnarkitekturer och DevOps-modellen är det emellertid kritiskt viktigt att befintliga systemadministratörer förstår vad DevOps-modellen innebär och när den är tillämplig, så att de korrekt kan utvärdera sina egna arbetslaster och unika behov. En stor del av den traditionella Snowflake-systemadministrationsvärlden kommer, över tid, att migrera till DevOps-modellen. Vi är mycket långt från att nå ett stabilt tillstånd i branschen vad gäller balansen mellan dessa två modeller.

Ursprungligen publicerad på StorageCraft-bloggen.