Bruce Lee om DevOps: Bemästra dina verktyg och leverera bättre mjukvara

Överlag kan kampsportaren tappa fokus på det nödvändiga grundarbetet och den precision som krävs. Att träna fler sätt att sparka är meningslöst om du inte har utvecklat de sparkar du redan kan till en nivå där de verkligen är användbara.

Att träna på fler saker i stället för att finslipa befintliga färdigheter innebär att kampsportaren slösar sin värdefulla träningstid. Det kan faktiskt vara bättre att använda tiden till en helt annan sport än att låta sig distraheras från sitt huvudmål: att bli bättre på kampsport.

Jag är inget undantag. ”Har du sett Wu Dang Eight Immortals Sword ’Ba Xian Jian’? Jag måste verkligen lära mig den!” När sådana tankar dyker upp behöver jag ha en vän i närheten som påminner mig om Bruce Lee.

Motsvarigheten till 10 000 sparkar i teknikföretag

I de flesta moderna DevOps - och utvecklingsteam introduceras nya verktyg för snabbt och utan tillräcklig eftertanke, ofta på bekostnad av den kundnära produkten. Tid och resurser är begränsade, och att lägga dem på fel saker påverkar produktkvaliteten direkt.

Ett verkligt exempel är ett team som körde några få, mycket små tjänster på VM:ar. Det var små Python-skript i Docker-containrar som kördes på en stabil Ubuntu-miljö. Underhåll och uppdateringar kunde bokstavligen utföras av vem som helst med grundläggande kunskaper i Ubuntu och Python, och gick snabbt.

En dag bestämde sig teamet för att flytta dessa tjänster till Kubernetes i molnet, helt enkelt för att Kubernetes är fantastiskt. För att göra det introducerades ytterligare automatiseringslager med verktyg som inte var välkända inom teamet. Sedan ersattes VM:arna med en Virtual Scale Set och redundant nätverkslagring för att dra nytta av allt fantastiskt med Kubernetes, vilket lade till en hel del Azure i teamets verktygsportfölj. För att övervaka tjänsterna och Kubernetes på bästa sätt ersattes standardlösningen för övervakning, vilket lade till ytterligare en databas som teamet tidigare inte kände till. 

Vid den här punkten krävde det så mycket mer kunskap att lösa ett problem med de små tjänsterna jämfört med den tidigare versionen att en kunskapsö i praktiken hade skapats, eftersom större delen av teamet helt enkelt inte hade tid att komma ikapp. Den fortsatta utvecklingen bromsades och felsökning blev en allvarlig fråga som tog timmar eller dagar. 

Allt detta utan någon uppenbar nytta för produkten och med ett kraftigt produktivitetstapp. 

Ett annat mycket vanligt mönster handlar om Jenkins: Föreställ dig ett företag som har det ständigt populära Jenkins i en typisk, föråldrad installation. Teamet bestämmer sig för att flytta till GitHub, men eftersom de gamla pipelinesen är komplexa hinner de aldrig flytta över alla. Nu används alltså två pipelinesystem. Vid någon tidpunkt lämnar några andra team GitHub för Azure DevOps, och det uppmuntrar hipsterteamet att argumentera för sin egen lösning, som ingen någonsin har hört talas om men som påstås lösa alla problem eftersom den är ny, liten och glänsande.

Vid den här punkten är Jenkins fortfarande ett problem som kräver exakt samma engagemang, och dessutom har teamen skapat kunskapsöar och barriärer.

Ska vi alla gå tillbaka till Perl då?

Vi skulle kunna fylla hundratals sidor med exempel, och alla skulle kännas igen. 

Att lägga till nya programmeringsspråk i teknikstacken, nya övervakningsverktyg, nya molnleverantörer och nya automatiseringsverktyg, eller att migrera från en teknikstack till en annan eftersom den nya lovar att vara bättre, fast du egentligen inte vet. Listan är lång.

Jag förespråkar inte att bara använda Perl på Unix bara för att den kombinationen får alla jobb gjorda. Det vore för extremt. Men i många fall ger ett tillägg till teknikstacken eller en migrering till en ny stack inte önskat resultat, eller leder till oönskade bieffekter. Och du måste erkänna att de där gamla Perl/Unix-killarna känner till varenda liten detalj i sin miljö, något som nästan ingen annan kan påstå.

