Sigurisht, ju keni pyetur sa kushton infrastruktura e projektit tuaj. Bej një surprizë: rritja e shpenzimeve nuk është lineare në lidhje me ngarkesat. Shumë pronarë biznesesh, CTO dhe zhvillues veçmas e kuptojnë që po paguajnë më shumë. Por për çfarë konkretisht?
Zakonisht, reduktimi i shpenzimeve pĂ«rfshin thjesht kĂ«rkimin e zgjidhjes mĂ« tĂ« lirĂ«, planit AWS ose, nĂ«se flasim pĂ«r raftet fizike, optimizimin e konfigurimit tĂ« pajisjeve. MĂ« shumĂ«, nĂ« tĂ« vĂ«rtetĂ«, kjo Ă«shtĂ« diçka me tĂ« cilĂ«n merret kushdo dhe siç e do Zoti: nĂ«se flasim pĂ«r njĂ« startup, ndoshta Ă«shtĂ« zhvilluesi kryesor qĂ« ka mjaft halle. NĂ« kompanitĂ« mĂ« tĂ« mĂ«dha, kĂ«saj i japin pĂ«rparĂ«si CMO/CTO dhe ndonjĂ«herĂ« merr pjesĂ« personalisht CEO-i me kreun e financave. NĂ« fund, ata janĂ« ata persona qĂ« kanĂ« âangazhime profesionaleâ tĂ« mjaftueshme. Dhe rezultati Ă«shtĂ« qĂ« faturat pĂ«r infrastrukturĂ«n rriten, por merret me kĂ«tĂ«... ai qĂ« nuk ka kohĂ« pĂ«r tĂ«.
NĂ«se zyrĂ«s i duhet tĂ« blejĂ« letĂ«r higjenike, kjo do tĂ« merret nga menaxheri i logjistikĂ«s ose ndonjĂ« person pĂ«rgjegjĂ«s nga kompania pastrimi. NĂ«se flasim pĂ«r zhvillimin â liderĂ«t dhe CTO. Shitjet gjithashtu janĂ« tĂ« qarta. Por qĂ« nga koha e vjetĂ«r, kur âserverâ quhej sidoqoftĂ« njĂ« dollap ku ishte njĂ« sistem PC tower me pak mĂ« shumĂ« memorie RAM dhe disa hard diskĂ« nĂ« RAID, tĂ« gjithĂ« (ose, siç do tĂ« paktĂ«n, shumĂ«) injorojnĂ« faktin se blerja e kapaciteteve duhet tĂ« merret nga njĂ« person i trajnuar posaçërisht.
FatkeqĂ«sisht, kujtesa historike dhe pĂ«rvoja tregojnĂ« se kjo detyrĂ« Ă«shtĂ« transferuar pĂ«r dekada mbi njerĂ«z ârastĂ«sorĂ«â: kush ishte afĂ«r, ai e mori çështjen. Dhe vetĂ«m sĂ« fundmi nĂ« treg ka filluar tĂ« formohet dhe tĂ« pranohen disa konture specifike tĂ« profesionit FinOps. Ky Ă«shtĂ« ai personi i trajnuar posaçërisht, i cili ka pĂ«r detyrĂ« kontrollimin e blerjeve dhe pĂ«rdorimit tĂ« kapaciteteve. Dhe, nĂ« fund, pĂ«r uljen e shpenzimeve tĂ« kompanisĂ« nĂ« kĂ«tĂ« drejtim.
Ne e shmangim që të heqim dorë nga zgjidhjet e shtrenjta dhe efektive: çdokër biznes duhet të vendosë vetë se çfarë i nevojitet për një ekzistencë komode në aspektin e pajisjeve dhe çmimeve të cloud. Por nuk mund të mos i kushtohet vëmendje faktit se blerja e menduar "sipër listës" pa kontroll dhe analizë të mëvonshme të përdorimit për shumë kompani përfundon në humbje shumë të mëdha për shkak të menaxhimit të paefektshëm të "aktiveve" të backend-it të tyre.
Kush është FinOps
Të supozojmë se keni një ndërmarrje të konsiderueshme, për të cilën shitësit flasin me frymë. Ndërsa me siguri keni blerë një duzinë serverësh, AWS dhe disa gjëra të tjera 'për gjëra të vogla'. Kjo është logjike: në një kompani të madhe ka vazhdimisht ndonjë lëvizje - disa ekipe rriten, të tjera shperbhen, të treta kalojnë në projekte fqinje. Dhe ky kombinim i lëvizjeve së bashku me mekanizmin e blerjeve 'sipër listës' përfundon me flokë të bardhë teksa shikoni faturën e ardhshme mujore për infrastrukturën.
ĂfarĂ« duhet tĂ« bĂ«ni - tĂ« prisni me durim, tĂ« mbuloni ose tĂ« kuptoni arsyet pĂ«r shfaqjen e kĂ«tyre zero-ve tĂ« frikshme nĂ« faturĂ«n tuaj?
ĂfarĂ« do tĂ« thoshit: miratimi, aprovimi dhe pagesa e kĂ«rkesĂ«s brenda kompanisĂ« pĂ«r tĂ« njĂ«jtin tarifĂ« AWS - nuk Ă«shtĂ« gjithmonĂ« (nĂ« realitet - pothuajse kurrĂ«) njĂ« proces i shpejtĂ«. Dhe pikĂ«risht pĂ«r shkak tĂ« lĂ«vizjes korporative konstante, njĂ« pjesĂ« e kĂ«tyre blerjeve mund tĂ« 'humbin' diku. Dhe thjesht tĂ« thatĂ«. NĂ«se njĂ« administratori tĂ« kujdesshĂ«m nĂ« serverin e tij i bie syri njĂ« stendĂ« tĂ« braktisur, me tarifat cloud Ă«shtĂ« shumĂ« mĂ« keq. Ato mund tĂ« qĂ«ndrojnĂ« 'nĂ« peizazh' pĂ«r muaj me radhĂ« - tĂ« paguara, por nĂ« tĂ« njĂ«jtĂ«n kohĂ« tashmĂ« tĂ« pavlera pĂ«r departamentin pĂ«r tĂ« cilin u blenĂ«. NdĂ«rkohĂ«, kolegĂ«t nga zyrat fqinje, flokĂ«t e tyre ende tĂ« pafraktuar, fillojnĂ« tĂ« çmenden - ata nuk kanĂ« mundur tĂ« paguajnĂ« njĂ« tarifĂ« tĂ« ngjashme AWS pĂ«r javĂ« tĂ« tĂ«ra, qĂ« u nevojitet urgjentisht.
Cila është zgjidhja më e dukshme? E saktë, t'ia kalosh nevojtarëve, dhe të gjithë janë të kënaqur. Por komunikimet horizontale nuk janë gjithmonë të vendosura mirë. Dhe departamenti i dytë mund thjesht të mos e dijë për pasurinë e parë, e cila ndoshta nuk i është dukur aq e rëndësishme.
Kush Ă«shtĂ« fajtor? â NĂ« pĂ«rgjithĂ«si, askush. KĂ«shtu Ă«shtĂ« pĂ«r momentin.
Kush po vuan nga kjo? â TĂ« gjithĂ«, e gjithĂ« kompania.
Kush mund ta rregullojĂ« situatĂ«n? â Po, FinOps.
FinOps nuk është thjesht një ndërmjetës midis zhvilluesve dhe pajisjeve që iu nevojiten atyre, por një person ose ekip që do të dijë se ku, çfarë dhe sa mirë "ndodhet" në lidhje me tarifat cloud, të blera nga kompania. Praktikisht, këta njerëz duhet të punojnë ngushtë me DevOps nga njëra anë, dhe me departamentin financiar nga ana tjetër, duke luajtur rolin e një ndërmjetësi efektiv dhe, më e rëndësishmja, të një analisti.
Pak për optimizimin
TĂ« dhĂ«nat cloud. Relativisht tĂ« lira dhe shumĂ« tĂ« pĂ«rshtatshme. Por kjo zgjidhje fillon tĂ« mos jetĂ« e lirĂ« kur numri i serverĂ«ve arrin dyshifror ose tre shifror. Gjithashtu, cloud ofron mundĂ«sinĂ« pĂ«r tĂ« pĂ«rdorur gjithnjĂ« e mĂ« shumĂ« shĂ«rbime qĂ« mĂ« parĂ« ishin tĂ« paaksesueshme: kjo Ă«shtĂ« si bazat e tĂ« dhĂ«nave si shĂ«rbim (Amazon AWS, Azure Database), aplikacione pa server (AWS Lambda, Azure Functions) dhe shumĂ« tĂ« tjera. TĂ« gjitha janĂ« tĂ« shkĂ«lqyera nĂ« pĂ«rdorim â Ă«shtĂ« thjesht blerĂ« dhe e ke, nuk ka problemo. Por sa mĂ« thellĂ« tĂ« zhytet kompania dhe projektet e saj nĂ« cloud, aq mĂ« mirĂ« fle drejtori financiar. Dhe aq mĂ« shpejt i bardhĂ«sohet koka drejtorit tĂ« pĂ«rgjithshĂ«m.
E vërteta është se faturat për shërbime të ndryshme cloud janë gjithmonë ekstremisht të përziera: për një pozicion mund të merrni një shpjegim tre faqesh, për çfarë, ku dhe si shkuan paratë tuaja. Kjo, sigurisht, është e këndshme, por të kuptosh atë është praktikisht e pamundur. Për më tepër, mendimi ynë në këtë çështje nuk është i vetmi: për të përkthyer faturat cloud në një gjuhë të kuptueshme, ekzistojnë shërbime të tëra, p.sh. ose . Nëse dikush u mundua të krijojë një shërbim të veçantë për shpjegimin e faturave, atëherë shkallë e problemit ka kaluar koston e ngjyrës për flokët.
Pra, çfarë bën FinOps në këtë situatë:
- kupton qartë kur dhe në cilat sasi janë blerë zgjidhje cloud.
- di se si përdoren këto kapacitete.
- rredispon ato, varësisht nga nevojat e departamenteve të ndryshme.
- nuk blen "për të pasur".
- dhe nĂ« fund â kursen paratĂ« tuaja.
NjĂ« shembull i shkĂ«lqyer Ă«shtĂ« ruajtja nĂ« cloud e njĂ« kopjeje tĂ« ftohtĂ« tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave. Ju, pĂ«r shembull, e arkivoni atĂ« qĂ« tĂ« reduktoni hapĂ«sirĂ«n e konsumuar dhe trafikun gjatĂ« azhurnimit tĂ« ruajtjes? Po, duket se situata Ă«shtĂ« e vogĂ«l â nĂ« njĂ« rast tĂ« veçantĂ«, por bashkimi i tillĂ« i situatave tĂ« vogla pĂ«rfundojnĂ« tĂ« bĂ«hen shpenzime tĂ« mĂ«dha pĂ«r shĂ«rbimet cloud.
Ose njĂ« situatĂ« tjetĂ«r: keni blerĂ« kapacitete nĂ« rezervĂ« nĂ« AWS ose Azure, pĂ«r tĂ« mos u goditur gjatĂ« ngarkesĂ«s maksimale. A mund tĂ« jeni tĂ« sigurt qĂ« kjo Ă«shtĂ« zgjidhja mĂ« optimale? Sepse nĂ«se kĂ«to instancat qĂ«ndrojnĂ« tĂ« papĂ«rdorura 80%, atĂ«herĂ« thjesht po i jepni para Amazonit. MĂ« shumĂ«, pĂ«r kĂ«to raste, tĂ« njĂ«jtit AWS dhe Azure kanĂ« instanca burstable â pse ju nevojiten serverĂ« nĂ« punĂ« tĂ« kotĂ«, kur mund tĂ« pĂ«rdorni njĂ« mjet pĂ«r tĂ« zgjidhur pikĂ«risht problemet e ngarkesave maksimale? Ose nĂ« vend tĂ« instancave On Premise, duhet tĂ« shqyrtoni ato tĂ« Rezervuara â ato dalin shumĂ« mĂ« lirĂ« dhe madje ofrojnĂ« zbritje.
Për më tepër, bëhet fjalë për zbritjet
Ashtu siç kemi folur nĂ« fillim, blerjet shpesh bĂ«hen nga kushdo â gjetĂ«n njĂ« âtĂ« funditâ, dhe pastaj ai do tĂ« gjejĂ« njĂ« zgjidhje pĂ«r vete. Shpesh, âtĂ« funditâ bĂ«hen ata njerĂ«z qĂ« janĂ« shumĂ« tĂ« zĂ«nĂ«, dhe rezultati Ă«shtĂ« se marrim njĂ« situatĂ« ku njĂ« person vendos shpejt dhe me kualifikim, por plotĂ«sisht nĂ« vetvete, se çfarĂ« dhe nĂ« cilat sasi duhet tĂ« blejĂ«.
MirĂ«po, duke bashkĂ«punuar me njĂ« shitĂ«s nga shĂ«rbimi cloud, mund tĂ« merrni kushte mĂ« tĂ« favorshme, nĂ«se bĂ«het fjalĂ« pĂ«r blerje me shumicĂ« tĂ« kapacitetit. Sigurisht, pĂ«r tĂ« marrĂ« kĂ«to zbritje nga njĂ« makinĂ« me regjistrim tĂ« heshtur dhe njĂ«anshĂ«m nuk do tĂ« arrini â por pas bisedave me njĂ« menaxher tĂ« vĂ«rtetĂ« tĂ« shitjeve, ndoshta do tĂ« fitoni. Po ashtu, kĂ«ta njerĂ«z mund tĂ« tregojnĂ« se pĂ«r çfarĂ« kanĂ« aktualisht zbritje. Kjo gjithashtu mund tĂ« jetĂ« e dobishme.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, duhet tĂ« mbahet mend qĂ« AWS ose Azure nuk janĂ« zgjidhja e vetme. Sigurisht, nuk ka bisedĂ« pĂ«r organizimin e serverĂ«ve tĂ« tu â por ka alternativa pĂ«r kĂ«to dy zgjidhje klasike nga gjigantĂ«t.
PĂ«r shembull, Google ofron pĂ«r kompanitĂ« platformĂ«n Firebase, ku mund tĂ« vendosni njĂ« projekt tĂ« tillĂ« mobil âme çelĂ«sâ qĂ« mund tĂ« kĂ«rkojĂ« zgjerim tĂ« shpejtĂ«. Gjetjet, databazat nĂ« kohĂ« reale, akomodimi dhe sinkronizimi i tĂ« dhĂ«nave nĂ« cloud, tĂ« gjitha janĂ« tĂ« aksesueshme nĂ« kĂ«tĂ« zgjidhje nĂ« njĂ« vend.
Nga ana tjetër, nëse flasim jo për një projekt monolitik, por për përbërjen e tyre, zgjidhja centralizuese nuk është gjithmonë e leverdishme. Nëse projekti është afatgjatë, ka një histori zhvillimi dhe sasinë e nevojshme të të dhënave për ruajtje, atëherë është e arsyeshme të mendohet për një shpërndarje më fragmentarike.
Kur optimizoni shpenzimet pĂ«r shĂ«rbimet cloud, mund t'ju duket se pĂ«r aplikacionet kritike pĂ«r biznesin, mund tĂ« blini tarifa mĂ« tĂ« fuqishme qĂ« do tĂ« sigurojnĂ« njĂ« fitim tĂ« pandĂ«rprerĂ« pĂ«r kompaninĂ«. MegjithatĂ«, ruajtja e 'trashĂ«gimisĂ«' sĂ« zhvillimit, arkivave tĂ« vjetra, DB-ve dhe tĂ« tjera nĂ« cloud tĂ« shtrenjta â Ă«shtĂ« njĂ« zgjidhje e diskutueshme. Sepse pĂ«r kĂ«to tĂ« dhĂ«na, njĂ« qendĂ«r tĂ« dhĂ«nash standarde me HDD tĂ« zakonshĂ«m dhe hardware tĂ« mesĂ«m pa ndonjĂ« 'shtesĂ«' do tĂ« ishte mjaft e pĂ«rshtatshme.
KĂ«tu mund tĂ« mendoni pĂ«rsĂ«ri se 'kjo mesele nuk ia vlen', por problemi i gjithĂ« kĂ«saj publikimi bazohet nĂ« faktin se nĂ« faza tĂ« ndryshme, individĂ«t pĂ«rgjegjĂ«s e injorojnĂ« tĂ« voglat dhe e bĂ«jnĂ« atĂ« siç Ă«shtĂ« mĂ« e lehtĂ« dhe mĂ« e shpejtĂ«. ĂfarĂ«, nĂ« fund, pas disa viteve rezulton nĂ« ato llogari horror.
ĂfarĂ« nĂ« pĂ«rfundim?
Në fakt, cloud është fantastik, ai zgjidh një mori problemesh për biznesin e çdo madhësie. Sidoqoftë, risia e këtij fenomeni çon në faktin se ende nuk kemi një kulturë të konsumimit dhe menaxhimit. FinOps është një levë organisatorike që ndihmon për të përdorur më efektivisht kapacitetet cloud. E rëndësishme është të mos e kthejmë këtë pozita në analogun e një skuadre ekzekutimi, qëllimi i së cilës do të jetë të kapë zhvilluesit e pa-vëmendshëm dhe t'i 'ndëshkojë' ata për qëndrimin e kapaciteteve.
Zhvilluesit duhet të zhvillojnë, jo të llogarisin paratë e kompanisë. Dhe FinOps duhet ta bëjë si procesin e blerjes, ashtu edhe procesin e shkarkimit ose transferimit të kapaciteteve cloud në ekipe të tjera një aktivitet të thjeshtë dhe këndshëm për të gjitha palët.
Burimi: habr.com
