Varför DevOps?

Varför DevOps?

Om man inte har anammat DevOps inom sin organisation än så är det något att börja fundera på innan det är för sent. Man skulle kunna dra paralleller mellan vad LEAN betydde när det introducerades i tillverkningsindustrin. De företag som då inte hängde med i utvecklingen blev ifrånsprungna utav sina konkurrenter och hamnade i värsta fall i konkurs.

Vi kan få se något liknande med DevOps. Idag introducerar flertalet stora IT-bolag, tack vare DevOps, nya funktioner snabbare och mer frekvent vilket skapar stort mervärde för deras kunder. Men vad som är lika viktigt enlig min mening är att dom får snabb feedback på vad som funkar och inte, vilket gör att de snabbt kan åtgärda eller helt enkelt ta bort det som inte ger ett värde för kunden.

För precis som med LEAN så är det viktigaste med DevOps att maximera kundens värde genom att identifiera onödiga flöden som inte ger något värde åt kunden.

Hur DevOps-rörelsen uppstod

Först tänkte jag att vi pratar lite om historiken bakom DevOps. För att kunna se framåt så är det viktigt att se tillbaka i backspegeln ibland.
Om vi börjar med själva namnets historia så startades allt med en tweet som skrevs den 23:e juni 2009 av Andrew Clay Shafer när han höll en konferens “10+ Deploys per Day: Dev and Ops Cooperation at Flickr” i Santa Clara, Kalifornien.

Bland åskådarna som följde konferensen digitalt så fanns Patrick Debois (Anses vara pappan till DevOps rörelsen) som på Twitter beklagade sig över att han inte kunde närvara på konferensen personligen. Då uppmanandes han att skapa sitt eget event i Belgien där han är bosatt vilket är exakt vad han gjorde genom att skapa ett event han kallade devopsday där han bjöd in utvecklare, systemadministratörer (IT-drift) och andra personer som jobbade inom relevanta områden att mötas och prata om hur man skulle kunna utveckla samarbetet mellan grupperna. Detta växte och andra började anordna sina egna lokala konferenser världen över.

DevOps föddes utifrån att ledare och intressenter från både utvecklings och IT-drift sidan träffades för att diskutera idéer och förslag på hur man skulle kunna effektiveras industrin då man märkte att det fanns en mur som växt mellan utveckling och driftsidan vilket resulterade i att det tog långt tid att få ut ändringar och nya funktioner till sina kunder.

Muren mellan Dev och Ops

För att förstå varför DevOps behövs så låt mig ge er ett scenario:

Melissa och André arbetar för ett företag vars framgång är beroende av deras förmåga att kunna erbjuda nya och spännande produkter till sina (online) kunder snabbare än sina konkurrenter.

Melissa är en utvecklare vars ansvar ligger på att skriva kod för nya produkter och funktioner samt hantera säkerhetsuppdateringar och buggfixar. André jobbar på IT-drift avdelningen och ansvarar för underhåll och övervakning av produktionsmiljöerna så att dom är uppe och snurrar 24/7.

Oftast så får Melissa vänta veckor eller månader innan hon kan frisläppa ut sin kod till produktionsmiljön.

Detta resulterar i utmaningar för Melissa som måste hantera både koden som är klar för leverans och samtidigt den nya kod hon jobbar med för nya funktioner som ska levereras i nästkommande produktions frisläppning. Det resulterar i svårigheter för Melissa som måste hantera olika kodversioner parallellt.

När det äntligen är dags att frisläppa koden i produktion så uppstår det ofta oförutsägbara problem. Oftast efter att man har felsökt problemet så kommer man fram till att felet ligger på konfigureringen i Melissas utvecklingsmiljö (oftast henne lokal dator) som inte speglar produktionsmiljön.

I andra änden så har vi André. Då företaget växer med nya produkter, funktioner och fler kunder så ökar antalet servrar. En utmaning för André blir då att de verktyg han har idag blir allt mer ineffektiva då de bara är anpassade för att hantera ett dussintal servrar.

Detta påverkar hans sätt att släppa ny kod till produktion. Oftast när ny kod ska släppas så krävs det en del bearbetning för att få koden att fungera i produktion och därav kräver han att man schemalägger frisläppningen och att den sker på fasta tider(t.ex. veckovis eller månadsvis) då det är Andrés ansvar att felsöka om några fel eller problem uppstår av koden som är släppt.

