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