Микросервисы или монолит: архитектура приложения для бизнеса

Вы запускаете новый продукт. Команда спорит: «Давайте сразу на микросервисах, как Netflix!» Архитектор настаивает на монолите. PM считает бюджет и хватается за голову. Знакомая ситуация?

За 7 лет enterprise-разработки я видел, как компании тратили 6–12 месяцев и 3–5 млн рублей на микросервисную архитектуру, которая им была не нужна. И наоборот — монолит на 200 000 пользователей превращался в неуправляемый комок кода, который невозможно масштабировать. Обе крайности дорого обходятся бизнесу.

В этой статье — конкретные критерии: когда монолит сэкономит деньги, когда микросервисы себя окупят, и как не попасть в ловушку хайпа.

Монолитная архитектура приложения: когда достаточно

Монолит — это единое приложение, где весь код живёт в одной кодовой базе, деплоится одним артефактом и работает в одном процессе. Звучит устаревше? На практике 70% бизнес-приложений в 2026 году — это монолиты. И работают отлично.

Сильные стороны монолита для бизнеса

Скорость старта. Команда из 2–4 разработчиков может запустить MVP за 2–3 месяца. Нет накладных расходов на оркестрацию, сервис-меши, распределённые транзакции. Один корпоративный портал на Jmix — от идеи до продакшена за 8 недель.

Простота отладки. Один стектрейс вместо 15 распределённых логов. Ошибка в монолите находится за 20 минут, в микросервисах — за 2–4 часа (с трейсингом) или за 2 дня (без него).

Низкая стоимость инфраструктуры. Один сервер за 5 000–15 000 руб./мес против кластера Kubernetes за 40 000–120 000 руб./мес. Для приложения с 500–5 000 пользователей разница — 300 000–600 000 руб. в год.

Транзакционная целостность. ACID-транзакции из коробки. Не нужно реализовывать Saga-паттерн, eventual consistency и двухфазные коммиты. Для финансовых операций, документооборота и CRM-систем — критично.

Когда монолит — правильный выбор

Монолит подходит, если:

• Команда до 10 человек
• Нагрузка до 10 000 одновременных пользователей
• Единая бизнес-доменная область (CRM, ERP, документооборот)
• Бюджет на MVP — до 2 млн рублей
• Нет требований к независимому масштабированию отдельных модулей

Пример: система автоматизации документооборота для 300 сотрудников. Монолит на Spring Boot + PostgreSQL. Время отклика — 120 мс, 99.5% uptime, стоимость инфраструктуры — 8 000 руб./мес.

Микросервисы: преимущества, масштабирование и скрытые затраты

Микросервисы — это набор небольших, независимо развёртываемых сервисов, каждый из которых отвечает за одну бизнес-функцию. Общение между ними — через API (REST, gRPC) или очереди сообщений (Kafka, RabbitMQ).

Когда микросервисы действительно нужны

Независимое масштабирование. У вас 1 млн+ устройств шлют телеметрию, но административная панель обслуживает 50 операторов. Масштабировать нужно только ingestion-сервис, а не всё приложение. В IoT-проекте на Java и Kafka мы обрабатывали 15 000 сообщений в секунду в одном сервисе, пока остальные 8 сервисов работали на минимальных ресурсах.

Разные команды — разные сервисы. Если у вас 20+ разработчиков, монолит превращается в бутылочное горлышко: мерж-конфликты, сломанные билды, невозможность деплоить один модуль без регрессии в другом. Микросервисы позволяют 3–4 командам деплоить независимо, по 5–10 релизов в день каждая.

Полиглотный стек. ML-модуль на Python, основной backend на Java, real-time нотификации на Go. В монолите это невозможно. В микросервисах — стандартная практика.

Скрытые затраты микросервисов, о которых молчат

Инфраструктурный overhead. Kubernetes кластер, service mesh (Istio/Linkerd), centralized logging (ELK/Loki), distributed tracing (Jaeger), API gateway — это 40 000–150 000 руб./мес только на инфраструктуру. Плюс DevOps-инженер за 250 000–400 000 руб./мес.

Сложность разработки. Распределённые транзакции, eventual consistency, circuit breakers, retry policies, идемпотентность — каждый паттерн добавляет 15–30% к времени разработки фичи. Простой CRUD, который в монолите занимает 2 часа, в микросервисах может потребовать 6–8 часов.

Организационная зрелость. Микросервисы требуют CI/CD pipeline для каждого сервиса, contract testing между сервисами, централизованное управление конфигурацией. Если у вас нет выделенного DevOps — не начинайте.