Jag har arbetat på flera företag där teknikstacken var mycket begränsad av olika skäl, och resultatet var att människor förstod koden, infrastrukturen och produkten över teamgränserna. Det var de enda verkligt agila företag jag har sett. 

Som konsult är ett av mina lackmustest för att bedöma en organisations mognad att se hur många verktyg de har på plats. Använder de ett litet urval verktyg för att få ut maximalt värde av dem? Eller har de en omfattande verktygsanarki? Svaret ligger förstås på en skala. I verkligheten finns inget svart eller vitt. 

Varför inte lägga till nya verktyg?

En kort lista över saker som kan bli sämre när något nytt läggs till i stacken omfattar komplexitet, produktivitet, underhållbarhet, teamets fokus och kunskapsdelning. 

Komplexitet: den moderna utvecklingens tysta dödare

Komplexitet urholkar produktiviteten snabbare än dålig kod. Det är farligt lätt att låta din DevOps-verktygskedja växa tills ingen längre förstår den fullt ut. Ett nytt verktyg kommer inte utan dolda kostnader. Ytterligare krav på infrastrukturen, nya typer av databaser, nya byggsystem, nya pakethanterare, kunskapsuppbyggnad, avveckling av gamla verktyg och datamigrering – allt detta och mer därtill är dolda kostnader utöver själva det nya verktyget. 

Någon sa att det viktigaste arbetet för varje senior utvecklare är att minska komplexiteten, och det stämmer helt. De flesta moderna företag har förlorat kampen mot komplexiteten och har inte längre kontroll. Det gör dem långsamma, minskar stabiliteten, gör att felsökning tar för lång tid och att all utveckling blir dyr. Deras lösning är vanligtvis att lägga till några fler lager av komplexitet, men det de borde göra är att minska komplexiteten.

Produktivitet: den dolda kostnaden för att introducera ett nytt verktyg.

Det finns en uppenbar kostnad med att introducera ett nytt verktyg: det tar tid.

Dessutom finns en dold kostnad i form av ökad kognitiv belastning, eftersom den ökade komplexiteten kräver att utvecklare delar upp sina insatser. Underhållskostnaderna fördubblas, tiden för att läsa dokumentation fördubblas och utvecklarna måste komma ihåg när de ska använda vilket verktyg och var olika data lagras. Det kan verka som småsaker, men de läggs på hög.

Tänk på det vanliga fallet med ett företag som har flera kunskapsbaser. Varje gång kunskap inte hittas eftersom någon letar i fel verktyg uppstår en direkt produktivitetsförlust, och dessutom finns risken att fel sak implementeras.

Produktiviteten kan verkligen stanna av när systemets komplexitet blir för stor.

Underhållbarhet: Om ingen ansvarar för det kommer det att gå sönder.

Någon måste underhålla verktyget. Det kan vara ett internt team, eller så väljer företaget att lägga ut det på ett annat företag. Oavsett vilket finns det en direkt kostnad i tid och pengar för att underhålla det nya verktyget, och den kostnaden försvinner inte inom överskådlig tid. Även för SaaS-lösningar är möjligheten att stänga ner dem vid behov i praktiken rent teoretisk när de väl har integrerats i utvecklingsflödet.

IT Ops har ett dåligt rykte om sig att synliggöra underhållskostnader genom att tydligt kräva de resurser som behövs för varje system de ska underhålla, vilket egentligen är bra! När ingen har tillräcklig förståelse för verktyget för att sköta underhåll, löpande administration eller uppdateringar, är det bara en tidsfråga innan det glänsande nya verktyget blir ett stort problem. Även om någon har full förståelse behöver personen fortfarande få avsätta tid för verktyget.

Det vanliga scenariot där en entusiastisk förespråkare för en produkt driver införandet av ett verktyg och sedan blir dess enda förvaltare slutar illa när personen lämnar företaget eller flyttas till ett nytt team. När någon säger att de kan underhålla ett nytt verktyg vid sidan av är det en tydlig varningssignal om att något kommer att explodera längre fram.

Teamfokus: Enkelhet håller teamen samordnade.

