В 1985 году Чжан Жуйминь раздал кувалды рабочим и заставил разбить 76 бракованных холодильников. Для сотрудников убыточного Qingdao Refrigerator General Factory это выглядело весьма странно (холодильники тогда стоили как пара месячных зарплат), но директор хотел проиллюстрировать простую идею: за качество отвечает тот, кто непосредственно делает продукт, а не только начальство.

Сорок лет спустя Haier — империя с выручкой $52 миллиарда — работает как живое воплощение принципа, который программисты открыли через боль рефакторинга: организационная структура неизбежно диктует архитектуру систем. То, что в IT называют законом Конвея, китайский производитель холодильников воплотил через радикальную децентрализацию всего бизнеса. 

Эта история о том, как структура команды неизбежно определяет архитектуру кода, почему Amazon Prime Video сэкономил, вернувшись к монолиту, и что общего между китайским производителем холодильников и вашим последним проектом на микросервисах.

Закон, который нельзя обойти

То, что Haier интуитивно воплотил в своей структуре — автономные команды создают автономные системы, — это не случайное совпадение. Еще в 1968 году программист Мелвин Конвей сформулировал наблюдение: «Организации, проектирующие системы, ограничены в создании дизайнов, которые являются копиями коммуникационных структур этих организаций». Проще говоря — ваш код всегда будет похож на вашу оргструктуру.

Более 50 лет это правило подтверждается снова и снова, а гарвардская школа бизнеса эмпирически доказала: open source — проекты со слабо связанными контрибьюторами стабильно производят модульный код, а корпоративные команды в одном офисе — монолиты.

Возьмем три команды разработчиков. Первая сидит в одном open space, обедает вместе и решает вопросы, просто повернув кресло в сторону коллеги. Вторая распределена по трем офисам в разных городах, созванивается раз в неделю. Третья — это 50 человек в одном здании, но разбитых на отделы, которые общаются через тикеты в Jira.

Можно легко предсказать архитектуру их продуктов. Первая команда напишет монолит. Вторая — независимые сервисы с REST API. Третья создаст большую систему с модулями, которые технически могут работать независимо, но почему-то требуют синхронного деплоя всех компонентов разом.

И это практически нерушимое, как законы физики, правило. Мартин Фаулер — автор культовых книг по архитектуре ПО, в 2022 году писал: «Вы обречены на поражение, если попытаетесь с этим бороться». Но индустрия борется уже несколько десятков лет. Безуспешно.

Великий исход из микросервисов

Как именно индустрия боролась с законом Конвея? Через микросервисы, конечно. Логика вроде железная: если маленькие независимые команды создают модульный код, давайте просто разобьем монолит на сервисы, архитектура будет модульной, а команды подтянутся. Но закон Конвея работает не так — если у вас одна команда, то вместо микросервисов получится распределенный монолит.

Помните хайп? Netflix, Uber, Spotify, Amazon… Каждая уважающая себя компания рвалась разбить монолит на микросервисы. И что произошло потом? 

Amazon Prime Video переработал сервис мониторинга и вернулся к монолиту, снизив затраты на 90% (на конкретном сервисе) и получив улучшение производительности. Segment (платформа аналитики, которую Twilio купила за $3,2 миллиарда) довела количество микросервисов до 140 штук, а потом схлопнула все обратно в один сервис (так и писали: Goodbye Microservices). Почему? Тратили больше времени на поддержку инфраструктуры, чем на разработку фич.

После консолидации Segment увеличил количество улучшений в shared-библиотеках с 32 до 46 в год. Время прогона тестов сократилось с часов до миллисекунд. Даже Istio (платформа для управления микросервисами!) объединила компоненты в один бинарник: «микросервисы — отличный паттерн, когда они соответствуют разным командам... но для control plane Istio это было не так». Одна команда разрабатывала все компоненты, поэтому микросервисная архитектура только добавляла сложности. Классический случай нарушения закона Конвея.

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

Китайский эксперимент

Вернемся к кувалде Чжана. В 1985 году его предприятие называлось Qingdao Refrigerator General Factory — типичный убыточный китайский завод того времени. После драматичного уничтожения бракованных холодильников Чжан двадцать лет обдумывал радикальную идею и в 2005 году запустил трансформацию компании по модели Rendanheyi — «интеграция людей и целей».

Суть: разбить компанию на микропредприятия по 10–15 человек. Каждое — независимый бизнес со своим P&L. Лидеров выбирает команда, а не назначает начальство. Микропредприятие само решает, кого нанимать, как тратить бюджет и с кем сотрудничать. Не показываешь результат — команда может тебя выкинуть.

