Распил монолита в 2026: а может, не надо? Как AI переворачивает закон Конвея

Десятилетие индустрия повторяла мантру: «монолит — плохо, микросервисы — хорошо». Мы честно дробили, нанимали команды на каждый сервис, строили service mesh, мучились с distributed tracing. А потом пришёл AI-ассистент, которому не нужно держать в голове весь монолит, чтобы менять любую его часть — и возник неудобный вопрос: а зачем мы вообще это делали?

В 2025-м компании начали массово внедрять AI-ассистентов в разработку — и обнаружили, что архитектурные аксиомы, казавшиеся незыблемыми, перестают работать.

Зачем вообще дробят монолиты: шесть канонических причин

Прежде чем заявлять, что что-то «не нужно», стоит перечислить, зачем это делалось. Вот шесть причин, которые приводят в каждом втором докладе на конференциях.

Причина 1: Закон Конвея. Организации проектируют системы, которые копируют структуру их коммуникаций. Пять команд — пять сервисов. Не потому, что так технически лучше, а потому, что иначе эти пять команд не могут работать параллельно без конфликтов в кодовой базе.

Причина 2: Когнитивный предел человека. Один разработчик не может удержать в голове 500 тысяч строк кода. Маленький сервис — маленький контекст — можно разобраться за неделю. Это, пожалуй, самый честный аргумент за микросер��исы.

Причина 3: Независимый деплой. Команда A не ждёт команду B. У каждого сервиса свой pipeline, свой release cycle. Релиз фичи в платёжном модуле не блокирует релиз в поисковом движке.

Причина 4: Изоляция отказов. Падение одного сервиса не роняет всё остальное. Circuit breakers, bulkheads, graceful degradation — весь Netflix-стек построен вокруг этой идеи.

Причина 5: Независимое масштабирование. Hot path масштабируется отдельно. Поисковый движок, перемалывающий терабайты данных, живёт на своём кластере и не конкурирует за ресурсы с CRM-модулем.

Причина 6: Технологическое разнообразие. Go для latency-critical сервисов, Python для ML-pipeline, Rust для парсинга — каждый инструмент для своей задачи.

Запомните этот список. Сейчас мы пройдём по каждому пункту и оценим, что происходит, когда в уравнение добавляется AI.

По данным CNCF 2025, 42% организаций, внедривших микросервисы, сейчас консолидируют сервисы обратно в крупные деплойменты. Доля service mesh упала с 18% до 8% за два года. Когда инструментарий, созданный для микросервисов, теряет половину adoption — это сигнал архитектурной усталости.

— ByteIota: Modular Monolith — 42% Ditch Microservices in 2026

Что AI делает с каждой причиной

Причина 1: Закон Конвея → следствие снимается

Закон Конвея описывал мир, в котором единственные каналы передачи контекста между людьми — митинги, документация, Slack-сообщения. Структура коммуникаций определяла структуру кода, потому что люди не могли эффективно работать с чужими модулями без прямого общения с их авторами.

AI-ассистент с правильно организованным контекстом (structured context — об этом подробнее ниже) не нуждается в митинге, чтобы понять чужой модуль. Он читает context.md, decisions-log.md, api-surface.md — и работает. Десять человек могут работать над одним репозиторием, каждый со своим AI-ассистентом, получающим контекст из файлов, а не из головы соседа.

Вердикт: закон Конвея остаётся верным — но AI переворачивает его практический вывод. Организации по-прежнему проектируют системы по структуре коммуникаций, только теперь в эту структуру входит AI, способный понимать любой модуль. Следствие — дробить по оргструктуре — снимается.

Недавний анализ от Infralovers формулирует это как «Conway’s AI-Inverse»: «AI сжимает команды. Закон Конвея говорит: маленькие команды строят монолиты. Значит, AI двигает архитектуру в сторону монолита.» Мартин Фаулер подтверждал: «Команда из 12-20 человек может общаться глубоко и неформально, и закон Конвея предсказывает для них монолит.»