Ibland kan André känna att utvecklarna bara kastar iväg sitt jobb (dvs koden) vidare till honom och hans team för att hantera problemet. Melissa å andra sidan känner att André och hans team inte är tillmötesgående då frisläppningen inte sker tillräcklig ofta i förhållande till utvecklarnas processcykel (sprints).

Dessa fördröjningar ökar pressen hos båda avdelningar då det finns konkurrenter som oftare och snabbare släpper sina produkter och funktioner.

Därav kommer namnet DevOps som man bryter isär i Dev för Development och Ops för Operations.

Nu när vi vet historiken och behovet så låt oss titta på dom gemensamma nämnare som gör att vi kan förbättra samspelet mellan utveckling (Dev) och IT-drift (Ops) så att det kan funka mer effektivt.

Hur viktigt är det med DevOps-verktyg?

Först behöver vi jobbar bort eventuell silomentalitet som finns mellan utveckling och IT-drift samt använda rätt verktyg för att få nöjdare medarbetare med gemensamma mål där man är beredd på snabba marknadsomställningar.

Ett verktyg skulle t ex kunna vara Azure DevOps , GitHub Actions, Puppet och Chef m.m, men det viktiga är att man har förstått principerna med DevOps och man jobbar med att ta fram en process som kommer att ge mervärde åt kunden och företaget. Det handlar alltså inte om hur många releaser man kan göra per dag, det viktiga här är att du är ute efter att lösa specifika problem i din organisation som kan ge din kund mervärde samt att du kan få feedback i retur.

Historisk så har man trott att ju fler releaser man gör desto fler buggar dyker upp, men med ett bra DevOps verktyg så kan du koppla på automatiska enhetstester vilket testar din källkod och användargränssnittstester där du testar den grafiska delen.

Det spelar ingen roll vilket verktyg man använder om man inte har förstått principerna med DevOps och därför handlar det att börja i rätt ände. Det är tyvärr många som tror att man har ett DevOps mindset på företaget bara för att man har ett verktyg som anammar DevOps. Det är ett steg i rätt riktning men ofta kan man göra ännu mer för att effektivisera sin organisation.

Vad är ett DevOps-mindset?

Att ha ett DevOps mindset i organisationen kan kräva mycket tid beroende på kulturen ser ut idag i organisationen då DevOps i sig är en kultur eller en rörelse kanske man kan säga. Man vill att båda grupperna (Dev och Ops) kommer varandra närmare och har gemensam mål att röra sig mot och ständigt utvecklas och effektivisera processerna och produkten.

Då många mjukvaruföretag ständigt släpper nya features så ligger det också på organisationen att vara på tårna och ständigt uppdatera sina egna verktyg, annars kan man ganska snabbt hamna efter med en legacy produkt som inte längre supportas eller ännu värre kan ha säkerhetsluckor.

Många tror att bara för att man går över till DevOps så behöver man inte IT-drift sidan men det är feltänkt skulle jag påstå. Dev (Utveckling) behöver få en förståelse för hur Ops (IT-drift) fungerar även om deras huvudsakliga fokus ändå ska ligga på att utveckla applikationen och inte ansvara för IT-arkitekturen och monitorering (servrarnas hälsa), detta är något för Ops-sidan. Säkerhet är också viktigt men här ligger ansvaret på båda grupperna.

Det är ofta en liten uppförsbacke för Ops-gruppen att komma igång då man måste börja jobba med kod och ha förståelse för hur man lagrar sin källkod. Det är ett nytt sätt att tänka på för dem medan Dev-gruppen inte har denna uppförsbacke, här blir det mer att förstå hur dom nya processerna ser ut och hur man ska följa dom.

Med hjälp utav kod så kan nu Ops-gruppen skriva hur deras arkitektur/infrastruktur och konfigurering ska se ut när man skapar en ny server. Vad som är bra med detta arbetssätt är att dom kan återanvända koden när dom ska skapa nya servrar dvs det blir enklare att skala ut sin miljöer till 10, 100 eller 1000-tals servrar med samma konfiguration. En till aspekt man får ut av detta är att man kan skapa en utvecklingsmiljö åt Dev-gruppen som speglar produktionsmiljön vilket kan leda till att man hittar buggar som är kopplade till konfigureringen utav servern innan man frisläpper till produktion. Detta kallas Infrastructure as code (IaC) och vi återkommer till det längre fram.

Hur uppnår man ett DevOps-mindset?

