Комментарии 10
Из неочевидных подводных камней: проверьте максимальные таймауты который разрешает ваш ApiGateway. У нативного амазоновского жётский лимит в 29 секунд и порой то холодный старт подлагал, то внешнее апи медленнее ответило и упс, ваш клиент уже получил gateway timeout.
В том же AWS как вариант можно использовать Application Load Balancer, который не имеет таких лимитов как Api Gateway (как не имеет и его фичей), но при этом вы всё ещё ограничены упомянутым в статье таймаутом на время выполнения функции, что может быть стоппером для fully serverless архитектуры, если вы обращаетесь к какому-нибудь легаси у которого единственный вид взаимодействия - синхронные http вызовы по 30 минут.
Спасибо за совет! Заглянул в Яндексовский - 5 минут. Основной плюс использования, если не большие личные проекты - есть free tier - 100к запросов.
Я стараюсь делать функции так, что бы они отвечали меньше двух минут. Если больше, тогда можно сделать как у меня в одном из примеров - выносить в очередь. Тригер по очереди не имеет такого лимита.
Большой головняк с тем, что драйверы для взаимодествия с БД плохо оптимизированы под жизненный "ритм" функций в serverless. Например, монговский пакет для Node.js долго подключается и создаёт большой пул соединений. Это ок для классических архитектур, но в serverless надо наоборот быстро стартовать и не держать слишком большой пул, потому что параллельной обарботки запросов одним и тем же пулом соединений всё равно не будет. И вот из-за этого начинаются пляски с provisioned concurrency, тюнингом настроек, чтением исходников драйверов и т.п.
Ответ тянет на статью, очень многое зависит от самого приложения и языка. Если коротко: unit на моках, если часть компонентов можно аналогично поднять у себя (не специфичный для облака продукт, например PostgreSQL) - тогда можно поднимать гонять в docker в рамках CI. По интеграционным тестам - большинство облачных провайдеров поддерживают версионирование функций. Можно деплоить тестовую версию функции параллельно с основной и гонять тесты на ней, направляя трафик через отдельные endpoint. БД и остальные компоненты в этом случае можно создавать под тесты - благо есть terraform и API провайдера.
В целом проблема не гигантская, и многие подходы используют классические - основная задача, это повторить окружение. Поэтому провайдеры предоставляют возможности, для тестирования. Есть еще фреймворк для разработки и тестирования - serverless
Если статья наберет достаточно лайков и я пойму что это действительно будет интересно многим, то я напишу гайд по разработке, так как есть много мелких нюансов.
С материалами действительно проблема, даже на английском. По тестированию - везде две строчки с пирамидой без особых подробностей реализации. Я когда первый раз пытался сделать функцию в YC по их гайду - даже просто с выводом логов намучился.
Проектирование serverless функций