Микросервисы: почему они часто хуже, чем кажется

Зачем нам эта тема?

Вы слышали, что любой проект должен сразу переехать в микросервисы? Поговорим. Тот же стартап «Курьерка», запустивший приложение за три месяца, решил разбить всё на пять сервисов. Через полгода команда потратила столько же времени на деплой, сколько на написание кода. Интересно, а где же выигрыш?

Миф о «масштабируемости»

ВАЖНО

Хотите глубже? Изучите первоисточники, на которые мы ссылаемся в статье.

Говорят, микросервисы позволяют масштабировать отдельные части без затрагивания остальных. В реальности каждый сервис – отдельный репозиторий, CI/CD‑pipeline, база, мониторинг. При росте проекта в два‑три раза появляется десяток новых точек отказа. Пример из «Тинькофф»: после перехода на микросервисы в 2019‑м году время отклика выросло с 120 мс до 340 мс, а количество багов в проде удвоилось. Почему? Потому что каждый сервис требует отдельного тестового покрытия, а в небольших командах ресурсы на это ограничены.

Скрытые издержки

Операционные расходы – ещё один «плюс», который часто забывают. Стоимость облачных контейнеров, оркестратора Kubernetes, лицензий на сервис‑мэшин. Для проекта с бюджетом в 2 млн рублей такие траты могут съесть 30‑40 % от общего фонда. Плюс постоянные «DevOps‑часы»: настройка сети, управление секретами, обновление образов. Всё это отнимает время у разработчиков, которые могли бы писать фичи.

«Мы думали, что микросервисы спасут наш стартап от технического долга. На деле они создали новый — операционный.

Моя позиция

Я считаю, что микросервисы – привилегия крупных компаний с командами от 50 человек и более. Для проекта из 5‑10 разработчиков лучше держать монолит, но с хорошей модульностью. Тесты покрывают всё приложение, деплой один. Когда рост действительно требует распределения нагрузки, тогда уже можно планировать переход, а не начинать с нуля.

Конечно, есть ситуации, когда микросервисы спасают: система рекомендаций у «Netflix», обработка транзакций у «PayPal». Но это исключения, а не правило. Если ваш продукт – локальный сервис бронирования столиков или приложение для учёта личных расходов, ставьте цель – быстро доставить ценность пользователю, а не собрать коллекцию Docker‑образов.

Вывод

Микросервисы звучат заманчиво, но в небольших проектах они часто оказываются дорогой иллюзией. Вместо того чтобы сразу разбивать всё на кусочки, лучше сосредоточиться на чистом коде, автоматизации тестов и быстром обратном отклике. А когда бизнес уже требует масштабирования, тогда уже будет время открывать новые сервисы, а не бороться с их «техническим долгом».