— Infralovers: Conway’s AI-Inverse (март 2026)

InVision — практический пример обратного Конвея. Когда команда, поддерживавшая микросервисы, сократилась, Principal Engineer Ben Nadel начал системно мерджить сервисы обратно в монолит: «Каждый свёрнутый микросервис экономил примерно $20 000 в год — на тестовые и production-окружения.»

— Ben Nadel: Why I’ve Been Merging Microservices Back Into The Monolith

Причина 2: Когнитивный предел → снимается

Это связано с первым пунктом, но стоит проговорить отдельно. Человеческий мозг удерживает 7±2 объекта. Монолит из 30 модулей — это 30 контекстов, каждый с десятками edge cases.

Для AI этого предела не существует — но не потому, что агент загружает 500K строк в контекст. Современные AI-агенты работают иначе: они нарезают кодовую базу на релевантные куски — architecture-overview.md (200 строк), booking/context.md (100 строк), нужные фрагменты кода — и собирают компактный, информативный контекст. Агенту не нужно помнить всё — ему нужно уметь быстро найти и понять нужное.

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

Вердикт: AI снимает когнитивный предел как причину дробления.

Причина 3: Независимый деплой → снимается частично

Это реальная инженерная потребность, но она не обязательно решается дроблением на сервисы. Feature flags, trunk-based development, модульная сборка с раздельным деплоем артефактов из монорепозитория — всё это работает без микросервисов.

Более того, «независимый деплой» микросервисов — это иллюзия в 80% случаев. Если сервис A зависит от API сервиса B, вы не можете деплоить A независимо — вам нужна координация версий API. Distributed monolith — это не мем, это реальность большинства «микросервисных» архитектур.

Вердикт: решается другими средствами (feature flags, monorepo). AI косвенно помогает (генерирует конфигурации, следит за совместимостью).

Shopify — живое доказательство: 2.8 миллиона строк Ruby, 500 000 коммитов, тысячи инженеров — и один деплоймент. Вместо дробления на сервисы они создали Packwerk — инструмент статического анализа, который отклоняет PR, нарушающие границы модулей. «Мы хотели увеличить модулярность системы как у микросервисов, сохранив единый деплоймент как у монолита.»

— Shopify Engineering: Under Deconstruction
— Shopify Engineering: Enforcing Modularity with Packwerk

Причина 4: Изоляция отказов → остаётся

Вот здесь AI ничего не меняет. Если ваш поисковый движок упал, а платёжная система должна продолжать работать — это физическая изоляция процессов. Никакой structured context не поможет, если всё крутится в одном процессе и OOM-killer прибивает его целиком.

Но заметьте: для изоляции отказов не нужны микросервисы. Достаточно 3-5 крупных, разнесённых по критичности деплойментов. Поисковый движок — отдельно. Платежи — отдельно. Всё остальное — вместе. Это не 30 сервисов с 30 pipeline’ами. Это 3-4 артефакта.

Вердикт: остаётся, но требует 3-5 крупных деплойментов вместо 30 микросервисов.

Причина 5: Масштабирование → остаётся

Аналогично: hot path нужно масштабировать отдельно. Рекомендательный движок, перемалывающий терабайты, не должен жить в одном пуле ресурсов с CRM.

Но опять: это вопрос деплоймента, не архитектуры кода. Модули могут жить в одном репозитории, разделять часть кода, и при этом деплоиться в разные runtime-среды.

Вердикт: остаётся, но решается на уровне инфраструктуры, не кода.

Причина 6: Технологическое разнообразие → остаётся, но переосмысляется

Один язык для бизнес-логики, другой для высоконагруженных сервисов, третий для критичных к latency компонентов — это легитимная потребность. Вот только AI-агент прекрасно работает со всеми тремя языками в рамках одной сессии. Structured context не привязан к языку — он описывает бизнес-логику, а не синтаксис.

