Обновить

Комментарии 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+ секунд ждать отработки запроса, без возможности закрыть вкладку и отойти) Подобное надо на какой-то асинхронный пайплайн перекладывать

Спасибо за статью, было интересно хоть и читаю её не в первые. Изначально попалась именно в ТГ, Я ещё тогда подумал: А почему не на хабре?)

Начал писать как пост в тг-канал и в процессе обнаружил, что получилась статья на Хабр) Вот только сейчас дошли руки опубликовать здесь)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации