Känns dina molnkostnader som ett svart hål?

När många organisationer tar steget att flytta helt eller delvis till molnet, möts de ofta av en utmaning som liknas vid ett expanderande svart hål – kostnaderna. Samtidigt har många av dessa organisationer genomgått en övergång till DevOps och ställts inför komplexiteten att sammanföra utvecklings- och driftkompetens i samma team. Dessa så kallade 'oberoende' DevOps-team kan ibland verka vara drivkraften bakom de ökande utgifterna. Det är här FinOps bruka komma in i bilden. Men vad är egentligen FinOps och hur kan det återställa kontrollen över kostnaderna? Innebär det att du måste placera dina ekonomer i utvecklingsteamen? Låt oss reda ut konceptet FinOps och förstå varför det är så omtalat.

Vi börjar som vanligt med en definition av begreppet. Enligt grundaren The FinOps Foundation, som är en non-profit organisation och en del av Linux Foundation:

”FinOps är en utvecklande disciplin för ekonomisk förvaltning i molnet och en kulturell praxis som möjliggör för organisationer att uppnå maximalt affärsvärde genom att hjälpa ingenjörs-, finans-, teknik- och affärsteam att samarbeta kring datadrivna beslut om utgifter.”

Enligt Microsoft, som också refererar till FinOps Foundation, är det:

“FinOps är en disciplin som kombinerar principer för finansiell förvaltning med molnteknik och drift för att ge organisationer en bättre förståelse för sina molnutgifter. Det hjälper dem också att fatta välgrundade beslut om hur de ska fördela och hantera sina molnkostnader. Målet med FinOps är inte att spara pengar, utan att maximera intäkterna eller affärsvärdet genom molnet. Det hjälper organisationer att kontrollera sina molnutgifter samtidigt som de upprätthåller den nivå av prestanda, tillförlitlighet och säkerhet som behövs för att stödja deras affärsverksamhet.”

Ingen av definitionerna är enligt mig speciellt tydlig och har varsin liten tvist. Enligt FinOps Foundation så pratar vi mer disciplin och kultur, medan Microsofts definition pratar mer affärsvärde och kostnadskontroll, vilket så klart är menat att tilltala företag som vill använda deras molntjänster. Låt oss bryta ner det ytterligare. Jag tycker mig uppfatta ett antal delar i ovanstående definitioner som behöver besvaras:

1. Vad är en utvecklande disciplin för ekonomisk förvaltning?

2. Vad är det för kulturell praxis?

3. Vad är samarbetsformerna?

4. Hur skapar du bättre förståelse för din organisations molnutgifter?

5. Hur kopplas alla ovanstående frågor till beslut som leder till affärsvärde?

Så första frågan, utvecklande disciplin för ekonomisk förvaltning, innebär helt enkelt att FinOps är en modell du kan följa, eller ta inspiration av, för att hantera budgetering, fördelning, redovisning och uppföljning av kostnader för din molnplattform. Modellen är under konstant utveckling enligt samma koncept som för öppen källkod. Alla som applicerar modellen kan också utveckla den och skicka in ändringsförslag till FinOps foundation.

Den kulturella praxisen refererar till de förhållningssätt som beskrivs inom Agilitet och DevOps, dvs, principerna om konstant förbättring, minimering av slöseri, automation och ökad mänsklig interaktion. Läs min artikel artikel om Agila metoder för djupare beskrivningar.

Samarbetsformerna behöver du själv sätta upp, men grunden som i den mesta förändringsledning är att ett initialt team är ansvarigt för FinOps och att det sedan finns ambassadörer utspridda på olika nivåer i organisationen som sprider både kultur och data. Har du gjort en agil transformation eller en större molnomställning har du förmodligen övat på och implementerat liknande strukturer.

