15 микросервисов в MVP на 50 человек: почему финансовые директора оплачивают чужие резюме

Оверинжиниринг и скрытый TCO разработки: как архитектурные амбиции программистов сжигают бюджет компаний

Разработчики продают бизнесу «масштабируемость до миллиарда запросов», когда у проекта еще нет первых 50 пользователей. Считаем реальный TCO микросервисной архитектуры и показываем, где бизнес теряет миллионы рублей на пустом месте.

Анатомия типового счета: сколько стоит микросервисный зоопарк в P&L

Рассмотрим реальный кейс: запуск внутреннего сервиса или MVP, рассчитанного всего на 50 активных пользователей. Архитектура, предложенная инженерами, включает 15 микросервисов, кластер Kubernetes, брокер сообщений Kafka и распределенные базы данных. Для финансового директора такая «современная» схема превращается в тяжелую статью расходов в P&L.

Структура ежемесячных затрат:

• Аренда серверных мощностей в облаке: от 180 000 до 350 000 ₽/мес (для поддержания работы всей инфраструктуры контейнеров и очередей).

• Стоимость владения альтернативой (выделенный сервер): от 12 000 до 15 000 ₽/мес за один стабильный «железный» сервер.

• ФОТ DevOps и SRE-инженеров: от 300 000 до 450 000 ₽/мес. Эти специалисты необходимы исключительно для поддержания жизнедеятельности упавших контейнеров и настройки сложных сетевых мостов.

• Замедление Time-to-Market: внедрение каждой новой кнопки или отчета занимает в 3–4 раза больше времени.

• Причина задержки: необходимость долгого согласования межсервисных контрактов и управления сетевыми очередями.

Конфликт интересов: почему программисты навязывают микросервисы

Проблема избыточной сложности часто кроется в психологии наемной разработки. Инженеру профессионально выгодно «прокачать» свое резюме наиболее востребованными и модными технологиями — Kubernetes, Kafka, Go, микросервисная архитектура. К сожалению для акционеров, эта учеба происходит за счет текущего работодателя или заказчика.

Бизнес-реальность диктует иные правила: компании нужна быстрая проверка гипотезы, минимальные издержки и возврат инвестиций. Ей не нужен выставочный стенд чужих карьерных амбиций, за который приходится платить из операционной прибыли.

Три технологические ловушки, которые съедают рабочее время

Когда архитектура переусложнена, возникают неявные потери, которые сложно оцифровать сразу, но которые отчетливо видны в годовом отчете.

• Сетевой оверхед и задержки: вместо мгновенного прямого вызова функции в памяти процессора, система вынуждена гонять терабайты JSON-пакетов по сети между сервисами, создавая искусственные тормоза.

• Распределенные транзакции: вы сталкиваетесь с ситуацией, когда деньги у клиента списались, а товар на складе не зарезервировался из-за сбоя в одном из узлов. Поиск концов в такой распределенной среде занимает недели оплачиваемых часов senior-разработчиков.

• Сложность мониторинга и дебага: чтобы просто понять, почему система «упала», приходится внедрять тяжелые и дорогие системы распределенного трейсинга (Jaeger, OpenTelemetry, ELK), что снова раздувает бюджет.

Золотой стандарт: когда монолит экономит миллионы

Опыт нашей студии показывает, что для 95% бизнес-задач идеальным решением остается модульный монолит. Мы в студии используем проверенный временем и рынком зрелый стек технологий.

Технологический стек:

• PHP 8.3 / Laravel 11

• Python / FastAPI

• Node.js / NestJS

• СУБД: PostgreSQL (реляционная база данных)

Один грамотно настроенный монолит на таком стеке без проблем выдерживает десятки тысяч запросов в секунду, что покрывает потребности большинства компаний.

Экономика монолитного решения:

• Серверные затраты: 10 000 – 15 000 ₽/мес.

• Затраты на DevOps: 0 ₽ на старте (достаточно простого базового CI/CD скрипта).

• Скорость внедрения фич: исчисляется часами вместо недель.

• Простота сопровождения: штатный программист видит весь проект целиком, а не разрозненные куски пазла, что кратно снижает риск ошибок.

Три объективных критерия: когда микросервисы действительно оправданы

Микросервисы — это не вопрос моды, а физика процессов. Мы в студии выделяем лишь три случая, когда такая архитектура оправдана:

1. Масштаб команды: когда в разработке одновременно участвуют более 3–4 независимых команд (суммарно от 25–30 инженеров), которые начинают физически мешать друг другу в одной кодовой базе.

2. Специфика аппаратных ресурсов: если отдельный модуль (например, AI-аналитика или тяжелая обработка видео) требует специфических мощных GPU, в то время как остальной системе достаточно стандартных CPU.

3. Доказанное узкое горлышко: когда конкретная изолированная операция создает 90% нагрузки и ее вынос в отдельный сервис реально снижает стоимость инфраструктуры, а не увеличивает ее.

Чек-лист для финдира и собственника: 5 вопросов подрядчику до подписания сметы

Чтобы защитить бюджет от архитектурных излишеств, используйте этот опросник при обсуждении проекта:

1. Какова расчетная стоимость серверной инфраструктуры в месяц при текущей нагрузке и при ее росте в 5 раз?

2. Сколько инженеров поддержки и какого профиля (DevOps, DBA) потребуется для обслуживания этой архитектуры?

3. Каков будет средний срок согласования и релиза новой формы или отчета?

4. Сможет ли проект работать и масштабироваться вертикально на одном сервере первые 1–2 года?

5. Готов ли подрядчик зафиксировать TCO (совокупную стоимость владения) инфраструктурой в договоре?