Disclaimer: Эта статья основана в том числе на личном мнении Амирама Шачара (Amiram Shachar, CEO of Spotinst). Компания автора предлагает конкурирующий продукт под названием Spotinst Functions.

Перевод выполнен облачным провайдером Cloud4Y. Мы предлагаем программно-конфигурируемые дата-центры (vDC) на базе кластерных решений VMware vSphere с управлением посредством портала самообслуживания VMware vCloud Director.
По мнению многих специалистов, бессерверные вычисления являются следующим шагом в эволюции архитектуры вычислительных систем. Причины для совершения этого «прыжка» ясны:

  • Вы экономите время: больше не нужно планировать и думать о том, как объём ресурсов для работы приложения будет расти или уменьшаться. Вам не только не придётся заниматься внедрением после развертывания, но также вы сможете потратить больше времени на дальнейшие инновации, экономя его на работе с инфраструктурой.
  • Вы можете сэкономить деньги: в serverless-мире, где вы платите за триггер, вам не нужно писать on/off-скрипты, планировать резервирование или прогнозировать всплески. Вы просто платите за то, что используете.

Serverless — следующий шаг

Как переход от on-premises к облаку, переход к serverless в некоторой мере неизбежен. Однако, сделав этот ход, вы можете неожиданно получить счёт на большую, чем ожидаете сумму.

Затраты на бессерверные вычисления больше, чем pay-per-trigger


TimerCheck.io — это сервис, построенный полностью на AWS Lambda и API Gateway Эриком Хаммондом (Eric Hammond, SVP Technology at CampusExplorer).

При работе на AWS Lambda затраты на функцию TimerCheck были невероятно низкими — всего $ 0.22 за 2 миллиона запросов и 300000+ секунд вычислений. Звучит намного выгоднее ситуации с оплатой за весь сервер при использовании только его части, не так ли?

Так, но дело в том, что на Lambda функции приходилось чуть меньше 2% от его общей стоимости облака AWS.



После этого Эрик написал статью о ценах на AWS Lambda с призывом к Amazon снизить стоимость API-шлюза.
«Если вы читаете этот пост после ноября 2016 года, цены на эти услуги AWS, безусловно, изменились, и вы не должны использовать какие-либо из вышеуказанных расчётов при принятии решений о работе с AWS» — отметил Эрик.

Но, на самом деле, цены не изменились.

Каковы реальные затраты на бессерверные вычисления?


В действительности затраты на serverless больше, чем просто стоимость CPU and RAM, и для многих пользователей основными факторами затрат станут дополнительные категории расходов, такие как API Requests, Storage and Networking.


5 категорий затрат на serverless

Видимые затраты


  • Requests: эти расходы, как правило, составляют около 0,2 доллара за 1 млн. запросов на выполнение функции по всему рынку, у всех провайдеров.
  • CPU & RAM: $ 0,000067 за ГБ/секунда — тоже вполне стандартно

Скрытые затраты


  • API Requests: Поскольку многие бессерверные приложения очень тяжелы в вызовах API, это может стать довольно большой статьёй расходов — примерно 3,50 доллара за 1 млн. запросов.
  • Сеть: Если вы отправляете много данных, вам необходимо внимательно изучить эту категорию затрат. При уровне 0,05-0,09 доллара за GB-out и 0,1-0,2 доллара между Virtual Private Clouds/regions на AWS, затраты на трафик могут обойтись очень дорого. В общем, затраты на сеть, как правило, являются самыми трудно отслеживаемым издержками.


Заранее неизвестные затраты


Некоторые из затрат на serverless не всегда легко измерить в долларах и центах.

Cопровождение программного кода
Serverless coding = больше строк кода. Так Twin Tech Innovations отметили: «Для каждого нетривиального маршрута обработки запросов (части функциональных возможностей), добавленного в программу, количество строк кода конфигурации, необходимых для поддержки проекта, растет с заоблачной линейной скоростью при использовании бессерверной архитектуры».


Сравнение кода построчно

«Кто-то должен поддерживать всё это. Кто-то должен гарантировать, что не будет проблем, что изменения внесены в конфигурирование только одной функции и не будут случайно перенесены на другие. Кто-то должен убедиться, что код не дублируется, а сложность и зависимости управляемы».

«Холодная» загрузка
Не погружаясь в подробности, стоит отметить что, начальный запуск — основная причина, по которой некоторые компании решили отказаться от serverless при оценке Lambda.

«100 миллисекунд только для запуска… в то время, как пользовательскому приложению требуется латентность менее пятидесяти миллисекунд», — отметила Ханна Тауб (Hannah Taub).

Эти задержки начального запуска, скорее всего, исчезнут в конце концов, но пока вы должны их учесть.

Как анализировать стоимость serverless-архитектуры


Теперь проведём анализ затрат на основе базовых составляющих. О каждой из них достаточно подробностей для гораздо более глубоких расчётов, но ограничимся этим.

Рассмотрим основные различия в ценах
Функция AWS Lambda с 512 МБ памяти стоит $ 0.030024. Сравнимый по характеристикам сервер On-Demand обойдётся в сумму от $ 0.0059. Поэтому, если процессор полностью используется всё время, работа на serverless-архитектуре может оказаться менее эффективной для подобной рабочей нагрузки.

Правильно проектируйте API-запросы
API Gateway имеет тенденцию быть значительной частью ваших затрат, если вы подключаетесь к большому количеству API-интерфейсов. Чем больше API-запросов вы делаете за триггер, тем меньше экономии вы увидите от перехода на serverless.

Не забывайте про трафик
Переход может оказаться нецелесообразным, если data/networking создаёт основной объём затрат на приложение.

Исследуйте предложения всех serverless-провайдеров
На рынке существует несколько альтернативных предложений, каждое из которых обладает своими уникальными преимуществами в ценообразовании.


Сравнение затрат

Оцените стоимость дополнительного сопровождения программного кода
Подумайте, сколько времени вам или вашей команде придется потратить на переход на бессерверные вычисления.

Уровень бесплатного пользования
Почти каждый провайдер предлагает уровень бесплатного пользования, иногда его достаточно для запуска небольших рабочих нагрузок. Если вы хотите быть суперэкономным, вы можете использовать их все вместе. Если вы спроектируете ваши serverless-приложения должным образом, это может стать отличной возможностью получить независимость от провайдера. Помимо экономии средств, это также позволит запускать функции у облачных провайдеров, наиболее подходящих для этой конкретной рабочей нагрузки.


Сравнение уровеней бесплатного пользования

В конечном счете, переход к бессерверной архитектуре может дать большой потенциал с точки зрения экономии затрат и времени. Чтобы избежать каких-либо неожиданностей, стоит потратить время на анализ перед полным погружением в serverless.

Комментарии (2)


  1. hippoage
    26.02.2018 22:00

    Пока что функции весьма специфичны: есть условия когда они уже и полезны, но говорить о широком использовании пока что слишком рано:
    — писать/поддерживать сложновато ещё
    — стоимость ещё должна упасть

    В принципе, об этом и статья.

    Как альтернативы есть системы на базе докера (например, кибернетис умеет скейлить до 0 deploy) и Google Apps Engine (стартует достаточно быстро, автомасштабируется так же до 0). Там можно писать обычные приложения на многих языках.


  1. wert_lex
    28.02.2018 10:40

    А как такой серверлесс тестируется? При обычном подходе всегда можно развернуть локальное окружение, замокать зависимости, поставить брейкпойнт в сомнительном месте. А с lambda со товарищи это как все происходит?