Om du frågar 10 personer vad DevOps är för något så kommer du nog troligtvis få 10 olika svar. Jag tänkte prata om några gemensamma nämnare som många använder sig utav när dom pratar om DevOps och DevOps strategi och vad som behövs för att uppnå ett DevOps mindset. Det fina med detta också är att det finns inga rätt eller fel för hur man ska jobba med DevOps, alla organisationer ser olika ut vilket betyder att man har chansen att ta fram en unik lösning för sin organisation.

Automatisering

Man bör lägga stort fokus på att försöka automatisera så mycket så möjligt; infrastrukturen (kan ta hjälp utav arbetssättet IaC), arbetsflöden, kodtestning osv. Målet är att automatisera i den mån det går. Det kan finnas steg som man inte kommer vilja automatisera som fortfarande kommer att vara personberoende t.ex. om något ska attesteras innan det går vidare till nästa steg i flödet.

Skriv kortare kod

Skriv kod i bitar dvs i mer frekvent och i mindre sprintar (arbetscykler) som man integrerar, testar, övervakar och frisläpper inom en timme istället för att bygga på sig kodändringar under veckor och sedan frisläppa vid ett fast tillfälle (t.ex. 1 gång per månad).

Infrastructure as code (IaC)

Istället för att bygga och konfigurera mjukvara och infrastruktur manuellt efter ad hoc behov så beskriv i kodtext hur man skall konfigurera sina infrastruktur-resurser (t.ex. databaser, VM:ar). Som ett resultat kommer man att kunna allokera dussintals, hundratals eller till och med tusentals servrar till olika platser och konfigurera till olika typer av hårdvaror.

Utvecklings/testmiljöerna ska spegla produktionsmiljön

Se till att utvecklings/testmiljöerna är en spegling utav produktionsmiljön så blir chansen minimal att man får problem när man släpper sin kod till produktion.

Ta kontroll över källkoden

Se till att ta kontroll över källkoden, beskriv hur man ska hantera koden (t.ex. att man använder sig utav Git som versionshanteringssystem), hur man kommer igång med koden, vilka verktyg som behövs för att kunna komma igång med sitt arbete och vad koden används till. Detta kommer att underlätta när nyanställda ska on-bordas till organisationen.

Mät, övervaka (monitorera) och håll er ”up to date”

Se till att börja mäta och övervaka allt för att kontinuerligt skapa ett effektivare arbetsflöde och se alltid till att era verktyg är uppdaterade med den senaste versionen. Snegla på dom senaste trender som har kommit, som sagt, det går snabbt och det kommer alltid ut nya verktyg som kan vara bra för er organisation.

Tålamod och utbildning

Var beredd på att det tar tid att implementera ett DevOps mindset, se det som att ni försöker implementera en ny kultur. Satsa på att analysera era gruppers kompetens, ta reda på vad era styrkor och svagheter är så att ni kan utbilda er personal men glöm inte heller styrkorna, här finns en bra grund för fortsatt utveckling.

Några Fördelar med DevOps

• Bättre samspel mellan utveckling och IT-drift ger bättre kvalitet på det som frisläpps till produktion (både kod och arbetssätt)
• Friare och mer frekventa releaser gör att man snabbare kan ändra och korrigera små problem som annars leder till större problem.
  Istället för att det ska ta veckor och månader så kan ledtiden ofta kapas ner till dagar eller timmar
• Kortare ledtider ger möjlighet till att vara lyhörd och prioritera företagets nuvarande behov.
• Snabbare omställning till marknadsefterfrågan
• Skapar möjlighet att förbättra företaget och deras produktinnehåll
• Mer tid att fokusera på aktiviteter som ger företaget affärsnytta både internt och extern
• Få mer frekvent feedback från kunden för att få veta vad som går bra och vad för funktioner som behöver förbättras. Detta leder också till att man kan åtgärda buggar snabbare i produktion
• Ger en bra spårbarhet utav er källkod med lagring på ett ställe där det är säkert men enkelt för era medarbetare att komma åt källkoden.

Nu kanske man tycker att jag är är lite partisk men jag har själv sett vad DevOps kan göra. Genom att centralisera sin källkod, hitta gemensamma arbetssätt och skapa automatiska konfigureringar och installationer kan man gå från releaser varannan vecka till under att kunna släppa en ny release inom 2 timmar med nöjdare anställda och förbättrat samarbete som resultat!

Med detta vill jag passa på att önska er lycka till på er resa med DevOps och säga att ni verkligen har valt en snabb men rolig utveckling för både era kunder och anställda. Tveka inte att höra av er om ni vill ha lite hjälp på vägen!