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