![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Ako ste naleteli na ovu stranicu misleći da ćete se obogatiti nekom šemom za brzo bogaćenje, žao mi je što ću vas razočarati. Ovaj članak će radije govoriti o tome kako smanjiti svoje račune za oblak za milion dolara. Čineći to, u suštini ćete ostvariti dodatnih milion dolara prihoda — koje možete potrošiti kupujući moj online kurs o tome kako se obogatiti uz AWS ( link do kursa ovdje ).
Troškovi u oblaku se često zanemaruju i ne uzimaju u obzir na početku projekata kompanija. Istraživanje HashiCorp-a iz 2021. pokazalo je da je skoro 40% kompanija potrošilo previše na troškove oblaka u 2021. [ 1 ]. U 2023. godini, skoro sve kompanije (94%) su priznale da su trošile novac na oblak [ 1 ] i najmanje 30% troškova oblaka je potrošeno [ 2 ]. Potrošnja u oblaku bila je skoro 500 milijardi dolara 2022. godine — dakle govorimo o 150 milijardi dolara potrošeno godišnje!!
Ne samo da je ovo zabrinutost zbog propuštenih prihoda već i zbog loših praksi održivosti. 150 milijardi dolara izgubljene energije!
Ovi nalazi se odnose na velika preduzeća kao i na manja, od zrelosti sa visokim oblacima do zrelosti sa niskim nivoom oblaka. Odnosi se na AWS, ali isti principi se mogu primijeniti na bilo koji drugi provajder u oblaku. Dakle, ako je bilo koji dio vašeg posla u oblaku, onda je ovaj članak za vas.
Govorim iz perspektive inženjera podataka, ali ista učenja se mogu primijeniti na druge prakse softverskog inženjeringa.
Hajde da zaronimo.
Ova vrsta računa u oblaku obično je ograničena na veoma velika preduzeća koja posluju globalno sa milionima klijenata.
Da vam dam ideju, račun u oblaku od 1 milion dolara može biti rezultat obrade posla Spark ETL ~1,5 Tb na sat 24x7 tokom 365 dana u godini. Drugi primjer može biti aplikacija koja dnevno prima milijarde zahtjeva sa više lokacija u svijetu.
U velikom preduzeću postoje stotine aplikacija ove veličine - što rezultira ugovorima od milijardu dolara sa dobavljačima u oblaku. Na primjer, Airbnb se obavezao potrošiti 1,2 milijarde dolara na resurse u oblaku tokom pet godina na kraju 2019. [3 ].
U Expediji smo smanjili troškove za obradu podataka ETL koja košta 1,1 milion dolara godišnje na samo 100.000 dolara godišnje primenom praksi optimizacije. To je smanjenje troškova za 91%!!
Nemaju sve kompanije aplikacije tako velike veličine, ali zamislite da smanjite troškove oblaka za 90% samo za jednu aplikaciju ili za cijelu kompaniju.
Idite i nabavite listu svojih najskupljih aplikacija i osporite svoje dizajnerske pretpostavke .
Sva ova pitanja vraćaju se na najvažnije pitanje: kako će se aplikacija koristiti? Koja je poslovna vrijednost za postojanje? Kako nam aplikacija pomaže da postignemo zadani cilj?
Naravno, svi ovi odgovori su često nejasni na početku projekta; ali zato dizajn treba uvijek biti iterativni proces – omogućavajući da se promjene dogode što je lakše moguće. Inženjeri bi trebalo da prihvate evoluciju i promene, usklađujući razvoj aplikacija sa uticajem.
Drugi korak se sastoji od obezbjeđivanja aplikaciji pravih resursa i prilagođavanja odgovarajuće infrastrukture.
Kao inženjer, budite svjesni kako se izračunavaju troškovi oblaka. Na primjer, AWS pruža spot instance, gdje možete licitirati za cijenu klastera — ovo je posebno korisno ako imate fleksibilne aplikacije otporne na greške. Koristite ih ako možete — AWS zahteva smanjenje troškova do 90% [ 4 ].
Neka druga razmatranja na koja biste mogli da se pozabavite su:
Postoji malo ili nimalo nedostataka u korištenju AWS Graviton instanci. AWS je uložio velika sredstva u stvaranje najisplativijih procesora. Možete postići do 40% smanjenje potrošnje u oblaku samo prelaskom sa procesora zasnovanog na Intelu na ARM procesor [ 10 ].
Jedino upozorenje za ovo je da vaša aplikacija mora biti kompatibilna sa ARM-baziranim procesorima na kojima Graviton radi. Ako imate posla sa upravljanom uslugom kao što je RDS ili OpenSearch, onda nema nikakvih komplikacija u prebacivanju — AWS se bavi osnovnim OS-om i kompatibilnošću aplikacija. Ako pravite sopstvenu aplikaciju, možda ćete morati ponovo da kompajlirate paket u zavisnosti od jezika koji koristite — Java i drugi jezici ne zahtevaju promene, dok Python zahteva malo pažnje.
I na kraju, ne zaboravite stalno pratiti svoje troškove za neočekivane vrhunce i iznenađenja. Trošak 0. dana vaše aplikacije bit će drugačiji od cijene 170. dana. Vodite računa o tome da pratite promjene i shvatite zašto se promjena događa: da li se radi o slaganju troškova skladištenja s3 ili je to samo jednokratno spike?
Postavite potrebna upozorenja i operativne vodiče !
Važno je implementirati oznake za raspodjelu troškova za praćenje potrošnje po odjelu, projektu ili okruženju. Izbjegnite rizik stvaranja močvare podataka u kojoj se troškovi ne mogu pratiti ili zahtijevaju dugo putovanje kroz različite sisteme evidencije. Trebalo bi biti brzo i jednostavno vratiti se na bilo koju cijenu aplikacije.
Gde god da radite, teško je uskladiti isporuku novih funkcija sa optimizacijom postojećih. Ko nije bio pod pritiskom da isporuči nove neobične karakteristike brzinom svjetlosti.
Međutim, neophodno je i za inženjere i za menadžere da donose promišljene i proaktivne odluke o svojim trenutnim projektima, efikasno upravljajući rizicima i prilikama.