#Utveckling & Arkitektur

Återblick och reflektion: DevOps Summit 2016

Innan sommaren var jag på DevOps Summit den 15 juni och lyssnade på ett gäng intressanta föreläsningar kring ämnet DevOps (Development + Operations) och jag vill här dela med mig av mina tankar från den dagen.

Det här tar jag med mig.

”Infrastructure as code” - https://www.thoughtworks.com/insights/blog/infrastructure-code-reason-smile

  • Att sätta upp en servermiljö bestående av diverse maskiner, tjänster och nätverk med anpassade konfigurationer tar tid att göra manuellt (dessutom blir det lätt fel)
  • Med scriptade installationer av en komplett miljö får man tryggheten i snabb och felfri återställning samt en bra levande dokumentation över sin miljö.

 

”two pizza teams“ - http://blog.idonethis.com/two-pizza-team/

  • Ett team ska inte vara större än att det går att mätta med två pizzor (US size), det motsvarar ungefär storleken på det optimala agila teamet, ca 6 personer.
  • Teamet bör enligt min mening inte vara mindre än 4 personer.
  • Detta gör kommunikation, kunskapsspridning och ansvarstagande möjligt och smidigt, samtidigt som teamet klarar av förlust av medlemmar utan att duka under.

 

“Separating deployment from release” – blue green deployment

  • Med dubbla (minst) miljöer för drift av en applikation kan den ena vara i produktion medan den andra används för deploy av den senaste koden, vilken efter testning blir den aktiva i produktion genom att enkelt peka om trafiken via en lastbalanserare eller liknande. Det här ger en väldigt snabb uppgradering av systemet och det går lika snabbt att backa uppgraderingen om något gick fel.

 

“MTTR OVER MTBF” – Mean Time To Recovery over Mean Time Between Failure

  • Genom att förvänta sig att fel uppstår och fokusera mer på att systemet ska gå att återställa/patchas snabbt då ett fel uppstår istället för allt för mycket testning skapas ett positivt momentum med högre velocitet/kortare releasecykler.

 

”If you build it, you run it”

  • Med fullt ansvar för att drifta det man bygger kommer kvalitetsmedvetenhet och därmed en bättre applikation.

 

”Ta dig frihet – ge tillbaks genom ansvarstagande”

  • Gör det du vill och tycker är roligt, men se till att det också är till nytta för din arbetsgivare/kund

 

 

Summeringen blir ungefär såhär..

DevOps är ett buzzword (och har varit i några år) för något som inte är så nytt egentligen.

Det handlar helt enkelt om samarbetet mellan och eller kombinationen av utveckling och drift.

 

DevOps som begrepp idag är ungefär vad Agilt var för några år sedan, ett modernare och flexiblare sätt att arbeta men fortfarande lite för nytt för att få fullt förtroende i viktiga och stora projekt i trögrörliga organisationer.

DevOps är dock en titel/roll som allt fler bolag tillsätter (och det finns en hög, och ökande, efterfrågan på kompetensen) när de inser att det ger ungefär samma synergier som agil utveckling; med kortare cykler och feedbackloopar kommer en snabbare leverans till marknaden och därmed snabbare ROI.

 

I mindre företag, som startups, är det ofta samma personer som sköter både utveckling och drift på grund av antalet medarbetare, men även stora organisationer som t ex Amazon arbetar på liknande sätt för att maximera sin produktivitet. iZettle berättade hur deras resa såg ut när de växte från några få utvecklare till 20personer och hur lätt det är att börja dela in sig i olika kompetensområden och hur viktigt det är att faktiskt inte dela upp sig för mycket.

 

Ian Massingham från Amazon berättade att de arbetar i tvärfunktionella team enligt modellen ”If you build it, you run it”, vilket ger ett högt ansvarstagande och därmed en bra kvalitet jämfört med de traditionella teknikindelade avdelningarna där utveckling och drift inte alltid arbetar mot samma mål och pratar samma språk.

  • Driftavdelningen ska se till att applikationer är stabila och online medan utvecklingsavdelningen ska leverera ny funktionalitet enligt budget och tidsplan.

tidsplan.jpg 

 

Spotify arbetar på liknande sätt, som Amazon, där Operations blev Infrastructure (as a service) och alla deras tjänster är automatiska via APIer där utvecklingsteamen kan beställa vad de behöver utan fördröjningar, precis som en molntjänst.

 

Sammantaget kan man säga att alla talare på plats var överens om att tvärfunktionella team med en maximal storlek av ”two pizza teams” som tar fullt ansvar för sina egna ”micro services” och ges fullt förtroende är ett framgångsrecept. Och, att oavsett om du har en intern miljö eller molntjänster är det bästa sättet (det enda hållbara) att bygga upp infrastrukturen för applikationer är med scriptade installationer, vilket betyder att utvecklarna (med hjälp av drift)  måste få koll på vad det är de faktiskt behöver och att man med ett enkelt ”knapptryck” kan få upp en komplex miljö som den som visas i högra delen på bilden nedan.

 devsum.jpg

 

Här kan ni del av presentationerna i PDF-format, men de flesta ger inte särskilt mycket om man inte har hört föreläsningarna.

http://techworld.event.idg.se/presentationer-devops-summit-2016/

 

 

 

//Jimi

 

Publicerad: 2016-10-13