Hur mycket spenderar du på infrastruktur? Och hur kan du spara på det?

Du har säkert undrat över vad infrastrukturen för ditt projekt kostar. Det är också intressant att kostnadsökningen inte är linjär i förhållande till belastningarna. Många företagsägare, CTO:er och utvecklare förstår undermedvetet att de betalar för mycket. Men för vad exakt?

Vanligtvis handlar kostnadsbesparingar helt enkelt om att hitta den billigaste lösningen, AWS-priser eller, om vi pratar om fysiska rack, att optimera utrustningskonfigurationen. Dessutom är det faktiskt vem som helst som sysslar med detta, som det passar: om vi talar om en startup är det sannolikt en ledande utvecklare som redan kämpar med många problem. I större företag hanteras detta av CMO/CTO, ibland ger till och med VD:n och huvudbokföraren sig in i frågan. I stort sett är det personer som redan har tillräckligt med 'fackmässiga' bekymmer. Och det visar sig att räkningarna för infrastrukturen ökar, men det hanteras av… de som inte har tid att hantera det.

Om toalettpapper behöver köpas in på kontoret, så tar förvaltaren eller en ansvarig från städfirman hand om det. Om det handlar om utveckling är det ledarna och CTO:erna som hanterar det. Försäljning är också klart. Men redan från de gamla tider då 'serverrummet' refererade till ett skåp där en vanlig tower-dator med något mer RAM och ett par hårddiskar i RAID stod, så har många (eller åtminstone många) ignorerat det faktum att ansvaret för inköp av kapaciteter också bör ligga på en särskilt utbildad person.

Tyvärr säger historisk erfarenhet oss att denna uppgift under flera decennier har lagts på 'slumpar': den som var närmast tog på sig frågan. Och först nyligen har yrket FinOps börjat ta form och få konkret innebörd på marknaden. Detta är just den särskilt utbildade person vars uppgift är att övervaka inköp och användning av kapacitet. Och i slutändan att sänka företagets utgifter inom detta område.

Vi uppmanar inte till att avstå från dyra och effektiva lösningar: varje företag måste själva avgöra vad de behöver för att trivas när det gäller hårdvara och molnavtal. Men man kan inte bortse från det faktum att tanklös inköp "enligt listan" utan efterföljande kontroll och analys av användningen leder till mycket stora förluster för många företag på grund av ineffektiv förvaltning av sina "tillgångar" i backend.

Vad är FinOps

Anta att du har ett stort företag som säljarna med beundran omtalar som "enterprise". Sannolikt har du "enligt listan" köpt ett tiotal servrar, AWS och lite annat "i smått". Vilket är logiskt: i ett stort företag pågår det ständigt någon typ av rörelse — vissa team växer, andra upplöses, och vissa övergår till angränsande projekt. Denna kombination av rörelser i samband med inköpsmekanismen "enligt listan" resulterar slutligen i nya grå hår när man granskar nästa månads faktura för infrastrukturen.

Vad ska man göra - fortsätta tålmodigt att gråna, färga hår eller ta reda på orsaken till dessa många hemska nollor i fakturan?

Vad ska man dölja: godkännande, auktorisation och själva betalningen av en begäran inom företaget för samma AWS-plan är inte alltid (i verkligheten nästan aldrig) en snabb process. Och just på grund av den ständiga företagsrörelsen kan en del av dessa inköp "förlora" sig någonstans. Och stå helt stilla. Om en uppsättning som saknar ägare i serverrummet märks av en uppmärksam administratör, är det mycket ledsnare med molnavtal. De kan stå "på is" i månader — betalda, men samtidigt redan överflödiga för den avdelning som de köptes för. Samtidigt börjar kollegorna från kontoret bredvid att riva sitt fortfarande mörka hår, eftersom de inte har kunnat få ungefär samma AWS-plan betald på flera veckor.

Vad är den mest uppenbara lösningen? Rätt, att överlämna ansvaret till de som behöver det, så är alla nöjda. Men de horisontella kommunikationerna är inte alltid väl etablerade. Och den andra avdelningen kanske helt enkelt inte vet om rikedomarna hos den första, vilket den första kanske inte känner något behov av.

Vem är skyldig här? – Egentligen ingen. Så här är det utformat just nu.
Vem lider av detta? – Alla, hela företaget.
Vem kan lösa situationen? – Precis, FinOps.

FinOps är inte bara en mellanhand mellan utvecklarna och den hårdvara de behöver, utan en person eller ett team som vet var, vad och hur väl det ser ut med avseende på de molntjänster som företaget köpt. Faktiskt ska dessa personer arbeta tillsammans med DevOps på ena sidan och ekonomiavdelningen på den andra sidan, och fungera som en effektiv mediator och, viktigast av allt – analytiker.

Lite om optimering

Moln. Relativt billigt och väldigt bekvämt. Men det här beslutet slutar vara billigt när antalet servrar blir tvåsiffrigt eller tresiffrigt. Dessutom ger moln möjlighet att använda allt fler tjänster som tidigare var otillgängliga: allt från databaser som en tjänst (Amazon AWS, Azure Database) till serverlös applikation (AWS Lambda, Azure Functions) och många fler. De är alla fantastiska då de är lätta att använda – köpt och klart, inga problem. Men ju djupare företaget och dess projekt går in i molnen, desto sämre sover finanschefen. Och desto snabbare grånar VD:n.