Вердикт: технологическое разнообразие остаётся, но не требует организационного разделения.

Инверсия закона Конвея

Итого из шести причин:

• Две снимаются как практические ограничения (Конвей, когнитивный предел) — AI меняет коммуникационную структуру, и дробление по оргструктуре перестаёт быть необходимым

• Одна снимается частично (независимый деплой)

• Три остаются (изоляция отказов, масштабирование, технологическое разнообразие) — но все три требуют 3-5 крупных деплойментов, вместо 15-20 микросервисов

Классический Конвей: «Организации проектируют системы, которые копируют структуру их коммуникаций.»

Инвертированный Конвей с AI: «Организация с AI-усиленной коммуникацией может поддерживать архитектуру проще, чем её оргструктура.»

10-15 разработчиков + AI могут поддерживать систему, которая по классике требовала 8-10 команд и 10+ микросервисов — как 3-5 крупных модулей в одном-двух репозиториях.

Эта инверсия касается не только архитектуры кода, но и управления. @cless75 в концепции Vibe Management (ProIT Fest, 2025) показывает: если руководитель — «архитектор контекстов», то AI-усиленная коммуникация сжимает не только команды разработки, но и управленческие прослойки. Structured context для организации (миссия, OKR, decisions log) работает по тем же принципам, что и context.md для модуля: AI получает явный контекст и даёт осмысленные рекомендации — без RAG, без мегапромптов, без раздувания штата.

Structured Context: почему AI может держать весь монолит

Ключевое условие, при котором всё вышесказанное работает: AI должен понимать вашу кодовую базу не хуже, чем Senior-разработчик, проработавший в проекте три года. Для этого нужен structured context — явная архитектура знаний, а не надежда, что AI «разберётся сам».

Вот как это выглядит на практике:

/codebase-context
├── architecture-overview.md      ← граф модулей, зависимости, БД
├── decisions-log.md              ← не «что сделали», а «почему так решили»
├── known-issues.md               ← грабли, на которые наступали
│
├── /modules
│   ├── booking/
│   │   ├── context.md            ← что этот модуль делает, границы
│   │   ├── decisions-log.md      ← локальные архитектурные решения
│   │   └── api-surface.md        ← internal API для других модулей
│   ├── payment/
│   │   └── ...
│   ├── smart-routes/
│   │   └── ...
│   └── gds-integrations/
│       ├── amadeus/
│       │   ├── api-reference.md  ← выжимка из документации
│       │   ├── known-quirks.md   ← «Amadeus возвращает дату в формате...»
│       │   └── error-handling.md
│       └── galileo/
│
├── module-dependencies.md        ← граф зависимостей между модулями
└── .cursorrules                  ← «при работе с booking, всегда проверь...»

Обратите внимание: это не документация в привычном смысле и не код. Это общий интерфейс между человеком и AI — structured context. Короткий, структурированный, с явными связями. Один context.md — 50-100 строк вместо 30-страничного Confluence. Человек пишет и читает эти файлы, AI потребляет их как контекст — оба работают с одним источником истины.

Это не теория — structured context уже стал отраслевым стандартом. Datadog, Sourcegraph и OpenAI продвигают AGENTS.md — открытый формат для навигации AI-агентов по монорепо: каждый подпакет имеет свой файл с инструкциями, агент обходит дерево каталогов и собирает контекст. «A well-maintained AGENTS.md is the contract between your codebase and the agent ecosystem.»

— DEV Community: Steering AI Agents in Monorepos with AGENTS.md

Теперь, когда Middle-разработчик открывает задачу в модуле booking, он пишет:

@architecture-overview.md @booking/context.md @booking/decisions-log.md
Нужно добавить поддержку мультивалютных бронирований.
Какие модули затронуты и какие ограничения учесть?

