Почему монолит предпочтительней микросервисов?

Приветствую, мои дорогие. В этом выпуске обсудим, что предпочтительнее монолит или микросервисы?

‍💻 Регистрируйся на курсы для будущих Python-разработчиков ⬇️⬇️⬇️

Курсы для будущих JS-разработчиков:

Курсы для будущих Java-разработчиков:

Курсы для будущих С#-разработчиков:

🎓 Другие направления:

🎓Продвинутые курсы для состоявшихся девелоперов:

Тайминг:
00:00 - Вступление
00:26 - Что такое монолит?
00:55 - Преимущества монолитной архитектуры
02:27 - Недостатки монолитов
03:28 - Python
06:16 - Микросервисы
06:51 - Преимущества микросервисов
09:12 - Недостатки микросервисов
15:25 - Что же выбрать? Призыв к оценке конкретных потребностей проекта при выборе архитектуры.

[РоманДейкаловский]

Наконец то не про джунов и какой язык выбрать. Тема зачётная. Даже отвлёкся от работы.

[Kirmakoff]

Если быть реалистами, то плохой монолит лучше, чем плохие микросервисы. А хороший монолит и хорошие микросервисы никто нигде не видел 🙂

Респект Сергею за то, что не побоялся поднять острую тему

[ЮрийКарпов-эч]

В микросервисах еще не раскрыты темы транзакционной целостности, каскадных откатов, саг, оркестрации, дебага и т.д. там тоже всплывает куча проблем) ну и конечно размер команды...и перекладывание оргструктуры на микросервисы. Одна команда - один сервис - две пиццы.

[ДенисДенис-цв]

Сергей, спасибо за видео.
Это какая-то магия.
Пришло уведомление о новом видео на вашем канале, посмотрел и поехал на собес.
И о чем вы думаете меня спросили??? 😁
Какие плюсы и минусы у монолита и микросервисов 🤣
Спасибо, прям вовремя.
Офер пока не получил, но всё прошло норм.

[Владислав-ещъ]

Очередное видео с ошибкой в названии. Правильное: "Java - самый лучший ЯП"

[zikimzikilus]

Да, только не совсем удобно разрабатывать монолит когда у тебя 100+ разработчиков. Сразу получаем деплои по расписанию, а не тогда когда хочешь ты или твоя команда, деплои будут переноситься почти каждый раз ибо кто-то где-то что-то сломал. Так же в рамках монолита будет сложнее поддерживать логические границу между модулями, в рамках микросервисов эти логические границы можно укрепить физическими. Безусловно микросервисы несут в себе кучу других проблем и головных болей, но говорить что микросервисы нужно только если у вас не строго типизированный язык точно не корректно.

[murchenko]

Не слова не сказал про то что микросервисы легче масштабировать в ширь. При монолите при большой нагрузке - пойдёте поднимать кол-во инстансов монолитов. В этом и основной смысл микросервисов.
Масштабирование будет намного дешевле чем монолита

[Yurec]

Сижу на монолите, но он разбит на модули

[aTbKa_MaxHo]

За монолит! Не Долг со Свободой же выбирать 😁

[VitaliiYakovlev-lk]

Не согласен с тем, что микросервисы выбирают потому что они "модные" и что они подходят только для проекта написанных на языках с динамической типизацией. Микросервисы усложняют систему в целом, но значительно упрощают работу для одной конкретной команды.
Я сталкивался с проектами (на java), в которых один "жирный" сервис может билдиться около получаса. И это только лишь один из сервисов. Если бы проект был бы монолитом, то он бы наверное билдился бы больше суток. В такой системе "хот фикс" можно было бы отменить. Особенно будет весело когда в самом конце билда подобного монолита билд по какой-то причине зафейлиться, тогда впереди ждёт следующее испытание: в мегабайтах логов огромного монолита найти кусок, который зафейлился и понять почему. Да и банальное индексирование проекта в IDE даже для просто большого микросервиса занимает значительное время и оператива на компе заметно подъедается. В случае с монолитом попросту не хватит нервных клеток для внесения малейшего изменения, так как комп будет тупить.
Следующий недостаток работы с большим монолитом - это то, что начинался он в незапамятные времена. И тут на конференциях рассказывают про Spring 6, Project Loom и новые интересные вещи. А на проекте с монолитом будут те технологии, которые были тогда, когда проект стартовал. Какая-нибудь Java 8 и Spring 4, и нет надежды на то, что это когда-нибудь обновиться. Это прямой путь к выгоранию.

Также не согласен, что монолит работает значительно быстрее микросервисов. Он работает значительно быстрее системы с очень сильной связанностью сервисов. А если микро сервисы имеет минимальное количество интеграций - то они будут работать быстрее. Рассмотрим в качестве примера банковское приложение. Если это будет монолит - то один и тот же сервер будет в один и тот же момент времени обновлять аватарку пользователя 1, вычитывать перечень транзакций пользователя 2, выполнять оплату коммуналки для пользователя 3 и принимать решение, какой кредитный лимит установить пользователю 4. И при этом для всех этих операций монолит будет лезть в одну базу.