Saken är den att fakturorna för olika molntjänster alltid är oerhört komplicerade: för en och samma post kan du få en tre-sidig specifikation av vad, vart och hur dina pengar gått. Det är förstås trevligt, men att förstå den är praktiskt taget omöjligt. Vår åsikt i denna fråga är långt ifrån unik: för att översätta molnfakturor till mänskligt språk finns det faktiska tjänster, till exempel www.cloudyn.com eller www.cloudability.com. Om någon har tagit sig tid att skapa en separat tjänst för att tolka fakturor, så har problemet vuxit bortom värdet av hårfärg.

Så vad gör FinOps i denna situation:

• förstår tydligt när och i vilka volymer molnlösningar har köpts.
• vet hur dessa resurser används.
• omfördelar dem beroende på behoven hos olika avdelningar.
• köper inte "bara för att ha".
• och i slutändan – sparar dina pengar.

Ett utmärkt exempel är molnlagring av en kall kopia av databasen. Arkiverar du den till exempel för att minska den använda lagringskapaciteten och trafik vid uppdatering av lagret? Ja, det kan tyckas vara en liten situation — i ett enskilt fall, men mängden sådana små situationer leder så småningom till orimliga kostnader för molntjänster.

Eller en annan situation: ni har köpt extra kapacitet på AWS eller Azure för att inte krascha under toppbelastning. Kan man vara säker på att detta är den optimala lösningen? Om dessa instanser står stilla 80% av tiden, ger ni helt enkelt bort pengar till Amazon. Dessutom, för sådana fall har både AWS och Azure burstable instanser — varför behöver ni serverar som går på tomgång, när ni kan använda ett verktyg för just toppbelastningar? Eller istället för On Premise-instansar kan ni överväga reserverade instanser — de är mycket billigare och de ger dessutom rabatter.

För övrigt, angående rabatter

Som vi nämnde i början, så är det vem som helst som ofta sköter inköpen — man hittar den som är ansvarig, och sen löser denne det på något sätt själv. Oftast blir de "ansvariga" personer som redan har fullt upp, och i slutändan får vi en situation där personen snabbt och kvalificerat, men helt på egen hand, beslutar vad och i vilka mängder som ska köpas.

Men vid interaktion med försäljaren från molntjänstföretaget kan man få mer fördelaktiga villkor, om det handlar om att köpa kapacitet i bulk. Självklart kommer man inte att få sådana rabatter genom att tysta och ensidigt registrera sig — men genom att prata med en verklig försäljningschef kan det faktiskt löna sig. Dessutom kan dessa killar tipsa om vad de har rabatter på just nu. Det kan också vara användbart.

Det är också viktigt att komma ihåg att det inte bara är AWS eller Azure som finns. Självklart är det inte tal om att organisera en egen serverhall — men det finns alternativ till dessa två klassiska lösningar från giganter.

Till exempel, Google har introducerat plattformen Firebase för företag, där man kan "vända nyckeln" och bygga ett mobilprojekt som kan kräva snabb skalning. Lagring, realtidsdatabaser, hosting och molnsynkronisering av data är tillgängligt på detta lösning på ett och samma ställe.

Å andra sidan, om vi inte pratar om ett monolitiskt projekt utan om deras sammansättning, så är en centraliserad lösning inte alltid lönsam. Om projektet är långlivat, har en historia av utveckling och en motsvarande mängd nödvändiga data att lagra, bör man tänka på ett mer fragmenterat sätt att placera dessa.

När man optimerar kostnaderna för molntjänster kan man plötsligt inse att för kritiska affärsapplikationer kan man investera i kraftfullare abonnemang som säkerställer företagets kontinuerliga intäkter. Samtidigt är det ett tveksamt beslut att lagra 'arv' från utvecklingen, gamla arkiv, databaser och liknande i dyra moln. För sådana data fungerar ett standard datacenter med vanliga HDD:er och medelstark hårdvara utan några 'finesser' alldeles utmärkt.

Här kan man återigen tänka att 'detta pyssel är inte värt besväret', men hela problematiken i denna publikation bygger på att ansvariga personer ignorera detaljer i olika skeden och gör det som är enklare och snabbare. Detta leder i slutändan till de skrämmande kostnaderna vi ser efter ett par år.

Vad blir resultatet?

Generellt sett är moln fantastiska, de löser en mängd problem för företag av alla storlekar. Men nyheten i detta fenomen innebär att vi fortfarande saknar en kultur för konsumtion och hantering. FinOps är en organisatorisk mekanism som hjälper till att använda molnkapacitet mer effektivt. Huvudpoängen är att inte göra denna tjänst till en slags dödsdomargrupp vars uppgift är att få ovinklade utvecklare på bar gärning och 'tika' dem för stillastående kapacitet.

Utvecklare bör utveckla, inte räkna företagets pengar. Och FinOps bör göra både inköpsprocessen och processen för avskrivning eller överföring av molnkapacitet till andra team till en enkel och trevlig händelse för alla parter.

Källa: habr.com