А если потом добавится Sync, а уже есть без Async? Тут правильно рассматривать еще и контекст. Для корп разработки, внутри команды, вполне норм потом переобуться. Для внешников нужно стараться не плодить breaking changes. Изменения - это риски.
Но есть же и дичь. Например использование выравниваний по какойто границе. Или несколько переносов строк для отделения секций (select, from, etc) в sql. Это очень шаткий стайл, который в маленький конструкциях норм а средние и большие - каша.
Не только субъективную, но и объективную в первую очередь. Меньше состояний и переходов в КА - проще. Ну и не всегда, но как правило, субъективная сложность очень сильно коррелируется с объективной.
Откуда у вас цифра, что сложность всегда константа? Что такое сложность тогда?
Сразу вас направлю к теории автоматов. И к иследованиям про сложность (например, what makes rules complex)
Сделайте любой запрос по сети с использованием какойто библиотеки (нр request в питоне)? Сложно? А теперь представьте сколько деталей от вас скрыли, в том числе благодаря ооп, чтобы реально сделать такой запрос. Сможете перечислить сколько всего происходит при вызове?
С Func as service я знаком. Не знаю имел ли в виду автор именно их.
Не, с точки зрения нагрузки не логично или не факт что логично следовать шаблону "сервис имени ручки". Тут нужно смотреть на конретику, а то может совместить несколько сценариев (ручек) в одном даже выгоднее будет (общая бд, кэширование, отсутствие походов по сети, отсутствие репликации и т.д.).
"иерархия в микросервисе из одной ручки" - смотря на сколько это паттерн. В принципе микросервис из одной ручки уже звучит странно. Но если таких немного, то в целом может быть и нормально. И иерархия может быть в таких сервисах также оправдана.
Например у нас: есть стандартый шаблон, разворачивающийся за секунду. В нем стандартная иерархия: презентация, прикладной, доменный и инфра. То, что в 2-3 сервисах из 100, задача на столько проста, что можно не заморачиваться насчет моделек, еще не говорит что нужно городить огород и делать в этих сервисах по разному. Нужно задавать вопрос "на сколько это проблемно завести прикладной сервис, дернуть его из слоя перезентации и отдать данные?".
шаблоны и стандартные решения дают выигрышь в поддержке и разработке, при условии что они применяются правильно (т.е. не превращаются в антишаблоны)
С приходом ИИ это становится еще актуальнее. Потому что ИИ требует быстрого доступа к большим объемам данных для принятия решений. В микросервисной архитектуре получить такой доступ очень сложно - пока соберешь данные из разных сервисов, пока их согласуешь... А в монолите ИИ может работать напрямую с данными.
вы искренне верите, что обученные модельки для принятия решения (и наверное обучения) будут использовать оперативные данные? Или вы в монолит еще и аналитические модели запихаете? Или оперативная обработка будет страдать от избыточности и денормализованности?
Части системы с умеренной нагрузкой остаются в монолите - там где нам важнее скорость доступа к данным и простота разработки.
Что такое простота разработки? Как будете решать проблемы масштабирования разработки? Представьте, что у вас монолит, с кучей подсистем, каждая подсистема (или подмножество) - выделенная команда. Как фичи деплоить? выстраиваться в очередь? Или накидываем фичи в кучу и раз в месяц, методом "большого взрыва" пытаемся заинтегрировать эти фичи и выкатиться в продакшн?
Вы просто скажите - у меня маленькие приложения, с ограниченными числом функций, поэтому у меня монолит. Или "у меня десктопное приложение" - но тут и понятно, что микросервисы как пятое колесо (хотя и здесь есть нюансы).
назовите хоть один орган, который бы дублировал функции другого? не дополняют друг друга или влияют оба на что-то, а именно выполнение один и тех же функций. На давление много что влияет. Так же как и на успешность, скажем, создания заказа в микросервисной или монолитной среде.
так и кровь можно рассматривать под разными углами.
Модульность - она ведь не про сокрытие данных, а про управление кодом, прежде всего.
как раз таки про сокрытие. Скрываешь внутрянку, даешь абстракции, значит можешь менять отдельные модули (или абстракции) без влияния на все остальное. Раскрываешь внутрянку - велком искать все зависимости и аккуратно, единомоментно, правильно меняешь их в каждом месте. Или получаешь breaking changes.
И да, ООП это про обмен абстракциями (событиями). Сами глобальные данные скрываются.
видимо мы вообще друг друга не понимаем. Я говорю вам про микросервисы, как способ обойти невозможность масшабирования монолита, а когда такой проблемы нет, то и обходить нечего (стало быть и микросервисы не нужны). Вы мне приводите пример отсутствия проблемы масштабирования (...все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов...).
Мы с вами про разные монолиты говорим. То что вы описываете это монолитный экземпляр, но внутри он устроен весьма грамотно - идеально (обычно на практике все гораздо хуже) - изолированные модули, грамотное разделение ответственности.
Но и здесь вы сами себя обманываете. От того, что вы в один исполнимый файл (кодовую базу) запихаете кучу логики, даже если она будет очень хорошо модулиризирована, проблема интеграции никуда не девается. Кол-во связей компонентов внутри (этих самых методов и типов) не уменьшается. Необходимость иметь узкоспециализированных разрабов модулей никуда не уходит. По большей части разница в транспорте.
Попробуйте-ка поскейлить такой экземпляр монолитный в огромнейшей системе на обработку хотя бы 100К rps (rps rps'у рознь, но кто знает, тот поймет о чем я). Это будет дикая неэффективность, если вообще возможно.
Я с вами во многом согласен, но давайте все-таки разберемся с аналогией мозга. Я ее использовал не для того чтобы сказать что мозг идеален, а чтобы показать разницу между прямым доступом к данным и доступом через внешние вызовы.
давайте. Самому думать и разбираться долго (хоть и полезно), а во всем разбираться и вовсе не получится, поэтому обращаюсь к эксперту. Вот мы только что создали 2 микросервиса. Я эксперт в одном - делаю только свое и делаю это хорошо, а он - свое.
Про доступ к данным я понимаю. Внутрипроцессный доступ он легче и проще, чем межпроцессный, а уж тем более через асинхронные сети. Но число связей то это не уменьшает. Микросервисы это компромисс невозможности масштабирования монолита. И да, за это придется заплатить. Но из двух зол выбирают меньшее, а серебряной пули не бывает.
Современный монолит это скорее единая кодовая база с четкой внутренней модульностью, где модули общаются через понятные интерфейсы, но при этом имеют прямой доступ к общим данным когда он нужен.
Ну как у вас могут быть глобальные данные и модульность одновременно? Это противоречие. Не может быть ООП, но с глобальными данными. Его придумали как раз чтобы их скрыть и получили буст в размерах и сложности ПО.
Если какие-то функции могут выполняться в рамках одного процесса, то зачем их дробить на микросервисы и устраивать геморой с общением по сети? Такие вопросы должны задавать себе проектировщики
А вот по поводу микросервисов - интересно что вы работаете в организации с 6000 микросервисов. Можете поделиться, как у вас решается проблема сложности управления таким количеством сервисов?
Есть микросервис специально обученный управлять другими микросервисами. Короче разделение функций. Один отвечает за сеть, другой за ресурсы, третий за пайплайны и т.д. Всех проблем я вам не скажу. Я - микросервис отвечающий за некоторый набор продуктовых функций (надеюсь делаю это хорошо :)).
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав
Вы очень ошибаетесь и преукрашаете возможности человеческого мозга. Быстрый доступ к данным возможен только по накатанной нейронной колее - например, с чем-то часто работаешь, поэтому быстро можешь на что-то ответить или сделать.
Попробуйте-ка воспользоваться знаниям, которые давно не использовались? вытащить их.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
Быстрые данные - полученные интуитивно - очень часто ошибочны. Много исследований на эту тему. Например, можно прочитать труды Канемана. Интуиция и распознание шаблонов - это вообще мимо интеллекта.
Про долгосрочную память можно ознакомиться в трудах Эббингауза.
Сравнение с мозгом некорректно в данном ключе. Либо надо более удачную метафору придумать.
Я работаю в организации, где 6к микросервисов и огромные монолиты под десятки ТБ реляционных данных. Нужно определиться "что такое монолит". У нас монолит - это журнючая БД (или набор БД) работающая под управлением одного экземпляра СУБД, с 10К+ хранимых процедур. Т.е. это ни что иное, как глобальные данные и куча процедурной обработки вокруг, с миллионами связей. Чувствуете пахнет 60мы годами 20ого века? Это стрельба дробью. Порушил связь - беда. И я вам скажу, что в такой монолит очень сложно вносить изменения. Любое мелкое изменение - необходимость менять логику, единомоментно, согласованно в куче мест только внутри БД. Обычно монолит характеризуется еще и внешними зависимостями (поискать связи по репе не такая и проблема, а вот за пределами - сущий ад). И поэтому внесение изменений в монолит это очень большой геморой, с вовлечением большого количества отделов и понятно дело согласований, техкомов, кроссдоменных проектов.
Микросервисная архитектура, при правильном использовании, как раз таки должна решить проблему глобальных данных. Если ты грамотно разделяешь ответственность, если ты умело скрываешь внутрянку, то будет тебе счастье. Но увы. Разработчики очень редко учатся разрабатывать/проектировать. Обычно они больше внимания уделяют инструментам - языкам программирования, базам данных, кафкам и т.д. А проектирование, по большей части, сводится к подражанию. "Мы так всегда делали". "Соседний отдел так делает".
Монолиты к сожалению не масштабируемые - ни по железу, ни по кодовой базе. Со временем, как раз из-за глобальных данных и числа связей, становятся неповоротливым "аппаратным" обеспечением. Но и неправильное применение микросервисных паттернов тоже приводит к такому же.
p.s.: опять же, подчеркну, нужно дать определение монолиту.
А если потом добавится Sync, а уже есть без Async? Тут правильно рассматривать еще и контекст. Для корп разработки, внутри команды, вполне норм потом переобуться. Для внешников нужно стараться не плодить breaking changes. Изменения - это риски.
Ситуации разные. Где-то важны цифры, где-то наглядность.
Предлагаю обратиться к определению "программное обеспечение". Подсказка - изменчивость
Вы привели эквивалентные стили..
Но есть же и дичь. Например использование выравниваний по какойто границе. Или несколько переносов строк для отделения секций (select, from, etc) в sql. Это очень шаткий стайл, который в маленький конструкциях норм а средние и большие - каша.
Эх, не пролистал чуть ниже ) уже было
А как вам запятые в начале строки? (Tsql)
Декомпозиция и композиция - меч обоюдоострый. Заигрываются и те кто слишком избыточно обобщают и те кто увеличивают вариативность.
Все должно быть предельно просто, но не проще.
Примеры хоть и утрированы, но встречаются. Но мне кажется лапша встречается чаще.
Не только субъективную, но и объективную в первую очередь. Меньше состояний и переходов в КА - проще. Ну и не всегда, но как правило, субъективная сложность очень сильно коррелируется с объективной.
Откуда у вас цифра, что сложность всегда константа? Что такое сложность тогда?
Сразу вас направлю к теории автоматов. И к иследованиям про сложность (например, what makes rules complex)
Сделайте любой запрос по сети с использованием какойто библиотеки (нр request в питоне)? Сложно? А теперь представьте сколько деталей от вас скрыли, в том числе благодаря ооп, чтобы реально сделать такой запрос. Сможете перечислить сколько всего происходит при вызове?
С Func as service я знаком. Не знаю имел ли в виду автор именно их.
Не, с точки зрения нагрузки не логично или не факт что логично следовать шаблону "сервис имени ручки". Тут нужно смотреть на конретику, а то может совместить несколько сценариев (ручек) в одном даже выгоднее будет (общая бд, кэширование, отсутствие походов по сети, отсутствие репликации и т.д.).
"иерархия в микросервисе из одной ручки" - смотря на сколько это паттерн. В принципе микросервис из одной ручки уже звучит странно. Но если таких немного, то в целом может быть и нормально. И иерархия может быть в таких сервисах также оправдана.
Например у нас: есть стандартый шаблон, разворачивающийся за секунду. В нем стандартная иерархия: презентация, прикладной, доменный и инфра. То, что в 2-3 сервисах из 100, задача на столько проста, что можно не заморачиваться насчет моделек, еще не говорит что нужно городить огород и делать в этих сервисах по разному. Нужно задавать вопрос "на сколько это проблемно завести прикладной сервис, дернуть его из слоя перезентации и отдать данные?".
шаблоны и стандартные решения дают выигрышь в поддержке и разработке, при условии что они применяются правильно (т.е. не превращаются в антишаблоны)
вы искренне верите, что обученные модельки для принятия решения (и наверное обучения) будут использовать оперативные данные? Или вы в монолит еще и аналитические модели запихаете? Или оперативная обработка будет страдать от избыточности и денормализованности?
Что такое простота разработки? Как будете решать проблемы масштабирования разработки? Представьте, что у вас монолит, с кучей подсистем, каждая подсистема (или подмножество) - выделенная команда. Как фичи деплоить? выстраиваться в очередь? Или накидываем фичи в кучу и раз в месяц, методом "большого взрыва" пытаемся заинтегрировать эти фичи и выкатиться в продакшн?
Вы просто скажите - у меня маленькие приложения, с ограниченными числом функций, поэтому у меня монолит. Или "у меня десктопное приложение" - но тут и понятно, что микросервисы как пятое колесо (хотя и здесь есть нюансы).
назовите хоть один орган, который бы дублировал функции другого? не дополняют друг друга или влияют оба на что-то, а именно выполнение один и тех же функций. На давление много что влияет. Так же как и на успешность, скажем, создания заказа в микросервисной или монолитной среде.
так и кровь можно рассматривать под разными углами.
как раз таки про сокрытие. Скрываешь внутрянку, даешь абстракции, значит можешь менять отдельные модули (или абстракции) без влияния на все остальное. Раскрываешь внутрянку - велком искать все зависимости и аккуратно, единомоментно, правильно меняешь их в каждом месте. Или получаешь breaking changes.
И да, ООП это про обмен абстракциями (событиями). Сами глобальные данные скрываются.
видимо мы вообще друг друга не понимаем. Я говорю вам про микросервисы, как способ обойти невозможность масшабирования монолита, а когда такой проблемы нет, то и обходить нечего (стало быть и микросервисы не нужны). Вы мне приводите пример отсутствия проблемы масштабирования (...все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов...).
Мы с вами про разные монолиты говорим. То что вы описываете это монолитный экземпляр, но внутри он устроен весьма грамотно - идеально (обычно на практике все гораздо хуже) - изолированные модули, грамотное разделение ответственности.
Но и здесь вы сами себя обманываете. От того, что вы в один исполнимый файл (кодовую базу) запихаете кучу логики, даже если она будет очень хорошо модулиризирована, проблема интеграции никуда не девается. Кол-во связей компонентов внутри (этих самых методов и типов) не уменьшается. Необходимость иметь узкоспециализированных разрабов модулей никуда не уходит. По большей части разница в транспорте.
Попробуйте-ка поскейлить такой экземпляр монолитный в огромнейшей системе на обработку хотя бы 100К rps (rps rps'у рознь, но кто знает, тот поймет о чем я). Это будет дикая неэффективность, если вообще возможно.
и почему это пример монолита, а не системы, состоящей из микросервисов?
да, а монолит автономен и не требует постоянно поддержки.
давайте. Самому думать и разбираться долго (хоть и полезно), а во всем разбираться и вовсе не получится, поэтому обращаюсь к эксперту. Вот мы только что создали 2 микросервиса. Я эксперт в одном - делаю только свое и делаю это хорошо, а он - свое.
Про доступ к данным я понимаю. Внутрипроцессный доступ он легче и проще, чем межпроцессный, а уж тем более через асинхронные сети. Но число связей то это не уменьшает. Микросервисы это компромисс невозможности масштабирования монолита. И да, за это придется заплатить. Но из двух зол выбирают меньшее, а серебряной пули не бывает.
Ну как у вас могут быть глобальные данные и модульность одновременно? Это противоречие. Не может быть ООП, но с глобальными данными. Его придумали как раз чтобы их скрыть и получили буст в размерах и сложности ПО.
Если какие-то функции могут выполняться в рамках одного процесса, то зачем их дробить на микросервисы и устраивать геморой с общением по сети? Такие вопросы должны задавать себе проектировщики
Есть микросервис специально обученный управлять другими микросервисами. Короче разделение функций. Один отвечает за сеть, другой за ресурсы, третий за пайплайны и т.д. Всех проблем я вам не скажу. Я - микросервис отвечающий за некоторый набор продуктовых функций (надеюсь делаю это хорошо :)).
Человеческий организм. Органы - сервисы, каждый выполняет свою функцию и делает только ее и делает хорошо.
Сложно найти пример монолита, где есть одна большая однородная структура, без иерархии, с дублированием функций. Скорее что-то неэффективное.
Вы очень ошибаетесь и преукрашаете возможности человеческого мозга. Быстрый доступ к данным возможен только по накатанной нейронной колее - например, с чем-то часто работаешь, поэтому быстро можешь на что-то ответить или сделать.
Попробуйте-ка воспользоваться знаниям, которые давно не использовались? вытащить их.
Быстрые данные - полученные интуитивно - очень часто ошибочны. Много исследований на эту тему. Например, можно прочитать труды Канемана. Интуиция и распознание шаблонов - это вообще мимо интеллекта.
Про долгосрочную память можно ознакомиться в трудах Эббингауза.
Сравнение с мозгом некорректно в данном ключе. Либо надо более удачную метафору придумать.
Я работаю в организации, где 6к микросервисов и огромные монолиты под десятки ТБ реляционных данных. Нужно определиться "что такое монолит". У нас монолит - это журнючая БД (или набор БД) работающая под управлением одного экземпляра СУБД, с 10К+ хранимых процедур. Т.е. это ни что иное, как глобальные данные и куча процедурной обработки вокруг, с миллионами связей. Чувствуете пахнет 60мы годами 20ого века? Это стрельба дробью. Порушил связь - беда. И я вам скажу, что в такой монолит очень сложно вносить изменения. Любое мелкое изменение - необходимость менять логику, единомоментно, согласованно в куче мест только внутри БД. Обычно монолит характеризуется еще и внешними зависимостями (поискать связи по репе не такая и проблема, а вот за пределами - сущий ад). И поэтому внесение изменений в монолит это очень большой геморой, с вовлечением большого количества отделов и понятно дело согласований, техкомов, кроссдоменных проектов.
Микросервисная архитектура, при правильном использовании, как раз таки должна решить проблему глобальных данных. Если ты грамотно разделяешь ответственность, если ты умело скрываешь внутрянку, то будет тебе счастье. Но увы. Разработчики очень редко учатся разрабатывать/проектировать. Обычно они больше внимания уделяют инструментам - языкам программирования, базам данных, кафкам и т.д. А проектирование, по большей части, сводится к подражанию. "Мы так всегда делали". "Соседний отдел так делает".
Монолиты к сожалению не масштабируемые - ни по железу, ни по кодовой базе. Со временем, как раз из-за глобальных данных и числа связей, становятся неповоротливым "аппаратным" обеспечением. Но и неправильное применение микросервисных паттернов тоже приводит к такому же.
p.s.: опять же, подчеркну, нужно дать определение монолиту.
Кто сказал, что я могу легко получить доступ к знаниям? Что такое легко?
При чем здесь мой комент и статья?