Ett exempel är att ha ett enda build-system eller ett enda övervakningssystem, vilket innebär att det alltid får uppmärksamhet. Problem eller uppdateringar identifieras och hanteras när de uppstår. Så snart det finns flera sådana system kommer utvecklare och ledning att hitta sätt att undvika det impopulära arbetet med att åtgärda problem och i stället välja den mer givande uppgiften att lansera funktioner i det andra verktyget. Data glöms bort att uppdateras, jobb för datainsamling förbrukar resurser trots att de inte längre behövs, och produktivitet går förlorad när utvecklare måste växla fokus mellan olika verktyg. Kanske ännu värre är att chefer, särskilt när det gäller övervakningsverktyg eller verktyg för kunskapsdelning, kan fatta fel beslut eftersom de tenderar att fokusera på ett litet antal verktyg och få sina svar från fel verktyg.

En del av problemet handlar om ägarskap. Ett team, inte en person, måste äga verktyget och ansvara för administration, uppdateringar och generella användningsfall. Teamet måste noga följa användningen och säkerställa att verktyget inte används utanför det angivna och överenskomna syftet. Utan en sådan ägare börjar verktyget användas utan tydligt fokus, och med tiden kommer det att täcka alla möjliga oregelbundna användningsfall. Det skapar mycket förvirring i utvecklingsteamet som helhet och gör underhållet svårt.

Utan en tydlig ägare för moln-Repositories och utan tydliga riktlinjer för hur de skulle användas upptäckte ett företag att det höll på att nå lagringsgränsen för repositories, eftersom ett team laddade upp stora mängder binärfiler. Att åtgärda detta och flytta binärfilerna till Artifactory blev betydligt dyrare än att använda Artifactory från början.

Kunskapsdelning: Gemensam förståelse slår individuell expertis.

Kunskapen om hur det nya verktyget används och underhålls måste delas och hållas uppdaterad i alla relevanta team. Det kan vara en synlig kostnad eller bara märkas som förseningar i uppgifter, men den kommer alltid att finnas där.

Ett särskilt fall är ett nytt programmeringsspråk: En bra utvecklare kan komma i gång med vilket nytt språk som helst på några dagar, men det tar ändå månader eller år att bli verkligt flytande i det. Fram till dess dyker tidskrävande refaktoreringsuppgifter upp för att anpassa koden i det nya språket till befintliga kvalitetsstandarder och beprövade metoder.

Frågan om hur ett nytt verktyg ska användas tillsammans med befintliga verktyg måste besvaras noggrant, så att användning enligt vilda västern-principen inte gör det svårt eller omöjligt att följa dataflödet. Ta binärfilexemplet ovan: Det är uppenbart inte ett bra användningsområde för ett Git-repository. Många nyanställda behövde lägga extra tid på att lära sig detta den hårda vägen, det tog längre tid att ta reda på var data lagrades eftersom de inte fanns på den självklara platsen, och övervakningen av lagringsgränserna – om den hade funnits – hade behövt känna till att det fanns två lagringstyper.

Men AI kommer att lösa det!

Den här uppfattningen är populär hos många företag som har förlorat kampen mot komplexiteten, men den är också fel. I slutändan innebär AI ovanpå kaos bara ytterligare ett lager av komplexitet som du har ännu mindre kontroll över. Om komplexiteten har vuxit till en punkt där inget mänskligt team har en chans att förstå vad som pågår, sitter du på en tickande bomb.

Jag värdesätter verkligen användningen av AI-verktyg i mitt dagliga arbete och rekommenderar att du använder dem för att få grepp om och minska komplexiteten, i stället för att blint öka den.

Så behåller du fokus

När någon vill lägga till ett nytt verktyg i din stack, stanna upp och fråga:

• Behöver vi det verkligen?

• Vad är den totala kostnaden, inklusive underhåll och inlärningskurva?

• Kan vi få tillfredsställande resultat genom att använda funktionerna i ett befintligt verktyg?

• Vilken är den faktiska nyttan för produkten?

Efter ett tag bör du ställa samma frågor om varje verktyg du redan har och rensa i din stack på samma sätt som Bruce Lee tränade sina sparkar – genom att fokusera på det som verkligen fungerar i striden.

När du faktiskt inför ett nytt verktyg bör du först ha en MVP (inte en POC) och sedan ställa dig frågorna efter MVP:n. Du har sannolikt fått nya insikter, och det finns en god chans att du upptäcker att du inte behöver det nya verktyget.

Sluta träna på de 9,9999 sparkarna till förmån för den enda som faktiskt fungerar i en strid.