Monolith vs Microservices vs Serverless: реальная стоимость для стартапа
Что такое выбор архитектуры на основе TCO для стартапа?
Выбор архитектуры на основе TCO — это практика принятия решения между монолитом, микросервисами и serverless путём расчёта полной стоимости владения, включая инфраструктуру, операционные расходы, время разработки фич, когнитивную нагрузку и стоимость миграции — а не сравнения абстрактных плюсов и минусов. Это важно потому, что стартапы, переходящие на микросервисы до product-market fit, стабильно тратят на инфраструктуру в 3–4 раза больше аналогичных команд на монолите, а разница в $18 900/год между архитектурами означает 2–3 дополнительных месяца runway.
TL;DR
- -Монолит при 5K DAU стоит ~$275/месяц суммарного TCO; микросервисы — ~$1 850/месяц при идентичной функциональности, разница составляет $18 900/год на стадии pre-PMF.
- -Инфраструктура — лишь 20–35% реальной стоимости архитектуры; DevOps-overhead, время разработки и когнитивная нагрузка составляют остальное, и микросервисы дороже по этим параметрам в 3–5 раз.
- -Порог перехода от монолита к микросервисам имеет четыре измеримых сигнала: деплой >15 минут, один модуль потребляет >60% ресурсов, команда >8–10 человек или разные SLA для разных компонентов.
- -Serverless оптимален для spiky event-driven нагрузок (webhooks, ETL, уведомления), но не подходит для stateful долгоживущих соединений — неправильное применение добавляет 20+ часов разработки воркэраундов на каждую фичу.
- -AI-расчёт TCO в трёх сценариях роста (2x, 5x, 20x DAU) занимает 30 минут и показывает конкретный месяц, когда текущая архитектура достигнет своих пределов.
Стартапы, перешедшие на микросервисы до product-market fit, стабильно тратят на инфраструктуру в 3–4 раза больше, чем аналогичные команды на монолите. Архитектурный выбор на ранней стадии определяет runway не меньше, чем размер раунда.
Проблема стандартных сравнений: они оперируют абстрактными плюсами и минусами. «Микросервисы масштабируются лучше» ничего не говорит о конкретных затратах при 1000 DAU и команде из четырёх человек. Нужна количественная модель.
Статья содержит TCO-модель для каждой из трёх архитектур, готовые промпты для AI-расчёта под конкретные параметры проекта и decision framework, который превращает архитектурный выбор из интуитивного в data-driven.
TCO-модель: что входит в реальную стоимость архитектуры
Total Cost of Ownership архитектуры выходит далеко за пределы счёта от облачного провайдера. TCO складывается из пяти категорий.
Инфраструктура. Серверы, контейнеры, функции, базы данных, CDN, DNS, SSL-сертификаты. Это единственная категория, которую считают все. Она составляет 20–35% реальных затрат.
DevOps и операционные расходы. CI/CD пайплайны, мониторинг, логирование, алертинг, управление секретами, backup-стратегия. Для микросервисов эта категория в 3–5 раз выше, чем для монолита.
Время разработки. Сколько часов уходит на feature delivery с учётом архитектурного оверхеда: сетевые вызовы между сервисами, контракты API, distributed debugging. Час разработчика в стартапе стоит $50–150 в зависимости от региона и уровня.
Когнитивная нагрузка. Количество контекстов, которые разработчик держит в голове. Монолит: один deployment, одна БД, один лог. Микросервисы: N deployments, M баз данных, distributed tracing. Это конвертируется в скорость онбординга новых разработчиков и частоту ошибок.
Стоимость миграции. Переход между архитектурами неизбежен при росте. Вопрос: когда это произойдёт и сколько будет стоить. Миграция с монолита на микросервисы при 50K DAU обходится в 2–4 месяца работы команды. Миграция обратно — ещё дороже.
Монолит: TCO-расчёт для стартапа на ранней стадии
Базовые параметры: SaaS-продукт, 1–10K DAU, команда 2–5 разработчиков, стек Node.js/Python + PostgreSQL.
Инфраструктура (месяц)
| Компонент | Провайдер | Стоимость |
|---|---|---|
| App server (2 vCPU, 4GB RAM) | DigitalOcean / Hetzner | $20–48 |
| Managed PostgreSQL | Supabase Free → Pro | $0–25 |
| Redis (кеш, сессии) | Upstash | $0–10 |
| CDN + домен | Cloudflare Free | $0 |
| CI/CD | GitHub Actions Free tier | $0 |
| Мониторинг | Sentry Free + UptimeRobot | $0 |
| Итого инфраструктура | $20–83/мес |
Операционные расходы
Один Dockerfile, один docker-compose.yml, одна команда деплоя. CI/CD настраивается за 2–4 часа и работает без обслуживания. Мониторинг: один процесс, один лог, один health check.
Операционный overhead: 2–4 часа/месяц.
Время разработки фичи
Новый API-эндпоинт в монолите: написать handler, добавить миграцию БД, написать тест, задеплоить. Среднее время от задачи до продакшена: 2–8 часов в зависимости от сложности. Нет сетевых вызовов между сервисами, нет версионирования API-контрактов, debugging в одном процессе.
Формула TCO монолита
TCO_monolith = Infra ($20–83) + Ops (2–4ч × $hourly_rate) + Dev_overhead (0%)
При $75/час разработчика: $170–383/мес на ранней стадии.
Микросервисы: TCO-расчёт при тех же параметрах
Те же условия: 1–10K DAU, 2–5 разработчиков, но архитектура разделена на 4–6 сервисов (auth, users, billing, core-logic, notifications, API gateway).
Инфраструктура (месяц)
| Компонент | Провайдер | Стоимость |
|---|---|---|
| Kubernetes (managed) | DigitalOcean DOKS | $36–72 |
| 3–5 node pool (2 vCPU, 4GB) | $60–150 | |
| Container registry | $5–20 | |
| Managed PostgreSQL (2+ инстанса) | $30–100 | |
| Message broker (RabbitMQ/Kafka) | CloudAMQP / Confluent | $0–89 |
| API Gateway / Service mesh | Kong / Istio | $0–50 |
| Distributed tracing | Jaeger / Tempo | $0–30 |
| Log aggregation | Loki / ELK | $0–50 |
| CI/CD (параллельные пайплайны) | GitHub Actions | $0–40 |
| Итого инфраструктура | $131–601/мес |
Операционные расходы
Каждый сервис требует собственный Dockerfile, Helm chart или Compose-конфиг, health check, readiness probe. Kubernetes нуждается в обслуживании: обновления нод, мониторинг ресурсов, auto-scaling policies.
Операционный overhead: 15–30 часов/месяц.
Время разработки фичи
Тот же API-эндпоинт теперь затрагивает 2–3 сервиса. Нужно определить контракт между ними, реализовать сетевые вызовы, обработать partial failures, написать integration-тесты, задеплоить каждый сервис отдельно.
Среднее время от задачи до продакшена: 8–24 часа.
Формула TCO микросервисов
TCO_microservices = Infra ($131–601) + Ops (15–30ч × $hourly_rate) + Dev_overhead (+50–100%)
При $75/час разработчика: $1,256–2,851/мес на ранней стадии. Это в 4–8 раз дороже монолита при идентичной функциональности.
Serverless: TCO-расчёт для event-driven нагрузки
Те же параметры: 1–10K DAU, 2–5 разработчиков. Стек: AWS Lambda / Cloudflare Workers / Supabase Edge Functions + managed DB.
Инфраструктура (месяц)
| Компонент | Провайдер | Стоимость |
|---|---|---|
| Functions (100K–1M invocations) | Cloudflare Workers Free → Paid | $0–5 |
| Database | Supabase / PlanetScale | $0–25 |
| Storage (S3-compatible) | Cloudflare R2 | $0–5 |
| Auth | Supabase Auth / Clerk | $0–25 |
| Queue / Cron | Cloudflare Queues / Cron Triggers | $0–5 |
| Мониторинг | Sentry + встроенные метрики | $0–26 |
| Итого инфраструктура | $0–91/мес |
Операционные расходы
Нет серверов, нет Kubernetes, нет Docker. Деплой: wrangler deploy или git push. Масштабирование автоматическое. Появляются специфические задачи: управление cold starts, мониторинг лимитов (CPU time, memory), обработка таймаутов, защита от каскадных отказов.
Операционный overhead: 4–10 часов/месяц.
Время разработки фичи
Функции изолированы, что ускоряет разработку отдельных endpoints. Stateless-природа создаёт сложности: нет shared memory, ограниченное время выполнения, специфичные паттерны для работы с БД. Debugging распределённых функций требует structured logging и correlation IDs.
Среднее время от задачи до продакшена: 3–12 часов.
Формула TCO serverless
TCO_serverless = Infra ($0–91) + Ops (4–10ч × $hourly_rate) + Dev_overhead (+10–30%)
При $75/час разработчика: $300–841/мес на ранней стадии.
Сводная таблица: три архитектуры при одинаковых условиях
Параметры: SaaS, 5K DAU, команда 3 человека, $75/час.
| Метрика | Монолит | Микросервисы | Serverless |
|---|---|---|---|
| Инфраструктура/мес | $50 | $350 | $30 |
| Ops часов/мес | 3 | 20 | 6 |
| Ops стоимость/мес | $225 | $1,500 | $450 |
| Feature delivery (среднее) | 5ч | 14ч | 7ч |
| Время до первого деплоя | 1–2 дня | 1–3 недели | 1–3 дня |
| Онбординг нового разработчика | 1–2 дня | 1–3 недели | 3–5 дней |
| TCO/мес | ~$275 | ~$1,850 | ~$480 |
| TCO/год | ~$3,300 | ~$22,200 | ~$5,760 |
Разница между монолитом и микросервисами на стадии pre-PMF: ~$18,900/год. Это runway, который можно потратить на продуктовые эксперименты вместо инфраструктуры.
Промпты для AI-расчёта TCO под конкретный проект
Эти промпты работают с Claude, GPT-5.5, Gemini. Подставьте параметры проекта и получите количественную модель.
Промпт 1: Базовый TCO-расчёт
Рассчитай TCO на 12 месяцев для трёх архитектур (монолит, микросервисы, serverless) со следующими параметрами:
- Продукт: [тип продукта, например SaaS для управления проектами]
- DAU сейчас: [число]
- Прогноз DAU через 12 мес: [число]
- Команда: [количество] разработчиков, ставка $[число]/час
- Стек: [языки, фреймворки]
- Основные нагрузки: [API calls/день, background jobs, real-time connections]
- Облачный провайдер: [AWS / GCP / Cloudflare / DigitalOcean]
Для каждой архитектуры рассчитай:
1. Помесячные расходы на инфраструктуру (конкретные сервисы и тарифы)
2. Операционные часы/месяц (DevOps, мониторинг, incident response)
3. Overhead на feature delivery (% увеличения времени разработки)
4. Стоимость миграции на следующую архитектуру при достижении лимитов
5. Break-even point: при каком DAU микросервисы становятся дешевле монолита
Выведи результат в виде таблицы с помесячной разбивкой.
Промпт 2: Анализ скрытых затрат
Для архитектуры [монолит/микросервисы/serverless] с параметрами:
- [вставить параметры из промпта 1]
Рассчитай скрытые затраты, которые не входят в счёт от облачного провайдера:
1. Когнитивная нагрузка: сколько контекстов одновременно держит разработчик, как это влияет на скорость и ошибки
2. Incident response: среднее время на диагностику и устранение инцидентов для данной архитектуры
3. Технический долг: с какой скоростью накапливается, когда потребует рефакторинга
4. Vendor lock-in: стоимость смены провайдера (часы разработки + период миграции)
5. Найм: насколько сложнее найти разработчика для данного стека/архитектуры (влияние на скорость найма и зарплатные ожидания)
Оцени каждый пункт в долларах/месяц и добавь к базовому TCO.
Промпт 3: Сценарное моделирование
Смоделируй три сценария роста для архитектуры [текущая архитектура] с параметрами:
- [вставить параметры]
Сценарий A — медленный рост: DAU x2 за 12 месяцев
Сценарий B — умеренный рост: DAU x5 за 12 месяцев
Сценарий C — взрывной рост: DAU x20 за 12 месяцев
Для каждого сценария определи:
1. В каком месяце текущая архитектура достигает лимитов
2. Какие компоненты станут узкими местами первыми
3. Стоимость и длительность миграции на следующую архитектуру
4. Оптимальную целевую архитектуру для каждого сценария
5. Суммарный TCO за 12 месяцев включая миграцию
Построй график: TCO по месяцам для каждого сценария.
Decision Framework: алгоритм выбора архитектуры
Архитектурный выбор зависит от четырёх переменных: стадия продукта, характер нагрузки, размер команды, прогноз роста.
Шаг 1: определить стадию
| Стадия | Признаки | Приоритет |
|---|---|---|
| Pre-PMF | Нет стабильного retention, частые pivot-ы | Скорость итераций |
| Post-PMF, pre-scale | PMF найден, DAU < 50K, рост 10–30%/мес | Стабильность + скорость |
| Scale | DAU > 50K, рост > 30%/мес | Масштабируемость |
Шаг 2: оценить характер нагрузки
| Характер нагрузки | Примеры | Лучшая архитектура |
|---|---|---|
| Синхронный CRUD | CRM, project management, CMS | Монолит |
| Event-driven, spiky | Webhooks, notifications, ETL | Serverless |
| Real-time + heavy compute | Video processing, ML inference | Микросервисы |
| API-heavy с внешними интеграциями | Агрегаторы, мультипровайдерные системы | Монолит → Serverless для интеграций |
| Mixed workloads | Основной CRUD + background processing | Монолит + serverless functions |
Шаг 3: матрица решений
IF стадия == Pre-PMF:
ВЫБРАТЬ монолит
ПРИЧИНА: минимальный TCO, максимальная скорость итераций
ИСКЛЮЧЕНИЕ: продукт нативно serverless (webhook-процессор, chatbot)
IF стадия == Post-PMF AND команда <= 5:
ВЫБРАТЬ монолит + serverless для фоновых задач
ПРИЧИНА: не хватит людей обслуживать микросервисы
IF стадия == Post-PMF AND команда > 10 AND DAU > 50K:
РАССМОТРЕТЬ извлечение первого микросервиса
ПРАВИЛО: извлекать только тот компонент, который масштабируется иначе
IF стадия == Scale AND разные компоненты масштабируются по-разному:
ВЫБРАТЬ микросервисы (постепенная декомпозиция)
ПРАВИЛО: один сервис за раз, не Big Bang migration
Шаг 4: валидация через AI
Используйте промпт 1 из предыдущего раздела с конкретными параметрами проекта. Сравните результат AI-расчёта с матрицей решений. Если AI-модель и framework дают разные рекомендации, это сигнал для более глубокого анализа.
Когда монолит становится проблемой: конкретные метрики
Монолит не вечен. Вот измеримые сигналы, что пора извлекать первый сервис.
Деплой длится > 15 минут. Сборка, тесты, деплой одного изменения занимают больше 15 минут. Разработчики избегают мелких деплоев и копят изменения.
Один модуль забирает > 60% ресурсов. Если image processing или ML inference потребляют основную долю CPU/RAM, а остальная часть приложения idle — кандидат на извлечение.
Разные SLA для разных компонентов. Биллинг требует 99.99% uptime, а генерация отчётов допускает 99.9%. Единый deployment делает невозможным разные гарантии.
Команда > 8–10 человек работает в одном репозитории. Merge conflicts становятся ежедневной проблемой. Деплои блокируют друг друга.
Частота инцидентов растёт нелинейно. Каждый новый модуль увеличивает вероятность, что деплой одного компонента сломает другой.
Антипаттерны: ошибки, которые увеличивают TCO в 5–10 раз
Premature microservices. Разделение на сервисы до понимания domain boundaries. Результат: постоянные изменения API-контрактов, distributed monolith, все минусы обеих архитектур.
Serverless для stateful workloads. Попытка реализовать долгоживущие WebSocket-соединения или complex transactions на Lambda/Workers. Результат: workaround поверх workaround, непредсказуемые cold starts, стоимость выше, чем у выделенного сервера.
Kubernetes для команды из двух человек. K8s требует dedicated DevOps-экспертизы. В команде из 2–3 разработчиков один будет тратить 30–50% времени на инфраструктуру вместо продукта.
Big Bang migration. Попытка мигрировать весь монолит на микросервисы за один проход. Такая миграция регулярно занимает в 3–5 раз больше запланированного и создаёт период нестабильности.
Игнорирование стоимости разработки в TCO. Сравнение только по счетам от AWS. $200/мес за Lambda выглядит дешевле $100/мес за VPS, пока не учтены 20 дополнительных часов разработки на адаптацию под serverless-ограничения.
Практический чеклист перед выбором архитектуры
- Рассчитать TCO для всех трёх архитектур с помощью промптов выше. Не интуиция, а цифры.
- Определить стадию продукта по framework из раздела Decision Framework.
- Оценить характер нагрузки. Синхронный CRUD или event-driven? Равномерная или пиковая?
- Учесть размер команды. Хватит ли людей обслуживать выбранную архитектуру без ущерба для продуктовой разработки?
- Смоделировать рост. Использовать промпт 3 для трёх сценариев. Определить точку, в которой архитектура потребует миграции.
- Определить стоимость миграции. Если выбрали монолит сейчас, во сколько обойдётся переход на микросервисы через 18 месяцев?
- Принять решение на основе данных, а не FOMO по новым технологиям.
Итоговая рекомендация
Для большинства стартапов на ранней стадии правильный ответ: начать с монолита, добавить serverless functions для фоновых задач и интеграций, и извлекать микросервисы только когда конкретные метрики (деплой > 15 мин, один модуль > 60% ресурсов, команда > 8 человек) покажут необходимость.
Это оптимальная стратегия по TCO. Монолит на ранней стадии экономит $15,000–20,000/год по сравнению с микросервисами: 2–3 дополнительных месяца runway или бюджет на продуктовые эксперименты, которые определят, выживет ли продукт вообще.
Архитектура не высечена в камне. Это инвестиционное решение с конкретным ROI. Считайте TCO, используйте AI для моделирования сценариев, принимайте решения на основе данных.
Нужна помощь с выбором архитектуры? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.
FAQ
В какой момент декомпозиция монолита действительно становится дешевле его поддержки?
Математика обычно склоняется в сторону разделения примерно при 50K DAU и команде из 8–10 разработчиков. Ниже этого порога операционный overhead микросервисов превышает прирост продуктивности. Выше него координация между командами в едином репозитории стоит больше, чем экономия на инфраструктуре. Более чёткий сигнал — время деплоя: когда цикл «изменение — тест — деплой» стабильно занимает более 15 минут, монолит начинает активно замедлять итерации.
Как сравнивать Cloudflare Workers и AWS Lambda по TCO?
Workers дешевле при низком и среднем объёме вызовов (до ~10M/месяц) и не имеют cold start, что делает их лучше для latency-sensitive эндпоинтов. Lambda поддерживает более длинное время выполнения (до 15 минут против 30 секунд CPU у Workers) и имеет более развитую экосистему. Для типичных стартап-нагрузок (webhooks, фоновые задачи, API-интеграции) Workers на бесплатном тарифе практически бесплатны, тогда как Lambda становится заметной статьёй расходов выше 1M вызовов/месяц. Переключение между ними дорого (разные рантаймы, разные API провайдеров), поэтому выбирайте исходя из экосистемы основного облачного провайдера.
Может ли стартап изначально строить гибридную архитектуру — монолит для ядра плюс serverless для отдельных функций?
Да, и нередко это правильное решение. Паттерн: монолит для CRUD-ядра, serverless-функции (Cloudflare Workers, Supabase Edge Functions) исключительно для фоновых задач, webhooks и интеграций с третьими сторонами. Это даёт TCO монолита (~$275/месяц) для основного продукта, при этом асинхронные нагрузки не влияют на деплой-процесс монолита. Операционный overhead минимален, и вы избегаете полных затрат на координацию микросервисов.