Kā nopelnīt USD 1 miljonu, izmantojot AWS vienā gadā

Ja jūs uzdūrāt šai lapai, domājot, ka kļūsit bagāts, izmantojot kādu ātri bagātības shēmu, man žēl, ka sagādāju jums vilšanos. Šajā rakstā drīzāk tiks runāts par to, kā samazināt mākoņa izmaksu rēķinus par 1 miljonu ASV dolāru. To darot, jūs būtībā būsit guvis papildu miljonus dolāru ieņēmumus, kurus varēsit iztērēt, pērkot manu tiešsaistes kursu par to, kā kļūt bagātam ar AWS ( saite uz kursu šeit ).

Mākoņu izmaksas uzņēmumu projektu sākumā bieži tiek ignorētas un netiek ņemtas vērā. 2021. gada HashiCorp aptaujā atklājās, ka gandrīz 40% uzņēmumu 2021. gadā pārtērēja mākoņdatošanas izmaksas [ 1 ]. 2023. gadā gandrīz visi uzņēmumi (94%) atzina, ka tērē naudu mākonī [ 1 ] un vismaz 30% mākoņa izmaksu tika izšķiesti [ 2 ]. Mākoņa izdevumi 2022. gadā bija gandrīz 500 miljardi dolāru — tāpēc mēs runājam par 150 miljardiem dolāru, kas tiek izšķiesti gadā!

Tas rada bažas ne tikai par neiegūtiem ieņēmumiem, bet arī par sliktu ilgtspējības praksi. 150 miljardu dolāru izšķērdēta enerģija!

Šie atklājumi attiecas gan uz lieliem, gan mazākiem uzņēmumiem, sākot no augsta mākoņa brieduma līdz zemam mākoņainības briedumam. Tas attiecas uz AWS, taču tos pašus principus var piemērot jebkuram citam mākoņa pakalpojumu sniedzējam. Tātad, ja kāda jūsu darba daļa ir mākonī, tad šis raksts ir paredzēts jums.

Es runāju no datu inženiera perspektīvas, taču tās pašas mācības var izmantot arī citās programmatūras inženierijas praksēs.

Nirsim iekšā.

Kas nepieciešams, lai gadā iztērētu 1 miljonu ASV dolāru mākoņa izmaksās?

Šāda veida mākoņa rēķini parasti attiecas tikai uz ļoti lieliem uzņēmumiem, kas darbojas visā pasaulē ar miljoniem klientu.

Lai sniegtu jums priekšstatu, 1 miljona dolāru mākoņa rēķins var rasties, ja Spark ETL darbs tiek apstrādāts ~1,5 Tb stundā 24x7 365 dienas gadā. Cits piemērs varētu būt lietojumprogramma, kas saņem miljardiem pieprasījumu dienā no vairākām vietām pasaulē.

Lielā uzņēmumā ir simtiem šāda izmēra lietojumprogrammu, kā rezultātā tiek noslēgti līgumi ar mākoņpakalpojumu sniedzējiem miljardu dolāru vērtībā. Piemēram, Airbnb bija apņemšanās 2019. gada beigās piecu gadu laikā mākoņresursiem iztērēt USD 1,2 miljardus [3 ].

Expedia mēs samazinājām izmaksas par datu apstrādes ETL, kas maksā 1,1 miljonu dolāru gadā, līdz tikai 100 000 USD gadā, ieviešot optimizācijas praksi. Tas ir par 91% izmaksu samazinājums!!

Ne visiem uzņēmumiem ir tik liela izmēra lietojumprogrammas, taču iedomājieties, ka mākoņdatošanas izmaksas samazināsies par 90% tikai vienai lietojumprogrammai vai visam uzņēmumam.

Kā mēs sākam ietaupīt?

1. SOLIS. Izaiciniet savus dizaina pieņēmumus

Dodieties un saņemiet savu dārgāko lietojumprogrammu sarakstu un izaiciniet savus dizaina pieņēmumus .

• Vai veidojat lietojumprogrammu, kuras pieejamība ir 99,999% un latentums ir mazāks par milisekundēm, taču reāli lietotāji būtu pietiekami labi ar 99% pieejamību un simtiem milisekunžu latentumu?
• Vai veidojat datu kopas ar miljardiem rindu, bet lietotāji izmantotu tikai dažu pasākumu apkopojumus?
• Vai jūs saņemat datus reāllaikā, bet dati tiek analizēti tikai vienu reizi dienā?
• Vai kešatmiņa tiek atsvaidzināta ik pēc 10 sekundēm, taču tā faktiski mainās tikai dienu laikā?

Visi šie jautājumi atgriežas pie vissvarīgākā jautājuma: kā lietojumprogramma tiks izmantota? Kāda ir biznesa vērtība, lai tā pastāvētu? Kā lietojumprogramma palīdz mums sasniegt noteiktu mērķi?

