Biztosan kíváncsi volt arra, hogy mennyibe kerül projektje infrastruktúrája. Meglepő ugyanakkor: a költségek növekedése nem lineáris a terhelésekhez képest. Sok cégtulajdonos, benzinkút és fejlesztő titokban megérti, hogy túlfizet. De pontosan minek?
A költségek csökkentése jellemzően egyszerűen a legolcsóbb megoldás, az AWS-terv megtalálásán múlik, vagy fizikai rackek esetében a hardverkonfiguráció optimalizálásán. Nem csak ez: igazából bárki úgy csinálja, ahogy Isten akarja: ha egy startupról beszélünk, akkor ez valószínűleg egy vezető fejlesztő, akinek bőven fáj a feje. Nagyobb irodákban ezzel a CMO/CTO foglalkozik, esetenként a főigazgató személyesen is bekapcsolódik a kérdésbe a főkönyvelővel együtt. Általában azok az emberek, akiknek van elég „alapvető gondjuk”. És kiderül, hogy az infrastrukturális számlák emelkednek, de akiknek nincs idejük ezzel foglalkozni, azok foglalkoznak vele.
Ha WC-papírt kell vásárolnia az irodába, azt az ellátási vezető vagy a takarító cég felelős személye fogja megtenni. Ha fejlesztésről beszélünk - vezet és CTO. Értékesítés - szintén minden világos. De a régi idők óta, amikor a „szerverszoba” egy olyan szekrény neve volt, amelyben egy közönséges toronyrendszer volt, kicsit több RAM-mal és néhány merevlemezzel a raidben, mindenki (vagy legalábbis sokan) figyelmen kívül hagyja a tény, hogy a kapacitásvásárlást is speciálisan képzett személynek kell kezelnie.
Sajnos a történelmi emlékezet és a tapasztalat azt mutatja, hogy ezt a feladatot évtizedeken át „véletlenszerű” emberekre hárították: aki a legközelebb volt, az vette fel a kérdést. A FinOps szakma pedig csak a közelmúltban kezdett formát ölteni a piacon, és konkrét formát öltött. Ugyanaz a speciálisan képzett személy, akinek a feladata a kapacitásvásárlás és -használat ellenőrzése. És végső soron a vállalat költségeinek csökkentésében ezen a területen.
Nem a drága és hatékony megoldások elhagyását hirdetjük: minden vállalkozásnak magának kell eldöntenie, hogy hardver- és felhőtarifák tekintetében mire van szüksége a kényelmes élethez. De nem lehet nem odafigyelni arra, hogy a meggondolatlan „lista szerinti” vásárlás a felhasználás utólagos nyomon követése és elemzése nélkül sok cégnél végeredményben nagyon-nagyon jelentős veszteséget okoz a háttérrendszerük „vagyonának” nem hatékony kezelése miatt.
Ki az a FinOps
Tegyük fel, hogy van egy jó hírű vállalkozása, amelyről az értékesítők lélegzetelállító hangnemben „vállalkozásról” beszélnek. Valószínűleg „a lista szerint” vásárolt egy-két tucat szervert, AWS-t és még néhány „apróságot”. Ami logikus: egy nagy cégben folyamatosan történik valamilyen mozgás - egyes csapatok nőnek, mások szétesnek, mások átkerülnek a szomszédos projektekbe. És ezeknek a mozgásoknak a kombinációja a „lista alapú” beszerzési mechanizmussal együtt végül új ősz hajszálakat eredményez a következő havi infrastrukturális számlát tekintve.
Tehát mit tegyünk - türelmesen szürküljön, fessen rá, vagy derítse ki, hogy miért jelenik meg ez a sok szörnyű nulla a fizetésben?
Legyünk őszinték: az ugyanazon AWS tarifa iránti kérelem vállalaton belüli jóváhagyása, jóváhagyása és közvetlen kifizetése nem mindig (a valóságban szinte soha) nem gyors. És éppen az állandó vállalati mozgás miatt előfordulhat, hogy ezeknek a felvásárlásoknak egy része valahol „elveszett”. És triviális tétlenül állni. Ha egy figyelmes adminisztrátor gazdátlan racket vesz észre a szerverszobájában, akkor a felhőtarifák esetében minden sokkal szomorúbb. Hónapokig lerakhatók – kifizetik, de ugyanakkor már senkinek sem kellek azon az osztályon, amelyre megvásárolták. A szomszédos iroda kollégái ugyanakkor nemcsak a fejükön kezdik tépni a még nem ősz hajukat, hanem máshol is – az n-edik hete nem tudnak megközelítőleg azonos AWS tarifát fizetni, ami égetően szükség van.
Mi a legkézenfekvőbb megoldás? Így van, adják át a gyeplőt a rászorulóknak, és mindenki boldog. A horizontális kommunikáció azonban nem mindig jól megalapozott. És a második osztály egyszerűen nem tud az első gazdagságáról, amelyről valahogy kiderült, hogy nincs igazán szüksége erre a vagyonra.
Ki a hibás ezért? - Tulajdonképpen senki. Jelenleg minden így van beállítva.
Ki szenved ettől? - Ez az, az egész társaság.
Ki javíthatja a helyzetet? - Igen, igen, FinOps.
A FinOps nem csupán egy réteg a fejlesztők és a szükséges berendezések között, hanem egy személy vagy csapat, aki tudni fogja, hogy hol, mi és mennyire „hazudik” a cég által megvásárolt azonos felhőtarifák tekintetében. Valójában ezeknek az embereknek együtt kell dolgozniuk egyrészt a DevOps-szal, másrészt a pénzügyi részleggel, hatékony közvetítőként és – ami a legfontosabb – elemzőként.
Egy kicsit az optimalizálásról
Felhők. Viszonylag olcsó és nagyon kényelmes. De ez a megoldás már nem olcsó, ha a szerverek száma eléri a két- vagy három számjegyet. Emellett a felhők egyre több olyan szolgáltatást tesznek lehetővé, amelyek korábban nem voltak elérhetőek: ezek az adatbázisok szolgáltatásként (Amazon AWS, Azure Database), a szerver nélküli alkalmazások (AWS Lambda, Azure Functions) és még sok más. Mindegyik nagyon klassz, mert könnyen használható - vásároljon és menjen, nincs probléma. De minél mélyebbre süllyed a cég és projektjei a felhőkbe, annál rosszabbul alszik a pénzügyi igazgató. És minél gyorsabban őszül a tábornok.
Az a helyzet, hogy a különböző felhőszolgáltatások számlái mindig rendkívül zavarosak: egy tételhez három oldalas magyarázatot kaphat, hogy mire, hová és hogyan ment el a pénz. Ez persze kellemes, de megérteni szinte lehetetlen. Sőt, véleményünk erről a kérdésről korántsem az egyetlen: a felhőalapú fiókok emberi fiókokba való átviteléhez teljes szolgáltatások állnak rendelkezésre, például vagy . Ha valakinek eszébe jutott egy külön szolgáltatás létrehozása a számlák megfejtésére, akkor a probléma mértéke túlnőtt a hajfestés költségein.
Tehát mit tesz a FinOps ebben a helyzetben:
- világosan megérti, hogy mikor és milyen mennyiségben vásárolták a felhőmegoldásokat.
- tudja, hogyan használják ezeket a kapacitásokat.
- egy adott egység igényeitől függően újraosztja őket.
- nem vásárol „hogy legyen”.
- és a végén pénzt takarít meg.
Jó példa erre az adatbázis hideg másolatának felhőalapú tárolása. Például archiválja, hogy csökkentse a tárhely frissítése során elfoglalt helyet és forgalmat? Igen, úgy tűnik, hogy a helyzet olcsó - egyetlen konkrét esetben, de az ilyen olcsó helyzetek összessége a későbbiekben a felhőszolgáltatások túlzott költségeit eredményezi.
Vagy egy másik helyzet: tartalékkapacitást vásárolt az AWS-ben vagy az Azure-ban, hogy ne essen a csúcsterhelés alá. Biztos lehet benne, hogy ez az optimális megoldás? Végül is, ha ezek a példányok 80%-ban tétlenek, akkor egyszerűen pénzt adsz az Amazonnak. Sőt, ilyen esetekben ugyanannak az AWS-nek és Azure-nak vannak feltörhető példányai – miért van szükség tétlen kiszolgálókra, ha egy eszközzel megoldhatja a csúcsterhelések problémáit? Vagy az On Premise példányok helyett inkább a Reserved felé nézzen – ezek sokkal olcsóbbak és kedvezményeket is kínálnak.
Egyébként a kedvezményekről
Ahogy az elején mondtuk, a beszerzést sokszor bárki lebonyolítja – megtalálták az utolsót, aztán valahogy ő maga csinálja. Leggyakrabban az amúgy is elfoglalt emberek „extrémmé” válnak, és ennek következtében olyan helyzetbe kerülünk, hogy az ember gyorsan és ügyesen, de teljesen önállóan dönti el, hogy mit és milyen mennyiségben vásároljon.
De ha a felhőszolgáltatás értékesítőjével kapcsolatba lép, kedvezőbb feltételeket kaphat a kapacitás nagykereskedelmi vásárlásakor. Egyértelmű, hogy egy csendes és egyoldalú regisztrációval rendelkező autóból nem kaphat ilyen kedvezményeket - de egy igazi értékesítési vezetővel való beszélgetés után kiéghet. Vagy ezek a srácok elmondhatják, hogy jelenleg milyen árengedményekkel rendelkeznek. Hasznos is lehet.
Ugyanakkor emlékeznie kell arra, hogy a fény nem konvergált ékként az AWS-en vagy az Azure-on. Természetesen szó sincs saját szerverterem megszervezéséről – e két klasszikus megoldásra azonban van alternatíva az óriáscégektől.
A Google például a Firebase platformot hozta el a cégeknek, amelyen ugyanazt a mobilprojektet kulcsrakészen fogadhatják, ami gyors skálázást igényelhet. Tárolás, valós idejű adatbázis, tárhely és felhőalapú adatszinkronizálás ezzel a megoldással példaként egy helyen érhető el.
Másrészt, ha nem monolitikus projektről beszélünk, hanem azok összességéről, akkor a központosított megoldás nem mindig előnyös. Ha a projekt hosszú életű, saját fejlesztési előzményekkel és ennek megfelelő adatmennyiséggel rendelkezik a tároláshoz, akkor érdemes töredezettebb elhelyezésben gondolkodni.
A felhőszolgáltatások költségeinek optimalizálásakor hirtelen ráébredhet, hogy az üzleti szempontból kritikus alkalmazásokhoz erősebb tarifákat vásárolhat, amelyek folyamatos bevételt biztosítanak a vállalat számára. Ezzel együtt megoldást jelent a fejlesztés „hagyatékának”, régi archívumainak, adatbázisainak stb., drága felhőkben való tárolása. Végül is az ilyen adatokhoz egy szabványos adatközpont normál merevlemezekkel és közepes teljesítményű hardverrel, csengő és síp nélkül teljesen megfelelő.
Itt is azt gondolhatnánk, hogy „nem éri meg ez a felhajtás”, de ennek a kiadványnak az egész problémája azon alapul, hogy a felelős emberek különböző szakaszokban elhanyagolják az apróságokat, és azt teszik, ami kényelmesebb és gyorsabb. Ami végül néhány év után ezekhez a horror beszámolókhoz vezet.
Az eredmény?
Általában véve a felhők menők, sok problémát megoldanak bármilyen méretű vállalkozás számára. A jelenség újszerűsége azonban azt jelenti, hogy még mindig nincs fogyasztási és gazdálkodási kultúránk. A FinOps egy olyan szervezeti kar, amely segít a felhőalapú teljesítmény hatékonyabb kihasználásában. A lényeg az, hogy ezt a pozíciót ne egy lőosztag analógjává változtassuk, amelynek feladata az lesz, hogy a figyelmetlen fejlesztőket kézen fogva „szidja” az állásidő miatt.
A fejlesztőknek fejleszteniük kell, nem a cég pénzét számolni. Ezért a FinOpsnak egyszerűvé és élvezetessé kell tennie a vásárlási folyamatot és a felhőkapacitás más csapatoknak történő leszerelését vagy átadását.
Forrás: will.com