Как выбрать архитектуру приложения: 5 ключевых вопросов

1. Сколько разработчиков будут работать над проектом?
До 8 человек → монолит. 10–15 → модульный монолит. 15+ → микросервисы. Закон Конвея работает: архитектура повторяет структуру организации.

2. Какая ожидаемая нагрузка через 12 месяцев?
До 5 000 одновременных пользователей → монолит справится. 5 000–50 000 → модульный монолит с возможностью выделения hot-модулей. 50 000+ → микросервисы.

3. Нужно ли масштабировать отдельные части системы независимо?
Если да (например, обработка платежей отдельно от каталога товаров) → микросервисы. Если нагрузка равномерная → монолит проще масштабируется вертикально.

4. Какой бюджет на инфраструктуру?
Монолит: 5 000–30 000 руб./мес. Микросервисы: 50 000–200 000 руб./мес. Если бюджет ограничен — монолит в 3–5 раз дешевле.

5. Есть ли DevOps-экспертиза в команде?
Нет DevOps → монолит. Есть 1 DevOps → модульный монолит. Есть DevOps-команда → можно микросервисы.

Модульный монолит: масштабирование без микросервисов

Модульный монолит — это архитектурный подход, где приложение остаётся единым артефактом, но внутри разделено на изолированные модули с чёткими границами. Каждый модуль имеет свой bounded context, общается с другими через внутренние API, и может быть выделен в отдельный сервис при необходимости.

Как это работает на практике. В Jmix-проектах мы используем модульную структуру: модуль авторизации, модуль отчётов, модуль интеграций — каждый со своим набором сущностей и сервисов. При этом деплой — один JAR-файл, база — одна, транзакции — ACID.

Преимущества:

• Простота монолита (один деплой, одна БД) + изоляция микросервисов (чёткие границы модулей)
• Возможность выделить «горячий» модуль в отдельный сервис за 1–2 спринта
• Время старта MVP — 2–4 месяца (на 30% быстрее микросервисов)
• Стоимость инфраструктуры — как у монолита (5 000–30 000 руб./мес)

Для 80% бизнес-проектов модульный монолит — оптимальный выбор. Вы получаете скорость разработки монолита с архитектурной чистотой, которая позволяет перейти на микросервисы, когда (и если) это действительно понадобится.

Кейс: эволюция архитектуры приложения GPS-платформы

Мы разрабатывали GPS-трекинговую систему, которая прошла все три стадии:

Стадия 1 (0–6 месяцев): Монолит на Jmix. 500 устройств, 10 пользователей. Один сервер за 7 000 руб./мес. Команда — 2 человека. Время от идеи до первого клиента — 3 месяца.

Стадия 2 (6–18 месяцев): Модульный монолит. 15 000 устройств, 200 пользователей. Выделили модуль приёма данных (MQTT) в отдельный процесс, остальное — единое приложение. Инфраструктура — 25 000 руб./мес.

Стадия 3 (18+ месяцев): Частичные микросервисы. 1 млн+ устройств. Kafka для обработки телеметрии (отдельный сервис), REST API gateway, аналитический сервис. Основная бизнес-логика — по-прежнему модульный монолит. Инфраструктура — 85 000 руб./мес, но обслуживает в 200 раз больше устройств.

Вывод: не нужно выбирать раз и навсегда. Архитектура эволюционирует вместе с продуктом.

Выводы и рекомендации

Начинайте с монолита. 90% стартапов, которые начали с микросервисов, потратили лишние 2–4 месяца и 1–3 млн рублей на инфраструктуру, которая не понадобилась в первый год.

Проектируйте модульно. Даже если пишете монолит — делайте чёткие границы между модулями. Это инвестиция в будущее: выделить модуль в сервис за 2 недели проще, чем распиливать «большой ком грязи» за 6 месяцев.

Микросервисы — для зрелых команд и продуктов. Если у вас нет DevOps, CI/CD pipeline и как минимум 10 разработчиков — микросервисы принесут больше проблем, чем пользы.

Считайте TCO, не только разработку. Микросервисы в 3–5 раз дороже по инфраструктуре и требуют на 30–50% больше DevOps-ресурсов. Убедитесь, что бизнес-кейс оправдывает эти затраты.

Нужна помощь с выбором архитектуры для вашего проекта? Мы в DEVRUM проектируем системы на Java, Spring Boot и Jmix с учётом реальных бизнес-требований — от MVP до высоконагруженных платформ. Напишите нам — обсудим вашу задачу.