Что вообще такое микросервисы?

Пост за июль 2026 года на var0.xyz, написанный после того, как предыдущую заметку автора втянули в привычный спор о микросервисах на Hacker News. Рассуждение начинается с наблюдения: каждый с первого взгляда узнаёт микросервис, но почти никто не может внятно объяснить, что именно делает его таковым.

Определение, которого ни у кого нет

Насколько мало это микро? Одна зона ответственности или две? Тысяча строк или десять тысяч? Количество развёртываний в день? Автор считает, что ни один из этих вариантов не даёт убедительного ответа, потому что все они пытаются измерить границу не в тех единицах. Годы попыток определить микросервисы через технические свойства привели лишь к свойствам, которые остаются размытыми. Это и есть главный признак: граница проходит вовсе не в коде.

Любая техническая причина решается внутри монолита

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

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

Чем приходится платить за автономию

Взамен вы отдаёте централизацию. Внутри монолита на вопросы "какие зависимости мы поставляем" и "используется ли ещё этот код где-либо" обычно может ответить статический анализ. Разнесите тот же код по тридцати сервисам, и оба вопроса превратятся в исследовательские проекты без надёжного метода решения.

Дальше начинаются подмены, которые в посте перечислены без лишнего драматизма: общение между функциями превращается в общение по сети, вызов метода - в HTTP-запрос, ошибка компилятора - в сбой во время выполнения. Задержки, повторные попытки, частичные отказы, сериализация, согласованность - весь каталог проблем распределённых систем переезжает внутрь вашего приложения. Ничего удивительного в этом нет, и в этом вся суть. Такова цена гибкости, а не ошибка в реализации.

То же наследие проявляется и за пределами архитектуры. log-distributed-llms приводит довод, что распараллеливание работы по независимым LLM-агентам - это задача распределённого консенсуса со всеми вытекающими теоремами о невозможности, а не мелкая деталь координации, которую сгладят более продвинутые модели. Разделение системы между командами выставляет ровно такой же счёт. Конкретные примеры быстро накапливаются: jwt-for-sessions отмечает, что проверка между сервисами без общего хранилища сессий - единственный случай, когда JWT действительно оправдывает свою сложность, и этот случай существует только потому, что систему кто-то разделил.

Цена, которой нет на диаграммах

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

Изменение API перестаёт быть рефакторингом и становится переговорами. Потребителей нужно предупреждать заранее. Версионирование становится обязательным. Старые версии живут до тех пор, пока не мигрируют абсолютно все. Изменение в базе данных, которое раньше было обычным коммитом, превращается в согласованную работу нескольких групп людей. Как сформулировано в посте: "Распределённым становится не только ПО. Принятие решений теперь тоже распределённое".

Осознанный выбор

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

Это полезный противовес тому, как обычно подаются архитектурные паттерны. porto-sap предлагает путь миграции от монолита к микросервисам, где Container настолько самодостаточен, что его выделение сводится в основном к изменениям в сборке и развёртывании. В свете аргументации var0 такое обещание решает лишь ту половину задачи, которая никогда и не была сложной. Выделение аккуратного Container'а никак не снимает вопрос о том, что результату нужна команда владельцев, а затраты на переговоры появятся неизбежно, как бы красиво ни выглядела граница в первый день.

metapatterns, справочник Дениса Полторака (Denys Poltorak), распределяющий сотни архитектурных паттернов по менее чем 20 метапаттернам, относит эту архитектуру к Services и Layered Services.

Автор также опубликовал видеоверсию тех же рассуждений: https://youtu.be/aacClo78H-8.