AI читает контекст и отвечает осмысленно — не потому, что он «умный», а потому, что ему дали правильный контекст. Он знает про зависимость booking → payment, про формат валют в GDS, про решение годичной давности «хранить всё в минорных единицах». Знает не потому, что обучен на вашем коде, а потому, что вы это явно написали в 50 строках markdown.

Что приходит на смену: AI-navigable modular monolith

Не монолит, не микросервисы, а что-то третье.

Физически — 3-5 крупных деплойментов, разделённых по критериям изоляции и масштабирования:

• Search Engine (hot path, отдельное масштабирование)

• Core Business Logic (booking, payment, routes — один артефакт)

• Data Pipeline (обработка больших объёмов данных — отдельная инфраструктура)

• Public API / BFF (фасад для клиентов и партнёров)

Критик скажет: 4 отдельных деплоймента — это макросервисы, а не монолит. Distributed-проблемы никуда не делись. Верно — но сложность распределённой системы растёт не линейно. 4 деплоймента — 6 возможных связей, 20 микросервисов — 190. Это разница в 30x в количестве точек отказа, версионируемых контрактов и distributed traces. При 4 деплойментах один человек держит в голове все связи; при 20 — не может никто, и вы снова решаете организационную проблему организационными средствами.

Но главное — причина разделения другая. Микросервисы дробят по организационным границам: команда = сервис = деплоймент. Здесь деплойменты разнесены по инфраструктурным критериям: разные SLA, разные паттерны масштабирования, разные runtime-требования. Внутри каждого — function calls, shared types, один процесс. Между ними — да, network boundary, но таких границ 3-4, а не 50.

Логически — модули внутри каждого деплоймента с чёткими границами:

• Domain modules с явными internal API

• Shared database — можно, если модули общаются через internal API, а не лезут в чужие таблицы напрямую

• Function calls вместо network calls — на порядки быстрее и надёжнее

Навигация — structured context вместо организационного разделения:

• Каждый модуль имеет context.md и api-surface.md

• AI-агент видит весь контекст: работая с booking, он «знает» про payment и smart-routes

• Границы модулей — логические (domain boundaries), а не физические (network boundaries)

Экономика сравнения

Допустим, вы — travel-tech компания с командой разработки человек 50. Два пути:

Разница: порядка 75-85M рублей в год. И это без учёта скрытых издержек: distributed debugging, eventual consistency bugs, network latency, operational complexity Kubernetes-кластера с 15-20 сервисами.

Это не умозрительные цифры. Replit CEO Amjad Masad: «Our internal tools team, just 3 people, built in months what would have been a multi-year project for a traditional team of 15-20.» Венчурный капиталист Elad Gil: «The actual engineering team size needed for most software products has collapsed by 5-10×.»

— Replit’s AI Coding Platform
— The New Minimum Viable Team

Цена дробления, о которой не говорят

Каждая граница между микросервисами — это не бесплатная абстракция. Это конкретные инженерные затраты.

Network call вместо function call. Вызов функции в том же процессе: наносекунды, гарантированная доставка, типизированные аргументы. HTTP-вызов между сервисами: миллисекунды, может не дойти, нужна сериализация/десериализация, retry logic, circuit breaker, timeout management. Каждый network call — это код, который может сломаться, и будет ломаться в 3 часа ночи.

Distributed debugging. «Бронирование не работает» в монолите — это стектрейс. В микросервисах — это цепочка из 5 сервисов, и ошибка может быть в любом. Distributed tracing (Jaeger, Zipkin) помогает, но это ещё одна система, которую нужно поддерживать.

Eventual consistency. Модули в одном процессе могут использовать одну транзакцию БД. Сервисы — нет. Saga pattern, компенсирующие транзакции, idempotency keys — это недели разработки на то, что в монолите решается одним BEGIN...COMMIT.

Насколько это больно на практике, описано в статье «Production Bugs No One Teaches You»: «Большинство инженеров думают, что eventual consistency — это просто лаг. На деле это может привести к перманентной некорректности данных» — бизнес-логика принимает решения на inconsistent-данных, а к моменту расследования окно inconsistency уже закрылось.

