Ваши микросервисы - карго-культ. Как IT-индустрия строит аэродромы из бамбука

Каждый день я вижу восторженные статьи: «Мы переехали на микросервисы и стали богами». А я смотрю на это и вижу стадо леммингов, радостно бегущих к обрыву. В этой статье я объясню на пальцах, почему 99% компаний, внедряющих микросервисы, занимаются карго-культом и просто меняют одну большую проблему на пятьдесят маленьких, разбросанных по сети.

Можете считать это токсичным мнением, но оно основано на опыте. Привет, я Руслан. За последние 20 лет я побывал хирургом, реаниматологом и, чего уж скрывать, патологоанатомом для десятков IT-проектов. Насмотрелся всякого.

Больше таких разборов, с меньшим количеством цензуры, я публикую в своем Telegram-канале "Токсичный (it) архитектор". А теперь - к сути.

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

Зато модно.

Вы вообще знаете, что такое карго-культ? Объясню на пальцах.

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

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

Google и Netflix показали вам свои «самолеты». А вы, как те туземцы, бросились лепить свои бамбуковые аэродромы. Разворачиваете Kubernetes там, где хватило бы одного bash-скрипта. Внедряете Kafka, чтобы передавать три сообщения в час. Копируете форму, не понимая сути.

Вы думаете, Netflix успешен, потому что у них микросервисы? Нет. У них микросервисы, потому что они, черт возьми, Netflix. У них тысячи инженеров и бюджеты, которые вам и не снились. Их архитектура решает их организационные проблемы.

А вы? Какие проблемы решаете вы?

Справедливости ради, есть тот самый 1% случаев, когда микросервисы - это осознанная необходимость. Это инструмент для компаний, которые задыхаются от организационной, а не технической сложности. Когда у вас 30+ независимых команд, которые должны релизиться, не ожидая друг друга. Когда разные части системы требуют принципиально разного стека технологий или профиля нагрузки. Если это не про вас - вы строите аэродром из бамбука.

Давайте честно, без булшита. Проверьте симптомы. Если узнали себя хотя бы в одном пункте - у меня для вас плохие новости.

1. Вы получили распределенный монолит. 50 сервисов, которые ходят в одну и ту же базу и деплоятся только все вместе. Гениально. Вы просто заменили надежный вызов функции на лотерею по сети.

2. Отладка превратилась в ад. Раньше у вас был стектрейс. Теперь - седой тимлид, три дашборда в Grafana и ритуальные танцы с бубном в попытке понять, почему запрос от сервиса А до сервиса Б вчера доходил, а сегодня - нет.

3. Разработчики превратились в YAML-инженеров. Они забыли, как писать бизнес-логику. Они пишут Helm-чарты и Dockerfile-ы. Они стали экспертами в отступах, а не в алгоритмах.

4. «У меня локально все работало» стало гимном вашей команды. Поднять всю эту распределенную прелесть на одной машине невозможно. Каждый коммит в main - это русская рулетка.

Начинать с хорошо спроектированного, модульного монолита - это не просто нормально. В 99% случаев это единственно правильное решение. Монолит - это предсказуемость. Это простота. Это здравый смысл.

И под 'модульным монолитом' я не имею в виду свалку кода в одном репозитории. Я говорю про архитектуру, где сервисы существуют как логические модули с четкими границами (Bounded Contexts из DDD, если вам так понятнее) внутри одного приложения. Они общаются через понятные внутренние API, а не через лотерею по сети. Такой монолит легко поддерживать, легко тестировать, и, если однажды вы дорастете до масштабов Netflix, его можно будет безболезненно распилить по этим самым границам. Но не раньше.

Микросервисы - инструмент для решения проблем организационного масштаба. Когда у вас 500 разработчиков коммитят в одну кодовую базу. У вас есть 500 разработчиков? Нет? Тогда какого черта?

Так что перед тем, как снова произнести это модное слово, ответьте себе на пару вопросов. Только честно, как на допросе:

❓ У вас есть DevOps-инженер, который не плачет по ночам?

❓ Ваша система мониторинга видит дальше собственного носа?

❓ Вы можете определить границы домена, не устроив поножовщину между отделами?

Если хоть на один вопрос ответ «нет» - закрывайте эту статью и идите работать. Строить нормальный, работающий продукт.

Мне плевать, монолитный он будет или нет. Лишь бы работал.

---

P.S. Эта статья - лишь вершина айсберга. Если вам зашел такой подход, и вы не боитесь честного взгляда на IT-индустрию, подписывайтесь на мой Telegram-канал "Токсичный (it) архитектор". Там я делюсь короткими и токсичными наблюдениями, которым не место в больших статьях.