Protams, visas šīs atbildes ļoti bieži projekta sākumā ir neskaidras; taču tāpēc dizainam vienmēr jābūt iteratīvam procesam, ļaujot izmaiņām notikt pēc iespējas vienkāršāk. Inženieriem ir jāpieņem evolūcija un pārmaiņas, saskaņojot lietojumprogrammu izstrādi ar ietekmi.

2. SOLIS. Pielāgojiet infrastruktūras resursus savām vajadzībām

Otrais solis ir nodrošināt lietojumprogrammu ar pareizajiem resursiem un pielāgot to pareizajai infrastruktūrai.

Kā inženieris ņemiet vērā, kā tiek aprēķinātas mākoņdatošanas izmaksas. Piemēram, AWS nodrošina tūlītējus gadījumus, kuros varat solīt klastera cenu — tas ir īpaši noderīgi, ja jums ir pret defektiem izturīgas un elastīgas lietojumprogrammas. Izmantojiet tos, ja varat — AWS apgalvo, ka izmaksas samazināsies līdz pat 90% [ 4 ].

Daži citi apsvērumi, kurus, iespējams, vēlēsities risināt, ir:

• Vai apkalpojat klientus visā pasaulē vai tikai vienā ģeogrāfiskajā apgabalā? Vai jums patiešām ir nepieciešama infrastruktūra, lai dzīvotu visā pasaulē, vai arī varat to iestatīt tuvāk savai klientu bāzei?
• Vai pārlieku nodrošina klasteru gadījumus? Centieties nodrošināt pietiekamu jaudu, lai bez liekām izmaksām varētu izturēt maksimālās slodzes. Izmantojiet automātisko mērogošanu, lai dinamiski pielāgotu resursus, pamatojoties uz faktisko pieprasījumu, novēršot pārmaksu par dīkstāvē esošiem resursiem.
• Ja strādājat ar datiem un Spark, noteikti izprotiet Spark koncepcijas un regulēšanu! Ja nē, apskatiet tālāk norādītos resursus [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

3. SOLIS. Izmantojiet AWS Graviton gadījumus

AWS Graviton gadījumu izmantošanā ir maz vai nav nekādu trūkumu. AWS ir ieguldījis lielus ieguldījumus izmaksu ziņā efektīvāko procesoru izveidē. Jūs varat iegūt līdz pat 40% samazinājumu mākoņdatošanas tēriņiem, vienkārši pārslēdzoties no Intel bāzes procesora uz ARM balstītu procesoru [ 10 ].

Vienīgais brīdinājums ir tāds, ka jūsu lietojumprogrammai ir jābūt saderīgai ar ARM procesoriem, kuros darbojas Graviton. Ja jums ir darīšana ar pārvaldītu pakalpojumu, piemēram, RDS vai OpenSearch, pārslēgšanās neradīs nekādu sarežģījumu — AWS nodarbojas ar pamatā esošo OS un lietojumprogrammu saderību. Ja veidojat savu lietojumprogrammu, iespējams, būs jāpārkompilē pakotne atkarībā no izmantotās valodas — Java un citām valodām nav nepieciešamas izmaiņas, savukārt Python ir jāpievērš uzmanība.

4. SOLIS. Pārraugiet savus izmaksu tēriņus un izglītojiet par izmaksu izpratni

Visbeidzot, neaizmirstiet pastāvīgi uzraudzīt izmaksas, lai izvairītos no neparedzētiem maksimumiem un pārsteigumiem. Izmaksas jūsu pieteikuma 0. dienā atšķirsies no izmaksām 170. dienā. Noteikti sekojiet līdzi izmaiņām un saprotiet, kāpēc izmaiņas notiek: vai tā ir s3 krātuves izmaksu uzkrāšana, vai arī tās ir tikai vienreizējas izmaksas. smaile?

Iestatiet nepieciešamos brīdinājumus un darbības rokasgrāmatas !

Svarīgi ir ieviest izmaksu sadales tagus, lai izsekotu tēriņiem pēc nodaļas, projekta vai vides. Izvairieties no riska izveidot datu purvu, kur izmaksas nav izsekojamas vai ja nepieciešams ilgs ceļojums dažādās žurnālu sistēmās. Jābūt ātri un vienkārši, lai atgrieztos pie jebkuras norādītās pieteikuma izmaksas.

Pēdējās domas

Lai kur jūs strādātu, ir grūti līdzsvarot jauno funkciju piegādi ar pašreizējo funkciju optimizāciju. Kurš gan nav bijis spiests nodrošināt jaunas savdabīgas funkcijas gaismas ātrumā.

Tomēr gan inženieriem, gan vadītājiem ir svarīgi pieņemt apzinātus un proaktīvus lēmumus par saviem pašreizējiem projektiem, efektīvi pārvaldot riskus un iespējas.