Si të fitoni 1 milion dollarë me AWS në një vit

Nëse keni hasur në këtë faqe duke menduar se do të pasuroheni me ndonjë skemë të pasurimit të shpejtë, më vjen keq t'ju zhgënjej. Ky artikull do të flasë më tepër se si të ulni faturat e kostos së cloud me 1 milion dollarë. Duke bërë këtë, në thelb do të keni gjeneruar një milion dollarë shtesë të ardhura – të cilat mund t'i shpenzoni duke blerë kursin tim në internet se si të pasuroheni me AWS ( lidhja me kursin këtu ).

Kostoja e resë kompjuterike shpesh anashkalohet dhe nuk llogaritet në fillim të projekteve të kompanive. Sondazhi i HashiCorp i vitit 2021 zbuloi se pothuajse 40% e kompanive shpenzuan mbi kostot e cloud në 2021 [ 1 ]. Në vitin 2023, pothuajse të gjitha kompanitë (94%) pranuan se po shpenzonin para në cloud [ 1 ] dhe të paktën 30% e kostos së resë kompjuterike u shpërdorua [ 2 ]. Shpenzimet e cloud ishin pothuajse 500 miliardë dollarë në 2022 - prandaj po flasim për 150 miliardë dollarë të humbur në vit!!

Jo vetëm ky është një shqetësim për të ardhurat e munguara, por edhe për praktikat e dobëta të qëndrueshmërisë. 150 miliardë dollarë energji e humbur!

Këto gjetje përfshijnë ndërmarrje të mëdha si dhe ato më të vogla, nga maturimi me renë e lartë deri tek maturimi me renë e ulët. I referohet AWS, por të njëjtat parime mund të zbatohen për çdo ofrues tjetër cloud. Pra, nëse ndonjë pjesë e punës suaj është në re, atëherë ky artikull është për ju.

Po flas nga perspektiva e inxhinierit të të dhënave, por të njëjtat mësime mund të zbatohen në praktikat e tjera të inxhinierisë softuerike.

Le të zhytemi.

Çfarë nevojitet për të shpenzuar 1 milion dollarë në kostot e cloud në një vit?

Kjo lloj faturë cloud zakonisht kufizohet në ndërmarrje shumë të mëdha që operojnë globalisht me miliona klientë.

Për t'ju dhënë një ide, një faturë prej 1 milion dollarësh në renë kompjuterike mund të rezultojë nga një punë në Spark ETL që përpunon ~ 1,5 Tb në orë 24x7 për 365 ditë në vit. Një shembull tjetër mund të jetë një aplikacion që merr miliarda kërkesa në ditë nga shumë vende në botë.

Në një ndërmarrje të madhe, ka qindra aplikacione në këtë madhësi - duke rezultuar në kontrata miliarda dollarësh me ofruesit e cloud. Për shembull, Airbnb kishte një angazhim për të shpenzuar 1.2 miliardë dollarë në burimet cloud gjatë pesë viteve në fund të 2019-ës [3 ].

Në Expedia ne ulëm kostot për një ETL të përpunimit të të dhënave që kushton 1.1 milion dollarë në vit në vetëm 100,000 dollarë në vit duke zbatuar praktika optimizimi. Kjo është një ulje e kostos 91%!!

Jo të gjitha kompanitë kanë aplikacione të një madhësie kaq të madhe, por imagjinoni uljen e kostos së cloud me 90% vetëm për një aplikacion të vetëm ose për të gjithë kompaninë tuaj.

Si të fillojmë të kursejmë?

HAPI 1: Sfidoni supozimet tuaja të projektimit

Shkoni dhe merrni një listë të aplikacioneve tuaja më të shtrenjta dhe sfidoni supozimet tuaja të dizajnit .

• A po ndërtoni një aplikacion që ka një disponueshmëri 99,999% dhe vonesë nën milisekonda, por realisht përdoruesit do të ishin mjaft të mirë me një disponueshmëri 99% dhe latente qindra milisekonda?
• A po krijoni grupe të dhënash me miliarda rreshta, por përdoruesit do të përdorin vetëm grumbullime të disa prej masave?
• A po dërgoni të dhëna në kohë reale, por të dhënat analizohen vetëm një herë në ditë?
• A po e rifreskoni cache-në çdo 10 sekonda, por ajo ndryshon vërtet vetëm gjatë ditëve?

Të gjitha këto pyetje kthehen në pyetjen më të rëndësishme: si do të përdoret aplikacioni? Cila është vlera e biznesit për të ekzistuar? Si po na ndihmon aplikacioni për të arritur një qëllim të caktuar?

