Red Hat: Optimera utvecklingen med devops

AdobeStock_127517656_DevOps_960x640.jpg

Team med utvecklare och driftpersonal ger ett annat helhetstänk än traditionell utveckling enligt "vattenfallsmodell".

Devops, mikrotjänster och containrar är tre av de hetaste begreppen inom utveckling just nu. Ted Schönbeck, teknisk chef på Red Hat förklarar fördelarna och berättar hur du kan komma igång.

– En av de viktigaste sakerna som sker nu när vi går in i den digitala eran är att det är ett konstant tryck på organisationerna att transformera och utveckla. Traditionellt sätt har it stått för stabilitet och en låg förändringsgrad men nu när det hela tiden krävs nya lösningar vill utvecklarna ha it på ett annat sätt och det skapar svårigheter. DevOps är helt enkelt en utvecklingsmetodik för att hantera detta, säger Ted Schönbeck, teknisk chef på Red Hat.

Den traditionella utvecklingsmodellen där man utvecklade en funktion i taget ersattes med ett mer agilt arbetssätt för länge sedan men i den snabba miljön som krävs idag har den fortfarande brister, och där kommer DevOps in, menar Ted Schönbeck. I en devopsmiljö tar man hänsyn till både drift och utvecklingen på samma gång vilket ger funktionella, skalbara och anpassningsbara applikationer.

– Utvecklarna är vana att lämna över hela ansvaret till driften så fort de är klara och när de sedan har velat uppdatera eller förändra något har man från båda håll haft problem att förstå varandras cykler. Det har varit en bromskloss för innovation. Genom att föra samman utvecklare och driftspersonal redan under utvecklingsprocessen så bryggar man in en ömsesidig förståelse.

Devops ger flexibilitet i processen

Ett devopsperspektiv på processen medför även andra fördelar enligt Ted Schönbeck. Bland annat möjliggör det en större flexibilitet att förändras i takt med omvärlden.

Mikrotjänster fungerar utmärkt ihop med devops som arbetsmetod.

Ted Schönbeck, teknisk chef, Red Hat

– Tidigare byggde man applikationer monolitiskt, och lade in all kod i en enda stor app i en jätteserver. Med den mer agila n-tier-metoden bröt man sönder appen i flera delar vilket passade bra ihop med ett agilt arbetssätt, men idag behöver man bygga tjänster som ska fungera konstant utan downtime. Där kommer mikrotjänster in som passar utmärkt ihop med devops som arbetsmetod.

Genom att bryta ner applikationerna i många små beståndsdelar utan beroenden kan utvecklingen ske enligt CI/CD, Continuous Integration / Continuous Delivery. Eftersom mikrotjänsterna är så små är det lätt att skapa dubbletter vilket gör att man kan jobba med koden utan att behöva stänga ner tjänsten.

– Mikrotjänster blir en bra, enkel, lagom stor enhet att jobba med och som dessutom går att skala upp och ner utifrån behov. Du kanske bara behöver skala en del av din applikation och inte hela, vilket förenklas om den är uppbyggd med mikrotjänster. Spotify och Netflix jobbar till exempel mycket med det här för att kunna skicka ut uppdateringar flera gånger per dag utan att behöva ta ner något, säger Ted Schönbeck.

Containrar – mer än bara ett trendord

Ett av hetaste trendorden inom it just nu är containrar och de är ett bra verktyg för devops och mikrotjänster.

– De virtuella servrarna var bra för det agila arbetssättet men de har fortfarande fulla OS och tar fortfarande lite tid att starta. I mikrovärlden krävs det snabbare ledtider. Containrar är förenklat sett superoptimerade virtuella maskiner där man bara tar det man behöver från operativsystemet. De är också isolerade från underliggande lager vilket gör att man kan köra dem varsomhelst eftersom de har vad de behöver inbyggt. Därför passar de jättebra för mikrotjänster som enkelt kan flyttas mellan olika plattformar, inte minst i en cloudmiljö, säger Ted Schönbeck.

TedS-Redhat_960x640.jpg

Ted Schönbeck, teknisk chef, Red Hat

Som exempel tar han Google som spinner upp en container vid varje tjänst vilket gör att de startar två miljarder containrar varje dag och tar död på lika många.

– Det blir ett helt annat sätt att jobba. På Netflix har man till och med byggt in så kallade chaos monkeys, som åker runt i produktionssystemet och dödar tjänster. På så sätt har man implementerat en devopsmetodik där utvecklingsteamen tvingas att ta hänsyn till hur och var applikationen körs och vilka problem som kan uppstå i drift med inbyggd, automatiserad hantering av detta.

En annan fördel med containrar är att de är lätta att skala upp och ner. Som exempel tar Ted Schönbeck Volvo Cars och deras online-konfigurator.

– Om de vet att de kommer att ha en stor anstormning efter en kampanj kan de skala upp konfiguratorn och med containrar blir det enkelt att ha en del i molnet och en del i sitt vanliga datacenter hemma. Containrar är en bra bärare för detta.

Så går du över till devops

Ted Schönbeck möter många som vill förändra både sin arbetsmetodik och implementera nya tekniker som containrar men inte vet hur de ska börja. Till dem har han ett råd:

– Börja med nästa app. Man behöver inte göra om allting från början utan ta nästa grej och gör den till ett lighthouse-projekt. Med ett avgränsat projekt får medarbetarna chans att lära sig jobba enligt devops och hur man ska göra. Det spelar ingen roll om du är ett stort bilföretag eller en kommun. Idag vill kunderna interagera via appar, det är den nya standarden. Det betyder inte att du måste flytta dina stora gamla applikationer som kanske passar bättre att köra i din egen hemmamiljö, men mikrotjänster som inte är lika känsliga för varierande prestanda är perfekta att köra i molnet.

Utmaningen är framför allt att bryta gamla fastlåsta strukturer, menar Ted Schönbeck.

– Utvecklare vill göra på sitt sätt och samma är det för driftpersonalen. Om du kommer och slår sönder strukturen helt kommer du att stöta på motstånd. Därför är det bra att hitta ett projekt som kan vara bryggan över till devops.

15 december 2016Uppdaterad 2 oktober 2023Reporter Miguel Guerrerodigit

Voisters nyhetsbrev

Rekommenderad läsning