Serverless часто подают как мир из сотен маленьких функций. Но на практике такой подход не всегда выгоден. Иногда serverless-монолит — одно приложение или крупный набор связанной логики в serverless-среде — оказывается проще, дешевле и надежнее.
Когда это оправдано👇
Проект на ранней стадии
Если продукт только запускается, важнее быстро проверять гипотезы, чем строить идеальную архитектуру. Один сервис проще разрабатывать, тестировать и выкатывать.Сильная связанность бизнес-логики
Когда модули постоянно обмениваются данными и почти не живут отдельно, дробление на функции создает лишние вызовы, сложные зависимости и рост задержек.Небольшая команда
2–5 разработчиков чаще эффективнее работают с одной кодовой базой, чем поддерживают десятки функций, IAM-ролей, CI/CD-пайплайнов и конфигураций.Нет высокой нагрузки по отдельным частям
Если системе не нужно независимо масштабировать конкретные сценарии, микродробление не дает явного выигрыша.Важна простота наблюдаемости
В монолите проще трассировать запрос, искать ошибки и анализировать логи. В наборе функций отладка часто превращается в расследование 🕵️
Почему не стоит сразу резать всё на функции:
Сложнее деплой — больше артефактов, больше точек отказа
Выше операционная сложность — права доступа, версии, интеграции
Больше latency — цепочки из нескольких вызовов добавляют задержки
Дороже сопровождение — особенно без зрелой DevOps-практики
Когда всё же лучше делить:
разные части системы имеют разную нагрузку
нужны независимые релизы команд
есть сценарии с разными требованиями по безопасности
важна изоляция отказов
логика уже стала слишком большой и тормозит развитие 🚀
Практичный подход:
не выбирать между “монолитом” и “100 функций” как религией. Часто лучший вариант — модульный serverless-монолит: одна система, но с четкими границами внутри кода. Это дает простоту старта и оставляет путь к дальнейшему выделению функций или сервисов.
Итог:
Serverless-монолит — не анти-паттерн, а нормальный этап зрелой архитектуры. Делить систему на функции стоит тогда, когда это решает конкретную проблему бизнеса или эксплуатации, а не потому что так “принято” в cloud-native мире 💡
Подборку каналов про IT стоит посмотреть тем, кто следит за архитектурой, cloud и практике разработки 📚