U heeft zich vast en zeker afgevraagd hoeveel de infrastructuur van uw project kost. Tegelijkertijd is het verrassend: de kostengroei is niet lineair ten opzichte van de lasten. Veel bedrijfseigenaren, tankstations en ontwikkelaars begrijpen heimelijk dat ze te veel betalen. Maar waarvoor precies?
Normaal gesproken komt het besparen van kosten simpelweg neer op het vinden van de goedkoopste oplossing, een AWS-plan, of, in het geval van fysieke racks, het optimaliseren van de hardwareconfiguratie. En dat niet alleen: eigenlijk doet iedereen dit, zoals God het wil: als we het over een startup hebben, dan is dit waarschijnlijk een toonaangevende ontwikkelaar die veel kopzorgen heeft. Bij grotere kantoren wordt dit afgehandeld door de CMO/CTO en soms wordt de algemeen directeur samen met de hoofdaccountant persoonlijk bij de kwestie betrokken. Over het algemeen zijn dat de mensen die voldoende ‘kern’-zorgen hebben. En het blijkt dat de rekeningen voor de infrastructuur stijgen, maar degenen die geen tijd hebben om ermee om te gaan, krijgen er mee te maken.
Als u toiletpapier voor op kantoor moet kopen, gebeurt dit door de voorraadbeheerder of een verantwoordelijke persoon van het schoonmaakbedrijf. Als we het over ontwikkeling hebben: leads en CTO. Verkoop - alles is ook duidelijk. Maar sinds vroeger, toen een ‘serverruimte’ een naam was voor een kast waarin zich een gewoon torensysteem bevond met wat meer RAM en een paar harde schijven in de raid, negeert iedereen (of in ieder geval velen) de feit dat de aankoop van capaciteit ook door een speciaal opgeleid persoon moet worden afgehandeld.
Helaas geven historische herinneringen en ervaringen aan dat deze taak tientallen jaren lang werd verschoven naar ‘willekeurige’ mensen: degene die er het dichtst bij stond, pakte de vraag op. En pas onlangs begon het FinOps-vak op de markt vorm te krijgen en enige concrete vorm aan te nemen. Dit is dezelfde speciaal opgeleide persoon die tot taak heeft de inkoop en het gebruik van capaciteit te controleren. En uiteindelijk in het verlagen van de kosten van het bedrijf op dit gebied.
Wij pleiten er niet voor om dure en effectieve oplossingen achterwege te laten: elk bedrijf moet zelf beslissen wat het nodig heeft voor een comfortabel bestaan op het gebied van hardware en cloudtarieven. Maar men kan niet anders dan aandacht besteden aan het feit dat ondoordachte aankopen “volgens de lijst” zonder daaropvolgende monitoring en analyse van het gebruik voor veel bedrijven uiteindelijk resulteert in zeer, zeer substantiële verliezen als gevolg van ineffectief beheer van de “activa” van hun backend.
Wie is FinOps
Stel dat u een gerenommeerde onderneming heeft, waar verkopers op luchtige toon over 'onderneming' praten. Waarschijnlijk heb je “volgens de lijst” een tiental servers, AWS en nog wat andere “kleine dingen” gekocht. Dat is logisch: in een groot bedrijf is er voortdurend een soort beweging gaande: sommige teams groeien, andere vallen uiteen, andere worden overgebracht naar aangrenzende projecten. En de combinatie van deze bewegingen, samen met het ‘op lijsten gebaseerde’ inkoopmechanisme, leidt uiteindelijk tot nieuwe grijze haren als we naar de volgende maandelijkse infrastructuurrekening kijken.
Dus wat te doen - geduldig doorgaan met grijs worden, eroverheen schilderen of de redenen achterhalen voor het verschijnen van deze talloze vreselijke nullen in de betaling?
Laten we eerlijk zijn: goedkeuring, goedkeuring en directe betaling van een aanvraag binnen het bedrijf voor hetzelfde AWS-tarief gaat niet altijd (in werkelijkheid bijna nooit) snel. En juist vanwege de voortdurende beweging van het bedrijfsleven kunnen sommige van deze zelfde overnames ergens ‘verloren’ gaan. En het is triviaal om stil te staan. Als een oplettende beheerder een rack zonder eigenaar in zijn serverruimte opmerkt, is alles in het geval van cloudtarieven veel triester. Ze kunnen maandenlang worden opgeborgen – betaald, maar tegelijkertijd door niemand meer nodig op de afdeling waarvoor ze zijn gekocht. Tegelijkertijd beginnen collega's van het volgende kantoor hun nog niet grijze haar uit te trekken, niet alleen op hun hoofd, maar ook op andere plaatsen - ze hebben voor de zoveelste week niet ongeveer hetzelfde AWS-tarief kunnen betalen, wat is hard nodig.
Wat is de meest voor de hand liggende oplossing? Dat klopt, geef de teugels over aan mensen in nood, en iedereen is gelukkig. Maar horizontale communicatie is niet altijd goed ingeburgerd. En de tweede afdeling is misschien gewoon niet op de hoogte van de rijkdom van de eerste, die op de een of andere manier deze rijkdom niet echt nodig bleek te hebben.
Wie heeft hier de schuld van? - Eigenlijk niemand. Zo is alles voorlopig ingericht.
Wie heeft hier last van? - Dat is alles, het hele bedrijf.
Wie kan de situatie oplossen? - Ja, ja, FinOps.
FinOps is niet alleen een laag tussen ontwikkelaars en de apparatuur die ze nodig hebben, maar een persoon of team dat weet waar, wat en hoe goed het “ligt” in termen van dezelfde cloudtarieven die het bedrijf heeft gekocht. In feite moeten deze mensen samenwerken met DevOps aan de ene kant en de financiële afdeling aan de andere kant, waarbij ze de rol spelen van een effectieve tussenpersoon en, belangrijker nog, van een analist.
Een beetje over optimalisatie
Wolken. Relatief goedkoop en erg handig. Maar deze oplossing is niet meer goedkoop als het aantal servers dubbele of drievoudige cijfers bereikt. Bovendien maken clouds het mogelijk om steeds meer diensten te gebruiken die voorheen niet beschikbaar waren: dit zijn databases as a service (Amazon AWS, Azure Database), serverloze applicaties (AWS Lambda, Azure Functions) en vele andere. Ze zijn allemaal erg cool omdat ze gemakkelijk te gebruiken zijn - kopen en meenemen, geen problemen. Maar hoe dieper het bedrijf en zijn projecten in de wolken duiken, hoe slechter de CFO slaapt. En hoe sneller de generaal grijs wordt.
Feit is dat facturen voor verschillende clouddiensten altijd enorm verwarrend zijn: voor één item kan het zijn dat je drie pagina's uitleg krijgt over wat, waar en hoe je geld is gegaan. Dit is natuurlijk prettig, maar het is bijna onmogelijk om het te begrijpen. Bovendien is onze mening over dit onderwerp verre van de enige: om cloudaccounts naar menselijke over te zetten, zijn er bijvoorbeeld hele diensten of . Als iemand de moeite zou nemen om een aparte dienst op te zetten voor het ontcijferen van rekeningen, dan is de omvang van het probleem de kosten van haarverf ontgroeid.
Dus wat doet FinOps in deze situatie:
- begrijpt duidelijk wanneer en in welke volumes cloudoplossingen zijn aangeschaft.
- weet hoe deze capaciteiten worden gebruikt.
- herverdeelt ze afhankelijk van de behoeften van een bepaalde eenheid.
- koopt niet ‘opdat het zo is’.
- en uiteindelijk bespaart het u geld.
Een goed voorbeeld is cloudopslag van een koude kopie van een database. Archiveert u het bijvoorbeeld om de hoeveelheid ruimte en verkeer die wordt verbruikt bij het updaten van de opslag te verminderen? Ja, het lijkt erop dat de situatie goedkoop is – in een enkel specifiek geval, maar het geheel van zulke goedkope situaties resulteert later in exorbitante kosten voor clouddiensten.
Of een andere situatie: u kocht reservecapaciteit op AWS of Azure om niet onder piekbelasting te vallen. Weet u zeker dat dit de optimale oplossing is? Als deze instanties voor 80% inactief zijn, geef je immers gewoon geld aan Amazon. Bovendien hebben dezelfde AWS en Azure voor dergelijke gevallen burstable instances - waarom heb je inactieve servers nodig als je een tool kunt gebruiken om problemen met piekbelastingen op te lossen? Of, in plaats van On Premise-instanties, moet u naar Gereserveerd kijken: deze zijn veel goedkoper en bieden ook kortingen.
Trouwens, over kortingen
Zoals we in het begin al zeiden, wordt de aanbesteding vaak door iedereen uitgevoerd - ze hebben de laatste gevonden, en dan doet hij het op de een of andere manier zelf. Meestal worden mensen die het al druk hebben 'extreem', en als resultaat krijgen we een situatie waarin een persoon snel en vakkundig, maar volledig onafhankelijk, beslist wat en in welke hoeveelheden hij wil kopen.
Maar als u communiceert met een verkoper van de clouddienst, kunt u gunstiger voorwaarden krijgen als het gaat om de groothandelsaankoop van capaciteit. Het is duidelijk dat je zulke kortingen niet kunt krijgen van een auto met een stille en eenzijdige registratie - maar na een gesprek met een echte verkoopmanager kun je opbranden. Of deze jongens kunnen je vertellen waar ze momenteel kortingen op hebben. Het kan ook nuttig zijn.
Tegelijkertijd moet je onthouden dat het licht niet als een wig samenkwam op AWS of Azure. Er is natuurlijk geen sprake van het organiseren van uw eigen serverruimte, maar er zijn alternatieven voor deze twee klassieke oplossingen van de reuzen.
Google heeft bijvoorbeeld het Firebase-platform naar bedrijven gebracht, waarop ze hetzelfde mobiele project turnkey kunnen hosten, wat mogelijk snelle schaalvergroting vereist. Opslag, realtime database, hosting en cloudgegevenssynchronisatie met deze oplossing als voorbeeld zijn op één plek beschikbaar.
Aan de andere kant, als we het niet hebben over een monolithisch project, maar over hun totaliteit, dan is een gecentraliseerde oplossing niet altijd voordelig. Als het project een lange levensduur heeft, een eigen ontwikkelingsgeschiedenis heeft en een overeenkomstige hoeveelheid gegevens die nodig is voor opslag, dan is het de moeite waard om na te denken over een meer gefragmenteerde plaatsing.
Wanneer u de kosten voor clouddiensten optimaliseert, realiseert u zich misschien plotseling dat u voor bedrijfskritische applicaties krachtigere tarieven kunt kopen die het bedrijf ononderbroken inkomsten zullen opleveren. Tegelijkertijd is het opslaan van de ‘erfenis’ van ontwikkeling, oude archieven, databases, etc. in dure clouds een oplossing. Voor dergelijke data is een standaard datacenter met gewone HDD's en middelzware hardware zonder toeters en bellen immers prima geschikt.
Ook hier zou je kunnen denken dat “deze ophef het niet waard is”, maar het hele probleem van deze publicatie is gebaseerd op het feit dat de verantwoordelijke mensen in verschillende stadia de kleine dingen verwaarlozen en doen wat handiger en sneller is. Wat uiteindelijk na een paar jaar resulteert in die zeer horrorverhalen.
Het resultaat?
Over het algemeen zijn wolken cool; ze lossen veel problemen op voor bedrijven van elke omvang. De nieuwheid van dit fenomeen betekent echter dat we nog steeds geen cultuur van consumptie en management hebben. FinOps is een organisatorische hefboom waarmee u de kracht van de cloud effectiever kunt benutten. Het belangrijkste is om deze positie niet te veranderen in een analoog van een vuurpeloton, wiens taak het zal zijn om onoplettende ontwikkelaars bij de hand te pakken en hen te "schelden" voor downtime.
Ontwikkelaars moeten zich ontwikkelen en het bedrijfsgeld niet tellen. En dus moet FinOps zowel het inkoopproces als het proces van het buiten gebruik stellen of overdragen van cloudcapaciteit aan andere teams een evenement voor alle partijen eenvoudig en plezierig maken.
Bron: www.habr.com