Comments 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, тюнингом настроек, чтением исходников драйверов и т.п.
полагаю тут для баз, вроде PG, балансеры/баунсеры становятся must have.
для постгри это pgbouncer.
и режим работы ни в коем случае не tcp session, а только потранзакционный переключатель. как-то так
Да, это нужно иметь ввиду и очень сильно зависит от языка/библиотеки. Как выше написали, можно использовать внешние пулы соединений. Еще хороший вариант - ориентироваться на serverless БД которые предоставляет провайдер, с которым вы работаете.
меня всегда больше всего волновал вопрос: "а как тестировать в CI вот это вот всё?"
и кроме варианта в CI создать свой namespace функций, баз данных, очередей итп и после на этом всём запустить набор тестов - кроме такого варианта в голову не приходит ничего.
а как Вы такое тестируете?
Ответ тянет на статью, очень многое зависит от самого приложения и языка. Если коротко: unit на моках, если часть компонентов можно аналогично поднять у себя (не специфичный для облака продукт, например PostgreSQL) - тогда можно поднимать гонять в docker в рамках CI. По интеграционным тестам - большинство облачных провайдеров поддерживают версионирование функций. Можно деплоить тестовую версию функции параллельно с основной и гонять тесты на ней, направляя трафик через отдельные endpoint. БД и остальные компоненты в этом случае можно создавать под тесты - благо есть terraform и API провайдера.
Ответ тянет на статью
меня вопрос serverless занимает давно, но именно из-за того, что никто не написал такую статью я делаю заключение, что ситуация здесь: "каждый ваяет что-то на коленке", а значит "и мне тоже придётся".
Поэтому я так и не удосужился попробовать.
В целом проблема не гигантская, и многие подходы используют классические - основная задача, это повторить окружение. Поэтому провайдеры предоставляют возможности, для тестирования. Есть еще фреймворк для разработки и тестирования - serverless
Если статья наберет достаточно лайков и я пойму что это действительно будет интересно многим, то я напишу гайд по разработке, так как есть много мелких нюансов.
С материалами действительно проблема, даже на английском. По тестированию - везде две строчки с пирамидой без особых подробностей реализации. Я когда первый раз пытался сделать функцию в YC по их гайду - даже просто с выводом логов намучился.
Проектирование serverless функций