ну как что, специально продуманный код привязанный к hwid конкретного сервера! Макс, ты че как маленький, вопросы глупые задаешь?)

и тебе привет)

и тебе привет)

привет)

Смотри, у меня есть ручки, у которых rps маленький( их я напишу на питоне) и есть ручки, у которых rps большой (их я напишу на го). Честно, не представляю как это сделать в контексте монолита, чтобы это получилось реально нормально. Всегда в самом начале проекта надо пилить монолит, но после, его может быть слишком сложно поддерживат или то, что я написал выше и тогда микросервисы реально могут помочь.

ты не представляешь, или это невозможно?

Смотри, у меня есть ручки, у которых rps маленький( их я напишу на питоне) и есть ручки, у которых rps большой (их я напишу на го). Честно, не представляю как это сделать в контексте монолита, чтобы это получилось реально нормально. Всегда в самом начале проекта надо пилить монолит, но после, его может быть слишком сложно поддерживат или то, что я написал выше и тогда микросервисы реально могут помочь.

Если для твоей задачи достаточно монолита. Почему бы и не использовать монолит, но есть реальные кейсы, когда микросервисная архитектура может помочь.

Смотри, у меня есть ручки, у которых rps маленький( их я напишу на питоне) и есть ручки, у которых rps большой (их я напишу на го). Честно, не представляю как это сделать в контексте монолита, чтобы это получилось реально нормально. Всегда в самом начале проекта надо пилить монолит, но после, его может быть слишком сложно поддерживат или то, что я написал выше и тогда микросервисы реально могут помочь.

дубль 2: микросервис != deployment unit монолит != single deployment unit для всего приложения

дубль 2: микросервис != deployment unit монолит != single deployment unit для всего приложения

Ну так

у тебя в рамках монолита может быть сколько угодно запускаемых сервисов суть не в скейлинге, а в разделении ответственности и связанности

у тебя в рамках монолита может быть сколько угодно запускаемых сервисов суть не в скейлинге, а в разделении ответственности и связанности

еретик

еретик

сами топите свои урановые микросервисы в ртутных серверах

сами топите свои урановые микросервисы в ртутных серверах

я пол ночи за контексты вещал. Но чёт явно по разному их понимаем.

у тебя в рамках монолита может быть сколько угодно запускаемых сервисов суть не в скейлинге, а в разделении ответственности и связанности

Думал это очевидно. Просто тему разделения ответственности и связанности поднимали до меня и похоже она вас не убедила. В любом случае, если вы ещё не чувствуете сложности в разработке монолита и он не тормозит, используйте монолит.

Думал это очевидно. Просто тему разделения ответственности и связанности поднимали до меня и похоже она вас не убедила. В любом случае, если вы ещё не чувствуете сложности в разработке монолита и он не тормозит, используйте монолит.

Выбор переходить на другую архитектуру или нет зависит от размера проекта.

Думал это очевидно. Просто тему разделения ответственности и связанности поднимали до меня и похоже она вас не убедила. В любом случае, если вы ещё не чувствуете сложности в разработке монолита и он не тормозит, используйте монолит.

если речь идет про ночное обсуждение - как бы контексты не имеют вот ваще ничего общего с тем, на каких языках писать сервисы

больше о контекстах я ничего не видел (кроме сообщений Максима)

@onokonem

Ceph-go кто нить юзает? С релизом mimic у кого-нибудь заработало?

вот серьёзно, что должно случиться с кодом, что бы я его не мог горизонтально маштабировать?)

Завести общий стейт. Например, у тебя чат, все юзаки на вебсокетах, все заоптимизировано и хранится в памяти - все красиво быстро работает. Теперь юзаков стало больше, один сервер не тянет. Пилишь на два - и ррраз - у тебя чат распался на 2. Одна половина юзаков не видит другую. Теперь ты начинаешь городить костыли для обмена списками бзаоков

Завести общий стейт. Например, у тебя чат, все юзаки на вебсокетах, все заоптимизировано и хранится в памяти - все красиво быстро работает. Теперь юзаков стало больше, один сервер не тянет. Пилишь на два - и ррраз - у тебя чат распался на 2. Одна половина юзаков не видит другую. Теперь ты начинаешь городить костыли для обмена списками бзаоков

общей стейт - это не проблема монолитов и его отсутствие - не козырь микросервисов

@onokonem с днём рождения :)

спасибо!

Счастья, сдоровья и пенсию не в 65 )

я намерен сдохнуть за клавиатурой

@onokonem с Днём Рождения!

спасибо!

я намерен сдохнуть за клавиатурой

это не связано с пенсией. Сдохнуть за клавиатурой можно как после пенсии, так и до нее. С Днем Рождения тебя.

Одмины, баньте этих китайцев. Заходите в Manage Group->Recent Actions и там в десктопе правой кнопой по мессаге джойна, а в мобилке - оттуда просто тыкать в польхователя, он будет опказывать профайл и внизу "ban from group"

Первое, что хочу сказать: я не китаец, не баньте)

Медведь, водка, балалайка.

Проиграл с имени

>security >’ or 1=1

Вижу в тебе школьника

Вижу в тебе школьника

Что за шейминг? Это культ кавычки.

Ух, ещё одно токсичное сообщество.

ох, сначала сходи к жавистам потом такое говори) уже улетел бы

общей стейт - это не проблема монолитов и его отсутствие - не козырь микросервисов

Это не особенность, это просто практика ) Когда недостаточно хорошие заборы между компонентами, код начинает слипаться в "грязный ком"