— Medium: Eventually Consistent Doesn’t Mean Eventually Correct

API versioning. Сервис A хочет изменить API. Сервис B зависит от старой версии. Нужна стратегия миграции, период параллельной поддержки, координация деплоя. В монолите — рефакторинг с IDE, один коммит.

Operational overhead. 20 сервисов — это 20 Dockerfile, 20 CI pipeline’ов, 20 Helm-чартов, 20 наборов health-checks и alerts. DevOps-команда из 3-5 человек только на поддержку инфраструктуры.

Конкретные цифры от практиков: стартап разбил приложение на 47 микросервисов — деплой вырос с 12 минут до 6 часов, продуктивность упала на 60%, три аварии в production, $140K потрачено впустую. Другой стартап — $500K на Spring Boot-микросервисы: 12 месяцев создания технического долга и 12 месяцев его выплаты. Облачный счёт третьей компании вырос с $2K до $18K/мес после миграции.

— $140K wasted on 47 microservices
— The $500K Microservices Mistake
— Cloud bill from $2K to $18K/month

Всё это — реальная цена, которую платит каждая компания с микросервисами. Вопрос: стоит ли платить эту цену, если AI снял главные причины дробления?

Когда всё-таки дробить

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

Сценарий 1: физически разные SLA. Если ваш API поиска должен отвечать за 50 мс, а CRM может тормозить до 2 секунд — это разные runtime-среды. Нельзя оптимизировать GC и memory allocation для обоих одновременно.

Сценарий 2: принципиально разные паттерны масштабирования. Поисковый движок — CPU-bound, latency-critical, масштабируется stateless-репликами. Data pipeline — throughput-oriented, масштабируется партиционированием данных. Ресурсные профили несовместимы: одному нужны десятки лёгких подов с быстрым откликом, другому — единицы тяжёлых воркеров с большим объёмом памяти и диска.

Сценарий 3: команды в разных часовых поясах с нулевым пересечением. Если ваша московская команда и кипрская команда работают над одним кодом и никогда не пересекаются — structured context может быть недостаточно. Но даже здесь решение скорее в модулях с чёткими границами, чем в HTTP между ними.

Заметьте: ни один из этих сценариев не требует 20 микросервисов. Они требуют 3-5 крупных, разнесённых по конкретным техническим критериям.

Практический переход: от «распиливаем дальше» к «укрупняем обратно»

Если вы — компания, которая уже начала распил монолита и нанимает людей на каждый новый сервис, вот конкретный план.

Шаг 1: Остановитесь и спросите «зачем». Для каждого планируемого нового сервиса задайте вопрос: какую из шести причин этот сервис решает? Если ответ — «закон Конвея» или «когнитивный предел» — возможно, дешевле создать structured context, чем новый сервис.

Шаг 2: Постройте structured context для существующего кода. Прежде чем дробить дальше, попробуйте другой подход: опишите каждый модуль монолита в context.md. Потратьте неделю на документирование архитектурных решений. Это вложение окупится независимо от того, какой путь вы выберете.

Шаг 3: Проведите эксперимент. Возьмите одну задачу, которую планировали решить выделением нового сервиса. Попробуйте решить её модулем внутри монолита + structured context + AI. Сравните time-to-market, стоимость поддержки, количество production incidents.

Шаг 4: Переоцените целевую архитектуру. Возможно, ваша целевая архитектура — не 20 микросервисов, а 4 крупных модуля с AI-навигацией. Это меняе�� план найма, бюджет на инфраструктуру и timeline трансформации.

Типичные контраргументы

«Но Google/Netflix/Amazon используют микросервисы!»

Они используют микросервисы для систем с миллионами RPS и тысячами инженеров. Если у вас 30-50 разработчиков и десятки тысяч RPS — вы не Google. Архитектура Netflix решает проблемы Netflix, а не ваши.

