Ако сте попаднали на тази страница, мислейки, че ще забогатеете с някаква схема за бързо забогатяване, съжалявам, че ще ви разочаровам. Тази статия по-скоро ще говори за това как да намалите сметките си за облачни разходи с 1 милион долара. Като направите това, вие по същество ще генерирате допълнителен милион долара приходи — които можете да похарчите, купувайки моя онлайн курс за това как да забогатеете с AWS ( връзка към курса тук ).
Облачните разходи често се пренебрегват и не се вземат предвид в началото на проектите на компаниите. Проучването на HashiCorp от 2021 г. установи, че почти 40% от компаниите са преразходвали за разходи за облак през 2021 г. [ 1 ]. През 2023 г. почти всички компании (94%) признават, че губят пари за облака [ 1 ] и поне 30% от разходите за облака са пропилени [ 2 ]. Разходите за облак бяха почти 500 милиарда долара през 2022 г. — следователно говорим за пропилени 150 милиарда долара годишно!!
Това е не само проблем за пропуснатите приходи, но и за лоши практики за устойчивост. 150 милиарда долара загуба на енергия!
Тези констатации включват големи предприятия, както и по-малки, от зрялост с висока облачна среда до зрялост с ниска облачна среда. Отнася се за AWS, но същите принципи могат да се приложат към всеки друг доставчик на облак. Така че, ако някоя част от вашата работа е в облака, тогава тази статия е за вас.
Говоря от гледна точка на инженера по данни, но същите знания могат да бъдат приложени към други практики за софтуерно инженерство.
Нека се потопим.
Този вид сметки за облак обикновено са ограничени до много големи предприятия, които работят в световен мащаб с милиони клиенти.
За да ви дадем представа, сметка за облак от $1 милион може да се получи от обработка на задание на Spark ETL ~1,5Tb на час 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 съхранение или е само еднократна шип?
Настройте необходимите предупреждения и оперативни ръководства !
Важно е да внедрите маркери за разпределение на разходите, за да проследявате разходите по отдел, проект или среда. Избягвайте риска от създаване на блато от данни, където цената е непроследима или изисква дълго пътуване през различни регистрационни системи. Трябва да е бързо и лесно да се върнете към дадена цена на приложението.
Където и да работите, балансирането на предоставянето на нови функции с оптимизирането на текущите е трудно. Кой не е бил принуден да предоставя нови странни функции със скоростта на светлината.
Въпреки това е важно както за инженерите, така и за мениджърите да вземат обмислени и проактивни решения относно текущите си проекти, като управляват ефективно рисковете и възможностите.