Natyrisht, të gjitha këto përgjigje janë shumë shpesh të paqarta në fillim të një projekti; por kjo është arsyeja pse dizajni duhet të jetë gjithmonë një proces përsëritës – duke lejuar që ndryshimet të ndodhin sa më mirë që të jetë e mundur. Inxhinierët duhet të përqafojnë evolucionin dhe ndryshimin, duke përafruar zhvillimin e aplikacioneve me ndikimin.

HAPI 2: Rregulloni burimet tuaja të infrastrukturës sipas nevojave tuaja

Hapi i dytë konsiston në sigurimin e aplikacionit me burimet e duhura dhe përshtatjen e tij në infrastrukturën e duhur.

Si inxhinier, jini të vetëdijshëm se si llogariten kostot e cloud. Për shembull, AWS ofron raste spot, ku mund të ofertoni për çmimin e grupit – kjo është veçanërisht e dobishme nëse keni aplikacione tolerante ndaj gabimeve dhe fleksibël. Përdorni ato nëse mundeni - AWS pretendon deri në 90% ulje të kostove [ 4 ].

Disa konsiderata të tjera që mund të dëshironi të trajtoni janë:

• A u shërbeni klientëve globalisht apo vetëm në një zonë gjeografike? A keni vërtet nevojë për infrastrukturën tuaj për të jetuar në të gjithë globin apo mund ta vendosni atë më afër bazës së klientëve tuaj?
• A po i mbi-proviziononi rastet tuaja të grupimit? Përpiquni të siguroheni që ka kapacitet të mjaftueshëm për të përballuar ngarkesat maksimale pa kosto të panevojshme. Përdorni shkallëzimin automatik për të rregulluar në mënyrë dinamike burimet bazuar në kërkesën aktuale, duke parandaluar mbipagesën për burimet boshe.
• Nëse jeni duke punuar me të dhëna dhe Spark, sigurohuni që të kuptoni konceptet dhe sintonizimin e Spark! Nëse nuk e bëni, hidhini një sy burimeve të mëposhtme [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

HAPI 3: Përdorni instancat AWS Graviton

Ka pak ose aspak të meta në përdorimin e instancave AWS Graviton. AWS ka investuar shumë në krijimin e procesorëve më me kosto efektive. Ju mund të merrni deri në 40% ulje të shpenzimeve në cloud vetëm duke kaluar nga një procesor i bazuar në intel në një procesor të bazuar në ARM [ 10 ].

E vetmja paralajmërim për këtë është se aplikacioni juaj duhet të jetë i pajtueshëm me procesorët e bazuar në ARM me të cilët funksionon Graviton. Nëse keni të bëni me një shërbim të menaxhuar si RDS ose OpenSearch, atëherë nuk ka fare komplikime në ndërrimin - AWS merret me përputhshmërinë e sistemit operativ dhe aplikacionit. Nëse po ndërtoni aplikacionin tuaj, atëherë mund t'ju duhet të ripërpiloni paketën në varësi të gjuhës që përdorni - Java dhe gjuhët e tjera nuk kërkojnë ndryshim ndërsa Python kërkon vëmendje.

HAPI 4: Monitoroni shpenzimet tuaja të kostos dhe edukoni për ndërgjegjësimin e kostos

Së fundmi, mos harroni të vazhdoni të monitoroni kostot tuaja për maja dhe surpriza të papritura. Kostoja në ditën 0 të aplikacionit tuaj do të jetë e ndryshme nga kostoja e ditës 170. Sigurohuni që të mbani gjurmët e ndryshimeve dhe e kuptoni pse po ndodh ndryshimi: a grumbullon kostot e ruajtjes së s3 apo është vetëm një herë thumba?

Vendosni sinjalizimet e nevojshme dhe udhëzuesit operativë !

E rëndësishmja, zbatoni etiketat e shpërndarjes së kostos për të gjurmuar shpenzimet sipas departamentit, projektit ose mjedisit. Shmangni rrezikun e krijimit të një kënete të dhënash ku kostoja është e pagjurmueshme ose kërkon një udhëtim të gjatë nëpër sisteme të ndryshme regjistrash. Duhet të jetë i shpejtë dhe i thjeshtë për t'u kthyer në çdo kosto të caktuar aplikimi.

Mendimet e fundit

Kudo që jeni duke punuar, është e vështirë të balanconi ofrimin e veçorive të reja me optimizimin e atyre aktuale. Kush nuk ka qenë nën presion për të ofruar karakteristika të reja të çuditshme me shpejtësinë e dritës.

Megjithatë, është thelbësore si për inxhinierët ashtu edhe për menaxherët që të marrin vendime të qëllimshme dhe proaktive në lidhje me projektet e tyre aktuale, duke menaxhuar në mënyrë efektive rreziqet dhe mundësitë.