Comments 23
Коллеги, спасибо за активность под статьей! Мы с командой на протяжении года наблюдаем растущий интерес к вопросу о сокращении костов на AWS, потребность в новых инструментах и методиках.
Мы разработали эффективный инструмент с понятной экономикой - InfinOps. Заходите на сайт https://infinops.com/, мы подробно расскажем о том, как именно наше решение поможет вам и вашим клиентам сэкономить более 80% на оплате счетов AWS.
Поясните, а в чем заключается необходимый профессионализм FinOps? Мне не совсем понятно, потому что Вы описали в статье собственно саму суть оптимизации — посмотреть что неиспользуется и выключить, а также снизить ресурсы где уже не такая нагрузка.
Вы можете подойти к этой проблеме самым традиционным способом. Игнорировать бесчисленные возможности, которые предоставляет AWS, и ограничить ваших разработчиков только покупкой виртуальных машин EC2.
SQS? Нет. DynamoDB? Нет. Просто используйте виртуальные машины EC2 и устанавливайте на них все, что нужно.
Если посыпать всё кубером, то проблем с маштабированием нет.
А альтернатива это сесть на штырь AWS и думать что это хребет айти-компании.
Ужос. Не знаю, сколько бы платили мы за этот AWS. Колокейшн нам стоит $95 за 1U и $120 за 2U серверы. Техподдержка, конечно, $80/час, минимум 15 минут, но всё налажено, поэтому за последние три года ни разу не была нужна.
Ах, да - стоимость серверов. $3000 в среднем, но в долгосрочной перспективе всё равно меньше AWS, причём гораздо.
"SQS? Нет. DynamoDB? Нет. Просто используйте виртуальные машины EC2 и устанавливайте на них все, что нужно"
Привет! Из этого пункта я делаю вывод что вы не совсем оптимальный для себя выбрали cloud. Думаю Azure или digitalocean вам бы больше подошло.
Спасибо за статью.
Все комментаторы, которые пишут что-то вроде "не используйте AWS", используйте Hetzner/Digitalocean и т.п. в том числе просто до конца не понимают насколько удобна его экосистема и насколько быстрее эти удобства позволяют выкатывать новый бизнес функционал в прод, который и приносит прибыль позволяющую в том числе оплачивать счета AWS. И да, это не для всех подходит.
Стартапам поначалу AWS может вообще ничего не стоить, т.к. AWS может выдать 100 тысяч долларов на старт.
К тому же AWS - серьёзное облако с большим количеством нюансов и возможностей для оптимизации расходов и заезжать в него и платить реальные деньги при этом не разбираясь и потому говорить, что дорого - это ... странный подход.
Стартапам поначалу AWS может вообще ничего не стоить, т.к. AWS может выдать 100 тысяч долларов на старт.
Так же как Azure и DO)
И это не отменяет остального сказанного мной выше.
Ставить DO в один ряд с Azure не серьёзно, а уж с AWS и подавно: DO беден по функционалу и экосистеме сервисов и менее надёжен и в этих условиях смысла использовать их программу для стартапов вместо AWS, в большинстве случаев, нет.
Например, events like S3 triggering Lambda or SQS и т.д., сама Lambda, API Gateway + XRay, KMS, Opensearch, multi region PG (Aurora) и другие сервисы крайне полезны стартапу в целом и разработке могут пригодиться в любой момент и это поднимаются в AWS в production ready конфигурации за минуты и по большей части не требует обслуживания (конечно кроме Aurora и то, если она под высокой нагрузкой и т.п.).
смузихрень. конечно
Что из перечисленного мной вы считаете "смузихренью" и можете ли вы обосновать ваше мнение? Вы видели, что используют что то и это на самом деле не нужно? Вопросы не к AWS, а к тому, у кого вы видели. AWS предоставляет возможности.
стартап стартапу рознь, все мечтают стать единорогом
о том, чтобы стать единорогом мечтает 100% стартапов, не обманывайте себя, если думаете по-другому. Это бизнес и все мечтают зарабатывать как можно больше.
остальные делают overkill
Для стартапов обычно крайне важно иметь возможность быстро изменить продукт в угоду спросу/потенциальным клиентам и в AWS это сделать легче всего, потому что есть готовые сервисы очень много для чего, на поднятие и обслуживание которых нужно тратить значительно меньше времени команды и соответственно денег на зп и найм. Да в AWS можно и накрутить лишнего, но если это нужно, то есть такая возможность. А ещё стартапам предоставляют консультации архитекторов AWS и много другого полезного, чтобы знать как делать правильно.
Я вам больше скажу: есть вполне себе не стартапы, а компании имеющие миллионы клиентов, которые прямо сейчас в проде под высокой нагрузкой используют перечисленные мной сервисы и не переезжают из AWS в том числе потому, что AWS дает им недоступную где либо ещё надежность и моментальную масштабируемость при резких наплывах трафика.
опять рекламный поток... Именно "надежность и моментальную масштабируемость при резких наплывах" это то, что подавляющему большинству стартапов не нужно.
Читайте внимательнее, в этом абзаце я писал не про стартапы.
Я, кстати, AWS не использовал, но...
Как говорится "не читал, но осуждаю"? Я не писал, что всем нужно только в AWS и что Hetzner плох. Но :) вот, например, понадобился вам брокер очередей и в Hetzner вы пойдете заниматься его установкой, настройкой и дальнейшей поддержкой и не забудьте про скейлинг инфраструктуры, если это должно работать под какой-то нагрузкой), тогда как в AWS вы очень быстро создаете, например, SQS, причем сразу по экземпляру на каждое окружение, пилите фичи, прогоняете по окружениям, катите в прод. Для тех.же стартапов скорость релизов бывает очень даже критична.
Статья про AWS, а не всех облачных провайдеров, и мои комментарии в целом тоже. Но всё же отмечу, что "ты тыкаешь start vm, а тебе в ответ - нет ресурсов" - это не похоже на "падение датацентра минимум на 2 дня".
Далее, даже при достаточно высокой надёжности AWS проблемы случаются везде и как и везде вам необходимо самостоятельно решать насколько много ресурсов вы готовы потратить на лишние девятки в доступности вашего приложения. Это относится как к созданию инфраструктуры в нескольких зонах доступности/регионах (отказал один дц/зона/регион, ваши пользователи это не ощутят), так и продумыванию использования конкретных технологий, вроде spot instances, у которых есть свои нюансы by design (именно поэтому они и дешевле). Например вы решили поднять всё на спотах в одной зоне доступности, но не учли, что споты могут и закончиться (в терминологии Google Cloud - Preemptible instances?). К слову в связке с AWS spot instances очень неплохо работает spot.io или Karpenter, у каждого из которых свои плюсы и минусы и которые позволяют реализовывать порой даже очень stateful нагрузки на спотах.
По итогу AWS даёт вам возможность реализовать желаемое, потратив на это минимум человекочасов и управляя всем этим правильно и очень гранулярно (например AWS IAM очень хорош, хоть и не прост для новичков) : git + terraform + CICD и т.д., а для большинства кейсов для Terraform ещё и community модули есть.
> понадобился вам брокер очередей
прогер его поднимет у себя на локалхосте одной доцкер-командой за 3 минуты
девопсь его поднимет в хетцнере одной командой ансибля. ну и вообще, у него в хетцнере кубер развернут )
Вы продолжаете игнорировать мои аргументы.
У любого сервиса есть цикл жизни. Вы почему то рассматриваете только "поднять", хотя нужно ещё обсуживать, масштабировать, патчить, разбираться с сетевыми проблемами и т.д. т.к. в Hetzner брокер очередей - это не managed сервис.
Для того, чтобы что-то поднять ансиблом одной командой у вас уже должен быть написан плейбук и в концов настроен ансибл, тогда как в случае с AWS разработчик может не имея вообще ничего (включая DevOps'а) с околонулевыми затратами времени накликопсить, после чего это можно импортировать в терраформ (например когда DevOps появится). Видел множество стартапом с такой не очень красивой ситуацией, но уже работающих в проде, т.е. приносящих необходимую им пользу, а иногда и реальные деньги от клиентов.
> это не похоже на "падение датацентра минимум на 2 дня"
мимо тазика, это были не preemptible узлы
у гугла и остальных аварии случаются достаточно часто, надо разбаниться в гугле уже.
Описанная вами ошибка не говорит о падении датацентра, и вы удобно проигнорировали всё, что я написал в том числе про зоны/регионы и девятки в доступности. Кратко перефразирую: вы можете реализовать вашу архитектуру так, что при падании одного из дц ваше приложение корректно отработает эту ситуацию и не повлияет на клиентов. В AWS часто это можно настроить из коробки. В Hetzner это гораздо сложнее.
За сим считаю бессмысленным продолжать дискуссию, потому что вы игнорируете мои аргументы.
Я согласен с вами, т.к. работаю на тот самый стартап, который нуждается в serverless и быстром, в течении 2-5 минут, scale out.
Специфика бизнеса такова, что у нас может не быть продуктовой нагрузки в течении недели. А потом нам нужно реально быстро обслужить наплыв клиентов.
Не все, конечно же, у нас serverless, много под управлением ECS. Это дороже, но реально удобнее в сравнении с EC2.
Как был у вас бардак, так и остался бардак....
Коллеги, спасибо за активность под статьей! Мы с командой на протяжении года наблюдаем растущий интерес к вопросу о сокращении костов на AWS, потребность в новых инструментах и методиках.
Мы разработали эффективный инструмент с понятной экономикой - InfinOps. Заходите на сайт https://infinops.com/, мы подробно расскажем о том, как именно наше решение поможет вам и вашим клиентам сэкономить более 80% на оплате счетов AWS.
Радикальная оптимизация расходов на AWS в пять шагов (мы сэкономили 80%)