Zeker, je hebt je waarschijnlijk afgevraagd hoeveel de infrastructuur van jouw project kost. Wat verbazingwekkend is, is dat de groei van de kosten niet lineair is ten opzichte van de belasting. Veel bedrijfeigenaren, CTO's en ontwikkelaars begrijpen onderbewust dat ze te veel betalen. Maar waarvoor precies?
Gewoonlijk is kostenbesparing eenvoudigweg het zoeken naar de goedkoopste oplossing, het AWS-tarief of, als we het hebben over fysieke racksystemen, het optimaliseren van de hardwareconfiguratie. Sterker nog: dit wordt in feite gedaan door wie dan ook, zoals het hen uitkomt: in het geval van een startup is dit waarschijnlijk de hoofdontwikkelaar, die genoeg problemen heeft. In grotere bedrijven wordt dit gedaan door de CMO/CTO, en soms bemoeit de CEO zich persoonlijk met de kwestie, samen met de hoofdboekhouder. Over het algemeen zijn dit de mensen die al genoeg 'specifieke' zorgen hebben. En het resultaat is dat de kosten voor infrastructuur stijgen, maar er mee omgaan... zijn degenen die er geen tijd voor hebben om zich ermee bezig te houden.
Als er in het kantoor toiletpapier moet worden gekocht, zal de huismeester of de verantwoordelijke persoon van het schoonmaakbedrijf dit oppakken. Als het over ontwikkeling gaat, zijn dit de leads en de CTO. Verkoop is ook duidelijk. Maar al sinds de oude tijden, toen een 'server' de kast werd genoemd waarin een gewone tower-pc met iets meer RAM en een paar harde schijven in RAID stond, negeren velen (of in ieder geval, veel mensen) het feit dat de inkoop van capaciteit ook door een speciaal opgeleide persoon moet worden gedaan.
Helaas zegt de historische geheugen en ervaring dat deze taak decennia lang is doorgeschoven naar 'toevallige' mensen: wie dichter bij het probleem stond, nam het maar op zich. Pas recent is het beroep FinOps op de markt ontstaan en begonnen er enkele concrete contouren te ontstaan. Dit is die speciaal opgeleide persoon, wiens taak bestaat uit het toezicht houden op de inkoop en het gebruik van capaciteit. En, uiteindelijk, het verlagen van de uitgaven van het bedrijf op dit gebied.
Wij pleiten niet voor het opgeven van dure en effectieve oplossingen: elk bedrijf moet zelf beslissen wat het nodig heeft voor een comfortabele werking op het gebied van hardware en cloudtarieven. Maar we kunnen niet om het feit heen dat ondoordachte aankopen "volgens lijst" zonder daaropvolgende controle en analyse van gebruik voor veel bedrijven uiteindelijk resulteren in aanzienlijke verliezen door ineffectief beheer van hun backend "activa".
Wie is FinOps
Stel dat u een solide onderneming heeft, waarvan verkopers met ontzag spreken als "enterprise". Waarschijnlijk heeft u "volgens lijst" een tiental servers en AWS en nog wat "kleineren" aangeschaft. Dat is logisch: in een groot bedrijf is er voortdurend beweging — sommige teams groeien, andere vallen uiteen, weer anderen worden naar naburige projecten overgebracht. En deze combinatie van bewegingen, in samenhang met het inkoopmechanisme "volgens lijst", leidt uiteindelijk tot nieuwe grijze haren bij het bekijken van de volgende maandelijkse factuur voor infrastructuur.
Wat te doen — geduldig blijven zitten, het verbergen of de oorzaken achter de vele afschuwelijke nullen op de factuur oplossen?
Wat valt er te verbergen: goedkeuring en betaling van een aanvraag binnen het bedrijf voor hetzelfde AWS-tarief is niet altijd (in werkelijkheid - bijna nooit) snel. En juist vanwege de constante corporatieve beweging kunnen sommige van deze aankopen ergens "verloren gaan". En eenvoudigweg inactief blijven. Als een oplettende beheerder een verlaten rek in de serverruimte opmerkt, dan is het met cloudtarieven veel somberder. Ze kunnen maanden "vast staan" — betaald, maar ondertussen al niet meer nodig in het departement dat ze heeft aangeschaft. Ondertussen beginnen collega's uit het naburige kantoor hun nog niet grijze haren niet alleen op hun hoofd, maar ook op andere plekken te trekken — hun kan al weken niet dezelfde soort AWS-tarief worden goedgekeurd dat ze dringend nodig hebben.
Wat is de meest voor de hand liggende oplossing? Juist, de touwtjes aan de behoeftigen overdragen, en iedereen is tevreden. Echter, horizontale communicatie is niet altijd goed geregeld. En de tweede afdeling weet mogelijk gewoon niet van de rijkdom van de eerste, waarvan deze rijkdom op de een of andere manier niet bijzonder nodig bleek te zijn.
Wie is hier verantwoordelijk? — Eigenlijk niemand. Zo is het momenteel allemaal geregeld.
Wie lijdt eronder? — Iedereen, het hele bedrijf.
Wie kan de situatie verbeteren? — Ja, juist, FinOps.
FinOps is niet slechts een schakel tussen ontwikkelaars en de benodigde apparatuur, maar een persoon of team dat weet waar, wat en hoe goed het gaat met betrekking tot de cloudtarieven die het bedrijf heeft aangeschaft. In feite moeten deze mensen samenwerken met DevOps aan de ene kant, en de financiële afdeling aan de andere kant, en fungeren als een effectieve tussenpersoon en, wat het belangrijkste is, als analist.
Een beetje over optimalisatie
Cloudoplossingen. Relatief goedkoop en heel handig. Maar dit advies verliest zijn voordelige karakter zodra het aantal servers in de dubbele of zelfs driedubbele cijfers gaat. Bovendien bieden clouds de mogelijkheid om steeds meer diensten te gebruiken die eerder niet beschikbaar waren: zoals databases als een dienst (Amazon AWS, Azure Database), serverless applicaties (AWS Lambda, Azure Functions) en veel anderen. Ze zijn geweldig omdat ze eenvoudig te gebruiken zijn — je koopt het en je kunt beginnen, geen problemen. Maar hoe verder een bedrijf en zijn projecten in de clouds duiken, hoe slechter de financiële directeur slaapt. En hoe sneller de CEO grijs wordt.
Het probleem is dat de facturen voor verschillende clouddiensten altijd ontzettend verwarrend zijn: voor één regel kun je een drie pagina's tellende uitleg krijgen over waar, hoe en waarom je geld is uitgegeven. Dit is uiteraard prettig, maar het is bijna onmogelijk om het te begrijpen. En onze mening is hierin zeker niet de enige: er bestaan zelfs hele diensten om cloudfacturen begrijpelijk te maken, zoals of . Als iemand zich de moeite heeft genomen om een aparte dienst voor het ontcijferen van facturen te creëren, dan is het probleem groter dan de kosten van haarkleur.
Dus, wat doet FinOps in deze situatie:
- begrijpt precies wanneer en in welke hoeveelheden cloudoplossingen zijn aangeschaft.
- weet hoe deze middelen worden gebruikt.
- herverdeelt ze op basis van de behoeften van de verschillende afdelingen.
- koopt niet ‘voor het geval dat’.
- en uiteindelijk — bespaart uw geld.
Een uitstekend voorbeeld is cloudopslag van een koude databasekopie. Archiveert u deze bijvoorbeeld om de benodigde opslagruimte en het verkeer tijdens de opslagupdates te verminderen? Ja, het lijkt misschien een kleinigheid - in één specifiek geval, maar de optelsom van dergelijke kleinigheden leidt uiteindelijk tot enorme kosten voor cloudservices.
Of een andere situatie: u heeft extra capaciteit op AWS of Azure aangeschaft om niet onder de piekbelasting te vallen. Kun je er zeker van zijn dat dit de optimale oplossing is? Want als deze instanties 80% stil liggen, geef je gewoon geld aan Amazon weg. Bovendien hebben AWS en Azure voor dergelijke situaties burstable instanties - waarom zou je onnodig servers in de lucht houden als je middelen kunt gebruiken om piekbelastingen aan te pakken? Of in plaats van On Premise-instanties kun je beter naar Reserved kijken - die zijn veel goedkoper en je krijgt er ook kortingen op.
Over kortingen gesproken
Zoals we aan het begin zeiden, worden aankopen vaak gedaan door wie dan ook - er wordt een scapegoat gevonden, en daarna moet diegene het zelf maar redden. Meestal worden die 'scapegoats' mensen die al druk bezet zijn, en uiteindelijk krijgen we een situatie waarin iemand snel en deskundig, maar volledig op zichzelf, beslist wat en in welke hoeveelheden er aangekocht moet worden.
Bij interactie met een verkoper van de cloudservice kun je vaak betere voorwaarden krijgen als het gaat om de grootschalige aankoop van capaciteit. Het is duidelijk dat je die kortingen niet van een machine kunt krijgen bij een stilzwijgend en eenzijdig proces - maar door te praten met een echte verkoopmanager kan het wel zo uitpakken. Of misschien kunnen deze mensen je vertellen waar momenteel kortingen op zijn. Dat kan ook nuttig zijn.
Houd er daarbij rekening mee dat de wereld niet alleen rond AWS of Azure draait. Natuurlijk is de oprichting van een eigen serverpark geen optie - maar er zijn ook alternatieven voor deze twee klassieke oplossingen van de giganten.
Bijvoorbeeld, Google heeft voor bedrijven het platform Firebase geleverd, waar je dezelfde mobiele projecten 'op maat' kunt hosten, die snel geschaald moeten kunnen worden. Opslag, realtime databases, hosting en cloudgegevenssynchronisatie zijn met deze oplossing op één plek beschikbaar.
Aan de andere kant, als we het niet hebben over een monolithisch project, maar over hun samenhang, dan is een gecentraliseerde oplossing niet altijd voordelig. Als het project langdurig is, een eigen ontwikkelingsgeschiedenis heeft en de benodigde hoeveelheid gegevens moet opslaan, dan moet je nadenken over een meer gefragmenteerde benadering.
Bij het optimaliseren van uitgaven voor cloudservices kun je je plotseling realiseren dat voor cruciale bedrijfstoepassingen je betere abonnementen kunt aanschaffen die zorgen voor ononderbroken inkomsten voor het bedrijf. Tegelijkertijd is het bewaren van 'erfgoed' ontwikkeling, oude archieven, databases en dergelijke in dure cloudoplossingen niet echt een goede keuze. Voor dergelijke gegevens voldoet een standaard datacenter met gewone HDD's en gemiddelde hardware zonder speciale 'toeters en bellen' ook prima.
Hier kan je weer denken dat 'al deze rompslomp het niet waard is', maar het probleem van deze publicatie is dat op verschillende momenten verantwoordelijke mensen details negeren en dingen doen zoals het hen uitkomt en sneller is. Wat uiteindelijk na een paar jaar resulteert in die verschrikkelijke rekeningen.
Wat is het resultaat?
Cloudservices zijn geweldig; ze lossen veel problemen op voor bedrijven van elke omvang. Echter, de nieuwheid van dit fenomeen leidt ertoe dat we nog steeds geen cultuur van consumptie en beheer hebben. FinOps is een organisatorisch hulpmiddel dat helpt om cloudcapaciteit efficiënter te gebruiken. Het belangrijkste is om deze rol niet te om te vormen tot een soort uitvoerende macht die als taak heeft om onoplettende ontwikkelaars op te sporen en te 'berispen' voor het niet efficiënt gebruiken van capaciteit.
Ontwikkelaars moeten ontwikkelen, en niet de financiën van het bedrijf bijhouden. En FinOps moet zowel het aankoopproces als het proces van afschrijven of het doorgeven van cloudcapaciteit aan andere teams eenvoudig en aangenaam voor alle betrokkenen maken.
Bron: habr.com
