[Перевод] Почему я перестал говорить с архитекторами о микросервисах
На прошлой неделе это случилось снова. Я был на совещании по анализу архитектуры, и коллега-архитектор начал ещё одну оживлённую дискуссию о микросервисах. Спустя считанные минуты взгляд присутствующих остекленел, и мы погрузились в абсурдное обсуждение того, что должно быть средством для достижения цели, но превратилось в саму цель. В тот самый момент я осознал: с меня хватит. Я наконец-то поклялся больше не общаться с архитекторами о микросервисах. Почему? Да потому, что такие обсуждения обычно не приводят ни к чему продуктивному.
Своё раздражение я сформулировал как три основные проблемы:
Никто не может прийти к согласию о значении термина «микросервис».
Обсуждения микросервисов абстрактны и почти не связаны с реальными целями бизнеса
Внедрение микросервисов без организационных изменений — бессмысленная затея.
Проблема первая: никто не знает, что такое микросервис
Эта проблема наиболее очевидна. Для микросервисов нет какого-то формального определения, поэтому когда люди обсуждают их, это приводит к недоразумениям.
Существует несколько определений:
Сервис из малого количества строк кода:
«Они очень маленькие. Даже сто строк кода, вероятно, считаются сегодня большим сервисом», — Фред Джордж, Barcelona Ruby Conference
«Команда на две пиццы»
Строго говоря, это не определение микросервисов, но часто используется в качестве эмпирического правила для выбора размера необходимой при их реализации команды; такая формулировка подразумевает, что для создания микросервиса требуется отдельная команда.
Требует для создания и поддержки только одного программиста:
«Если сервис проектирует и поддерживает несколько программистов, то это не микросервис», — Фред Джордж, GOTO 2016
Автономные, самостоятельные и уникальные процессы
«Каждый сервис автономен, самостоятелен и выполняет уникальный процесс».
Контейнер/pod
«Каждый микросервис упакован как контейнер Docker, чтобы обеспечить возможность развёртывания в кластер Kubernetes для оркестрации приложения».
Сервис с собственным хранилищем данных
Это долгое время было моим эмпирическим правилом; также оно подразумевается здесь
«Независимо заменяемые и обновляемые»
Иэн Купер, повторивший за книгой 1975 года «Структурный дизайн» Эдварда Йордона и Ларри Константина
«Маленький компьютер, работающий с моделью концепций бизнеса, релевантных задаче», — Дэниел Терхорст-Норт
Хоть некоторые из этих определений во многом пересекаются с другими, при их обсуждении упор делается на разное, из-за чего возникает ситуация «слепые и слон»: каждый корректно описывает нечто слегка иначе, поэтому никто не «ошибается», но у нас определённо нет согласования в терминологии.
(Я говорил о запутанности термина «микросервис» при обсуждении перехода Amazon Video с так называемых микросервисов на монолит.)
После кучи подобных дебатов мы решили, что проще всего будет полностью запретить использование термина «микросервисы». Если термин порождает такую запутанность, то, вероятно, он бесполезен.
Вместо того, чтобы спорить о названиях архитектуры, лучше поговорить о конкретных трудностях и компромиссах: как быстрее внедрять новые фичи, как снизить связанность, как масштабировать разные части системы. Иными словами, микросервисы (что бы вы под этим словом ни подразумевали) — это не конечный результат сам по себе, а побочный продукт достижения какой-то другой цели.
Проблема первая (б): отсутствие дисциплины в терминологии ПО
Это проблема не только микросервисов, но и нашей отрасли в целом. Мы разбрасываемся громкими словами, которые звучат впечатляюще, но для разных людей означают разное. Вот примеры терминов и их истории:
DevOps
Изначально этот термин означал отказ от стандартного разделения на команды разработчиков и операционного персонала, но теперь абсолютно нормально говорить об отдельных и централизованных «командах DevOps», занимающихся инструментарием развёртывания
Agile
Изначально означал отказ в разработке ПО от методологий и поведений, ассоциировавшихся с каскадной разработкой, принятие динамических и контекстных методологий и поведений; сейчас этот термин ассоциируется с сильно забюрократизированными и ритуализированными действиями
SRE
Изначально это разработанная Google дисциплина, нацеленная на привнесение практик разработки в эксплуатацию, делая упор на надёжность, автоматизацию и service-level objective (SLO); теперь превратилась в производственную функцию, обычно без культурного сдвига в сторону автоматизации и общего владения, как предполагалось поначалу
Observability (наблюдаемость)
Изначально это концепция из теории управления, применяемая к программным системам с упором на понимание внутренних состояний из внешних выводов; была принята современными инфраструктурными командами для выхода за пределы традиционного мониторинга. Однако после того, как поставщики начали продвигать коммерческие решения обеспечения наблюдаемости, она всё больше становится синонимом затратных дэшбордов, слишком большого количества метрик, разрастающихся инструментов, чаще запутывающих, а не помогающих отслеживать здоровье системы
Каждую из этих концепций придумали с благой целью, но со временем их суть менялась и искажалась в зависимости от того, хочет ли человек продвигать или критиковать их. Неудивительно, что при таких нечётких определениях дискуссии бесконечно ходят по кругу.
(В дополнение скажу, что мне хотелось бы отдать должное GitOps. Этот термин используется относительно стабильно, в основном благодаря исходному чёткому определению (к сожалению, исчезшему из Интернета вместе с создателями термина, компанией Weaveworks), поэтому его не так просто исказить в коммерческих целях.)
Проблема вторая: разговоры о микросервисах абстрактны и не связаны с целями бизнеса
Обсуждения микросервисов часто отвязаны от любых осязаемых целей бизнеса. Если задать вопрос «Какую задачу бизнеса мы решаем?», то часто вам будут давать подобные расплывчатые ответы:
Микросервисы улучшают масштабируемость. (Масштабируемость чего? Где у нас сейчас есть узкие места?)
Микросервисы делают команды более agile. (Как? Развёртывания медленные из-за архитектуры или из-за ограничений процесса?)
Микросервисы позволяют выполнять независимые развёртывания. (Это действительно обязательное требование для вашей команды, или просто приятное дополнение?)
Микросервисы снижают когнитивную нагрузку. (Для кого? И действительно ли это так, или они просто переносят сложность в другое место?)
Если прислушаться внимательно, то многие из таких обсуждений микросервисов на самом деле посвящены не архитектуре, а желанию работать в другой компании, где применяются передовые технологии и задачи теоретически интересны, а не погрязли в легаси и компромиссах реального мира.
Печальная реальность заключается в том. что многим командам, приступающим к миграции на микросервисы, лучше было бы оставаться на хорошо структурированном монолите, пока масштабирование действительно не потребует другого подхода. Автор книги Building Microservices Сэм Ньюман часто предупреждает, что большинству организаций не следует браться за микросервисы, если на то нет убедительной причины.
Повторюсь, будет гораздо лучше перестать говорить о микросервисах. Надо начать говорить о снижении времени цикла, повышении надёжности и устранении конкретных узких мест бизнеса. Если разбиение системы на меньшие сервисы — лучший способ добиться этих результатов, то пусть так, но споры архитекторов о количестве ангелов на кончике иглы микросервисах — точно не способ решения.
Проблема третья: микросервисы без организационных изменений бессмысленны
Ещё одно важное следствие того, что инженеры обсуждают микросервисы в отрыве от контекста бизнеса, заключается в том, что они чаще всего игнорируют организационные изменения, требующиеся для того, чтобы микросервисы заработали.
Микросервисы не работают в вакууме. Они требуют такого структурирования команд, чтобы те поддерживали их. Это означает:
Наличие кроссфункциональных автономных команд, полностью отвечающим за сервисы. Если команда по-прежнему зависит от централизованных узких мест (например, от одной команды DBA), то микросервисы не обеспечат обещанных преимуществ
Децентрализованный процесс принятия решений, чтобы избежать лишней траты ресурсов на координацию. Если релизы продолжат требовать длительных процессов согласования, то независимость сервисов — это иллюзия
Зрелая культура DevOps с CI/CD, мониторингом и практиками управления инцидентами, способными справиться со сложностью распределённых систем
Если ваша организация не готова вносить такие изменения, то микросервисы лишь ухудшат положение. Они добавят техническую сложность, сохранив всю старую организационную неэффективность. Если вкратце, технологии должны следовать за потребностями бизнеса, а не наоборот.
Большинство обсуждающих микросервисы не принимает это во внимание или не понимает, насколько это сложно. Если ваш бизнес вырос до приличных размеров, изменить организационную структуру намного сложнее, чем поменять архитектуру ПО. Именно поэтому маленькие стартапы могут пробовать разные подходы и так быстро менять архитектуру своего ПО: их организационную структуру можно изменить сразу, как только все согласятся на архитектурные изменения.
Когда в следующий раз кто-то заговорит о микросервисах…
Я хорошо осознаю иронию: всю статью я говорил о том, что больше не буду говорить о микросервисах. И на этом я закрываю рот и больше никогда не будут разговаривать о них.
