Не не не. Это либо не очевидно, либо "не те слои". Нормальная архитектура, модульная, как раз позволяет нормально порезать прилу на кучу слоёв, и потом менять и заменять их. Сейчас же в отрасти очень много "фейков", и подмены понятий, в т.ч. отсутствие правильного понимания паттернов проектирования, и их подмена. Что в итоге приводит именно к тому самому "монолиту" (слипшемуся куску), в котором гибкости ноль и распилить его просто невозможно. Я об этом.
Все программные компоненты монолитной системы взаимозависимы из-за использования встроенных механизмов обмена данными внутри системы. Модификация монолитной архитектуры возможна лишь частично и занимает много времени, поскольку даже небольшие изменения затрагивают большие области базы кода.
Если же мы ведём речь о нормальном гибком проекте, с модульной архитектурой, тогда назвать его "монолитом" уже язык не поворачивается. Пилится на куски такой проект довольно легко, и модули легко заменяются или правятся. Собрать из такого проекта какой-то "новый", с небольшим допилом, тоже вполне тривиальная задача.
Даже в статье Амазона о монолитах и микросервисах много лукавства. Хотя и фактов тоже полно. Очевидно отражена бОльшая сложность микросервисной архитектуры, и неимоверная сложность её отладки.
В плюсы микросервисов же скопом засунули "все недостатки" "монолитов". Т.е. изначально из крайности в крайность. Гибкой модульной архитектуры Амазон даже не предполагает. И либо неделимый монолит (без модулей и изоляций) либо "волшебные" (на деле ни разу) микросервисы.
Из крайности в крайность в общем. О чём я и пишу уже в сотый раз. Истина же в том, чтобы не впадать в крайности и следовать канонам программирования, известным уже более полувека.
А такую задачу "быстрого старта" кто-то ставил вообще? Может если её поставить перед разрабами, то они её решат? Может такую задачу никто и не ставил только потому, что её решение не нужно?
так в этом и суть и статьи и обсуждений, что по итогу микросервисы засунули везде, в 99% случаях туда где нельзя, притом сделали их не десяток или сотню, а тысячи. Но и этого было мало. Даже архиекторов не нашли под это.
Для всех этих проектов набрали толпы студентов, которые ни разу не за копейки быдлокодят просто тоннами, и кучу всего этого "кода" невозможно собрать по итогу ни во что. Зато модно! Задачи все завалены, зато весело бабло распилили (результата нет). Как то так.
Проектировать надо. Если проектировщик - инженер. Ну и "не надо" (он не сможет), если проектировщик модный студент.
Кого где нет? Кадров полно, но проблема сейчас как раз в том, что у рулят в индустрии именно студенты-лиды, набирающие в проекты таких же студентов. Опытные разрабы им не указ! Мания величия там просто запредельная! Им почему-то кажется, что стадо из 20 студентов способно заменить одного реального гуру. По итогу (100й раз это напишу) весть проект они превращают в "кашу". То кашу из плохих микросервисов, то в застывшую кашу неподъёмного монолитного блока.
Из джунов как получаются мидлы и сеньоры? Серьёзно? Вы реально не знаете? Надо объяснить?
У меня была личная беседа не так давно с одним "мидлом" (в МТСе) , притом он сам признался что по-сути он даже не джун и ничерта не понимает в программировании, архитектуре и т.п. .Он диплом в том году получил. Да и то диплом был получен ради получения. Не вспомню точно чем он занимается на проекте, то ли документацией и требованиями, толи каким-то тестированием, врать не хочу. Но точно помню что он на должности мидла и при этом сам на 100500% знает что даже на 1% ей не соответствует.
Кстати они там наелись микросервисов и избавляются от них полностью (с его слов).
Странно у вас как-то получатся. То ЯП зачем-то должен "заменять" архитекта в проекте, добавляя лишние изоляции. Ну ладно, пропустим это, хотя в наших проектах разрабу всегда давался полный доступ до всего, а СКПД уже резала клиентам доступы. Мы (разрабы) при этом чётко всегда понимали, что такое архитектура и как она важна, и нам и в голову не приходило наваять 20-50 лишних строк кода, для прямого доступа к базе или морде, если ядро предоставляет те же возможности само, и для управления фичей надо написать 1-2 строки. Бог с ним. Проехали.
То наоборот на бедного архитекта взвалена вся куча ответственности... и за кого? За кодеров - студентов. Которые про архитектуру может и слышали, да и то это не факт.
Почему-то смешно для вас не допущение этих же самых студентов на реальные боевые проекты.
Вот это для меня странно. Но сейчас индустрия именно так и выстроена, что кодят одни студенты, и тим лиды буквально вчера универ закончившие. На собесах определения разные спрашивают и кучу оторванной от практики теории. Т.е. по сути и не лиды вовсе, и даже до уровня мидлов не дотянувшие, но лиды.
Сразу становится ясно, что тим лид теоретик, вгрёб кучу проблем, и пытается их решить добавляя в проект "свежую кровь". Притом пропустит он в проект таких же студентов как он сам. Т.е. ничего он по итогу не решит.
Отсюда и такие перекосы в девелопменте, ибо проектируют, архитектурят и кодят проекты, люди по-сути далёкие от программирования и вообще не обладающие необходимыми для полноценной реализации проектов навыками. Как и кто их вообще на работу взял, лично для меня остаётся загадкой.
В итоге в отрасли реально 2 крайности, одни лепят монолиты, притом стойко нарушая все базовые принципы индустрии, и ваяя по итогу тот самый нерушимый и неподдерживаемый монолит, который с каждой итерацией кодить всё дольше и сложнее (сюда же не я отношу проекты, в которых код вынесли на уровень БД в язык запросов - тот или иной SQL, забыв что ЯЗ это не ЯП).
Ну либо описанные тут микросервисы, т.е. рой мух различного размера, формы и цвета, которые даже теоретически никогда не соберутся в одну единую конструкцию. Молчу уж о её "стройности" и всём остальном.
Но удручает то, что вы считаете что за весь этот хоровод и рой мух, должен отвечать лишь один архитект, и на проект можно запустить студентов, вообще без опыта и знаний. Ну тогда и результат будет вполне логичным и предсказуемым. Студенты напишут на коленке спагетти-код, разбросают его повсюду так, чтоб ты обязательно в него вляпался по полной. А самые ответственные из них напишут в коде комментарии, что им самим стыдно за то что они написали, и они дико сочувствуют всем тем, кто после них будет вынужден разбираться в этом всём "коде" (лично видел такие комменты).
ПыС Если у архитектора опыта мало, кто его блин взял в архитекты??? Пусть сидит джунит тогда.
а зачем им общаться по сети (туда-сюда гонять данные и тратить память на копии и проц на упаковку/распаковку данных), если их можно сразу друг на друга завязать в едином модуле / сервисе?
Извините, вы статью прочитали хоть? Сервис это не микросервис. Это совершенно разные понятия.
Что за неожиданные для всех изменения? Впервые слышу о подобном цирке в проекте. В проект пришёл террорист и решил бомбануть базу кода, всем нападлив? Если нет, тогда всё для всех вполне ожидаемо, продумано и обсуждается заранее.
Вам надо разжевать смысл термина микросервис? Именно микро! Прочитайте хотя бы статью.
кучу бабла вливать сразу не надо, это глупо. тем не менее не надо "плевать на каноны" программирования. на старте можно вполне создать допустим 5 модулей / слоёв, и реализовать их "на коленке" каждый. Но строго с изоляцией слоёв, дабы сразу не превратить стройную систему в "месево" и кусок не пойми чего.
В дальнейшем с развитием проекта каждый модуль обязан жить отдельной жизнью и развиваться строго отдельно (т.е. сохраняя изоляцию). По итогу модули/уровни абстракции могут добавляться, что даёт проекту дополнительную гибкость (раз) и позволяет на том же ядре запускать другие (похожие) проекты с незначительными доработками (два). Т.е. это обыкновенные канонизированные повторное использование кода и рефакторинг. Это всё та же суть паттернов SOLID, DRY, KISS, MVC, плагины, многозвенка.
Получившееся ядро позволит запускать практически любые проекты, и интегрировать разные подсистемы бизнеса в единую платформу.
ПыС и ещё раз. Главное не забывать основные каноны программирования и не забивать на них. К сожалению очень многие вообще плюют на архитектуру и с первого дня начинают лепить тя-ляп. Да и лиды (очень часто сталкиваюсь с таким) вообще не имеют компетенций архитекторов и соответствующего опыта. Это прям бич какой-то в индустрии.
мне кажется у вас много "теории" в микросервисах, если вы считаете их меньшим злом. ну и языки программирования. Причём тут вообще язык? Архитектура и паттерны не зависят от языка, более того мы "реализовывали" (в т.ч. генерировали) одни и те модели на разных ЯПах. Что не исключило ни требований по архитектуре, ни изоляции уровней/слоёв.
Допускать слипания в комок конечно нельзя от слова совсем. И "студентов" (вечных джунов) тоже допускать на проект нет никакого смысла. Тем не менее практически вся индустрия сейчас страдает от полного отсутствия архитектуры, от полного игнорирования требований, которым уже "сто лет в обед", путём разведения сказок о волшебности микросервисов. Ничего из описанного вами микросервисы не решали и не решают. А вот архитектуру уничтожают полностью, от слова совсем. Каждый кодит как он хочет. Итогом такого подхода является полное уничтожение стройности систем, и огромнейший зверинец/зоопарк, не поддающийся ни контролю, ни управлению, ни грамотным поддержке и развитию. Цирк цирком в итоге. Притом с клоунами. Хотя нет, в цирке хотя бы дрессируют животных, а в микросервисах свободная свобода делать всё что хочешь, забив на все каноны программирования.
ПыС как архитектор может быть "не достаточно хорош" ? И как отсутствие архитектора заменяют микросервисы??? Никак! Микросервисы только усиливают проблемы при отсутствии архитектора и архитектуры! И код там "аля фулл стек" зачастую уровня "я джун (студент) и 1й день на проекте, потому мне самому стыдно" .
у вас крайности, ау. Разрезать / разделить изначально "монолит" на 5-10 слоёв это точно не микро сервисы. И даже не сервисы. Да и я ничего не изобретал. Всё изобретено задолго до нас.
А вам порекомендую не ударятся в крайности и находить золотую середину. В том числе не использовать микросервисы, а и следовало, использовать модули, плагины и сервисы (не микро!), заточенные под свои нужды и задачи.
сколько я написал ORM-ядер, ни разу мне не приходилось думать о вышеописанном. ЧЯДНТ?
Может быть "странно", но мои ОРМки вполне сами справлялись со всем маппингом, в т.ч. всех связей. И т.к. бизнес-модель и модель БД генерируемые, и отражающие мает описание бизнес-модели, то и нет ни малейшей вероятности отличия этих моделей друг от друга.
Зачем вам лишний "DLL Hell" в голове? Что мешает точно "бит в бит" зеркалить модели?
Тут не совсем так, или совсем не так. Модульность и модульная архитектура изначально предполагают как раз возможность отключения модулей/плагинов, их заменяемость, а также возможность их переписать.
Монолит же зачастую (вижу это почти во всех проектах сейчас) это как раз способ "положить кое что" на архитектуру и сидеть ручками кодить кучу спагетти-легаси кода, забив на все паттерны проектирования, или исказив их до неузнаваемости.
Следствие такого подхода к программированию, т.е. игнорирование требований архитектуры, приводит именно к тому, что монолит становится именно монолитом, который практически нельзя распилить. В нём тупо нет ни одного модуля или слоя. Отделять тупо нечего. Таких проектов сейчас в продакшене очень и очень много, если не все.
(Кстати микросервисы тоже страдают архитектурными проблемами.)
По сути это ежедневное игнорирование базовых архитектурных требований, что приводит в непоправимым архитектурным проблемам. Распилить такой монолит просто невозможно. И чем дольше "команда" работает с этим монолитом, тем всё становится хуже и хуже с каждым днём. Разработка всё сложнее и дольше с каждой итерацией.
Если бы выполнялись базовые архитектурные требования, и приложение было бы чётко и строго разделено на различные слои в т.ч. с дополнительными уровнями абстракций (у меня в ORMке к примеру 3 уровня абстракций, как и в модулях генерации морд), то заменяемость модулей вообще не была бы проблемой. Любой модуль можно было бы совершенно безболезненно выкинуть и заменить аналогичным.
В итоге в случае необходимости нужно было бы допилить / переписать (хотя скорее просто обернуть сервисами) пару модулей и всё. При этом это ведь требование базовых паттернов проектирования (SOLID, KISS, DRY, MVC). Но очень многие в индустрии их не понимают вообще и путают. Недавно один герой заявил мне к примру что паттерн MVC вообще касается только ASP.Net и всё. Кайф. А ведь он тим лид и под ним команда из 20 таких же заблудших айтишников.
Резюме: Если изначально соблюдать архитектурные требования, то и софт (мягенький) можно было бы легко и быстро адаптировать под ситуацию и задачи. Ну а если не соблюдать, то можно лепить большие монолиты или кучи мухосервисов.Что как по мне две крайности.
Хайпы и хейты это вопросы базовой психологии человека. Обычно человека в первую необразованного! Т.е. далеко не инженера!! Человека, который подвержен прежде всего мимолётным эмоциям, а не здравым рассуждениям. Инженеры основываются в своей работе знанием, расчётами и опытом, а не модными фичами и хайпами с хейтами.
Да и любые хайпы грамотные инженеры, прежде чем запускать их в работу, сначала проверят на себе (если дураки и учатся на своих ошибках), ну или посмотрят реальные "успешные" истории других (или неуспешные, учиться надо на чужих ошибках). Изначально любые новшевства (так уж природой заложено) обязаны восприниматься в штыки, пока не доказана их явная польза.
Вопрос же в том, что индустрия вся поголовно отказалась от мозгов и инженерных подходов, и полезла хайповать хрен знает куда. А теперь распробовав сей горький (но вполне предсказуемый) вкус (по сути отсутствия пользования могом) начинается вполне закономерный хейт. Ведь по-сути вся индустрия "в дураках", и "повелась" на "модные фичи".
Стоп стоп стоп. Объясните мне глупому, что мешает в первый же день (нулевой) заложить в архитектуру "монолита" 5-10 слоёв? Отделить сразу мух от котлет? Ну хотя бы из уважения к SOLID, KISS, DRY и MVC ?? Зачем изначально закладывать в проект бомбу замедленного действия? Можно ведь разделить слои данных, логики и морд, в первый же день проектирования всего приложения. Какие могут быть оправдания игнорированию базовых архитектурных требований?
если это один хост, зачем вообще тогда гонять туда-сюда данные, создавая по-сути лишние их копии,и тупо поедая ресурсы? Притом поедается как и память на хранение лишних копий данных, так и процессорное время на сериализацию и десериализацию данных, зачастую не бинарных.
Не не не. Это либо не очевидно, либо "не те слои".
Нормальная архитектура, модульная, как раз позволяет нормально порезать прилу на кучу слоёв, и потом менять и заменять их.
Сейчас же в отрасти очень много "фейков", и подмены понятий, в т.ч. отсутствие правильного понимания паттернов проектирования, и их подмена. Что в итоге приводит именно к тому самому "монолиту" (слипшемуся куску), в котором гибкости ноль и распилить его просто невозможно. Я об этом.
Все программные компоненты монолитной системы взаимозависимы из-за использования встроенных механизмов обмена данными внутри системы. Модификация монолитной архитектуры возможна лишь частично и занимает много времени, поскольку даже небольшие изменения затрагивают большие области базы кода.
(Амазон) Ключевые отличия монолитной архитектуры от микросервисов
Если же мы ведём речь о нормальном гибком проекте, с модульной архитектурой, тогда назвать его "монолитом" уже язык не поворачивается. Пилится на куски такой проект довольно легко, и модули легко заменяются или правятся.
Собрать из такого проекта какой-то "новый", с небольшим допилом, тоже вполне тривиальная задача.
Даже в статье Амазона о монолитах и микросервисах много лукавства. Хотя и фактов тоже полно. Очевидно отражена бОльшая сложность микросервисной архитектуры, и неимоверная сложность её отладки.
В плюсы микросервисов же скопом засунули "все недостатки" "монолитов". Т.е. изначально из крайности в крайность.
Гибкой модульной архитектуры Амазон даже не предполагает. И либо неделимый монолит (без модулей и изоляций) либо "волшебные" (на деле ни разу) микросервисы.
Из крайности в крайность в общем. О чём я и пишу уже в сотый раз.
Истина же в том, чтобы не впадать в крайности и следовать канонам программирования, известным уже более полувека.
А такую задачу "быстрого старта" кто-то ставил вообще?
Может если её поставить перед разрабами, то они её решат?
Может такую задачу никто и не ставил только потому, что её решение не нужно?
так в этом и суть и статьи и обсуждений, что по итогу микросервисы засунули везде, в 99% случаях туда где нельзя, притом сделали их не десяток или сотню, а тысячи. Но и этого было мало. Даже архиекторов не нашли под это.
Для всех этих проектов набрали толпы студентов, которые ни разу не за копейки быдлокодят просто тоннами, и кучу всего этого "кода" невозможно собрать по итогу ни во что. Зато модно! Задачи все завалены, зато весело бабло распилили (результата нет). Как то так.
Проектировать надо. Если проектировщик - инженер. Ну и "не надо" (он не сможет), если проектировщик модный студент.
как у вас всё просто, выглядит прям сказочно.
Ну а я, конечно же, в сказки не верю.
Да и архитектора жалко прям. Не архитектор, а козёл отпущения прям.
Быдлокодят одни, а отвечать ему. Так себе радость.
Кого где нет? Кадров полно, но проблема сейчас как раз в том, что у рулят в индустрии именно студенты-лиды, набирающие в проекты таких же студентов. Опытные разрабы им не указ! Мания величия там просто запредельная! Им почему-то кажется, что стадо из 20 студентов способно заменить одного реального гуру. По итогу (100й раз это напишу) весть проект они превращают в "кашу". То кашу из плохих микросервисов, то в застывшую кашу неподъёмного монолитного блока.
Из джунов как получаются мидлы и сеньоры? Серьёзно? Вы реально не знаете? Надо объяснить?
У меня была личная беседа не так давно с одним "мидлом" (в МТСе) , притом он сам признался что по-сути он даже не джун и ничерта не понимает в программировании, архитектуре и т.п. .Он диплом в том году получил. Да и то диплом был получен ради получения.
Не вспомню точно чем он занимается на проекте, то ли документацией и требованиями, толи каким-то тестированием, врать не хочу. Но точно помню что он на должности мидла и при этом сам на 100500% знает что даже на 1% ей не соответствует.
Кстати они там наелись микросервисов и избавляются от них полностью (с его слов).
ого. Архитект во всём крайний теперь (жаль его, застрелится же)? А вместо адекватных разрабов студентов наберём?
Странно у вас как-то получатся. То ЯП зачем-то должен "заменять" архитекта в проекте, добавляя лишние изоляции. Ну ладно, пропустим это, хотя в наших проектах разрабу всегда давался полный доступ до всего, а СКПД уже резала клиентам доступы. Мы (разрабы) при этом чётко всегда понимали, что такое архитектура и как она важна, и нам и в голову не приходило наваять 20-50 лишних строк кода, для прямого доступа к базе или морде, если ядро предоставляет те же возможности само, и для управления фичей надо написать 1-2 строки. Бог с ним. Проехали.
То наоборот на бедного архитекта взвалена вся куча ответственности... и за кого? За кодеров - студентов. Которые про архитектуру может и слышали, да и то это не факт.
Почему-то смешно для вас не допущение этих же самых студентов на реальные боевые проекты.
Вот это для меня странно. Но сейчас индустрия именно так и выстроена, что кодят одни студенты, и тим лиды буквально вчера универ закончившие. На собесах определения разные спрашивают и кучу оторванной от практики теории. Т.е. по сути и не лиды вовсе, и даже до уровня мидлов не дотянувшие, но лиды.
Сразу становится ясно, что тим лид теоретик, вгрёб кучу проблем, и пытается их решить добавляя в проект "свежую кровь". Притом пропустит он в проект таких же студентов как он сам. Т.е. ничего он по итогу не решит.
Отсюда и такие перекосы в девелопменте, ибо проектируют, архитектурят и кодят проекты, люди по-сути далёкие от программирования и вообще не обладающие необходимыми для полноценной реализации проектов навыками. Как и кто их вообще на работу взял, лично для меня остаётся загадкой.
В итоге в отрасли реально 2 крайности, одни лепят монолиты, притом стойко нарушая все базовые принципы индустрии, и ваяя по итогу тот самый нерушимый и неподдерживаемый монолит, который с каждой итерацией кодить всё дольше и сложнее (сюда же не я отношу проекты, в которых код вынесли на уровень БД в язык запросов - тот или иной SQL, забыв что ЯЗ это не ЯП).
Ну либо описанные тут микросервисы, т.е. рой мух различного размера, формы и цвета, которые даже теоретически никогда не соберутся в одну единую конструкцию. Молчу уж о её "стройности" и всём остальном.
Но удручает то, что вы считаете что за весь этот хоровод и рой мух, должен отвечать лишь один архитект, и на проект можно запустить студентов, вообще без опыта и знаний. Ну тогда и результат будет вполне логичным и предсказуемым. Студенты напишут на коленке спагетти-код, разбросают его повсюду так, чтоб ты обязательно в него вляпался по полной. А самые ответственные из них напишут в коде комментарии, что им самим стыдно за то что они написали, и они дико сочувствуют всем тем, кто после них будет вынужден разбираться в этом всём "коде" (лично видел такие комменты).
ПыС Если у архитектора опыта мало, кто его блин взял в архитекты??? Пусть сидит джунит тогда.
а зачем им общаться по сети (туда-сюда гонять данные и тратить память на копии и проц на упаковку/распаковку данных), если их можно сразу друг на друга завязать в едином модуле / сервисе?
да, это именно крайности. И в них впадать нельзя.
золотая середина (и давно) - это гибкая архитектура, но без фанатизма.
вот не знаю зачем такие тренды поддерживаются. Но как по мне, всё это от отсутствия знаний и опыта.
Извините, вы статью прочитали хоть? Сервис это не микросервис. Это совершенно разные понятия.
Что за неожиданные для всех изменения? Впервые слышу о подобном цирке в проекте. В проект пришёл террорист и решил бомбануть базу кода, всем нападлив? Если нет, тогда всё для всех вполне ожидаемо, продумано и обсуждается заранее.
Вам надо разжевать смысл термина микросервис? Именно микро! Прочитайте хотя бы статью.
кучу бабла вливать сразу не надо, это глупо.
тем не менее не надо "плевать на каноны" программирования.
на старте можно вполне создать допустим 5 модулей / слоёв, и реализовать их "на коленке" каждый. Но строго с изоляцией слоёв, дабы сразу не превратить стройную систему в "месево" и кусок не пойми чего.
В дальнейшем с развитием проекта каждый модуль обязан жить отдельной жизнью и развиваться строго отдельно (т.е. сохраняя изоляцию). По итогу модули/уровни абстракции могут добавляться, что даёт проекту дополнительную гибкость (раз) и позволяет на том же ядре запускать другие (похожие) проекты с незначительными доработками (два). Т.е. это обыкновенные канонизированные повторное использование кода и рефакторинг.
Это всё та же суть паттернов SOLID, DRY, KISS, MVC, плагины, многозвенка.
Получившееся ядро позволит запускать практически любые проекты, и интегрировать разные подсистемы бизнеса в единую платформу.
ПыС и ещё раз. Главное не забывать основные каноны программирования и не забивать на них. К сожалению очень многие вообще плюют на архитектуру и с первого дня начинают лепить тя-ляп. Да и лиды (очень часто сталкиваюсь с таким) вообще не имеют компетенций архитекторов и соответствующего опыта. Это прям бич какой-то в индустрии.
мне кажется у вас много "теории" в микросервисах, если вы считаете их меньшим злом.
ну и языки программирования. Причём тут вообще язык? Архитектура и паттерны не зависят от языка, более того мы "реализовывали" (в т.ч. генерировали) одни и те модели на разных ЯПах. Что не исключило ни требований по архитектуре, ни изоляции уровней/слоёв.
Допускать слипания в комок конечно нельзя от слова совсем. И "студентов" (вечных джунов) тоже допускать на проект нет никакого смысла.
Тем не менее практически вся индустрия сейчас страдает от полного отсутствия архитектуры, от полного игнорирования требований, которым уже "сто лет в обед", путём разведения сказок о волшебности микросервисов. Ничего из описанного вами микросервисы не решали и не решают.
А вот архитектуру уничтожают полностью, от слова совсем. Каждый кодит как он хочет. Итогом такого подхода является полное уничтожение стройности систем, и огромнейший зверинец/зоопарк, не поддающийся ни контролю, ни управлению, ни грамотным поддержке и развитию. Цирк цирком в итоге. Притом с клоунами. Хотя нет, в цирке хотя бы дрессируют животных, а в микросервисах свободная свобода делать всё что хочешь, забив на все каноны программирования.
ПыС как архитектор может быть "не достаточно хорош" ? И как отсутствие архитектора заменяют микросервисы??? Никак! Микросервисы только усиливают проблемы при отсутствии архитектора и архитектуры! И код там "аля фулл стек" зачастую уровня "я джун (студент) и 1й день на проекте, потому мне самому стыдно" .
у вас крайности, ау. Разрезать / разделить изначально "монолит" на 5-10 слоёв это точно не микро сервисы. И даже не сервисы.
Да и я ничего не изобретал. Всё изобретено задолго до нас.
А вам порекомендую не ударятся в крайности и находить золотую середину.
В том числе не использовать микросервисы, а и следовало, использовать модули, плагины и сервисы (не микро!), заточенные под свои нужды и задачи.
ПыС я не управляю зоопарками. Я интегратор.
джоины от лукавого. ORM обязана работать без них.
крипта? Недвига? Диверсификация рисков???
сколько я написал ORM-ядер, ни разу мне не приходилось думать о вышеописанном. ЧЯДНТ?
Может быть "странно", но мои ОРМки вполне сами справлялись со всем маппингом, в т.ч. всех связей. И т.к. бизнес-модель и модель БД генерируемые, и отражающие мает описание бизнес-модели, то и нет ни малейшей вероятности отличия этих моделей друг от друга.
Зачем вам лишний "DLL Hell" в голове? Что мешает точно "бит в бит" зеркалить модели?
Тут не совсем так, или совсем не так. Модульность и модульная архитектура изначально предполагают как раз возможность отключения модулей/плагинов, их заменяемость, а также возможность их переписать.
Монолит же зачастую (вижу это почти во всех проектах сейчас) это как раз способ "положить кое что" на архитектуру и сидеть ручками кодить кучу спагетти-легаси кода, забив на все паттерны проектирования, или исказив их до неузнаваемости.
Следствие такого подхода к программированию, т.е. игнорирование требований архитектуры, приводит именно к тому, что монолит становится именно монолитом, который практически нельзя распилить. В нём тупо нет ни одного модуля или слоя. Отделять тупо нечего. Таких проектов сейчас в продакшене очень и очень много, если не все.
(Кстати микросервисы тоже страдают архитектурными проблемами.)
По сути это ежедневное игнорирование базовых архитектурных требований, что приводит в непоправимым архитектурным проблемам. Распилить такой монолит просто невозможно. И чем дольше "команда" работает с этим монолитом, тем всё становится хуже и хуже с каждым днём. Разработка всё сложнее и дольше с каждой итерацией.
Если бы выполнялись базовые архитектурные требования, и приложение было бы чётко и строго разделено на различные слои в т.ч. с дополнительными уровнями абстракций (у меня в ORMке к примеру 3 уровня абстракций, как и в модулях генерации морд), то заменяемость модулей вообще не была бы проблемой. Любой модуль можно было бы совершенно безболезненно выкинуть и заменить аналогичным.
В итоге в случае необходимости нужно было бы допилить / переписать (хотя скорее просто обернуть сервисами) пару модулей и всё.
При этом это ведь требование базовых паттернов проектирования (SOLID, KISS, DRY, MVC). Но очень многие в индустрии их не понимают вообще и путают.
Недавно один герой заявил мне к примру что паттерн MVC вообще касается только ASP.Net и всё. Кайф. А ведь он тим лид и под ним команда из 20 таких же заблудших айтишников.
Резюме: Если изначально соблюдать архитектурные требования, то и софт (мягенький) можно было бы легко и быстро адаптировать под ситуацию и задачи.
Ну а если не соблюдать, то можно лепить большие монолиты или кучи мухосервисов.Что как по мне две крайности.
Хайпы и хейты это вопросы базовой психологии человека. Обычно человека в первую необразованного! Т.е. далеко не инженера!! Человека, который подвержен прежде всего мимолётным эмоциям, а не здравым рассуждениям.
Инженеры основываются в своей работе знанием, расчётами и опытом, а не модными фичами и хайпами с хейтами.
Да и любые хайпы грамотные инженеры, прежде чем запускать их в работу, сначала проверят на себе (если дураки и учатся на своих ошибках), ну или посмотрят реальные "успешные" истории других (или неуспешные, учиться надо на чужих ошибках). Изначально любые новшевства (так уж природой заложено) обязаны восприниматься в штыки, пока не доказана их явная польза.
Вопрос же в том, что индустрия вся поголовно отказалась от мозгов и инженерных подходов, и полезла хайповать хрен знает куда. А теперь распробовав сей горький (но вполне предсказуемый) вкус (по сути отсутствия пользования могом) начинается вполне закономерный хейт. Ведь по-сути вся индустрия "в дураках", и "повелась" на "модные фичи".
А ведь это программирование, а не мир фейшена.
Стоп стоп стоп. Объясните мне глупому, что мешает в первый же день (нулевой) заложить в архитектуру "монолита" 5-10 слоёв? Отделить сразу мух от котлет? Ну хотя бы из уважения к SOLID, KISS, DRY и MVC ??
Зачем изначально закладывать в проект бомбу замедленного действия?
Можно ведь разделить слои данных, логики и морд, в первый же день проектирования всего приложения.
Какие могут быть оправдания игнорированию базовых архитектурных требований?
если это один хост, зачем вообще тогда гонять туда-сюда данные, создавая по-сути лишние их копии,и тупо поедая ресурсы? Притом поедается как и память на хранение лишних копий данных, так и процессорное время на сериализацию и десериализацию данных, зачастую не бинарных.