Comments 7
Спасибо за статью
Есть пара вопросов:
1 Подходят ли лямбды реализации редко запускаемых шедулеров?
2 Как вы считаете насколько оправдано разворачивать свою инфраструктуру для лямбд? Или разумнее использовать провайдера?
Спасибо
Есть пара вопросов:
1 Подходят ли лямбды реализации редко запускаемых шедулеров?
2 Как вы считаете насколько оправдано разворачивать свою инфраструктуру для лямбд? Или разумнее использовать провайдера?
Спасибо
Насчет шедулеров, это прямо одно из основных направлений я бы сказал. CloudWatch может работать по принципу cron job и триггерить запуск лямбды. Также для лямбды доступно огромное количество триггеров, который могут даже существовать параллельно.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
Александр, спасибо большое за две статьи.
Я недавно работаю с AWS и для меня это было очень полезно!
Хотел уточнить такой момент.
В Вашем примере, мы отлавливаем все исключительнные ситуации и всегда возращаем соотвествующий респонс из лямбды (400 либо 500).
Но если нам будет необхомидо протестить, например, такой кейс — при определенных ошибках лямбда должна сделать рестрат запроса, т.е. попыться обработаь тот же запрос повторно.
Например, лямбда ходит в некоторый внешний сервис и он, например, временно не доступен или выкинул какую-то ошибку и нам необходимо повторить запрос чуть позже еще раз.
Правильно ли я понимаю, что:
Во-первых, в этом случае нам необходимо, чтобы лябмбда брасала определенный exception и не обробытывала его, тогда будет ее рестарт (что определяется настройками retry attempts);
Во-вторых, в тесте соответственно, проверить, что такой exception босается.
Спасибо,
Виталий
Я недавно работаю с AWS и для меня это было очень полезно!
Хотел уточнить такой момент.
В Вашем примере, мы отлавливаем все исключительнные ситуации и всегда возращаем соотвествующий респонс из лямбды (400 либо 500).
Но если нам будет необхомидо протестить, например, такой кейс — при определенных ошибках лямбда должна сделать рестрат запроса, т.е. попыться обработаь тот же запрос повторно.
Например, лямбда ходит в некоторый внешний сервис и он, например, временно не доступен или выкинул какую-то ошибку и нам необходимо повторить запрос чуть позже еще раз.
Правильно ли я понимаю, что:
Во-первых, в этом случае нам необходимо, чтобы лябмбда брасала определенный exception и не обробытывала его, тогда будет ее рестарт (что определяется настройками retry attempts);
Во-вторых, в тесте соответственно, проверить, что такой exception босается.
Спасибо,
Виталий
Спасибо! Шикарная статья.
Отличная статья, спасибо!
Инфраструктуру намного удобнее писать на CDK, чем на CFN или SAM. Да, там пока нет инструментов для локального тестирования, но сама разработка шаблонов инфраструктуры настолько проще и приятнее (особенно если использовать TS в VSCode), что попробовав однажды обратно дороги уже нет. Некоторый недостаток инструментов деплоя (например, он не умеет собирать пакеты Python по requirements.txt как SAM) легко обходится простейшим Makefile.
Инфраструктуру намного удобнее писать на CDK, чем на CFN или SAM. Да, там пока нет инструментов для локального тестирования, но сама разработка шаблонов инфраструктуры настолько проще и приятнее (особенно если использовать TS в VSCode), что попробовав однажды обратно дороги уже нет. Некоторый недостаток инструментов деплоя (например, он не умеет собирать пакеты Python по requirements.txt как SAM) легко обходится простейшим Makefile.
Sign up to leave a comment.
AWS Lambda in Action. Часть 2: знакомимся с инструментами разработки и тестирования