А знаете, этот пример отлично показывает почему сейчас все движется именно к композитной архитектуре, особенно с развитием ИИ.
Смотрите - когда у вас нагрузка в несколько тысяч RPS, монолитная архитектура с хорошей модульностью отлично справляется. А вот когда доходит до 100К RPS - тут уже без микросервисов никак, потому что нужно масштабировать разные части системы независимо.
И вот тут как раз композитная архитектура дает идеальный баланс. Части системы с умеренной нагрузкой остаются в монолите - там где нам важнее скорость доступа к данным и простота разработки. А высоконагруженные части выносятся в отдельные микросервисы - там где реально нужно независимое масштабирование.
С приходом ИИ это становится еще актуальнее. Потому что ИИ требует быстрого доступа к большим объемам данных для принятия решений. В микросервисной архитектуре получить такой доступ очень сложно - пока соберешь данные из разных сервисов, пока их согласуешь... А в монолите ИИ может работать напрямую с данными.
Поэтому логичный путь такой - держать ИИ и связанные с ним компоненты в монолитной части для быстрой работы с данными, а то что требует реального масштабирования выносить в микросервисы. Собственно, это и есть композитная архитектура, которая сейчас становится все популярнее.
Я это на своем опыте увидел - 5 лет назад делал чистую микросервисную архитектуру, а сейчас бы уже так не стал. Слишком сложно интегрировать туда ИИ и работать с данными в реальном времени.
если нужно спроектировать альтернативный протокол или файловую систему, то для этого не нужно ИИ подключать к данным предприятия. Там задачи другие стоят, например найти неоптимальные процессы или спрогнозировать продажи на следующий период. Вот как раз с таким ИИ справляется на ура. Даже сейчас. Но на вход нужна качественная информация. Хотя конечно именно для этих задач не нужно чтобы данные были в режиме реального времени. Для реального времени другие задачи, поиск по запросу нужных операций, составление отчетов в реальном времени (например для выявления аномалий). Всякие там разные чатботы для помощи как сотрудникам так и клиентам. Много чего можно напридумывать.
Вообще активное развитие генеративного ИИ началось не так давно, соответственно еще не так уж много действительно полезных внедрений, но тенденция уже наметилась, кто сможет обеспечить хороший доступ ИИ к данным тот будет иметь огромное преимущество, процесс уже этот запущен...
Понимаю вашу точку зрения, но тут есть интересный нюанс. Когда вы делаете микросервис изолированно как эксперт в своей области - это хорошо для самого сервиса, но плохо для системы в целом.
Когда эксперты работают по отдельности, каждый супер-круто делает свою часть, но общая картина часто получается так себе. Это как если бы вы делали машину и у вас отдельно крутой эксперт по двигателям сделал мощный двигатель, отдельно эксперт по аэродинамике нарисовал обтекаемый кузов, а эксперт по комфорту спроектировал роскошный салон. И вроде каждый сделал идеально свою часть, но собрать это вместе так чтобы работало - та еще задачка.
Человек имеет ограничения, объем мозга и скорость его работы ограничены. Человек должен есть спать и другие дела делать, человек не может постоянно изучать информацию. По этому люди - супер эксперты довольно редки и дороги. А вот ИИ хоть пока и не догоняет до уровня человека по умению создавать новое, но у него нет ограничений по скорости работы и умению обучаться
А теперь представьте что у вас есть ИИ который может одновременно быть экспертом во всех этих областях и видеть общую картину. Он может не просто сложить отдельные экспертизы, а найти оптимальное решение учитывая все факторы сразу. Это как если бы у вас был один супер-эксперт который одновременно разбирается и в двигателях, и в аэродинамике, и в эргономике, и еще в куче смежных тем.
Именно поэтому ИИ дает такое преимущество крупным компаниям - он может преодолеть эту проблему узкой экспертизы и найти действительно системные решения. В то время как группа даже самых крутых экспертов часто застревает в спорах и не может прийти к общему знаменателю.
Ну как у вас могут быть глобальные данные и модульность одновременно?
Вот вам конкретный пример из реальной жизни чтобы было понятнее про монолит с модулями.
Возьмем приложение для онлайн-магазина. У нас есть модуль заказов, модуль товаров, модуль пользователей. Каждый модуль инкапсулирует свою логику и данные. Но когда нужно оформить заказ - модуль заказов может напрямую получить все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов.
А теперь представьте что мы разнесли это на микросервисы. Чтобы создать заказ нам надо:
Сделать HTTP запрос в сервис товаров
Дождаться ответа
Сделать еще запрос в сервис пользователей
Снова ждать
И только потом создавать заказ
И везде на этом пути могут быть проблемы - сеть лагает, сервис не отвечает, версии API не совпадают.
В монолите же все модули работают в одном процессе, и хотя данные так же инкапсулированы в модулях - доступ к ним происходит напрямую через вызовы методов. Это и быстрее и надежнее.
Да, и самое интересное что если брать современные ORM - они как раз и реализуют этот принцип. Возьмите например Entity Framework или Hibernate - вы описываете модели данных, связи между ними, и ORM позволяет вам работать с ними как с объектами в памяти.
При этом когда вы делаете Include в Entity Framework - вы явно указываете какие связанные данные вам нужны, то есть инкапсуляция сохраняется. Но сами данные загружаются напрямую из базы в память процесса, без всяких HTTP запросов и сериализации.
То есть современный монолит с ORM - это по сути и есть та самая модульность с прямым доступом к данным, о которой я говорю. Вы получаете и чистоту ООП подхода, и производительность прямого доступа к данным в рамках одного процесса.
Есть микросервис специально обученный управлять другими микросервисами.
Да, я понимаю о чем вы говорите, это похоже на BRE (Business Rules Engine) паттерн, где отдельные сервисы управляют бизнес-правилами. У меня был опыт разработки похожей архитектуры.
Основная проблема которую я там увидел - это именно сильная фрагментация данных. Смотрите что получается: у вас есть специальный микросервис для управления другими сервисами, отдельный для сети, отдельный для ресурсов, для пайплайнов и так далее. И вроде это круто с точки зрения разделения ответственности, каждый занимается своим делом.
Но когда вам нужно собрать общую картину - например, для анализа проблем или оптимизации работы системы - приходится собирать данные из всех этих сервисов в одном месте. И на это уходит просто огромное количество усилий, потому что данные могут быть в разных форматах, могут быть рассинхронизированы по времени, некоторые сервисы могут быть недоступны, а связи между данными из разных сервисов неочевидны.
В своей архитектуре я для этого разрабатывал специальные сервисы для сбора данных, но все равно это сложная задача, сервисы учитывали разные моменты и задержки, в итоге собирали данные в одном месте но все это было не мгновенно. И собираемые данные использовались в основном для мониторинга, а вот для анализа использовался отдельный поток который требовал до суток на то чтобы собрать данные на день.
В итоге получается что простая с виду задача "посмотреть что происходит в системе" превращается в сложный проект по сбору и согласованию данных из десятков сервисов. И это одна из главных причин почему такие большие микросервисные системы так сложно поддерживать.
Я это делал 5 лет назад, тогда не было генеративного ИИ и задач по доступу в реальном времени, и это не было проблемой, сейчас же уже ситуация поменялась и требования другие. Наверное я бы уже так не делал. Хотя соглашусь, архитектура - это компромисс. Бросаться и все переделывать в угоду ИИ, который сейчас хоть и сделал мощный рывок вперед но не дает таких уж огромных преимуществ (пока), тоже не следует. Но как мне кажется, дрейф в сторону композитной архитектуры с модульными монолитами уже наметился.
Я с вами во многом согласен, но давайте все-таки разберемся с аналогией мозга. Я ее использовал не для того чтобы сказать что мозг идеален, а чтобы показать разницу между прямым доступом к данным и доступом через внешние вызовы.
Да, вы абсолютно правы про то что быстрый доступ работает только по накатанным нейронным путям, и что интуитивные решения часто ошибочны - но суть в том, что сам механизм доступа к данным прямой. Даже когда мозг долго думает или ошибается - он все равно работает напрямую со своей памятью, а не делает распределенные запросы через API.
По поводу монолитов - вот тут вы очень точно описали проблему. Когда я говорю про монолит, я не имею в виду огромную БД с кучей хранимых процедур - это действительно антипаттерн из 60-х. Современный монолит это скорее единая кодовая база с четкой внутренней модульностью, где модули общаются через понятные интерфейсы, но при этом имеют прямой доступ к общим данным когда он нужен.
А вот по поводу микросервисов - интересно что вы работаете в организации с 6000 микросервисов. Можете поделиться, как у вас решается проблема сложности управления таким количеством сервисов? Я просто видел несколько крупных проектов где микросервисная архитектура в итоге развалилась под собственной сложностью, и интересно как вы с этим справляетесь.
Также, полностью согласен про то что разработчики часто не уделяют достаточно внимания проектированию. Сначала наделают кучу микросервисов по модному паттерну, а потом удивляются почему все так сложно поддерживать.
Хотя суть проблемы намного глубже чем просто выбор между микросервисами и монолитами. По моим наблюдениям, а я видел много компаний, дело часто обстоит так, бизнес постоянно требует быстрых решений, команды наскоро пилят функционал и перебегают на следующий проект. Старый код превращается в легаси - он вроде как работает, но как именно - уже никто не помнит.
И вот эта куча легаси растет как снежный ком. Команды разработки ушли, документации толком нет, новые люди приходят и не могут разобраться что там внутри происходит. В итоге чтобы просто поддерживать это всё в рабочем состоянии нужно в несколько раз больше людей чем могло бы быть при нормальном подходе.
А самое интересное начинается когда условные топ-менеджеры приносят красивую ИТ-стратегию с модными словами про искусственный интеллект и инновации. А на земле - месиво из легаси-кода, в котором никакой ИИ работать просто не сможет.
Получается замкнутый круг - чтобы поддерживать легаси нужно все больше людей, а чтобы внедрять что-то новое - нужно еще больше. И дело тут не в том что микросервисы плохи или монолит хорош. Просто когда технические решения принимаются не техническими специалистами, а бизнесом который торопится и не думает о последствиях - любая архитектура превратится в большой ком проблем, который будет только расти.
Вы извините, я возможно не верно вашу мысль понял про "Миллион связей внутри, миллион связей наружу.. хрен редьки не слаще". Мне кажется что разница есть и она принципиальная, если смотреть с точки зрения системы принятия решений.
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
А теперь посмотрите как работает большая корпорация с микросервисной архитектурой - там быстрых решений вообще не бывает. Работает целая система сбора и подготовки данных: сначала отделы строят отчеты и шлют их в департаменты, там эти отчеты собирают и обрабатывают, потом отправляют наверх. Там на основе этого строят стратегии, передают их в менеджмент борд, и только там принимаются решения. При этом часто даже делаются обратные запросы, которые запускают весь этот процесс по новой.
Вот это второе - и есть типичный пример микросервисной архитектуры, где каждый шаг принятия решения требует кучи согласований и передачи данных между сервисами.
Так что, позволю себе не согласиться с тем, что внутренние и внешние связи - это "хрен редьки не слаще". Внутренние связи обеспечивают мгновенный доступ к данным и эффективное принятие решений, в то время как внешние связи неизбежно создают существенные накладные расходы на коммуникацию и координацию. Это особенно критично для систем с искусственным интеллектом, где скорость доступа к данным напрямую влияет на эффективность принятия решений.
И вы абсолютно правы насчет того, что проектирование - это грязная эвристическая проблема, а не алгоритм. Именно поэтому так важно понимать фундаментальные принципы и ограничения разных архитектурных подходов, а не просто следовать модным трендам. Потому что иначе действительно получится как в поговорке про молитву и лоб - можно и микросервисов наделать где не надо, и монолит раздуть до невменяемого состояния. Архитектура должна следовать за реальными потребностями системы, а не за абстрактными принципами.
PS. Я автор той статьи которую мы комментируем, если что.
А вот насчет распределенных систем интересное замечание. Смотри - у тех же пчел и муравьев распределенная система возникла не от хорошей жизни, а потому что один маленький муравей или одна маленькая пчела физически не могут решить большую задачу. У них просто нет выбора, они обязаны кооперироваться.
А у человека есть мощный процессор в голове, который позволяет решать сложные задачи монолитно. И когда мы делаем микросервисы - мы как бы добровольно отказываемся от этого преимущества, разбивая простую задачу на много маленьких. Это как если бы человек вместо того чтобы просто взять и поднять бревно, начал бы бегать вокруг него кучей маленьких человечков.
Поэтому сравнение с роем не очень корректное - рой это вынужденное решение из-за ограничений отдельной особи. А микросервисы это когда мы сами себе создаем сложности, разбивая монолит на кучу мелких сервисов, а потом героически эти сложности преодолеваем.
И кстати, муравьи с двутавром это отличный пример - они конечно затащат его куда надо, но это будет стоить огромных усилий по координации. А один человек с нормальным мозгом просто возьмет и перенесет его, потому что может просчитать траекторию и все сделать эффективно.
На самом деле, там все интереснее. В улье действительно больше специализаций пчел - есть уборщицы которые чистят ячейки, кормилицы для личинок, пчелы-регулировщики которые вентилируют улей и поддерживают температуру, пчелы-водоносы, пчелы-приемщицы которые забирают нектар у сборщиц и сгущают его в мед, пчелы-строители, пчелы-разведчики, пчелы-охранники на входе, пчелы-санитары которые выносят умерших, есть даже специальные пчелы которые запечатывают соты воском. Кроме рабочих пчел есть еще матка, которая отвечает за воспроизводство всей системы, и трутни, у которых своя специализированная роль
А по поводу дублирования - тут как раз работает правильный скейлинг, как в микросервисах. Если нужно больше меда - улей увеличивает количество пчел-сборщиц. Если идет активное строительство сот - больше строителей. То есть "инстансов" каждого типа пчел ровно столько, сколько нужно под текущую задачу.
И насчет количества - в улье обычно 20-60 тысяч пчел, а не сотни тысяч. Это как раз нормальное количество микросервисов для крупной системы, где каждый тип сервиса масштабируется отдельно под нагрузку.
Так что аналогия с микросервисами очень точная - специализированные юниты, свои протоколы общения, автомасштабирование под нагрузку. Другое дело что такая система реально сложная в поддержке, стоит матке заболеть - и всё, привет. И наверное поэтому пчелы так и не захватили мир - один монолитный медведь может запросто уничтожить несколько десятков распределенных микросервисных ульев. А уж когда появились модульно организованные люди, которые научились создавать крупные монолитные структуры вроде сельского хозяйства - пчелы вообще оказались на грани выживания как вид. Потому что против огромной согласованной системы вроде промышленного земледелия с пестицидами даже идеально организованная микросервисная архитектура улья оказалась бессильна.
На самом деле рой пчел больше похож на микросервисы, пчелы делятся по функциям, они не одинаковые, есть пчелы разведчики, есть пчелы которые нектар собирают, есть солдаты, есть те кто соты строит и так далее там у них сложная конструкция. И АПИ есть, пчелы могут передавать информацию через феромоны и через танец, например разведчики танцем показыают рабочим пчелам куда лететь за нектаром.
Но в данном случае пчелы - это скорее исключение которое подтверждает правило. Пчелы со своей микросервисной архитектурой очень уязвимы и не захватили мир, а захватил мир монолитный человек благодаря ИИ в мозгу
У вас в голове миллиарды синапсов образуют связи и тем не менее вы можете легко получить доступ к тому что знаете, а вот в больших организациях где знания распределены по головам тысяч или даже всего лишь сотен человек собор знаний требует больших усилий и уж точно не быстрый, как орг структуру не проектируй и какие процессы не внедряй.
А знаете, этот пример отлично показывает почему сейчас все движется именно к композитной архитектуре, особенно с развитием ИИ.
Смотрите - когда у вас нагрузка в несколько тысяч RPS, монолитная архитектура с хорошей модульностью отлично справляется. А вот когда доходит до 100К RPS - тут уже без микросервисов никак, потому что нужно масштабировать разные части системы независимо.
И вот тут как раз композитная архитектура дает идеальный баланс. Части системы с умеренной нагрузкой остаются в монолите - там где нам важнее скорость доступа к данным и простота разработки. А высоконагруженные части выносятся в отдельные микросервисы - там где реально нужно независимое масштабирование.
С приходом ИИ это становится еще актуальнее. Потому что ИИ требует быстрого доступа к большим объемам данных для принятия решений. В микросервисной архитектуре получить такой доступ очень сложно - пока соберешь данные из разных сервисов, пока их согласуешь... А в монолите ИИ может работать напрямую с данными.
Поэтому логичный путь такой - держать ИИ и связанные с ним компоненты в монолитной части для быстрой работы с данными, а то что требует реального масштабирования выносить в микросервисы. Собственно, это и есть композитная архитектура, которая сейчас становится все популярнее.
Я это на своем опыте увидел - 5 лет назад делал чистую микросервисную архитектуру, а сейчас бы уже так не стал. Слишком сложно интегрировать туда ИИ и работать с данными в реальном времени.
если нужно спроектировать альтернативный протокол или файловую систему, то для этого не нужно ИИ подключать к данным предприятия. Там задачи другие стоят, например найти неоптимальные процессы или спрогнозировать продажи на следующий период. Вот как раз с таким ИИ справляется на ура. Даже сейчас. Но на вход нужна качественная информация. Хотя конечно именно для этих задач не нужно чтобы данные были в режиме реального времени. Для реального времени другие задачи, поиск по запросу нужных операций, составление отчетов в реальном времени (например для выявления аномалий). Всякие там разные чатботы для помощи как сотрудникам так и клиентам. Много чего можно напридумывать.
Вообще активное развитие генеративного ИИ началось не так давно, соответственно еще не так уж много действительно полезных внедрений, но тенденция уже наметилась, кто сможет обеспечить хороший доступ ИИ к данным тот будет иметь огромное преимущество, процесс уже этот запущен...
Понимаю вашу точку зрения, но тут есть интересный нюанс. Когда вы делаете микросервис изолированно как эксперт в своей области - это хорошо для самого сервиса, но плохо для системы в целом.
Когда эксперты работают по отдельности, каждый супер-круто делает свою часть, но общая картина часто получается так себе. Это как если бы вы делали машину и у вас отдельно крутой эксперт по двигателям сделал мощный двигатель, отдельно эксперт по аэродинамике нарисовал обтекаемый кузов, а эксперт по комфорту спроектировал роскошный салон. И вроде каждый сделал идеально свою часть, но собрать это вместе так чтобы работало - та еще задачка.
Человек имеет ограничения, объем мозга и скорость его работы ограничены. Человек должен есть спать и другие дела делать, человек не может постоянно изучать информацию. По этому люди - супер эксперты довольно редки и дороги. А вот ИИ хоть пока и не догоняет до уровня человека по умению создавать новое, но у него нет ограничений по скорости работы и умению обучаться
А теперь представьте что у вас есть ИИ который может одновременно быть экспертом во всех этих областях и видеть общую картину. Он может не просто сложить отдельные экспертизы, а найти оптимальное решение учитывая все факторы сразу. Это как если бы у вас был один супер-эксперт который одновременно разбирается и в двигателях, и в аэродинамике, и в эргономике, и еще в куче смежных тем.
Именно поэтому ИИ дает такое преимущество крупным компаниям - он может преодолеть эту проблему узкой экспертизы и найти действительно системные решения. В то время как группа даже самых крутых экспертов часто застревает в спорах и не может прийти к общему знаменателю.
Вот вам конкретный пример из реальной жизни чтобы было понятнее про монолит с модулями.
Возьмем приложение для онлайн-магазина. У нас есть модуль заказов, модуль товаров, модуль пользователей. Каждый модуль инкапсулирует свою логику и данные. Но когда нужно оформить заказ - модуль заказов может напрямую получить все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов.
А теперь представьте что мы разнесли это на микросервисы. Чтобы создать заказ нам надо:
Сделать HTTP запрос в сервис товаров
Дождаться ответа
Сделать еще запрос в сервис пользователей
Снова ждать
И только потом создавать заказ
И везде на этом пути могут быть проблемы - сеть лагает, сервис не отвечает, версии API не совпадают.
В монолите же все модули работают в одном процессе, и хотя данные так же инкапсулированы в модулях - доступ к ним происходит напрямую через вызовы методов. Это и быстрее и надежнее.
Да, и самое интересное что если брать современные ORM - они как раз и реализуют этот принцип. Возьмите например Entity Framework или Hibernate - вы описываете модели данных, связи между ними, и ORM позволяет вам работать с ними как с объектами в памяти.
При этом когда вы делаете Include в Entity Framework - вы явно указываете какие связанные данные вам нужны, то есть инкапсуляция сохраняется. Но сами данные загружаются напрямую из базы в память процесса, без всяких HTTP запросов и сериализации.
То есть современный монолит с ORM - это по сути и есть та самая модульность с прямым доступом к данным, о которой я говорю. Вы получаете и чистоту ООП подхода, и производительность прямого доступа к данным в рамках одного процесса.
Да, я понимаю о чем вы говорите, это похоже на BRE (Business Rules Engine) паттерн, где отдельные сервисы управляют бизнес-правилами. У меня был опыт разработки похожей архитектуры.
Основная проблема которую я там увидел - это именно сильная фрагментация данных. Смотрите что получается: у вас есть специальный микросервис для управления другими сервисами, отдельный для сети, отдельный для ресурсов, для пайплайнов и так далее. И вроде это круто с точки зрения разделения ответственности, каждый занимается своим делом.
Но когда вам нужно собрать общую картину - например, для анализа проблем или оптимизации работы системы - приходится собирать данные из всех этих сервисов в одном месте. И на это уходит просто огромное количество усилий, потому что данные могут быть в разных форматах, могут быть рассинхронизированы по времени, некоторые сервисы могут быть недоступны, а связи между данными из разных сервисов неочевидны.
В своей архитектуре я для этого разрабатывал специальные сервисы для сбора данных, но все равно это сложная задача, сервисы учитывали разные моменты и задержки, в итоге собирали данные в одном месте но все это было не мгновенно. И собираемые данные использовались в основном для мониторинга, а вот для анализа использовался отдельный поток который требовал до суток на то чтобы собрать данные на день.
В итоге получается что простая с виду задача "посмотреть что происходит в системе" превращается в сложный проект по сбору и согласованию данных из десятков сервисов. И это одна из главных причин почему такие большие микросервисные системы так сложно поддерживать.
Я это делал 5 лет назад, тогда не было генеративного ИИ и задач по доступу в реальном времени, и это не было проблемой, сейчас же уже ситуация поменялась и требования другие. Наверное я бы уже так не делал. Хотя соглашусь, архитектура - это компромисс. Бросаться и все переделывать в угоду ИИ, который сейчас хоть и сделал мощный рывок вперед но не дает таких уж огромных преимуществ (пока), тоже не следует. Но как мне кажется, дрейф в сторону композитной архитектуры с модульными монолитами уже наметился.
Я с вами во многом согласен, но давайте все-таки разберемся с аналогией мозга. Я ее использовал не для того чтобы сказать что мозг идеален, а чтобы показать разницу между прямым доступом к данным и доступом через внешние вызовы.
Да, вы абсолютно правы про то что быстрый доступ работает только по накатанным нейронным путям, и что интуитивные решения часто ошибочны - но суть в том, что сам механизм доступа к данным прямой. Даже когда мозг долго думает или ошибается - он все равно работает напрямую со своей памятью, а не делает распределенные запросы через API.
По поводу монолитов - вот тут вы очень точно описали проблему. Когда я говорю про монолит, я не имею в виду огромную БД с кучей хранимых процедур - это действительно антипаттерн из 60-х. Современный монолит это скорее единая кодовая база с четкой внутренней модульностью, где модули общаются через понятные интерфейсы, но при этом имеют прямой доступ к общим данным когда он нужен.
А вот по поводу микросервисов - интересно что вы работаете в организации с 6000 микросервисов. Можете поделиться, как у вас решается проблема сложности управления таким количеством сервисов? Я просто видел несколько крупных проектов где микросервисная архитектура в итоге развалилась под собственной сложностью, и интересно как вы с этим справляетесь.
Также, полностью согласен про то что разработчики часто не уделяют достаточно внимания проектированию. Сначала наделают кучу микросервисов по модному паттерну, а потом удивляются почему все так сложно поддерживать.
Хотя суть проблемы намного глубже чем просто выбор между микросервисами и монолитами. По моим наблюдениям, а я видел много компаний, дело часто обстоит так, бизнес постоянно требует быстрых решений, команды наскоро пилят функционал и перебегают на следующий проект. Старый код превращается в легаси - он вроде как работает, но как именно - уже никто не помнит.
И вот эта куча легаси растет как снежный ком. Команды разработки ушли, документации толком нет, новые люди приходят и не могут разобраться что там внутри происходит. В итоге чтобы просто поддерживать это всё в рабочем состоянии нужно в несколько раз больше людей чем могло бы быть при нормальном подходе.
А самое интересное начинается когда условные топ-менеджеры приносят красивую ИТ-стратегию с модными словами про искусственный интеллект и инновации. А на земле - месиво из легаси-кода, в котором никакой ИИ работать просто не сможет.
Получается замкнутый круг - чтобы поддерживать легаси нужно все больше людей, а чтобы внедрять что-то новое - нужно еще больше. И дело тут не в том что микросервисы плохи или монолит хорош. Просто когда технические решения принимаются не техническими специалистами, а бизнесом который торопится и не думает о последствиях - любая архитектура превратится в большой ком проблем, который будет только расти.
Вы извините, я возможно не верно вашу мысль понял про "Миллион связей внутри, миллион связей наружу.. хрен редьки не слаще". Мне кажется что разница есть и она принципиальная, если смотреть с точки зрения системы принятия решений.
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
А теперь посмотрите как работает большая корпорация с микросервисной архитектурой - там быстрых решений вообще не бывает. Работает целая система сбора и подготовки данных: сначала отделы строят отчеты и шлют их в департаменты, там эти отчеты собирают и обрабатывают, потом отправляют наверх. Там на основе этого строят стратегии, передают их в менеджмент борд, и только там принимаются решения. При этом часто даже делаются обратные запросы, которые запускают весь этот процесс по новой.
Вот это второе - и есть типичный пример микросервисной архитектуры, где каждый шаг принятия решения требует кучи согласований и передачи данных между сервисами.
Так что, позволю себе не согласиться с тем, что внутренние и внешние связи - это "хрен редьки не слаще". Внутренние связи обеспечивают мгновенный доступ к данным и эффективное принятие решений, в то время как внешние связи неизбежно создают существенные накладные расходы на коммуникацию и координацию. Это особенно критично для систем с искусственным интеллектом, где скорость доступа к данным напрямую влияет на эффективность принятия решений.
И вы абсолютно правы насчет того, что проектирование - это грязная эвристическая проблема, а не алгоритм. Именно поэтому так важно понимать фундаментальные принципы и ограничения разных архитектурных подходов, а не просто следовать модным трендам. Потому что иначе действительно получится как в поговорке про молитву и лоб - можно и микросервисов наделать где не надо, и монолит раздуть до невменяемого состояния. Архитектура должна следовать за реальными потребностями системы, а не за абстрактными принципами.
PS. Я автор той статьи которую мы комментируем, если что.
А вот насчет распределенных систем интересное замечание. Смотри - у тех же пчел и муравьев распределенная система возникла не от хорошей жизни, а потому что один маленький муравей или одна маленькая пчела физически не могут решить большую задачу. У них просто нет выбора, они обязаны кооперироваться.
А у человека есть мощный процессор в голове, который позволяет решать сложные задачи монолитно. И когда мы делаем микросервисы - мы как бы добровольно отказываемся от этого преимущества, разбивая простую задачу на много маленьких. Это как если бы человек вместо того чтобы просто взять и поднять бревно, начал бы бегать вокруг него кучей маленьких человечков.
Поэтому сравнение с роем не очень корректное - рой это вынужденное решение из-за ограничений отдельной особи. А микросервисы это когда мы сами себе создаем сложности, разбивая монолит на кучу мелких сервисов, а потом героически эти сложности преодолеваем.
И кстати, муравьи с двутавром это отличный пример - они конечно затащат его куда надо, но это будет стоить огромных усилий по координации. А один человек с нормальным мозгом просто возьмет и перенесет его, потому что может просчитать траекторию и все сделать эффективно.
На самом деле, там все интереснее. В улье действительно больше специализаций пчел - есть уборщицы которые чистят ячейки, кормилицы для личинок, пчелы-регулировщики которые вентилируют улей и поддерживают температуру, пчелы-водоносы, пчелы-приемщицы которые забирают нектар у сборщиц и сгущают его в мед, пчелы-строители, пчелы-разведчики, пчелы-охранники на входе, пчелы-санитары которые выносят умерших, есть даже специальные пчелы которые запечатывают соты воском. Кроме рабочих пчел есть еще матка, которая отвечает за воспроизводство всей системы, и трутни, у которых своя специализированная роль
А по поводу дублирования - тут как раз работает правильный скейлинг, как в микросервисах. Если нужно больше меда - улей увеличивает количество пчел-сборщиц. Если идет активное строительство сот - больше строителей. То есть "инстансов" каждого типа пчел ровно столько, сколько нужно под текущую задачу.
И насчет количества - в улье обычно 20-60 тысяч пчел, а не сотни тысяч. Это как раз нормальное количество микросервисов для крупной системы, где каждый тип сервиса масштабируется отдельно под нагрузку.
Так что аналогия с микросервисами очень точная - специализированные юниты, свои протоколы общения, автомасштабирование под нагрузку. Другое дело что такая система реально сложная в поддержке, стоит матке заболеть - и всё, привет. И наверное поэтому пчелы так и не захватили мир - один монолитный медведь может запросто уничтожить несколько десятков распределенных микросервисных ульев. А уж когда появились модульно организованные люди, которые научились создавать крупные монолитные структуры вроде сельского хозяйства - пчелы вообще оказались на грани выживания как вид. Потому что против огромной согласованной системы вроде промышленного земледелия с пестицидами даже идеально организованная микросервисная архитектура улья оказалась бессильна.
На самом деле рой пчел больше похож на микросервисы, пчелы делятся по функциям, они не одинаковые, есть пчелы разведчики, есть пчелы которые нектар собирают, есть солдаты, есть те кто соты строит и так далее там у них сложная конструкция. И АПИ есть, пчелы могут передавать информацию через феромоны и через танец, например разведчики танцем показыают рабочим пчелам куда лететь за нектаром.
Но в данном случае пчелы - это скорее исключение которое подтверждает правило. Пчелы со своей микросервисной архитектурой очень уязвимы и не захватили мир, а захватил мир монолитный человек благодаря ИИ в мозгу
У вас в голове миллиарды синапсов образуют связи и тем не менее вы можете легко получить доступ к тому что знаете, а вот в больших организациях где знания распределены по головам тысяч или даже всего лишь сотен человек собор знаний требует больших усилий и уж точно не быстрый, как орг структуру не проектируй и какие процессы не внедряй.