Это не особенность, это просто практика ) Когда недостаточно хорошие заборы между компонентами, код начинает слипаться в "грязный ком"

И те же граждане, что сотворили такой монолит, исправят ситуацию микросервисами?)

получится несколько маленьких комочков, из которых подтекает в соседние

И те же граждане, что сотворили такой монолит, исправят ситуацию микросервисами?)

Подтекать будет. Но не так сильно.

Подтекать будет. Но не так сильно.

я тя умоляю) будет ровно то же самое уг, но с микросервисами :)

не, вместо большого кома УГ, будет несколько комочков уг поменьше ))

так се утешение, если честно)

коллеги, вы все трете за эту херню

коллеги, вы все трете за эту херню

за эту херню тереть будут вечно :)

пока соа вновь не переименуют)

я тя умоляю) будет ровно то же самое уг, но с микросервисами :)

Боюсь, вы не правы. 1. Если у нас отрубиться один сервис, все остальные будут работать. 2. Похоже вы не встречались с большим rps.

Боюсь, вы не правы. 1. Если у нас отрубиться один сервис, все остальные будут работать. 2. Похоже вы не встречались с большим rps.

рпс тут при чём?) блин, что ты чёрт подери такое несёшь?)

соа - это не про рпс)

Потому что можно спокойно запустить один сервер, который будет обрабатывать те же запросы.

В монолите мне нужно запускать весь монолит.

и? в этом есть какая-то связь?)

Если тебе нужна мастштабируемая фигня, ты должен сразу думать не несколько машин вперед. Микросервисы хорошо настраивают на этот лад. Уже этим хорошо.

ясна короче)

ясна короче)

Не слышал про разделение на простые задачи, чтобы код был не лапшой?

ну как что, специально продуманный код привязанный к hwid конкретного сервера! Макс, ты че как маленький, вопросы глупые задаешь?)

самый правильный ответ дня. Хоть и саркастичный, но от истины не далёк

Не слышал про разделение на простые задачи, чтобы код был не лапшой?

я-то как раз слышал :)

Что за шейминг? Это культ кавычки.

Культ ковычки

код лапшой к микросервисам\монолитам аще никак не относится. Хватит всё в кучу мешать

рпс, код лапшой, модна... что дальше-то будет

коллеги, вы про 7 признаков проблемного дизайна слышали

все знакомые мне монолиты выбивают 5 из 7 минимум

но микросервисы - это тупо дорого, поэтому mvp еще долго будут сочинаять монолитным

и спорить тут не о чем

все знакомые мне монолиты выбивают 5 из 7 минимум

что мешает микросервисам, написанным этими же людьми, выбивать 5\7?

не что, а кто. архитектор

тот самый, который допустил 5\7 в монолите?

монолит - это постаревший mvp обычно. к mvp архитектора обычно не допускают, чтобы оно в долгострой не превратилось

ну - так принято сейчас в индустрии

https://habr.com/post/331732/ эти признаки, так? а можно те самые 5 из 7 назвать?

Убить прототип нужна сила воли

монолит - это постаревший mvp обычно. к mvp архитектора обычно не допускают, чтобы оно в долгострой не превратилось

мдя

эти, да

обычно вот эти 5: Жесткость (трудно менять код, так как простое изменение затрагивает много мест); Неподвижность (сложно разделить код на модули, которые можно использовать в других программах); Вязкость (разрабатывать и/или тестировать код довольно тяжело); Плохая Читабельность (трудно понять что код делает, трудно его поддерживать); Хрупкость (легко поломать функционал даже небольшими изменениями);

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

архитектор не падает в особенности реализации, нет?

но я видал и монолиты 7из7

проблема в том, что большинство признаков не относятся к монолитной или микросервисной архитектуре

обычно вот эти 5: Жесткость (трудно менять код, так как простое изменение затрагивает много мест); Неподвижность (сложно разделить код на модули, которые можно использовать в других программах); Вязкость (разрабатывать и/или тестировать код довольно тяжело); Плохая Читабельность (трудно понять что код делает, трудно его поддерживать); Хрупкость (легко поломать функционал даже небольшими изменениями);

это всё не относится к монолитам. Это относится к непониманию программирования, как такового. К понятием контекстов, сцепления и связанности

и можно писать и так и так

это всё не относится к монолитам. Это относится к непониманию программирования, как такового. К понятием контекстов, сцепления и связанности

именно

точно так же можно написать хреновые микросервисы, если недостаточно описать их контракты и их общение друг с другом

это все так

но вы за что топите-то, коллеги?

жесткость, вязкость, хрупкость - фактически следствие высокой связности модулей (coupling)

давайте без капитанства

сразу к тезису

что, наверное, пора заканчивать всякую херню называть микросервисами?) вы ведь чуток умнее эйчаров, которые в требованиях пишут про soa и микросервисы рядом :)

ну например можно обсудить те самые антипаттерны микросервисов)

мы топим за то, чтобы микросервисы не называли серебряной пулей при любых проблемах с разработкой

ну например можно обсудить те самые антипаттерны микросервисов)

google -> udi dahan

это не все, далеко не все

он как-то подзабыл про distributed monoliths

у него плохой код заканчивается на RPC

не вижу связи

он рассказывает про bounded context и пропускает факт, что многие системы имеют разное представление об объекте, например, кастомер для CRM подсистемы - это набор контактных данных + история общения, кастомер для пеймент подсистемы - payment token + история платежей, и так далее

за эту херню тереть будут вечно :)

Пророк.