Comments 7
Спасибо за статью
Есть пара вопросов:
1 Подходят ли лямбды реализации редко запускаемых шедулеров?
2 Как вы считаете насколько оправдано разворачивать свою инфраструктуру для лямбд? Или разумнее использовать провайдера?
Спасибо
Насчет шедулеров, это прямо одно из основных направлений я бы сказал. CloudWatch может работать по принципу cron job и триггерить запуск лямбды. Также для лямбды доступно огромное количество триггеров, который могут даже существовать параллельно.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
Александр, спасибо большое за две статьи.
Я недавно работаю с AWS и для меня это было очень полезно!
Хотел уточнить такой момент.
В Вашем примере, мы отлавливаем все исключительнные ситуации и всегда возращаем соотвествующий респонс из лямбды (400 либо 500).
Но если нам будет необхомидо протестить, например, такой кейс — при определенных ошибках лямбда должна сделать рестрат запроса, т.е. попыться обработаь тот же запрос повторно.
Например, лямбда ходит в некоторый внешний сервис и он, например, временно не доступен или выкинул какую-то ошибку и нам необходимо повторить запрос чуть позже еще раз.
Правильно ли я понимаю, что:
Во-первых, в этом случае нам необходимо, чтобы лябмбда брасала определенный exception и не обробытывала его, тогда будет ее рестарт (что определяется настройками retry attempts);
Во-вторых, в тесте соответственно, проверить, что такой exception босается.

Спасибо,
Виталий
Почти все верно, но по большей степени для асинхронных вызовов. Для них настраивается Retry pollicy (по дефолту 2 раза). Для синхронных запросов, как в моем случае, retry — это обязанность API Gateway либо консьюмера Api Gateway. Можно сделать на стороне JS к примеру.
Надеюсь, что действительно это как-то поможет распространить применение serverless ))
Отличная статья, спасибо!
Инфраструктуру намного удобнее писать на CDK, чем на CFN или SAM. Да, там пока нет инструментов для локального тестирования, но сама разработка шаблонов инфраструктуры настолько проще и приятнее (особенно если использовать TS в VSCode), что попробовав однажды обратно дороги уже нет. Некоторый недостаток инструментов деплоя (например, он не умеет собирать пакеты Python по requirements.txt как SAM) легко обходится простейшим Makefile.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 January 1998

Location

Россия

Website

dins.ru

Employees

501–1,000 employees

Registered

3 September 2018