Jy het beslis gewonder hoeveel jou projek se infrastruktuur kos. Terselfdertyd is dit verbasend: die groei van koste is nie lineêr met betrekking tot vragte nie. Baie sake-eienaars, vulstasies en ontwikkelaars verstaan heimlik dat hulle te veel betaal. Maar waarvoor presies?
Tipies kom die besnoeiing van koste neer op die vind van die goedkoopste oplossing, 'n AWS-plan, of, in die geval van fisiese rakke, die optimalisering van die hardeware-konfigurasie. Nie net dit nie: om die waarheid te sê, enigiemand doen dit, soos God wil: as ons praat van 'n begin, dan is dit waarskynlik 'n toonaangewende ontwikkelaar wat baie hoofpyn het. In groter kantore word dit deur die CMO/CTO hanteer, en soms raak die hoofdirekteur persoonlik saam met die hoofrekenmeester by die kwessie betrokke. Oor die algemeen, daardie mense wat genoeg "kern" bekommernisse het. En dit blyk dat infrastruktuurrekeninge styg, maar diegene wat nie die tyd het om dit te hanteer nie, hanteer dit.
Indien jy toiletpapier vir die kantoor moet koop, sal dit deur die voorsieningsbestuurder of 'n verantwoordelike persoon van die skoonmaakmaatskappy gedoen word. As ons praat oor ontwikkeling - lei en CTO. Verkope - alles is ook duidelik. Maar sedert die ou dae, toe 'n "bedienerkamer" 'n naam was vir 'n kabinet waarin daar 'n gewone toringstelsel was met 'n bietjie meer RAM en 'n paar hardeskywe in die aanval, ignoreer almal (of ten minste baie) die feit dat die aankoop van kapasiteit ook 'n spesiaal opgeleide persoon hanteer moet word.
Helaas, historiese geheue en ervaring dui daarop dat hierdie taak vir dekades na "lukraak" mense verskuif is: wie ook al die naaste was, het die vraag opgetel. En eers onlangs het die FinOps-professie op die mark begin vorm aanneem en 'n konkrete vorm aanneem. Dit is dieselfde spesiaal opgeleide persoon wie se taak is om die aankoop en gebruik van kapasiteit te beheer. En uiteindelik om die maatskappy se koste op hierdie gebied te verminder.
Ons bepleit nie om duur en doeltreffende oplossings te laat vaar nie: elke onderneming moet self besluit wat hy nodig het vir 'n gemaklike bestaan in terme van hardeware en wolktariewe. Maar 'n mens kan nie anders as om aandag te gee aan die feit dat ondeurdagte aankope "volgens die lys" sonder daaropvolgende monitering en ontleding van gebruik vir baie maatskappye uiteindelik baie, baie aansienlike verliese tot gevolg het as gevolg van ondoeltreffende bestuur van die "bates" van hul agterplaas.
Wie is FinOps
Kom ons sê jy het 'n betroubare onderneming, waarvan verkoopsmense op 'n asemrowende toon oor "onderneming" praat. Waarskynlik, "volgens die lys" het jy 'n dosyn of twee bedieners gekoop, AWS en 'n paar ander "klein dingetjies". Wat logies is: in 'n groot maatskappy vind 'n soort beweging voortdurend plaas - sommige spanne groei, ander disintegreer, ander word na naburige projekte oorgeplaas. En die kombinasie van hierdie bewegings, tesame met die “lysgebaseerde” verkrygingsmeganisme, lei uiteindelik tot nuwe grys hare wanneer na die volgende maandelikse infrastruktuurrekening gekyk word.
So wat om te doen - gaan geduldig voort om grys te word, verf daaroor, of vind die redes uit vir die voorkoms van hierdie talle verskriklike nulle in die betaling?
Kom ons wees eerlik: goedkeuring, goedkeuring en direkte betaling van 'n aansoek binne die maatskappy vir dieselfde AWS-tarief is nie altyd (in werklikheid amper nooit) vinnig nie. En juis as gevolg van die voortdurende korporatiewe beweging, kan sommige van hierdie selfde verkrygings iewers “verlore” wees. En dit is onbenullig om ledig te staan. As 'n aandagtige administrateur 'n eienaarlose rak in sy bedienerkamer opmerk, dan is alles in die geval van wolktariewe baie hartseerder. Hulle kan maande lank gelê word – betaal word, maar terselfdertyd nie meer nodig deur enigiemand in die departement waarvoor hulle gekoop is nie. Terselfdertyd begin kollegas van die volgende kantoor hul nog nie grys hare nie net op hul koppe uitskeur nie, maar ook op ander plekke - hulle kon nie vir die nde week vir ongeveer dieselfde AWS-tarief betaal nie, wat is broodnodig.
Wat is die mees voor die hand liggende oplossing? Dis reg, gee die leisels oor aan behoeftiges, en almal is gelukkig. Maar horisontale kommunikasie is nie altyd goed gevestig nie. En die tweede departement weet dalk eenvoudig nie van die rykdom van die eerste nie, wat op een of ander manier geblyk het dat dit nie regtig hierdie rykdom nodig het nie.
Wie is hiervoor te blameer? - Eintlik, niemand nie. Dis hoe alles vir nou ingestel is.
Wie ly hieraan? - Dit is dit, die hele maatskappy.
Wie kan die situasie regmaak? - Ja, ja, FinOps.
FinOps is nie net 'n laag tussen ontwikkelaars en die toerusting wat hulle nodig het nie, maar 'n persoon of span wat sal weet waar, wat en hoe goed dit "lê" in terme van dieselfde wolktariewe wat deur die maatskappy gekoop word. Trouens, hierdie mense moet saamwerk met DevOps, aan die een kant, en die finansiële departement aan die ander kant, en speel die rol van 'n effektiewe tussenganger en, bowenal, 'n ontleder.
'N bietjie oor optimalisering
Wolke. Relatief goedkoop en baie gerieflik. Maar hierdie oplossing hou op om goedkoop te wees wanneer die aantal bedieners dubbel- of driedubbelsyfers bereik. Boonop maak wolke dit moontlik om meer en meer dienste te gebruik wat voorheen nie beskikbaar was nie: dit is databasisse as 'n diens (Amazon AWS, Azure Database), bedienerlose toepassings (AWS Lambda, Azure Functions) en vele ander. Hulle is almal baie cool, want hulle is maklik om te gebruik - koop en gaan, geen probleme nie. Maar hoe dieper die maatskappy en sy projekte in die wolke duik, hoe slegter slaap die finansiële hoof. En hoe vinniger word die generaal grys.
Die feit is dat fakture vir verskeie wolkdienste altyd uiters verwarrend is: vir een item kan jy 'n drie bladsy-verduideliking ontvang van wat, waar en hoe jou geld gegaan het. Dit is natuurlik aangenaam, maar dit is amper onmoontlik om dit te verstaan. Boonop is ons mening oor hierdie kwessie ver van die enigste een: om wolkrekeninge na mense oor te dra, is daar hele dienste, byvoorbeeld of . As iemand die moeite gedoen het om 'n aparte diens te skep vir die ontsyfering van rekeninge, dan het die omvang van die probleem die koste van haarverf ontgroei.
So, wat doen FinOps in hierdie situasie:
- verstaan duidelik wanneer en in watter volumes wolkoplossings aangekoop is.
- weet hoe hierdie vermoëns gebruik word.
- herverdeel hulle na gelang van die behoeftes van 'n spesifieke eenheid.
- koop nie "sodat dit kan wees nie".
- en op die ou end spaar dit jou geld.
'n Goeie voorbeeld is wolkberging van 'n koue kopie van 'n databasis. Argiveer jy dit byvoorbeeld om die hoeveelheid spasie en verkeer wat verbruik word tydens die opdatering van die berging te verminder? Ja, dit wil voorkom asof die situasie goedkoop is - in 'n enkele spesifieke geval, maar die geheel van sulke goedkoop situasies lei later tot buitensporige koste vir wolkdienste.
Of 'n ander situasie: jy het reserwekapasiteit op AWS of Azure gekoop om nie onder pieklas te val nie. Kan jy seker wees dat dit die optimale oplossing is? Na alles, as hierdie gevalle 80% ledig is, gee jy bloot geld aan Amazon. Boonop, vir sulke gevalle, het dieselfde AWS en Azure barstbare gevalle - hoekom het jy ledige bedieners nodig as jy 'n instrument kan gebruik om probleme van piekladings op te los? Of, in plaas van On Premise-gevalle, moet jy na Reserved kyk - hulle is baie goedkoper en hulle bied ook afslag.
Terloops, oor afslag
Soos ons aan die begin gesê het, word verkryging dikwels deur enigiemand uitgevoer - hulle het die laaste een gevind, en dan doen hy dit op een of ander manier self. Dikwels word mense wat reeds besig is "uiters", en as gevolg daarvan kry ons 'n situasie waar 'n persoon vinnig en vaardig, maar heeltemal onafhanklik, besluit wat en in watter hoeveelhede om te koop.
Maar wanneer u met 'n verkoopspersoon van die wolkdiens kommunikeer, kan u gunstiger toestande kry wanneer dit kom by die groothandelaankoop van kapasiteit. Dit is duidelik dat jy nie sulke afslag van 'n motor met 'n stil en eensydige registrasie sal kan kry nie - maar nadat jy met 'n regte verkoopsbestuurder gepraat het, kan jy uitbrand. Of hierdie ouens kan jou vertel waarop hulle tans afslag het. Dit kan ook nuttig wees.
Terselfdertyd moet jy onthou dat die lig nie soos 'n wig op AWS of Azure konvergeer het nie. Daar is natuurlik geen sprake daarvan om jou eie bedienerkamer te organiseer nie – maar daar is alternatiewe vir hierdie twee klassieke oplossings van die reuse.
Byvoorbeeld, Google het die Firebase-platform na maatskappye gebring, waarop hulle dieselfde mobiele projek op 'n sleutel-basis kan aanbied, wat vinnige skaal kan vereis. Berging, intydse databasis, hosting en wolkdatasinchronisasie deur hierdie oplossing as voorbeeld te gebruik, is op een plek beskikbaar.
Aan die ander kant, as ons nie van 'n monolitiese projek praat nie, maar van hul totaliteit, dan is 'n gesentraliseerde oplossing nie altyd voordelig nie. As die projek langlewend is, sy eie ontwikkelingsgeskiedenis het en 'n ooreenstemmende hoeveelheid data wat benodig word vir berging, is dit die moeite werd om te dink aan meer gefragmenteerde plasing.
Wanneer jy koste vir wolkdienste optimaliseer, kan jy skielik besef dat jy vir besigheidskritiese toepassings kragtiger tariewe kan koop wat die maatskappy van ononderbroke verdienste sal voorsien. Terselfdertyd is die berging van die "nalatenskap" van ontwikkeling, ou argiewe, databasisse, ens. in duur wolke 'n oplossing. Vir sulke data is 'n standaard datasentrum met gewone HDD's en mediumkrag hardeware sonder enige klokkies en fluitjies immers heel geskik.
Hier kan jy dalk weer dink dat “hierdie bohaai nie die moeite werd is nie”, maar die hele probleem van hierdie publikasie is gebaseer op die feit dat die verantwoordelike mense in verskeie stadiums die klein dingetjies afskeep en doen wat geriefliker en vinniger is. Wat uiteindelik na 'n paar jaar daardie einste gruwelverslae tot gevolg het.
Die resultaat?
Oor die algemeen is wolke koel, dit los baie probleme op vir besighede van enige grootte. Die nuutheid van hierdie verskynsel beteken egter dat ons steeds nie 'n kultuur van verbruik en bestuur het nie. FinOps is 'n organisatoriese hefboom wat jou help om wolkkrag meer effektief te benut. Die belangrikste ding is om nie hierdie posisie in 'n analoog van 'n vuurpeloton te verander nie, wie se taak sal wees om onoplettende ontwikkelaars met die hand te vang en hulle te "skel" vir stilstand.
Ontwikkelaars moet ontwikkel, nie maatskappygeld tel nie. En dus behoort FinOps beide die aankoopproses en die proses om wolkkapasiteit uit diens te stel of oor te dra na ander spanne 'n geleentheid eenvoudig en aangenaam vir alle partye te maak.
Bron: will.com