Kako zaraditi 1 milijun dolara s AWS-om u jednoj godini

Ako ste naletjeli na ovu stranicu misleći da ćete se obogatiti nekom shemom za brzo bogaćenje, žao mi je što vas moram razočarati. Ovaj će članak radije govoriti o tome kako smanjiti račune za troškove oblaka za milijun dolara. Čineći to, zapravo ćete generirati dodatnih milijun dolara prihoda — koje možete potrošiti kupujući moj online tečaj o tome kako se obogatiti s AWS-om ( link na tečaj ovdje ).

Trošak oblaka često se zanemaruje i ne uzima u obzir na početku projekata tvrtki. Anketa HashiCorpa iz 2021. pokazala je da je gotovo 40% tvrtki pretjerano potrošilo na troškove oblaka u 2021. [ 1 ]. Godine 2023. gotovo sve tvrtke (94%) priznale su da uzalud troše novac na oblak [ 1 ], a najmanje 30% troškova oblaka je uzalud potrošeno [ 2 ]. Potrošnja u oblaku iznosila je gotovo 500 milijardi dolara 2022. — dakle, govorimo o 150 milijardi dolara izgubljenih godišnje!!

Ne samo da je to problem propuštenih prihoda, već i loših praksi održivosti. 150 milijardi dolara izgubljene energije!

Ovi nalazi uključuju velika poduzeća, kao i manja, od zrelosti u visokom oblaku do zrelosti u niskom oblaku. Odnosi se na AWS, ali ista načela mogu se primijeniti na bilo kojeg drugog pružatelja usluga oblaka. Dakle, ako je bilo koji dio vašeg posla u oblaku, onda je ovaj članak za vas.

Govorim iz perspektive podatkovnog inženjera, ali ista učenja mogu se primijeniti na druge prakse softverskog inženjerstva.

Zaronimo.

Što je potrebno da se godišnje potroši milijun dolara na troškove oblaka?

Ova vrsta računa za oblak obično je ograničena na vrlo velika poduzeća koja posluju globalno s milijunima kupaca.

Da bismo vam dali predodžbu, račun za oblak od 1 milijun dolara može proizaći iz Spark ETL obrade ~1,5 Tb po satu 24x7 tijekom 365 dana u godini. Drugi primjer može biti aplikacija koja prima milijarde zahtjeva dnevno s više lokacija u svijetu.

U velikom poduzeću postoje stotine aplikacija ove veličine — što rezultira ugovorima s pružateljima usluga u oblaku vrijednim milijarde dolara. Na primjer, Airbnb se obvezao potrošiti 1,2 milijarde dolara na resurse u oblaku tijekom pet godina krajem 2019. [3 ].

U Expediji smo smanjili troškove ETL-a za obradu podataka koji košta 1,1 milijun dolara godišnje na samo 100.000 dolara godišnje implementacijom optimizacijskih praksi. To je smanjenje troškova od 91%!!

Nemaju sve tvrtke aplikacije tako velike veličine, ali zamislite smanjenje troškova u oblaku za 90% samo za jednu aplikaciju ili za cijelu tvrtku.

Kako da počnemo štedjeti?

1. KORAK: izazovite svoje pretpostavke o dizajnu

Idite i nabavite popis svojih najskupljih aplikacija i izazovite svoje pretpostavke o dizajnu .

• Izrađujete li aplikaciju koja ima dostupnost od 99,999% i latenciju ispod milisekunde, ali realno bi korisnici bili dovoljno dobri s dostupnošću od 99% i latencijom od stotine milisekundi?
• Stvarate li skupove podataka s milijardama redaka, ali korisnici bi koristili samo agregacije nekih mjera?
• Dohvaćate li podatke u stvarnom vremenu, ali podaci se analiziraju samo jednom dnevno?
• Osvježavate li predmemoriju svakih 10 sekundi, ali se stvarno mijenja samo kroz dane?

Sva ova pitanja vraćaju se na najvažnije pitanje: kako će se aplikacija koristiti? Koja je poslovna vrijednost za njegovo postojanje? Kako nam aplikacija pomaže u postizanju zadanog cilja?

