Комментарии 4
Ух, работал с таким лямбдалитом. В idle состоянии по сравнению с постоянно запущенным контейнером не стоит ничего, что позволяет например развертывать полноценные среды per developer без препинаний с финансовым отделом :)
Из минусов:
Лямбда реально быстро умирает когда отработает. Соответственно какой-нибудь настроенный OpenTelemerty (мы же отказались от специальных фреймворков), отправляющий телеметрию батчами будет либо терять 90% инфы, либо добавлять время, за которое он делает принудительный Flush, в общее время ответа.
Api gateway в AWS имеет жесткий лимит 29 секунд на реквест. Не для всех приложений такого таймаута может хватать (особенно если лямбдалит это тяжелая легаси фигня), а также если это малонагруженный сервис, aws залагал и стартует лямбду секунд 15, которые тоже считаются в лимит гейтвея. Но в принципе есть альтернатива: можно пускать http на лямбды через Application Load Balancer вместо Api gateway. Тогда вы ограничены только таймаутом лямбды (15 минут ЕМНИП). Но ALB стоит денег per-hour и возможно тогда уже проще и контейнер поднять? :)
Лямбда реально быстро умирает когда отработает
Ага, об этом говорил в абзаце про слабые стороны. Если пишем на js, то происходит php-изация Ноды)
aws залагал и стартует лямбду секунд 15
Вот с таким не сталкивались. Не помню, чтобы дольше 5с они разогревались. А вот с таймаутом api gateway - да, было дело. Но как правило, если в него упираешься - значит что-то делаешь не так) Ведь не очень, если пользователь будет сидеть 20+ секунд ждать отработки запроса, без возможности закрыть вкладку и отойти) Подобное надо на какой-то асинхронный пайплайн перекладывать
Спасибо за статью, было интересно хоть и читаю её не в первые. Изначально попалась именно в ТГ, Я ещё тогда подумал: А почему не на хабре?)

Serverless паттерн Lambdalith или «Монолитная лямбда»