В этой статье мы хотим рассказать о пользе высокоэффективных бессерверных архитектур для организаций и независимых разработчиков.
Не нужно тратить усилия на управление серверами
Бессерверная архитектура освобождает разработчиков и организации от необходимости управления базовой инфраструктурой. Кроме того, AWS берет на себя управление серверами от имени клиента и позволяет им сосредоточиться на создании функций и возможностей приложения.
Таким образом, в бессерверных системах организации в принципе не должны управлять никакими серверами. А это значит, что они могут рационально распределять свои средства по следующим направлениям:
управление масштабируемостью кластеров;
реализация мер по снижению рисков;
реализация стратегий аварийного восстановления;
применение патчей для закрытия уязвимостей системы безопасности;
установка обновлений операционной системы;
наем персонала для управления серверами.
Снижение рисков и затрат в области безопасности
Доверив AWS управление базовой инфраструктурой, вы получите еще один приятный бонус — существенно сократите свои риски в области безопасности и связанные с ними расходы. В AWS работают лучшие инженеры в области безопасности и инфраструктурного обеспечения. Используя бессерверную архитектуру, вы фактически поручаете управление своей инфраструктурой профессионалам мирового класса. Благодаря этому вы снижаете затраты и риски на уровне собственных отделов информационной безопасности.
Сокращение расходов на вычислительные ресурсы
Поскольку в AWS Lambda ресурсы тарифицируются по фактическому времени исполнения, мы можем сэкономить значительную сумму денег, исключив затраты, обусловленные:
простоем серверов (вы не платите за время, когда серверы не обрабатывают никаких вызовов);
необходимостью проектирования высокодоступных систем (вы не платите за резервирование и аварийное восстановление серверов).
Предоставляемые AWS Lambda API-интерфейсы обладают катастрофоустойчивостью, поскольку способны автоматически переключать исполнение функций между разными зонами доступности в пределах одного и того же региона AWS.
Сокращение затрат и времени на разработку
API-интерфейсы на основе AWS Lambda позволяют нам прицельно сосредоточиться на создании приложения. Мы экономим бюджетные средства, которые обычно уходят:
на настройку и обслуживание серверов;
на тестирование масштабируемости и отказоустойчивости кластеров;
на проектирование и внедрение систем аварийного восстановления.
Поскольку теперь всё это делегировано сервисам AWS, мы можем говорить о сокращении релизного цикла промышленной разработки.
Анонимный кейс
Последние полтора года я работаю в команде, в которой 90% бессерверной инфраструктуры. У нас в общей сложности 71 стек Cloud Formation — это чистая бессерверная магия, включающая более 460 Lambda-функций. В июле 2020 года мы выполнили 91000 API-вызовов, что потребовало 91 час фактического времени исполнения на уровне AWS Lambda и стоило нам ноль сингапурских долларов с точки зрения поддержки нашей среды разработки.
Мы также отправили 6.6 млн сообщений, используя SQS, и заплатили за это скромную сумму в два сингапурских доллара за тот месяц. С другой стороны, традиционная архитектура потребовала бы минимум 19 тысяч сингапурских долларов при следующих допущениях:
одна виртуальная машина EC2 t2.xlarge обходится в 0.185 сингапурских доллара в час;
обычно для поддержки высокодоступной HA-архитектуры нам требуется две таких виртуальных машины, что будет стоить 0.370 сингапурских долларов в час;
рассчитать стоимость аренды ресурсов EC2 за весь месяц можно по такой формуле:
Цена одного API-кластера в месяц
0.370 х 730 часов в месяц = $270.10 в месяц
Умножим эту сумму на 71 (число API-стеков в нашей среде разработки)
270.10 x 71 = 19710 сингапурских долларов в месяц
Я не включил сюда затраты на зарплату администраторам, которых пришлось бы привлечь для управления парком виртуальных машин EC2 и непрерывного их мониторинга, а это весьма дорогой ресурс в Сингапуре. Надеюсь, что этот кейс помог вам убедиться в том, что бессерверные архитектуры действительно способны сократить затраты на разработку и промышленную эксплуатацию программных продуктов.
P. S. От переводчика
Лично я не жду, что процесс внедрения Serverless-архитектур будет быстрым. Массовых отказов от старой архитектуры в ближайшее также не предвидится. Чтобы работать с Serverless, нужно не просто выучить пару новых штук, а изменить своё мышление под новый тип разработки. О новых шагах Serverless-сервисов, подробностях и нюансах разработки можно узнать в сообществе Serverless в Telegram: Yandex Serverless Ecosystem.
mr_tron
6 миллионов сообщений за месяц это 2 сообщения в секунду. копеечная нагрузка для любого mq типа nats.
и, если я правильно понимаю, то 91 час суммарного времени выполнения значит что 1 виртуальное ядро процессора было загружено 91 час на 100%. тоесть в среднем за месяц одно ядро было бы загружено на 12%, что вполне укладывается в нормы запаса производительности чтобы обработать пиковое потребление (сферическое в вакууме. возможно там нагрузка вся приходится ровно на один час в сутки, но об этом в статье не сказано).
тоесть хватило бы пару виртуалок по одному ядру. общей стоимостью 10-20$ в месяц. и никакого вендорлока.
easyman
Лямбды по 100мс тарифицируются :)
Поэтому, для оптимизации расходов на вычисления, люди добавляют неиспользуемую функцией память, чтобы облако добавило CPU чтобы уменьшить тарифицируемое время