Микросервисы: что этот термин означает для бизнеса
Разбор того, что стоит за словом 'микросервисы' и как руководителю думать об этом архитектурном выборе.
Слово "микросервисы" появляется в разговорах с командами разработки всё чаще. Иногда это обоснованное предложение, иногда - модное слово, прикрывающее желание переписать всё с нуля. Для руководителя важно понять, что за этим стоит, прежде чем соглашаться или отказываться.
Архитектурный выбор здесь реальный, и у него есть практические последствия для скорости разработки, стоимости поддержки и способности компании меняться. Но он также несёт риски, которые часто остаются за кадром в энтузиастских презентациях.
Что такое монолит и почему он перестаёт устраивать
Большинство корпоративных систем начинались как монолиты - единое приложение, где всё связано со всем. Это не плохо на старте: проще разрабатывать, проще тестировать, проще развёртывать.
Проблема появляется позже. Когда система выросла, любое изменение в одной части требует понимания всего остального. Команда боится трогать "работающий" код. Релизы замедляются. Новые функции добавляются с оглядкой на всё, что уже есть. Именно это давление сформировало запрос на меньше монолитов и больше архитектурной дисциплины.
В этой точке обычно и возникает разговор об альтернативах.
Что предлагают микросервисы
Идея простая: разбить большое приложение на независимые части, каждая из которых делает одно дело и общается с остальными через чётко определённые интерфейсы.
Теоретические преимущества:
- разные команды могут работать над разными частями независимо;
- каждую часть можно обновлять и развёртывать отдельно;
- проблема в одной части не валит всю систему;
- разные части можно масштабировать по отдельности.
Это звучит убедительно. Но есть и оборотная сторона.
Что остаётся за кадром
Микросервисная архитектура решает проблемы масштаба, но создаёт новые проблемы операционной сложности. Вместо одного приложения нужно эксплуатировать десятки или сотни. Каждое - со своим развёртыванием, мониторингом, логированием, версионированием.
Сетевые вызовы между сервисами ненадёжны. Нужно думать о том, что происходит, если один сервис недоступен. Транзакции, которые в монолите были атомарными, теперь распределены по нескольким системам - это отдельный класс задач.
Наконец, организационный момент: независимость сервисов работает, только если команды действительно независимы. Если три команды постоянно ждут друг друга, архитектура не поможет.
Когда это имеет смысл
Разбивать монолит на микросервисы оправдано, если:
- система действительно большая и несколько команд мешают друг другу при разработке;
- разные части системы имеют принципиально разные требования к нагрузке и надёжности;
- есть операционная зрелость - команда умеет эксплуатировать распределённые системы;
- есть время и ресурсы на переход, а не только на разработку нового.
Если компания только выстраивает продукт и ищет рынок - преждевременная декомпозиция скорее замедлит, чем ускорит. Те же компромиссы действуют независимо от того, смотреть на это как архитектурный выбор или управленческое решение.
Вопросы для разговора с командой
Прежде чем принимать архитектурное решение, я рекомендую получить ответы на следующие вопросы:
- Какую конкретную проблему мы решаем этой архитектурой - что именно сейчас не работает?
- Сколько команд будет работать с системой и насколько они реально независимы сейчас?
- Есть ли у нас опыт эксплуатации распределённых систем или нам придётся его приобретать по ходу?
- Каков план перехода - переписываем с нуля или постепенно выделяем части?
- Как изменится стоимость поддержки через год после перехода?
Архитектура - это не религия. Это инструмент, и выбирать его нужно под конкретную задачу.