Я даже знаю, где их применение удачно. В каком-нибудь суперуспешном и супернагруженном проекте. Там где много разрабов, много денег, отлажены процессы и очень много rps. Миллионы. Но при этом от сервисов не требуется рокет саенс. Один микросервис котиков отдаёт, второй сиськи. А мы их масштабируем в зависимости от нагрузки. Ну я так, очень утрировано.
А, знаю этот прикол. Когда делают микросервисы часто упираются в связность взаимодействия. Получается как-бы монолит по связности, но на обслуживание сериализации/десериализации уходит 60% cpu. И плюшки вроде падения в рантайме из-за рассинхрона апишечки.
Про ваш монолит. Поверьте, несколько дней от аппрува до мастера - это ещё очень лайтово. Учитывая количество разрабов кодобазы. Когда количество разрабов растёт, ломаются нахер все ранее работавшие процессы. Лиды не успевают всех ревьюить. Пуш гита прокатывает с 3й или 4й попытки мержа. Репозиторишна опухла или как. У нас была поменьше репа (наверное) в 34гб, но был hg, потому что гиту было с ней ой как плохо.
Ну тут реально пилить надо, Шура. Причём скорее не на сервисы, а на команды, тут больше административных проблем. И решать их сложно. Микросервисы даже тут очень плохая идея. Микросервисы просто перенесут сложность взаимодействия на этап интеграции, по факту ничего не решив и только добавив своей "специфики".
Ну как монолит, только распределённый. Когда пишется большая система, обычно делается монолит, это просто следствие yagni.
Потом, когда (и если) возникает необходимость масштабировать (упирается в rps/cpu/mem), то возникает идея распределить нагрузки на несколько узлов. Самый простой вариант - отделить ту часть, которую можно распараллелить. Тут даже можно запускать один и тот же разный монолит, но с разными ключами, назначив мастер-ноду. Много разных способов существует. Может быть даже каждый монолит со своей БД, завёрнутый в докер. Может они равноправны и ходят в одну БД. Это всё зависит от типа приложения и характера нагрузки, потому что распараллеливание нужно для оптимизации нагрузки.
Да, именно так. Большие проекты сами подталкивают к этому. Но нужен опыт, чтобы смотреть на это не как на статичный код, а как на процесс собственно разработки.
Отделение быстромутирующего кода от фундаментального - это один из принципов. Да, со временем он сам по себе появится. Следование единой терминологии с предметной областью тоже само появляется, когда хочется не запутаться в большом проекте.
Целые книги не знаю, зачем появляются. Я вот сам дошёл до DDD. Может быть это написано для тех, кто не хочет годами сам доходить до этих мыслей. Для тех, кто хочет срезать углы и сразу подготовиться к большим проектам, не наделав на старте ошибок.
Кстати, "документ" - это плохое название для сущности. Это могут быть счета, накладные, акты, договоры или приложения к ним. Да много чего. У каждого документа - своё прикладное значение. И чаще всего он появляется не сам по себе, а как фиксирующая какую-либо информацию сущность у другой сущности, уже из предметной области.
Так смысл перераспределения именно в этом. Базовый закон сложности - это когда сложность одной задачи умножается на сложность другой. При N задачах это всё вырождается в O^N сложность, то есть невозможную.
Смысл управления сложностью как раз в том, чтобы по максимуму оградить каждую задачу от сложностей другой. То есть приблизиться к линейной. К O = (N).
С самой сложностью бороться бесполезно, но её можно сократить до известных пределов.
Монолит - это одно приложение со связанным контекстом и типами.
Микросервисы - это отдельные приложения, не связанные ничем, кроме сетевого апи.
И то и другое может быть хреново написанное. Только у монолит сложнее писать, потому что он требует связность взаимодействия между частями. Поменял одну часть - остальное не скомпилится, пока не привёл в соответствие всех связанных.
Микросервисы проще писать, потому что они ни от кого не зависят. Зато потом вскрывается это "не зависит". Оказывается, что зависит, и ещё как. Но уже в рантайме.
Это не я свёл к бюджету. Это вы. Это вы сказали, что в айти только к срокам и бюджетам риски сводятся. Они точно так же к рискам и бюджету сводятся, как и у бизнеса, даже просто потому, что айти - часть бизнеса.
Вопрос: а зачем все эти пафосные речи? Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
И это победитель нашей сегодняшней викторины!!! Правильно!
После запрета вацапа аудитория преимущественно переползёт в телеграм. Наверное слухи о том, что Паша договаривается с правительством не беспочвенны. Жаль, что потом отрубят и телеграм.
Риски ведения любого реального бизнеса, связанного с физическими объектами и живыми людьми несоизмеримо выше любой разработки, поэтому даже заикаться о рисках в ИТ, что чего‑то там «возможно не получится» — откровенно смешно.
Не смешно. Надо разделять вероятность риска и влияние плохого результата на дальнейшую деятельность. Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Влияние в деньгах на бизнес выше, это правда. Но это компенсируется прибыльностью бизнеса. Бизнес не будет делиться неожиданно высокой прибыльностью с линейным программером, он заберёт всё себе. Как следствие - он не в праве штрафовать программера, если у него появилась куча подводных камней. Да и вообще, программер обещал менять часы работы на деньги, а не впахивать на успех бизнеса.
Еще раз: ни одна предметная область не является "фиксированной"
Ни одно приложение не является "фиксированным". Более того, люди постоянно развивают свои приложения, обрабатывая новые процессы, объективно имеющиеся в предметной области, но до сих пор скрытых.
Прикол в том, что если задумаете убрать бардак (то есть бороться со сложностью), то вы захотите отделить изменчивую бизнес-логику от каркаса приложения. Просто потому что так будет намного легче читать и дорабатывать бизнес-код.
Потом вы захотите эту бизнес-логику типизировать по названиям, чтобы с бизнесом говорить на одном языке. И ещё сделаете иерархию доменных сущностей как в бизнес-процессах. Но доменными сущностями вы их всё равно не будете называть.
А потом покажете людям и скажете: смотрите, я навёл порядок не используя DDD!
Мне останется только усмехнуться тихонечко в стороне. Я же уже это проходил. Конечно, вы не использовали DDD. Вы его породили.
Противоречит. Автор пишет, что распределённый монолит - это ад. А я считаю, что микросервисы - ад и у меня есть веские основания так считать. А распределённый монолит считаю просто нормальной архитектурой, где нет вышеописанных недостатков и позаботились об разделении обязанностей блоков кода. Впрочем, при нормальной архитектуре монолит будет ещё и модульным и тогда требующие распределения части легко вынести в отдельные сервисы. Не микро.
Я даже знаю, где их применение удачно. В каком-нибудь суперуспешном и супернагруженном проекте. Там где много разрабов, много денег, отлажены процессы и очень много rps. Миллионы. Но при этом от сервисов не требуется рокет саенс. Один микросервис котиков отдаёт, второй сиськи. А мы их масштабируем в зависимости от нагрузки. Ну я так, очень утрировано.
А, знаю этот прикол. Когда делают микросервисы часто упираются в связность взаимодействия. Получается как-бы монолит по связности, но на обслуживание сериализации/десериализации уходит 60% cpu. И плюшки вроде падения в рантайме из-за рассинхрона апишечки.
Про ваш монолит. Поверьте, несколько дней от аппрува до мастера - это ещё очень лайтово. Учитывая количество разрабов кодобазы. Когда количество разрабов растёт, ломаются нахер все ранее работавшие процессы. Лиды не успевают всех ревьюить. Пуш гита прокатывает с 3й или 4й попытки мержа. Репозиторишна опухла или как. У нас была поменьше репа (наверное) в 34гб, но был hg, потому что гиту было с ней ой как плохо.
Ну тут реально пилить надо, Шура. Причём скорее не на сервисы, а на команды, тут больше административных проблем. И решать их сложно. Микросервисы даже тут очень плохая идея. Микросервисы просто перенесут сложность взаимодействия на этап интеграции, по факту ничего не решив и только добавив своей "специфики".
Ну как монолит, только распределённый. Когда пишется большая система, обычно делается монолит, это просто следствие yagni.
Потом, когда (и если) возникает необходимость масштабировать (упирается в rps/cpu/mem), то возникает идея распределить нагрузки на несколько узлов. Самый простой вариант - отделить ту часть, которую можно распараллелить. Тут даже можно запускать один и тот же разный монолит, но с разными ключами, назначив мастер-ноду. Много разных способов существует. Может быть даже каждый монолит со своей БД, завёрнутый в докер. Может они равноправны и ходят в одну БД. Это всё зависит от типа приложения и характера нагрузки, потому что распараллеливание нужно для оптимизации нагрузки.
Мало. DDD начинает работать так навскидку от 10 тысяч строк. Да, для работы любого инструмента по управлению сложностью нужна эта самая сложность.
Да, именно так. Большие проекты сами подталкивают к этому. Но нужен опыт, чтобы смотреть на это не как на статичный код, а как на процесс собственно разработки.
Отделение быстромутирующего кода от фундаментального - это один из принципов. Да, со временем он сам по себе появится. Следование единой терминологии с предметной областью тоже само появляется, когда хочется не запутаться в большом проекте.
Целые книги не знаю, зачем появляются. Я вот сам дошёл до DDD. Может быть это написано для тех, кто не хочет годами сам доходить до этих мыслей. Для тех, кто хочет срезать углы и сразу подготовиться к большим проектам, не наделав на старте ошибок.
Кстати, "документ" - это плохое название для сущности. Это могут быть счета, накладные, акты, договоры или приложения к ним. Да много чего. У каждого документа - своё прикладное значение. И чаще всего он появляется не сам по себе, а как фиксирующая какую-либо информацию сущность у другой сущности, уже из предметной области.
Так смысл перераспределения именно в этом. Базовый закон сложности - это когда сложность одной задачи умножается на сложность другой. При N задачах это всё вырождается в O^N сложность, то есть невозможную.
Смысл управления сложностью как раз в том, чтобы по максимуму оградить каждую задачу от сложностей другой. То есть приблизиться к линейной. К O = (N).
С самой сложностью бороться бесполезно, но её можно сократить до известных пределов.
Если вы говорите, что разработка - это сидение попой на стуле, ты вы - [CENSORED].
Всего хорошего.
А, вы Джеки Чана снимаете? Снимаю шляпу, молодцы!
Лида тоже может и не быть. Ну вот вообще. И никто не понимает, что с этим кодом делать. Ну вот физически нет.
Лид ушёл. Что вы будете делать?
ммм... нет.
Монолит - это одно приложение со связанным контекстом и типами.
Микросервисы - это отдельные приложения, не связанные ничем, кроме сетевого апи.
И то и другое может быть хреново написанное. Только у монолит сложнее писать, потому что он требует связность взаимодействия между частями. Поменял одну часть - остальное не скомпилится, пока не привёл в соответствие всех связанных.
Микросервисы проще писать, потому что они ни от кого не зависят. Зато потом вскрывается это "не зависит". Оказывается, что зависит, и ещё как. Но уже в рантайме.
Ага, только нового каскадёра обучать - это дни. А вот нового лида вкурить в курс дела - год. При большом проекте.
Вы там переживёте оцепление, надо будет - постановщика найдёте нового.
Я не понимаю вот чего: а зачем вы так пренебрежительно относитесь к рискам в айти?
Зачем опять вы переходите на личности? В прошлый раз мы мне советовали обратиться к лечащему врачу. Зачем так?
Может быть это вы далеки от реальности айтишной и не понимаете, что тут риски не меньше по амплитуде?
Окей, верно. Но я не про это спрашивал. В чём разница для проекта?
Замена каскадёра тогда тоже не повлияет.
В чём разница?
А, то есть лид проекта не может попасть под автобус, да?
Бюджет
Сроки, возможно бюджет
Это не я свёл к бюджету. Это вы. Это вы сказали, что в айти только к срокам и бюджетам риски сводятся. Они точно так же к рискам и бюджету сводятся, как и у бизнеса, даже просто потому, что айти - часть бизнеса.
Вопрос: а зачем все эти пафосные речи? Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
Например я. Что это меняет в области рисков?
То же, что и все остальные - страховать.
А что, бывают другие риски, кроме сроков и бюджета?
Ну давайте, расскажите про риски бизнеса, которые не в бюджет и не в сроки упираются.
И это победитель нашей сегодняшней викторины!!! Правильно!
После запрета вацапа аудитория преимущественно переползёт в телеграм. Наверное слухи о том, что Паша договаривается с правительством не беспочвенны. Жаль, что потом отрубят и телеграм.
Не смешно. Надо разделять вероятность риска и влияние плохого результата на дальнейшую деятельность. Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Влияние в деньгах на бизнес выше, это правда. Но это компенсируется прибыльностью бизнеса. Бизнес не будет делиться неожиданно высокой прибыльностью с линейным программером, он заберёт всё себе. Как следствие - он не в праве штрафовать программера, если у него появилась куча подводных камней. Да и вообще, программер обещал менять часы работы на деньги, а не впахивать на успех бизнеса.
Ни одно приложение не является "фиксированным". Более того, люди постоянно развивают свои приложения, обрабатывая новые процессы, объективно имеющиеся в предметной области, но до сих пор скрытых.
Прикол в том, что если задумаете убрать бардак (то есть бороться со сложностью), то вы захотите отделить изменчивую бизнес-логику от каркаса приложения. Просто потому что так будет намного легче читать и дорабатывать бизнес-код.
Потом вы захотите эту бизнес-логику типизировать по названиям, чтобы с бизнесом говорить на одном языке. И ещё сделаете иерархию доменных сущностей как в бизнес-процессах. Но доменными сущностями вы их всё равно не будете называть.
А потом покажете людям и скажете: смотрите, я навёл порядок не используя DDD!
Мне останется только усмехнуться тихонечко в стороне. Я же уже это проходил. Конечно, вы не использовали DDD. Вы его породили.
Противоречит. Автор пишет, что распределённый монолит - это ад. А я считаю, что микросервисы - ад и у меня есть веские основания так считать. А распределённый монолит считаю просто нормальной архитектурой, где нет вышеописанных недостатков и позаботились об разделении обязанностей блоков кода. Впрочем, при нормальной архитектуре монолит будет ещё и модульным и тогда требующие распределения части легко вынести в отдельные сервисы. Не микро.