🤦‍♂️ Я забил на споры о микросервисах с архитекторами, и вот почему

Надоели бесконечные дискуссии о микросервисах, которые ни к чему не приводят? Один разработчик рассказывает, почему решил послать все это куда подальше, и что из этого вышло.

Опять двадцать пять! На прошлой неделе это снова случилось. Сижу я на обсуждении архитектуры, как вдруг один из коллег-архитекторов с жаром завел очередную шарманку про микросервисы. Не прошло и пары минут, как у всех присутствующих взгляды потухли — мы увязли по уши в абсурдной дискуссии о том, что должно было быть просто средством достижения цели, но каким-то образом превратилось в самоцель. И тут меня осенило: хватит с меня. Я твердо решил больше не обсуждать микросервисы с архитекторами. Почему? Да потому что толку от этих разговоров — как от козла молока.

Все мое раздражение сводится к трем проблемам:

1. Никто не может прийти к общему знаменателю в определении «микросервиса»
2. Разговоры о микросервисах витают в облаках, почти не касаясь реальных бизнес-задач
3. Внедрять микросервисы без изменений в организации — пустая трата времени

Проблема первая

Что такое микросервис? Кажется, никто не знает

Начнем с самого очевидного: в индустрии до сих пор нет четкого определения микросервиса. Из-за этого разработчики часто спорят, подразумевая совершенно разные вещи.

Существующие трактовки

🔹 Минималистичный подход. «Сервис должен быть крошечным. Сейчас даже сотня строк кода — это уже многовато» — Фред Джордж на RubyConf Barcelona

🔹 Правило двух пицц. Не столько определение микросервиса, сколько мем от Amazon про идеальный размер команды: должна наесться двумя пиццами (5-8 человек). Подразумевается, что под каждый микросервис нужна отдельная команда.

🔹 Принцип одного разработчика. «Если для разработки и поддержки требуется больше одного программиста — какой же это микросервис?» — Фред Джордж, GOTO 2016

🔹 Технические определения:

• Автономный изолированный процесс.
• Docker-контейнер в Kubernetes-кластере.
• Сервис с собственной базой данных.

🔹 Концептуальный подход. «Представьте себе миниатюрный компьютер, который работает только с нужной ему моделью бизнес-процессов» — Дэниел Терхорст-Норт

Ситуация напоминает притчу о слепых мудрецах, которые пытаются описать слона: каждый говорит о своей части, и формально все правы, но целостного понимания нет ни у кого.

После множества подобных дискуссий я пришел к радикальному решению: просто перестал использовать термин «микросервисы». Если понятие вызывает столько путаницы — возможно, пора от него отказаться.

Вместо споров о терминологии продуктивнее обсуждать конкретные задачи:

1. Как ускорить релизы новых функций.
2. Как снизить связанность компонентов.
3. Как масштабировать отдельные части системы.

По сути, микросервисы (как бы мы их ни определяли) — это не самоцель, а всего лишь инструмент для решения конкретных бизнес-задач.

Бардак в терминологии

Дело не только в микросервисах — это системная проблема всей нашей индустрии. Мы любим разбрасываться громкими словами, которые звучат внушительно, но для каждого означают что-то свое.

Давайте посмотрим на историю некоторых популярных терминов:

📦 DevOps

Изначально это был манифест против разделения команд разработки и эксплуатации. А во что превратилось? В отдельные централизованные «DevOps-команды», которые занимаются только настройкой инструментов развертывания. Приехали!

🔄 Agile

Задумывался как отказ от закостенелых методологий водопадной разработки в пользу гибких, учитывающих контекст подходов. А превратился во что? В бюрократическую машину с ритуалами ради ритуалов.

👨🛠 SRE

Google придумал эту дисциплину, чтобы привнести инженерные практики в эксплуатацию, сделав упор на надежность, автоматизацию и целевые показатели качества сервиса (SLO). А что получилось? Обычный ребрендинг отдела эксплуатации, без той самой культуры автоматизации и общей ответственности, ради которой все затевалось.

👀 Observability

Началось все с применения теории управления к программным системам — возможности понимать внутреннее состояние системы по внешним признакам. Инфраструктурные команды подхватили идею, чтобы выйти за рамки простого мониторинга. А чем закончилось? Вендоры навязали свои дорогущие решения, и теперь это синоним бесконечных дашбордов, метрик ради метрик и зоопарка инструментов, которые не проясняют, а только затуманивают реальное состояние системы.

Каждый термин начинался с четкого смысла, но со временем превратился в пустышку, которую каждый натягивает на свои хотелки или критику. Неудивительно, что при такой каше в определениях наши разговоры ходят по кругу!

Кстати, отдельное спасибо GitOps. Этот термин, пожалуй, единственный сохранил свое первоначальное значение — во многом благодаря четкому определению от создателей (которое, увы, исчезло из интернета вместе с компанией Weaveworks). Его оказалось сложно извратить в коммерческих целях.

🤔 Проблема вторая: разговоры о микросервисах — разговоры ни о чем

Эта проблема вытекает из первой — обсуждения микросервисов оторваны от земли и реальных бизнес-задач. Стоит только спросить: «Какую конкретную бизнес-проблему мы пытаемся решить?», как в ответ услышишь что-нибудь расплывчатое вроде:

