Rozhodně jste se ptali, kolik stojí infrastruktura vašeho projektu. Ale je překvapující, že růst nákladů není lineární v poměru k zátěžím. Mnoho majitelů firem, CTO a vývojářů podvědomě chápe, že přeplácejí. Ale za co konkrétně?
Obvykle spočívá snižování nákladů jednoduše v hledání nejlevnějšího řešení, tarifu AWS, nebo, pokud hovoříme o fyzických serverech, optimalizaci konfigurace zařízení. Kromě toho: vlastně se tím zabývá kdokoli, jak je napadne: pokud mluvíme o startupu, pak je to pravděpodobně vedoucí vývojář, který má dost svých starostí. Ve větších firmách se tím zabývá CMO/CTO, občas se do otázky zapojí sám generální ředitel spolu s hlavním účetním. Obecně ti, kteří mají dost „profesních“ starostí. A tak se stává, že účty za infrastrukturu rostou, ale řeší to… ti, kteří na to nemají čas.
Pokud je třeba v kanceláři koupit toaletní papír, postará se o to správce budovy nebo odpovědná osoba z úklidové firmy. Pokud jde o vývoj – vedoucí a CTO. Prodeje – to je také jasné. Ale ještě od dob, kdy se „serverem“ nazýval skříň, ve které stál obyčejný tower systém s trochu větším množstvím paměti RAM a pár disků v RAID, všichni (nebo alespoň mnozí) ignorují fakt, že nákup kapacit by měl také provádět speciálně vyškolený člověk.
Bohužel, historická paměť a zkušenosti ukazují, že tato úloha byla po desetiletí delegována na „náhodné“ lidi: kdo byl blíž, ten se ujal problému. A teprve nedávno se na trhu začala vyvíjet a přijímat určitá konkrétní podoba profese FinOps. To je ten speciálně vyškolený člověk, jehož úkolem je kontrola nákupu a využívání kapacit. A v konečném důsledku snižování nákladů společnosti v této oblasti.
Nepodporujeme odmítání drahých a efektivních řešení: každý podnik by měl sám rozhodnout, co potřebuje k pohodlnému fungování z hlediska hardwaru a cloudových tarifů. Nelze však přehlédnout skutečnost, že bezmyšlenkovité nakupování „podle seznamu“ bez následné kontroly a analýzy využití se pro mnohé firmy v konečném důsledku mění na velmi solidní ztráty z důvodu neefektivního řízení „aktiv“ svého backendu.
Kdo je to FinOps
Představte si, že máte solidní podnik, o kterém prodejci s úctou říkají „enterprise“. Pravděpodobně jste „podle seznamu“ pořídili desítku-dvě serverů, AWS a ještě něco „maličkosti“. Což je logické: ve velké společnosti se neustále něco děje – některé týmy rostou, jiné se rozpadávají a třetí se přesouvají na sousední projekty. A právě kombinace těchto pohybů spolu s mechanismem nákupu „podle seznamu“ nakonec přivádí k novým šedivým vlasům při pohledu na další měsíční fakturu za infrastrukturu.
Co tedy dělat – trpělivě šedivět dál, zakrývat to, nebo se zabývat příčinami vzniku těchto mnoha příšerných nul na faktuře?
Co si budeme namlouvat: schvalování, aprobace a přímo platba žádosti uvnitř firmy za stejný tarif AWS není vždy (ve skutečnosti - téměř nikdy) rychlé. A právě kvůli neustálému firemnímu pohybu část těchto zakoupení může někde „zmizet“. A prostě zůstává stát. Zatímco pečlivý administrátor si může všimnout opuštěného stojanu ve své serverovně, u cloudových tarifů je to mnohem smutnější. Ty mohou stát „na příklepu“ měsíce – zaplacené, ale už nikomu nepoužitelné v oddělení, pro které byly zakoupeny. Mezitím kolegové z vedlejší kanceláře si začínají rvát své zatím nešedivé vlasy nejen na hlavě, ale i na jiných místech - už několik týdnů nemohou zaplatit přibližně stejný tarif AWS, který akutně potřebují.
Jaké je to nejzřejmější řešení? Správně, předat otěže potřebným a všichni jsou spokojeni. Jenže horizontální komunikace není vždy dobře nastavená. A druhé oddělení může jednoduše nevědět o bohatství prvního, které se ukázalo jako očividně nepotřebné.
Kdo za to může? — V podstatě nikdo. Tak už to prostě je.
Kdo tím trpí? — Všichni, celá společnost.
Kdo může situaci napravit? — Ano, FinOps.
FinOps není pouze mezivrstvou mezi vývojáři a potřebným vybavením, ale člověk nebo tým, kteří vědí, kde, co a jak dobře „leží“ z hlediska těchto cloudových tarifů, které si společnost zakoupila. V podstatě by tito lidé měli pracovat v jedné jizbě s DevOps na jedné straně a s finančním oddělením na straně druhé, zastávající roli efektivního prostředníka a, co je nejdůležitější, analytika.
Trochu o optimalizaci
Cloudy. Relativně levné a velmi pohodlné. Ale toto řešení přestává být levné, když se počet serverů dostane do dvouciferných nebo trojciferných čísel. Kromě toho cloud umožňuje využívat stále více služeb, které byly dříve nedostupné: například databáze jako služba (Amazon AWS, Azure Database), serverless aplikace (AWS Lambda, Azure Functions) a mnoho dalších. Všechny jsou skvělé tím, že jsou jednoduché na používání — koupil jsi a jedeš, žádné problémy. Jenže čím hlouběji se společnost a její projekty ponoří do cloudu, tím hůř spí finanční ředitel. A tím rychleji šediví generální ředitel.
Jde o to, že účty za různé cloudové služby jsou vždy extrémně zmatené: za jednu položku můžete obdržet tří stránkovou rozpis, za co, kam a jak šly vaše peníze. To je sice příjemné, ale vyznat se v tom je prakticky nemožné. A naše názory na tuto záležitost rozhodně nejsou jediné: existují celé služby, které převádějí cloudové účty do lidského jazyka, například nebo . Pokud si někdo dal práci se založením samostatné služby pro rozbor účtů, problém přerostl náklady na barvu na vlasy.
Takže, co v této situaci dělá FinOps:
- jasně chápe, kdy a v jakém objemu byla cloudová řešení zakoupena.
- ví, jak jsou tyto zdroje využívány.
- přerozděluje je podle potřeb různých oddělení.
- nekupuje „aby bylo“.
- a nakonec — šetří vaše peníze.
Skvělý příklad – cloudové úložiště pro studenou kopii databáze. Archivujete ji například, abyste snížili spotřebu prostoru a přenosu při aktualizaci úložiště? Ano, situace se zdá bezvýznamná – v konkrétním případě, ale součet takových drobných situací se nakonec promění v nesnesitelné náklady na cloudové služby.
Nebo jiná situace: nakoupili jste rezervní kapacitu na AWS nebo Azure, abyste se vyhnuli problémům při špičkové zátěži. Můžete si být jistí, že je to optimální řešení? Vždyť pokud tyto instance stojí 80 % času, prostě darujete peníze Amazonu. Ještě více, pro takové případy mají AWS a Azure burstable instance – proč vám mají běžet nevyužité servery, pokud můžete využít nástroj, který řeší problémy při špičkových zátěžích? Nebo namísto On Premise instancí se vyplatí podívat na Reserved – jsou mnohem levnější a navíc poskytují i slevy.
Mimochodem, o slevách
Jak jsme již zmínili na začátku, nákup často zajišťuje kdokoli – našli jsme odpovědného, a dál to už nějak zvládne sám. Nejčastěji se „odpovědnými“ stávají lidé, kteří už jsou tak vytížení, a výsledkem je, že dotyčný rychle a kvalifikovaně, ale naprosto samostatně rozhoduje, co a v jakém množství nakupovat.
Přitom při jednání s obchodníkem z cloudové služby můžete získat výhodnější podmínky, pokud jde o velkoobchodní nákup kapacit. Je jasné, že takové slevy od stroje při tiše a jednostranně provedeném objednání nezískáte – ale po rozhovoru s skutečným obchodním manažerem se to může vyplatit. Ti lidé vám také mohou poradit, na co mají nyní slevy. To může být také užitečné.
Je však třeba mít na paměti, že AWS nebo Azure nejsou jedinými možnostmi. Samozřejmě, nemluvíme o vytváření vlastního serveru – ale existují i alternativy k těmto dvěma klasickým řešením od gigantů.
Například Google představil pro společnosti platformu Firebase, na které lze "na klíč" umístit stejný mobilní projekt, který může vyžadovat rychlé škálování. Úložiště, realtime databáze, hosting a cloudová synchronizace dat na tomto řešení jsou dostupné na jednom místě.
Na druhé straně, pokud nehovoříme o monolitním projektu, ale o jejich souhrnu, nemusí být centralizované řešení vždy výhodné. Pokud je projekt dlouhodobý, má svou historii vývoje a příslušné množství potřebných dat k uložení, stojí za to zvážit fragmentovanější umístění.
Při optimalizaci nákladů na cloudové služby si najednou můžete uvědomit, že pro kriticky důležité obchodní aplikace si můžete pořídit i výkonnější tarify, které zajistí společnosti nepřetržitý zisk. Na druhé straně uchovávat 'dědictví' vývoje, staré archivy, databáze a další věci v drahých cloudech není příliš rozumné. Vždyť pro taková data by zcela postačil běžný datacenter s obyčejnými HDD a průměrným hardwarem bez jakýchkoliv 'vychytávek'.
Zde opět můžeme pomyslet, že 'tato dřina za to nestojí', ale celá problematika tohoto článku spočívá v tom, že v různých fázích zodpovědní lidé opomíjejí drobnosti a dělají to, co je pohodlnější a rychlejší. Což se nakonec za pár let projeví v těchto hrozných účtech.
Jaký je výsledek?
Obecně jsou cloudové služby skvělé, řeší spoustu problémů pro podniky všech velikostí. Novinka tohoto jevu však vede k tomu, že stále nemáme kulturu spotřeby a řízení. FinOps je organizační nástroj, který pomáhá efektivněji využívat cloudové zdroje. Hlavní věcí je neproměnit tuto pozici v obdobu popravčí čety, jejíž úkolem bude chytnout nevšímavé vývojáře při činu a 'pokárat' je za nevyužitý výkon.
Vývojáři by měli vyvíjet, nikoli počítat peníze společnosti. A FinOps by měly jak proces nákupu, tak proces odepisování nebo předávání cloudových zdrojů dalším týmům učinit jednoduchou a příjemnou záležitostí pro všechny strany.
Zdroj: habr.com