Чтобы примерно понять масштаб. HR-департамент сократился с 860 человек до 11 — просто внедрили платформу shared services. 12 тысяч менеджеров среднего звена исчезли как класс (при этом компания создала 1,9 миллиона рабочих мест через свою экосистему). 

Через 10 лет с начала модернизации Haier купила GE Appliances — американскую компанию, которая под новым управлением переместилась с четвертого на первое место на рынке США. К 2017 году акции Haier выросли в четыре раза. С 2015 года выручка Haier Smart Home растет более чем на 18% ежегодно. Сегодня это империя с 99 тысячами сотрудников по всему миру и 4–5 тысячами микропредприятий. 77% из них генерируют больше $15,7 миллионов выручки в год. Успешность новых проектов — 50% против 10% у обычных китайских стартапов.

Самое интересное —  их IT-инфраструктура. Промышленная платформа COSMOPlat работает на Spring Cloud — да, на микросервисах. Каждое микропредприятие получает сервисы через API: MES, PLM, CRM. Взаимодействие между микропредприятиями идет через смарт-контракты на блокчейне (не повсеместно, но тем не менее) — по сути, те же API-контракты между сервисами.

Лучшим бенчмарком стратегии Haier стала пандемия. Когда традиционные компании ждали указаний сверху по каждому локдауну и закрытой границе, микропредприятия Haier принимали решения на месте. Закрыли порт в Шанхае? Местная команда уже договаривается об альтернативном маршруте. Нет комплектующих у обычного поставщика? Микропредприятие находит нового, не дожидаясь одобрения пяти уровней менеджмента. В результате Haier сохранила поставки, пока конкуренты их отменяли. Классическая иерархия просто не успевала бы реагировать на хаос пандемии.

Обратный маневр Конвея

Зачем мы вообще рассказываем про китайского производителя холодильников? Потому что Haier, сам того не зная, решил главную проблему разработки — несоответствие между желаемой архитектурой и реальной структурой команды. Чжан Жуйминь не знал про закон Конвея. Он просто хотел, чтобы его компания работала быстро, автономно, без бюрократии. И для этого он изменил организацию, а не процессы. Сначала создал структуру из независимых микропредприятий, а потом под нее подтянулась и IT-инфраструктура на микросервисах. В индустрии разработки этот подход позже формализовали как «Обратный маневр Конвея»: вместо того чтобы позволить случайной оргструктуре диктовать архитектуру решения, нужно сознательно проектировать организацию под архитектуру.

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

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

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

Кстати, Haier довел идею до абсолюта. У них даже HR и финансы конкурируют как внутренние поставщики услуг. Микропредприятия выбирают, чьими услугами пользоваться, основываясь на качестве и цене. По сути, внутренний маркетплейс сервисов.

Модульные монолиты и другие компромиссы

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

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

Как видно по опыту Shopify, это работает на огромных масштабах. Больше тысячи разработчиков работают над монолитом в 2,8 миллиона строк кода. Их разработка в одну из «черных пятниц» переварила 30 терабайт данных в минуту, 11 миллионов запросов к базе и 42 миллиарда API-вызовов. Секрет в жесткой модульности: команды владеют своими доменами, но деплоят в единый процесс. Можно быстро вносить изменения (преимущество монолита) и держать код чистым (преимущество модульности).

Академические исследования подтверждают тренд. Так, в работе «Модульный монолит: это тренд в архитектуре ПО?» анализируются кейсы ухода от микросервисов: компании не отказываются от модульности, они отказываются от сетевых вызовов между модулями.

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

Выводы?

Перед следующим архитектурным решением посмотрите на свою команду. Сидите в одном офисе? Начинайте с монолита. Распределенная команда? Сразу закладывайте четкие границы между компонентами — все равно получатся независимые модули.

Планируете микросервисы? Сначала разбейте команду на автономные группы и дайте каждой группе полную ответственность за свой сервис: от разработки до поддержки в продакшене. Если не готовы к такой автономии — оставайтесь с монолитом. Будет дешевле.

Хотите модульный монолит? Организуйте код-ревью между командами, но деплой делайте общий. Введите правило: изменения в модуле A не должны ломать модуль B. Нарушителей бьют канделябром.

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

Главное — перестать бороться с законом Конвея. Это все равно что плыть против течения: можно, но зачем? Лучше развернуть лодку и использовать силу потока. Ваш код, так или иначе, будет похож на вашу оргструктуру. Вопрос только в том, спроектируете вы это соответствие заранее или получите случайную архитектуру, которую потом годами будете рефакторить.

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