Ако налетавте на оваа страница мислејќи дека ќе се збогатите со некоја шема за брзо збогатување, извинете што ве разочарувам. Оваа статија попрво ќе зборува за тоа како да ги намалите сметките за трошоците за облак за 1 милион долари. Со тоа, во суштина ќе генерирате дополнителен милион долари приход - што можете да го потрошите купувајќи го мојот онлајн курс за тоа како да се збогатите со AWS ( врска до курсот овде ).
Трошоците за облак често се занемаруваат и не се земаат предвид на почетокот на проектите на компаниите. Истражувањето на HashiCorp од 2021 година покажа дека речиси 40% од компаниите прекумерно трошеле трошоци за облак во 2021 година [ 1 ]. Во 2023 година, речиси сите компании (94%) признаа дека трошат пари на облакот [ 1 ] и најмалку 30% од трошоците за облак беа потрошени [ 2 ]. Трошењето во облак беше скоро 500 милијарди долари во 2022 година - затоа зборуваме за залудно потрошени 150 милијарди долари годишно!!
Не само ова е загриженост за пропуштените приходи, туку и лошите практики за одржливост. Потрошена енергија од 150 милијарди долари!
Овие наоди вклучуваат големи претпријатија, како и помали, од зрелост со висок облак до зрелост со низок облак. Се однесува на AWS, но истите принципи може да се применат на кој било друг облак провајдер. Значи, ако некој дел од вашата работа е во облакот, тогаш оваа статија е за вас.
Зборувам од перспектива на инженерот за податоци, но истите учења може да се применат и на други практики за софтверско инженерство.
Ајде да се нурнеме.
Овој вид на сметка за облак обично е ограничен на многу големи претпријатија кои работат на глобално ниво со милиони клиенти.
За да ви дадеме идеја, сметката од облак од 1 милион долари може да произлезе од обработката на работното место Spark ETL ~ 1,5 Tb на час 24x7 во 365 дена во годината. Друг пример може да биде апликација која прима милијарди барања дневно од повеќе локации во светот.
Во големо претпријатие, постојат стотици апликации со оваа големина - што резултира со договори од милијарди долари со облак-добавувачи. На пример, Airbnb имаше обврска да потроши 1,2 милијарди долари на ресурси на облак во текот на пет години на крајот на 2019 година [3 ].
Во Expedia ги намаливме трошоците за ETL за обработка на податоци што чини 1,1 милиони долари годишно на само 100.000 долари годишно со спроведување на практики за оптимизација. Тоа е намалување на трошоците за 91%!!
Не сите компании имаат апликации со толку огромна големина, но замислете да ги намалите трошоците за облак за 90% само за една апликација или за целата компанија.
Одете и добијте листа на вашите најскапи апликации и оспорете ги вашите претпоставки за дизајн .
Сите овие прашања се враќаат на најважното прашање: како ќе се користи апликацијата? Која е деловната вредност за да постои? Како апликацијата ни помага да постигнеме дадена цел?
Се разбира, сите овие одговори се многу често нејасни на почетокот на проектот; но затоа дизајнот секогаш треба да биде итеративен процес - дозволувајќи им на промените да се случат што е можно полесно. Инженерите треба да ја прифатат еволуцијата и промените, усогласувајќи го развојот на апликациите со влијанието.
Вториот чекор се состои од обезбедување на апликацијата со вистинските ресурси и нејзино прилагодување на вистинската инфраструктура.
Како инженер, бидете свесни за тоа како се пресметуваат трошоците за облак. На пример, AWS обезбедува точки, каде што можете да наддавате за цената на кластерот - ова е особено корисно ако имате толерантни и флексибилни апликации. Користете ги ако можете - AWS тврди до 90% намалување на трошоците [ 4 ].
Некои други размислувања што можеби сакате да ги разгледате се:
Има малку или никакви недостатоци во користењето на примерите на AWS Graviton. AWS инвестираше многу во создавање на најекономични процесори. Може да добиете до 40% намалување на трошењето на облакот само со префрлување од процесор базиран на Intel на процесор базиран на ARM [ 10 ].
Единственото предупредување за ова е дека вашата апликација треба да биде компатибилна со процесорите базирани на ARM на кои работи Graviton. Ако се занимавате со управувана услуга како што се RDS или OpenSearch, тогаш нема никаква компликација во префрлувањето - AWS се занимава со основниот оперативен систем и компатибилноста на апликациите. Ако градите сопствена апликација, тогаш можеби ќе треба повторно да го компајлирате пакетот во зависност од тоа кој јазик го користите - Java и другите јазици не бараат промена, додека Python бара одредено внимание.
И на крај, не заборавајте да продолжите да ги следите вашите трошоци за неочекувани врвови и изненадувања. Трошоците на денот 0 од вашата апликација ќе се разликуваат од трошоците на 170-тиот ден. Погрижете се да ги следите промените и разбирате зошто се случува промената: дали ги собира трошоците за складирање s3 или е само еднократна шип?
Поставете ги потребните предупредувања и оперативни прирачници !
Поважно, имплементирајте ознаки за распределба на трошоците за следење на трошењето по оддел, проект или околина. Избегнете го ризикот од создавање мочуриште на податоци каде што цената не може да се следи или бара долго патување низ различни системи на дневници. Треба да биде брзо и едноставно да се вратите на која било дадена цена на апликацијата.
Каде и да работите, тешко е да се балансира испораката на нови функции со оптимизација на тековните. Кој не бил под притисок да испорача нови чудни карактеристики со брзина на светлината.
Сепак, од суштинско значење е и инженерите и менаџерите да донесат намерни и проактивни одлуки за нивните тековни проекти, ефикасно да управуваат со ризиците и можностите.