Я относительно новичок в мире серверов, поэтому простите меня, если что-то из этого является базовым (и первым фрагментом текста будет я объясняю свою логику, чтобы убедиться, что это не ошибочно). Все мои вопросы будут выделены жирным шрифтом, чтобы вам было легче помочь :).
Я исследовал и обучал себя некоторым технологиям AWS, и я заметил в их Mobile Hub, что если вам нужна облачная логика, они позволяют только «автоматическую» настройку функций Lambda. После прочтения и исследования я нашел несколько ресурсов, которые указывают на «бессерверную» архитектуру (которую поддерживает введение Lambda). Насколько я понимаю, в прошлом Elastic Beanstalk был представлен, чтобы значительно упростить управление сервером (особенно для мобильных устройств).
Для мобильных разработчиков есть 2 варианта (очевидно, больше, но для простоты соглашаемся):
Все это наводит меня на мысль, что полноценный бэкэнд Lambda будет вполне возможным и простым в создании за небольшую часть стоимости сервера, работающего 24/7. Это правильно?
Теперь, предполагая, что вышеизложенное верно, нам нужно определить, действительно ли использование Lambda выгодно по сравнению с Elastic Beanstalk.
Для простых серверов мы могли бы настроить несколько функций Lambda и прекратить работу (и, вероятно, это намного проще и дешевле (по крайней мере, для небольших проектов), чем использование Elastic Beanstalk).
Однако для более сложных серверов с большим количеством URL-адресов и подключений к базе данных все становится интереснее.
Вот проблемы, которые я вижу при использовании Lambda в приведенной выше ситуации.
Единственный способ (я мог придумать) избежать первых двух проблем - это создать одну надежную функцию, которая действует как отправка (основная функция принимает параметр из шлюза API и определяет, какой файл запускать в функции Lambda).
Есть ли какие-то важные моменты, которые мне не хватает, чтобы определить, стоит ли использовать Lambda поверх Elastic Beanstalk?
Чтобы держать всех в курсе, я не получал ответов, поэтому спросил на StackOverflow и получил следующий ответ из mbaird. В комментариях есть небольшая дискуссия, так что не стесняйтесь проверить это и отдать ему должное.
Похоже, вы уже это поняли. Вы правы, что использование Lambda вместо сервера, работающего 24/7, может дать значительную экономию средств. Эта статья утверждает:
И это позволяет некоторым клиентам Amazon сэкономить большие деньги, поскольку по крайней мере один довольный клиент Lambda экономит 80% на своих счетах за облако. Возможно, вы захотите взглянуть на Serverless Framework, который управляет некоторыми болевыми точками.
Я думаю, что со временем многие из болевых точек исчезнут, поскольку Amazon добавляет в Lambda больше функций и для нее создается больше сторонних инструментов. Я постоянно открываю для себя новые способы использования Lambda, но я также постоянно нахожу варианты, которые сначала кажутся подходящими, но на самом деле не работают с Lambda, по крайней мере, пока. Например, мне действительно нужен способ ограничить количество экземпляров функции Lambda, которые могут выполняться одновременно, чтобы предотвратить максимальное использование доступных подключений к базе данных или ограничение использования сторонних API. Мне также действительно нужны функции Lambda для работы в моем VPC, но это должно появиться очень скоро.