В общем, если проект - стартап, который пока не приносит денег, то конечно же лучше начинать с монолита, так как нужно как можно раньше выкинуть на рынок что-то, что начнёт приносить деньги + поменьше тратить на cloud провайдера. Но если проекту много-много лет, над разными фичами работают разные команды, и его до сих пор не подробили на микросервисы - то это очень странный проект и явно не то, на чем хотелось бы работать.

[ivanpriz]

Один из основных плюсов микросервисов - горизонтальная масштабируемость и отказоустойчивость. Кроме того, более эффективное распределение ресурсов, потому что цпу/ио/ГПУ привязанные вещи можно разнести по разным машинам. Странно что про них здесь не упомянули.
Самый простой пример - одна часть приложения вытаскивает данные откуда-то и завязана тол ко на инпут/аутпут, другая обрабатывает каким-то дорогим алгоритмом, мл моделька условная, каким образом поселить обе эти части в одном проекте сделает проект проще и эффективнее?

[TonyFlexPromo]

Отличный обзор архитектур и очень рад что в наше хипстерское время всё ещё есть сторонники монолитов!

Хочу подсветить одну особенность микросервисов, о которой не было сказано. Они позволяют инкапулировать не только логику, но и зависимости. Бывало ли у вас такое, что вы используете библиотеку и в одном месте вам нужна версия 15, а в другом, несовместимая с версией 15, версия 18? Например у них конфликтуют зависимости. Микросервисы позволяют отлично решить эту проблему- на каждый кусок логики у вас будут свои собственные зависимости.

[u]

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

[topalidinka]

Спасибо, обожаю вас слушать ❤
Запишите, пожалуйста, видео про TDD
Очень интересно ваше мнение 🙂

[stiIlen]

Честно говоря не очень понял, буду рад разъяcнениям:

1. "Монолит проще микросервиса и его проще рефакторить" - обычно монолит имеет кучу интерфейсов и абстракций, потому что solid и все дела. Но тем не менее связность кода иногда очень сильная и что-то просто поменять в иерархии классов или не дай Бог пакетов - это иногда просто нереально. В микросервисах зачастую можно вообще выкинуть интерфейсы и делать сразу конкретную реализацию и, если надо, ее же потом менять. Других реализаций все равно не будет, потому что ну не будет. Хочешь, можешь хоть весь микросервис переписать за один день и проблем у тебя не будет.
2. Понятно, что монолит можно надробить на модули и вот тебе те же микросервисы в одном "адресном пространстве", только без копипасты общей стуктуры. - Ну окей, на кластере 6 проектов из +- 10 микросервисов и 50+ общих переиспользуемых ими микросервисов. Делать монолит из 50 модулей? А потом все это поднимать единым инстансом?
3. Перфоманс - в случае с монолитом горизонтальное масштабирование обязывает дублировать на ноде все это гигантское приложение. Да и сама нода должна быть весьма мощной, чтобы вывозить его - вертикальное масштабирование очень быстро обгоняет горизонтальное по себестоимости. А если от всего приложения нагружена только небольшая его часть? В микросервисах можно было бы масштабировать конкретный сервис, а тут придется весь монолит поднимать целиком на другой ноде.
4. Если продукт работает, поддерживается и развивается, то так или иначе и язык и различные фреймворки надо поддерживать в актуальном состоянии (надеюсь не надо пояснять зачем). Перевести микросервисы один за другим на новую версию (или на новый язык даже, может более удобный или подходящий) имхо гораздо проще чем например поменять версию одной зависимости в монолите и словить кучу конфликтов и нерешаемых проблем.

[dmitryzagorevskiy]

И сразу лайк не зная контента, и я думаю понятно почему ;) Возвращение одного из лучших каналов про поговорить и не напрягаясь послушать об IT, тоже я думаю понятно для кого ;).

[АлексейСуббота-цп]

Хороший монолит, та вещь которую никто не видел, но всё о нём говорят)

[Dark]

Монолит, вернись к покинутым детям своим.
Монолит - это свет и знание, знание и свет.

[Serhii-Kostin]

мне это напомнило холивары в конце 90-х, начале 00-х: "алгоритмическое программирование или ооп". побеждали алгоритмы с ровно теми же доводами 🙂
p.s. я был сторонником алгоритмического подхода, в первую очередь из-за скорости работы
p.p.s. ждем этот же ролик через 10-15 лет 😀

[СергейНовоселецкий-жч]

З монолітом особливо весело коли він на Java, запускається 10 хвилин і займає пів сервера. Ну і якщо лиш один модуль під великим навантаженням, то не доцільно запускати ще 10 таких монолітів + якщо додаток statefull і архітектурно distribution не передбачений, то буде проблемно. Але випливаючи з цього, якраз згідний з минулими коментаторами, що краще створити моноліт з хорошою модульною архітектурою а далі якщо проект вистрілить, то розбивати на сервіси по потребі. Той самий модуль можна або винести в окремий сервіс і на моноліті замінити імплементацію на мережевий виклик, а сервіс взагалі переписати на іншу мову.

Не використовував ще в реальному житті gRPC, але на скільки бачу з прикладів, він повинен зменшити час latency між сервісами і тим самим пришвидшити роботу всієї системи