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