1. «Микросервисы улучшают масштабируемость!» (Чего именно? Где сейчас узкое горлышко?).
2. «С микросервисами команды работают гибче!» (Каким боком? Может, проблема не в архитектуре, а в бюрократической волоките?).
3. «Микросервисы позволяют обновлять части системы независимо!» (А это действительно нужно, или просто хотелки?).
4. «Микросервисы снижают сложность восприятия!» (Для кого? Реально снижают или просто перекладывают с больной головы на здоровую?).

Если копнуть поглубже, большинство таких разговоров — это не про архитектуру, а про розовые мечты о работе в другой компании. Там, где технологии — последний писк, задачи — одна интереснее другой, и нет никаких legacy-систем и скучной рутины реального мира.

Горькая правда в том, что многим командам, которые сломя голову бросаются в микросервисы, лучше бы остаться с добротным монолитом. По крайней мере, пока реальные потребности в масштабировании не припрут к стенке. Даже Сэм Ньюман (написавший «библию» микросервисной архитектуры «Building Microservices») не устает повторять: не лезьте в микросервисы без веской причины.

И опять же мой совет — хватит талдычить про микросервисы. Давайте обсуждать то, что действительно важно:

1. Как быстрее выкатывать новые фичи.
2. Как быстрее выкатывать новые фичи.
3. Как решить насущные бизнес-проблемы.

Если разбиение системы на мелкие сервисы — лучший способ достичь этих целей, прекрасно. Но бесконечные споры архитекторов о том, сколько микросервисов должно быть в системе — это дорога в никуда.

🏗️ Проблема третья: внедрять микросервисы без перестройки организации— пустая трата времени

Когда технические обсуждения оторваны от бизнес-контекста, случается типичная ошибка: инженеры забывают, что для успеха микросервисов необходимо менять саму структуру организации.

Микросервисы не существуют сами по себе. Для их эффективной работы команды должны быть выстроены особым образом:

1. Нужны многопрофильные самостоятельные команды, которые ведут свои сервисы от идеи до продакшена. Если все упирается в общие узкие места (скажем, в единую команду администраторов баз данных) — все прелести микросервисов пойдут прахом.
2. Решения должны приниматься на местах, без бесконечных согласований. Если для выпуска обновления по-прежнему нужно собрать десять подписей — разговоры о независимости сервисов так и останутся сказками.
3. Требуется зрелая DevOps культура: отлаженный процесс непрерывной разработки и развертывания (CI/CD), грамотный мониторинг и четкий порядок работы с инцидентами — все то, что поможет справиться со сложностью распределенных систем.

Если ваша организация не готова к таким переменам, микросервисы только усугубят положение. К старым организационным проблемам добавится еще и техническая головная боль. Проще говоря, технологии должны работать на бизнес, а не наоборот.

Большинство поклонников микросервисов либо не осознают этого, либо недооценивают сложность таких изменений. Перекроить структуру компании куда сложнее, чем поменять архитектуру приложения — особенно когда компания уже выросла из коротких штанишек. Вот почему небольшие команды могут так легко развернуться на 180 градусов и поменять архитектуру на ходу: когда все решения принимаются в одном чате, договориться о переменах гораздо проще.

Что думает сообщество о микросервисах?

«Распределенный монолит» и другие архитектурные грехи

Один из самых популярных комментариев на Reddit называет такие системы «распределенным монолитом». Это определение получило широкий отклик в сообществе, с вариациями вроде «макросервис» и «модульный монолит».

Пользователи отмечают, что настоящие микросервисы должны быть независимыми, но на практике это редкость. Часто так называемые «микросервисы» требуют одновременного развертывания из-за взаимных зависимостей, что противоречит самой идее микросервисной архитектуры.

Практические соображения

Некоторые комментаторы отмечают, что разделение на микросервисы может быть полезным для инфраструктуры, если функциональное разделение продумано. Например, разделение на сервисы для GET и POST запросов позволяет по-разному масштабировать компоненты с разными требованиями к ресурсам.

Однако другие возражают, что такой подход создает проблемы с общей бизнес-логикой и может быть примером переусложнения.

Технический долг и организационные проблемы

Один из комментаторов предупреждает, что то, что кажется веселым сейчас, может превратиться в технический долг позже. Микросервисы хороши для быстрой разработки и четкого определения зон ответственности, но могут создавать проблемы при реорганизации команд или когда сервис долго не обновлялся.

Другой пользователь называет микросервисы «самым переиспользуемым архитектурным паттерном наших дней», отмечая, что они решают организационные проблемы, но часто используются не по назначению для создания «переусложненных мусорных приложений».

Когда «весело» — это тревожный знак

Самый популярный комментарий в обсуждении предупреждает: «Каждый раз, когда я видел, что кто-то классифицирует что-то как "веселое" в этой индустрии, позже это оказывалось ужасным военным преступлением».

Продолжение этой мысли: «Скучное — это хорошо, значит, оно простое, интуитивно понятное и без сюрпризов». Другие пользователи подхватывают эту идею, называя микросервисы «FUN — Fucking Unnecessary Nonsense» (чертовски ненужная ерунда).

Когда действительно нужны микросервисы?

Микросервисы решают проблему масштабирования, которой у большинства компаний просто нет. Их преимущество в том, что части приложения с разной нагрузкой могут иметь соответствующую инфраструктуру, повышая эффективность. Но это актуально только после определенного масштаба.

С точки зрения организации они могут стать кошмаром для поддержки и приводить к дублированию работы. Также возникают проблемы с документацией.

Простой вывод: если вам не нужно масштабировать независимые компоненты, микросервисы вам не нужны.