Frågan om hur du skapar förståelse innehåller flera aspekter, där den grundläggande aspekten är att använda de verktyg som molnleverantörerna har för kostnadsanalys. Jag brukar normalt sätt inte börja med verktygen men de är de lättaste sättet att börja titta på och mäta sina kostnader, vem har konsumerat vilken tjänst och när.
Detta skapar dock inte förståelse på alla nivåer. Här kommer kulturen in, ett utvecklingsteam kan titta på detaljerna i fakturan, precis som en bilmekaniker kan förstå innebörden och rimligheten i detaljerna på fakturan för din motorrenovering, och sedan förklara för en tekniskt oinsatt varför kostnaden har uppkommit. Den stora skillnaden från ett besök hos bilverkstaden är att molnutgifter sker konstant och i en organisation med många utvecklingsteam så förändras också kostnaden konstant. För att komplicera det ytterligare kanske det också, beroende på avtal, sker valutaförändringar som dagligen påverkar kostnader. Därför behöver också kostnadsövervakningen ske konstant och diskuteras ofta, kanske behöver fler realtidsgränssnitt utvecklas. och även normalt tekniskt oinsatta behöver lära sig vissa grunder för att förstå. Tiden där man sätter en budget, signerar ett avtal som matchar budgeten och sedan inväntar nästa års avtal är tyvärr förbi.

Till sist den kanske viktigaste frågan, hur vet du att det som betalats för och de beslut som tagits har lett till att värde har skapats. Här är det största jobbet och det som leder till störst förändringar, att faktiskt hitta mätetal att följa upp på. Vad är det för värde du vill skapa, har den nya arkitekturen som du valde lett till kortare nedtid, hur mäter du det? Har den uppgraderade databastjänsten du valde lett till kortare väntetid för kunder att köpa varor och därmed minskat antalet avbrutna köp eller skulle du valt en annan förändring? Behöver du A/B-testa dem mot varandra? Detta är beslut och data dina utvecklingsteam behöver kunna redovisa för. Det handlar om att mäta och prata om värde från gräsroten till toppen i din organisation.

Jag tycker FinOps principerna från FinOps Foundation sammafattar visionen väldigt bra:

Samarbete mellan team:

• Team arbetar tillsammans tvärfunktionellt för att kontinuerligt förbättra effektiviteten och innovationen.

Personligt ägarskap över molnanvändning:

• Ansvar för användning och kostnader fördelas till individuella tekniker/utvecklare.

• Delegera budget och beslut om molnanvändning till produktteamen.

• Inkludera kostnad som ett mätvärde tidigt i programvaruutvecklingslivscykeln.

Tillgängliga och aktuella rapporter:

• Kostnadsdata bör finnas tillgängligt brett i organisationen och uppdateras så nära realtid som möjligt.

• Skapa, övervaka och förbättra realtids finansiell prognos och planering.

Centraliserat team driver FinOps:

• Ett centralt team främjar bästa praxis och delar ansvar, liknande säkerhetsteamet.

• Ledningen måste stödja FinOps och dess metoder.

• Prissättning, åtagande och rabatter hanteras centralt för att dra nytta av stordriftsfördelar.

Beslut tas med affärsnytta i fokus:

• Använd enhetskostnader och värdebaserade mätvärden för att mäta affärsnytta istället för totala kostnader.

• Gör medvetna avvägningar mellan kostnad, kvalitet och hastighet vid beslutsfattande.

• Se på molnet som en drivkraft för innovation, inte bara som en teknisk resurs.

Utnyttja molnets variabla kostnadsmodell:

• Molnets variabla kostnadsmodell bör betraktas som en möjlighet att leverera mer värde, inte som en risk.

• Agil iterativ planering föredras framför statiska långsiktiga planer.

• Arbeta proaktivt och gör kontinuerliga kostnadsförbättringar istället för engångsinsatser.

FinOps är helt enkelt en fördjupning av DevOps-kulturen och ett fokus på att också diskutera finansiella frågor, budget, affärsvärde och att redovisa vilket värde man producerat för kostnaderna av de val man gjort. Men också att faktiskt delegera ner delar av budgetansvaret direkt till dem som använder pengarna. Du behöver inte ha ekonomer i utvecklingsteamen, men dina ekonomer behöver troligen ha en ökad närvaro och vara med och stötta både närmare verksamhet och utveckling.