Jason Warner, бывший CTO GitHub: «I’m convinced that one of the biggest architectural mistakes of the past decade was going full microservice. 90% of companies don’t need microservices.»

— HackerNews discussion

Martin Fowler: «Almost all successful microservice stories have started with a monolith that got too big and was broken up, while almost all cases where a system was built as a microservice system from scratch have ended up in serious trouble.»

— Martin Fowler: Monolith First

Фаулер визуализировал это в диаграмме Microservice Premium: при низкой сложности системы микросервисы снижают продуктивность из-за накладных расходов, и лишь после определённого порога начинают окупаться. AI сдвигает этот порог ещё дальше вправо — потому что снимает когнитивные ограничения, которые раньше заставляли дробить.

«AI галлюцинирует, ему нельзя доверять архитектуру»

Правильно. AI не выбирает за вас между монолитом и микросервисами — архитектурные решения принимает человек. Но AI делает больше, чем просто ускоряет эти решения: он снимает когнитивные ограничения, которые вынуждали дробить. Structured context — явная архитектура знаний, которую вы создаёте и контролируете. AI работает в заданных вами рамках, но внутри них заменяет то, что раньше мог дать только человек с тремя годами в проекте: понимание контекста, связей и истории решений.

«Модулярный монолит — это то, что мы имели 10 лет назад. Мы от этого ушли.»

Мы ушли от этого, потому что люди не могли поддерживать модулярность без физического разделения. Границы модулей нарушались, потому что «быстрее написать прямой запрос в чужую таблицу, чем через API». AI меняет это уравнение: structured context + .cursorrules обеспечивают discipline, которую раньше обеспечивала только сеть.

Ирония: даже Istio — проект, созданный для управления микросервисами — не смог поддерживать микросервисную архитектуру собственного control plane. В 2020-м Pilot, Citadel, Galley и Mixer были свёрнуты в единый бинарник istiod. Christian Posta написал: «The complexity of the microservices approach proved to not deliver the value or goals it intended. On the contrary, it worked against those goals.»

— Christian Posta: Istio as an Example of When Not to Do Microservices

«А как же независимые команды? Микросервисы дают автономию.»

Автономию даёт не HTTP между сервисами. Автономию дают чёткие контракты на границах модулей. api-surface.md работает не хуже OpenAPI-спецификации, при этом не требует network overhead.

Заключение: архитектура как отражение инструментов, а не людей

Закон Конвея не перестал быть верным. Он стал шире. Организации проекти��уют системы, которые копируют структуру их коммуникаций — включая коммуникации с AI. Если AI — полноценный участник вашей «коммуникационной структуры», способный понимать контекст любого модуля, то потребность в физическом разделении снижается.

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

Прогноз на ближайшие 2-3 года: компании, которые остановят бесконтрольный распил и инвестируют в structured context + AI-навигацию, получат кумулятивное преимущество: меньше людей (2-3×), меньше инфраструктуры, нет distributed debugging и eventual consistency — и радикально быстрее time-to-market.

На Хабре — живой кейс: AGIMA начинали стартап на микросервисах для быстрой проверки гипотез, но при переходе к продукту обнаружили, что «преимущества микросервисов не давали значимых плюсов, а недостатки существенно влияли на качество и скорость разработки». Решение — гибрид: доменные модули внутри одного проекта, а отдельные сервисы остались только для аналитики, файлового хранилища и нотификаций.

— Habr: От микросервисов к монолиту — маршрут построен

А тем, кто только начинает новый проект: начните с монолита. Но не с бесструктурного кома — а с AI-navigable modular monolith, где каждый модуль имеет свой context.md, каждое решение задокументировано, и AI-агент может работать с любой частью системы, не спрашивая разрешения у соседней команды.

Микросервисы — не ошибка. Они были хорошим ответом на ограничения своего времени. Просто время изменилось.