Микросервисы: управленческая цена, о которой не говорят
Разбираю, почему переход на микросервисную архитектуру - это не только техническое решение, но и новая операционная нагрузка на организацию.
Микросервисы - один из самых обсуждаемых архитектурных подходов последних двух лет. Netflix, Amazon, SoundCloud - все крупные технологические компании рассказывают, как декомпозиция монолита на небольшие независимые сервисы дала им скорость и масштабируемость.
Я регулярно вижу, как эти истории влияют на решения в компаниях, которые не являются Netflix. Команда предлагает перейти на микросервисы, обоснование звучит убедительно, и проект начинается. Через год выясняется, что стало сложнее, а не проще.
Я не против микросервисов. Я против того, чтобы принимать это решение без понимания полной цены.
Что именно усложняется
Каждый сервис - это отдельный процесс, который нужно деплоить, мониторить, логировать и обновлять. У него есть своя конфигурация, свой жизненный цикл, свои зависимости. Когда сервисов пять - это управляемо. Когда их пятьдесят - это отдельная инфраструктурная задача.
Локально это выглядит как техническая проблема. Организационно - это вопрос владения: кто отвечает за каждый сервис, кто принимает решения при инцидентах, кто следит за совместимостью интерфейсов между командами.
Монолит при всех своих недостатках прозрачен. Микросервисы требуют явных контрактов, явных владельцев и явных процессов на каждом шве между компонентами.
Скрытые издержки
Первая скрытая издержка - сетевые вызовы вместо вызовов внутри процесса. То, что в монолите было функцией, теперь является HTTP-запросом со всеми вытекающими: задержки, сбои, необходимость обрабатывать недоступность партнёра.
Вторая - распределённая отладка. Когда что-то идёт не так, проблема может находиться в любом из нескольких сервисов или в точке их взаимодействия. Для расследования нужна централизованная система логов и трассировки, иначе отладка превращается в детективное расследование без улик.
Третья - управление данными. В монолите у вас одна база. В микросервисах каждый сервис часто хочет свою. Это порождает вопросы синхронизации и согласованности, которые в монолите не существовали.
Когда это оправдано
Микросервисная архитектура оправдана, когда у вас есть независимые части продукта с разными темпами изменений, разными требованиями к масштабируемости, и - главное - когда у вас есть зрелая инженерная культура с автоматизированными деплоями, мониторингом и практикой работы с распределёнными системами.
Если этого нет - вы не получаете гибкость микросервисов. Вы получаете сложность микросервисов на организационную культуру монолита.
Компании вроде Netflix начали с монолита, переходили постепенно и выстроили инструменты вокруг своих потребностей. Их история - это не рецепт, это отчёт о многолетней работе.
Вопросы перед принятием решения
Если команда предлагает переход на микросервисы, вот что стоит прояснить:
- Что именно сейчас не работает в текущей архитектуре, и почему микросервисы решат именно это?
- Есть ли у нас автоматизированный деплой и тестирование, на которые можно положиться?
- Кто будет владельцем каждого нового сервиса?
- Как мы будем расследовать инциденты в распределённой системе?
- Готовы ли мы к росту операционной нагрузки на первые полгода после перехода?
Ответы на эти вопросы не отменят решение, но сделают его осознанным.