Naravno, svi ovi odgovori su vrlo često nejasni na početku projekta; ali zato bi dizajn uvijek trebao biti ponavljajući proces — dopuštajući da se promjene dogode što je moguće neprimjetnije. Inženjeri bi trebali prihvatiti evoluciju i promjene, usklađujući razvoj aplikacija s učinkom.

KORAK 2: Fino prilagodite svoje infrastrukturne resurse svojim potrebama

Drugi korak sastoji se od pružanja pravih resursa aplikaciji i njezinog prilagođavanja pravoj infrastrukturi.

Kao inženjer, budite svjesni kako se izračunavaju troškovi oblaka. Na primjer, AWS pruža trenutne instance, gdje možete licitirati za cijenu klastera — ovo je osobito korisno ako imate fleksibilne aplikacije otporne na pogreške. Iskoristite ih ako možete — AWS tvrdi do 90% smanjenja troškova [ 4 ].

Neka druga razmatranja koja biste mogli razmotriti su:

• Uslužujete li klijente globalno ili samo u jednom zemljopisnom području? Trebate li doista svoju infrastrukturu za život diljem svijeta ili je možete postaviti bliže svojoj korisničkoj bazi?
• Dajete li previše instanci klastera? Pokušajte osigurati dovoljno kapaciteta za podnošenje vršnih opterećenja bez nepotrebnih troškova. Upotrijebite automatsko skaliranje za dinamičku prilagodbu resursa na temelju stvarne potražnje, sprječavajući preplaćivanje za neaktivne resurse.
• Ako radite s podacima i Sparkom, budite sigurni da razumijete Spark koncepte i podešavanje! Ako ne, pogledajte sljedeće resurse [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

KORAK 3: Koristite instance AWS Graviton

Korištenje instanci AWS Gravitona ima malo ili nimalo nedostataka. AWS je mnogo uložio u stvaranje najisplativijih procesora. Možete dobiti do 40% smanjenja potrošnje u oblaku samo prelaskom s procesora temeljenog na Intelu na procesor temeljen na ARM-u [ 10 ].

Jedino upozorenje za ovo je da vaša aplikacija mora biti kompatibilna s ARM-baziranim procesorima na kojima Graviton radi. Ako imate posla s upravljanom uslugom kao što je RDS ili OpenSearch, tada nema nikakvih komplikacija u prebacivanju — AWS se bavi temeljnim OS-om i kompatibilnošću aplikacija. Ako gradite vlastitu aplikaciju, možda ćete morati ponovno kompajlirati paket ovisno o tome koji jezik koristite — Java i drugi jezici ne zahtijevaju promjene, dok Python zahtijeva određenu pozornost.

4. KORAK: Pratite svoju potrošnju i educirajte se o troškovima

Na kraju, ne zaboravite pratiti svoje troškove zbog neočekivanih vrhunaca i iznenađenja. Trošak na dan 0 vaše aplikacije razlikovat će se od troška na dan 170. Vodite računa o promjenama i shvatite zašto se promjena događa: je li to gomilanje troškova s3 pohrane ili je samo jednokratna šiljak?

Postavite potrebna upozorenja i operativne vodiče !

Važno je implementirati oznake raspodjele troškova za praćenje potrošnje po odjelu, projektu ili okruženju. Izbjegnite rizik od stvaranja močvare podataka gdje se troškovi ne mogu pratiti ili zahtijevaju dugo putovanje kroz različite sustave evidencije. Povratak na bilo koji trošak aplikacije trebao bi biti brz i jednostavan.

Završne misli

Gdje god radili, teško je balansirati isporuku novih značajki s optimizacijom postojećih. Tko nije bio pod pritiskom da isporuči nove neobične značajke brzinom svjetlosti.

Međutim, bitno je i za inženjere i za menadžere da donose promišljene i proaktivne odluke o svojim trenutnim projektima, učinkovito upravljajući rizicima i prilikama.