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