Почему монолит предпочтительней микросервисов?
Vložit
- čas přidán 16. 06. 2024
- Приветствую, мои дорогие. В этом выпуске обсудим, что предпочтительнее монолит или микросервисы?
💻 Регистрируйся на курсы для будущих Python-разработчиков ⬇️⬇️⬇️
🔥 PYTHON Start (перед менторингом) - go.foxminded.ua/3RV7nKI
🔥 PYTHON менторинг - go.foxminded.ua/48Rd81V
Есть вопросы по обучению в FoxmindEd? Пишите нам в телеграм - t.me/foxminded
Вы можете стать спонсором канала и получать плюшки - / @sergeynemchinskiy
❤ FoxmindEd в Instagram: / foxminded.ua
Курсы для будущих JS-разработчиков:
JavaScript Start - go.foxminded.ua/3Qczwvs
FRONT-END (ANGULAR, REACT) - go.foxminded.ua/48U4UGo
NODE.JS - go.foxminded.ua/3RVBKR8
Курсы для будущих Java-разработчиков:
JAVA Start - go.foxminded.ua/48Ld6sJ
Инструментарий JAVA - go.foxminded.ua/48Taucg
JAVA - go.foxminded.ua/3tpbSD0
Обучение на проекте - go.foxminded.ua/3rOmuei
Курсы для будущих С#-разработчиков:
C# START - go.foxminded.ua/3PSkPfW
C#/.NET - go.foxminded.ua/3FdkShg
Обучение на проекте - go.foxminded.ua/3rOmuei
🎓 Другие направления:
ANDROID - go.foxminded.ua/3LVxk9h
SALESFORCE Developer - go.foxminded.ua/48PqFas
UI/UX дизайн - go.foxminded.ua/3Qd2vPU
Unreal Engine - go.foxminded.ua/3Qed5pH
QA Automation - go.foxminded.ua/3tnF7pO
IOS разработка - go.foxminded.ua/3PWRnFm
PHP - go.foxminded.ua/3ZQU0gB
Unity - go.foxminded.ua/3Fkz2wY
GOLANG - go.foxminded.ua/3rOeLgf
🎓Продвинутые курсы для состоявшихся девелоперов:
Enterprise patterns - go.foxminded.ua/3rOmlrg
Алгоритмы и структуры данных - go.foxminded.ua/3twTLLL
C# NEXT - go.foxminded.ua/3Qeu4YX
🔧 Пробное техническое собеседование со специалистом уровня Senior Developer/ Team Leader - go.foxminded.ua/3Qed2Kx
👔 Карьерная консультация с Сергеем Немчинским - go.foxminded.ua/3ZQsKip
Сайт FoxmindEd для новичков: go.foxminded.ua/3RVLCKI
Сайт для разработчиков уровня мидл+: go.foxminded.ua/45uUM49
FoxmindEd в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Мой Telegram: t.me/nemchinskiyOnBusiness
Для деловых запросов: youtube@foxminded.ua
Тайминг:
00:00 - Вступление
00:26 - Что такое монолит?
00:55 - Преимущества монолитной архитектуры
02:27 - Недостатки монолитов
03:28 - Python
06:16 - Микросервисы
06:51 - Преимущества микросервисов
09:12 - Недостатки микросервисов
15:25 - Что же выбрать? Призыв к оценке конкретных потребностей проекта при выборе архитектуры.
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 czcams.com/video/NnM1Od1TKdA/video.html
Наконец то не про джунов и какой язык выбрать. Тема зачётная. Даже отвлёкся от работы.
Если быть реалистами, то плохой монолит лучше, чем плохие микросервисы. А хороший монолит и хорошие микросервисы никто нигде не видел 🙂
Респект Сергею за то, что не побоялся поднять острую тему
Странно, ты не смотрел Нетфликс? Да и ютьюб, сомневаюсь, что это монолит раскиданый по серверам для масштабирования, как там говорил автор
Ты пишешь ютуб или нетфликс? в 99.9% микросервисная архитектура излишня для проекта
В микросервисах еще не раскрыты темы транзакционной целостности, каскадных откатов, саг, оркестрации, дебага и т.д. там тоже всплывает куча проблем) ну и конечно размер команды...и перекладывание оргструктуры на микросервисы. Одна команда - один сервис - две пиццы.
А там вообще по другому надо думать. Например, темы транзакционной целостности надо решать в рамках одного домена.
@@GK-tw7nu любой плохой проект ведет себя подобным образом.
@@GK-tw7nu прикольно. И че, как жизнь теперь? Сколько вы в таком режиме?
Тема оркестрации решается кубером! Дебаг решается делвом, IDE, printLn и др. Каскадные откаты, они же транзакционная целостность, сага решаются инструментарием, типа temporal. Почаще заходите на CNCF.
Куча проблем это какие? Конкретно надо идентифицировать и почти под каждую есть свой развитый инструментарий и почти всегда есть изящное решение.
Проблем у монолита дохрена! Как логируем? Как мы используем inMemoryDB? Как решаем проблему идентификации и аутентификации? Как мы решаем проблему очередей? Как мерить перфоманс? Как делать тесты и интеграционные тесты? Как делегировать разработку/поддержку сервиса другой команде по причине того, что нынешняя залупилась.В МСА это решается изучением решений. Да, это муторно бывает, но ты решишь все равно так или иначе...
А в монолите ты не решишь в принципе!
Мой backgound из Oracle. Так что я знаю о чем идет речь! В Oracle я был 20 лет. И ни разу не пожалел, что с ним больше не работаю с ним!
Честно говоря не очень понял, буду рад разъяcнениям:
1. "Монолит проще микросервиса и его проще рефакторить" - обычно монолит имеет кучу интерфейсов и абстракций, потому что solid и все дела. Но тем не менее связность кода иногда очень сильная и что-то просто поменять в иерархии классов или не дай Бог пакетов - это иногда просто нереально. В микросервисах зачастую можно вообще выкинуть интерфейсы и делать сразу конкретную реализацию и, если надо, ее же потом менять. Других реализаций все равно не будет, потому что ну не будет. Хочешь, можешь хоть весь микросервис переписать за один день и проблем у тебя не будет.
2. Понятно, что монолит можно надробить на модули и вот тебе те же микросервисы в одном "адресном пространстве", только без копипасты общей стуктуры. - Ну окей, на кластере 6 проектов из +- 10 микросервисов и 50+ общих переиспользуемых ими микросервисов. Делать монолит из 50 модулей? А потом все это поднимать единым инстансом?
3. Перфоманс - в случае с монолитом горизонтальное масштабирование обязывает дублировать на ноде все это гигантское приложение. Да и сама нода должна быть весьма мощной, чтобы вывозить его - вертикальное масштабирование очень быстро обгоняет горизонтальное по себестоимости. А если от всего приложения нагружена только небольшая его часть? В микросервисах можно было бы масштабировать конкретный сервис, а тут придется весь монолит поднимать целиком на другой ноде.
4. Если продукт работает, поддерживается и развивается, то так или иначе и язык и различные фреймворки надо поддерживать в актуальном состоянии (надеюсь не надо пояснять зачем). Перевести микросервисы один за другим на новую версию (или на новый язык даже, может более удобный или подходящий) имхо гораздо проще чем например поменять версию одной зависимости в монолите и словить кучу конфликтов и нерешаемых проблем.
Сергей, спасибо за видео.
Это какая-то магия.
Пришло уведомление о новом видео на вашем канале, посмотрел и поехал на собес.
И о чем вы думаете меня спросили??? 😁
Какие плюсы и минусы у монолита и микросервисов 🤣
Спасибо, прям вовремя.
Офер пока не получил, но всё прошло норм.
Ржали после твоего ответа сразу, или подождали пока дверь закроется?
Спасибо, обожаю вас слушать ❤
Запишите, пожалуйста,видео про TDD
Очень интересно ваше мнение 🙂
Не слова не сказал про то что микросервисы легче масштабировать в ширь. При монолите при большой нагрузке - пойдёте поднимать кол-во инстансов монолитов. В этом и основной смысл микросервисов.
Масштабирование будет намного дешевле чем монолита
и про отказоустойчивость - если под нагрузкой приложение помрет, то в случае с монолитом это будет не один модуль, а вся система)
хотя про масштабирование на 18й минуте он упоминает, но правда почему-то считает это притянутым за уши)
@SergeyNemchinskiy зазвичай виробите корисний відео контент, але не цього разу. Це буває дуже рідко, але зараз я не зміг втриматися.
Як ви казали - ви не практикуючий розробник і на мою думку ця тема або вам не по зубах, або ви не заглибилися в неї.
1. жодна велика чи мала компанія в здоровому глузді, чи маленький стартап - ніколи не будуть плодити зоопарк сервісів на різних мовах. За звичай різні мови можуть використовуватися для бєкенду C#/Java/Golang/C/C++/тощо, для фронтенда TypeScript/JavaScript/HTML/CSS, для AI/Machine learning частіше за все використовується Python.
2. У кожного мікросервіса є свій домен, і жодна людина при глузді не буде переносити фронтову частину на бєк чи ще кудись, теж саме стосується й логіки бєку чи AI - ніхто не будет писати нейронки на PHP, або на JavaScript.
3. В усіх хмарах вже давно вигадали автоматичне горизонтальне масштабування як сервісів, так і архітектури (ноди/або фізичні сервери).
4. У моноліта обо немає або треба додаткові присідання щодо створення High Valaibility, у мікросервісного підходу таких проблем - немає.
5. Оновити моноліт без часу простою не можливо, або треба мати зелену і синю інфраструктури, і якщо ваш моноліт хоче жерти 32CPU та 200GB, то тримати 2 таких сервери не дуже дешева історія. При оновлені мікросервісної архітектури - сервіси зазвичай оновлюються порціонно, за замовчанням це 25% - тому простою немає та користувач не помічає що щось оновилося.
6. Мікросервіси ніхто давно не оновлює руками, для цього придумано і Helm charts і Terraform і багато чого іншого.
Підсумок: Єдина річ з якою я погоджуюся з вами - це "Не треба писати мікросервісну архітектуру там де її не треба писати", ну і архітектор повинен бути трошки "відсталий розумом" якщо він, наприклад гру, наприклад Киберпанк пише на мікросервісах. У інших випадках, якщо для людини не важливі 50-100 миллисекунд реакції (будь-який веб додаток), або ви не пишете код для критичної інфраструктури (драйвери, реалтайм контролери) - то моноліт писати не варто. А взагалі - перед початком проєктування подумайте яка вам модель підходить більше, і які плюси та мінуси ви отримаєте від кожної моделі.
Вибачте, якщо написав різко.
@@ceearrashee ну и да про перенос функционала между микросервисами тоже поржал, кем надо быть чтобы например функционал создания заказа написать сначала на микросервисе пользователей например и только потом его переносить на микросервис заказов/товаров. Обычно функционал сразу пишеться в том микросервисе в котором он хотя бы примерно уместен, а общий функционал мы например выносим в отдельный пакет (composer в случае с PHP) чтобы этот код можно было переиспользовать во всех микросервисов
@@murchenko99 вы говорите о сферическом коне в вакууме. Если вы новые проекты начинаете клепать с микросервисами и идеальной архитектурой, у меня для вас плохие новости - вы дали нехилую такую фору вашим конкурентам. Микросервисы это инструмент для решения определенных проблем. А преждевременная оптимизация это один главных антипаттернов, которым страдают многие новички, мечтающие писать идеальный код в окружении таких же хипстеров.
Соответственно, итерация за итерацей придя к понимаю того, что для решения вашей конкретной проблемы вам нужно разделить ваш монолит (пусть даже и модульный) на микросервисы, вы рискуете попасть в ситуацию, когда что-то куда нужно будет переносить, либо в силу неидеальных архитектурных решений, либо в силу легаси и других исторических причин.
Я так понимаю, вы ничего сложнее системы управления пользователями не видели? А, ну тогда да. Но прочитав все ваши доводы не увидел ни единого факта. Не убедили. Сорян. Практикующим программистом я был 20 лет, если уж вы на личности перешли. Так что давайте фактический довод, с которым мы и будем спорить
Сижу на монолите, но он разбит на модули
@Yurec10
круто...модульность это хорошо !!! легче обслуживать код!!!
Сижу на стуле, но он с пиками точеными
Наилучший вариант на сегодняшний момент
@@SerhiiNemchynskyi ну не знаю, я бы все же выбрал второй стул. Жопа болеть будет, но хотя бы жив останешься🤷
@@MasterSergiusглавное что б не с дрочоными)))
Очередное видео с ошибкой в названии. Правильное: "Java - самый лучший ЯП"
"а Немчинский - самый умный"
C#- самый лучший ЯП!!!
За монолит! Не Долг со Свободой же выбирать 😁
Да, только не совсем удобно разрабатывать монолит когда у тебя 100+ разработчиков. Сразу получаем деплои по расписанию, а не тогда когда хочешь ты или твоя команда, деплои будут переноситься почти каждый раз ибо кто-то где-то что-то сломал. Так же в рамках монолита будет сложнее поддерживать логические границу между модулями, в рамках микросервисов эти логические границы можно укрепить физическими. Безусловно микросервисы несут в себе кучу других проблем и головных болей, но говорить что микросервисы нужно только если у вас не строго типизированный язык точно не корректно.
я слава богу ко всему этому веб аду отношения не имею, но почему-то мне кажется, что в случае с 100+ разработчиками, расписанием и "кто-то что-то сломал" разница только лишь в том, что в микросервисах если кто-то что-то сломал или сделал breaking change, то узнать об этом заранее на этапе компиляции или pull request'a практически невозможно. И в итоге да, вроде каждый деплоит когда захочет, только проблемы это не решает, а только усугубляет тк. надо все изменения тщательно тестировать прежде чем выкатывать пользователям. Разве нет? Прошу разъяснения.
Деплои по расписанию мы получаем только в том случае, если мы не смогли придумать рабочую имплементацию merge queue. С оной мы получаем релиз в одну кнопку не глядя, при наличии зеленых статусов, за процессом которого можно даже не следить, если алерты настроены корректно. В случае инцидентов да, можно заблокать всю очередь. Но это скорее уже вопрос к построению процесса QA.
Заботу о логических границах можно переложить на дептрак какой-нибудь, и больше об этом не вспоминать.
Да и не строго типизированные языки, где они? Под этим грозным словом негласно принято подразумевать пыху, на которой без стрикт режима, мне думается, давно уже никто не пишет, а со стриктом и вменяемым фреймом типа Симфы принципиальные отличия от любого другого силайк языка ещё поискать надо.
@@AlexS-gn9tq Проблема в том что в монолите (сугубо исходя из моего опыта) часто нарушаются логические границы и кто-то начинают юзать твою внутреннюю логику напрямую, миную твой фасад. В рамках микросервисов это границы ты так просто не сломаешь, ибо поверх них находятся физические границы (networ ). По этой причине "кто-то что-то сломал" происходит реже, ибо никак не получить доступ к твоей внутренней логике, только через интерфейс твоего сервиса.
@@zikimzikilus1841 Почитав ваши комментарии, нашел правильную аналогию сравнения монолита с микросервисами, только более понятную обывателю... Разница между монолитом и микросервисом в том, что когда ты строишь небольшой дом, то ты можешь сам его построить, сделать внутреннюю обделку, ремонт и т.д.... но вот когда ты решил построить многоэтажку, то тут увы, ты сам уже не справишься... Т.е. монолит от микросервиса отличается размерами... пока монолит не большой, он удобный и быстро можно там внести изменения, но вот когда у Вас в геометрической прогрессии начинается рост запросов, а еще и разнообразных, то никакой монолит не сможет справится уже с этим потоком запросов, нужно масштабироваться не только вертикально, но и горизонтально, вот тут то и приходим к микросервисам...
@@zikimzikilus1841 я кстати согласен в этом плане. Думал куда засунуть комментарий, вот это хорошее место.
Да, если тебе нужно прикрутить кнопку на сайте - то зачем тебе ждать неделю или месяц? Или если сделать ее чуть круглее, или внести какую-то задержку срабатывания.
Пока за функцию этой кнопки отвечает одна группа (даже из пары разработчиков) - абсолютно не имеет никакого смысла "напрягать" остальные 98 человек так или иначе (ха, день потратили на функцию, остальные 4 дня отдыхают?). Для остальных это изменение произойдет незаметно, и даже если что-то пойдет не так - решение проблемы будет на плечах опять же этих 2 человек, а не всех.
Да, опять же, релиз трейн из кучи изменений это адский ад в траблшутинге.
И сразу лайк не зная контента, и я думаю понятно почему ;) Возвращение одного из лучших каналов про поговорить и не напрягаясь послушать об IT, тоже я думаю понятно для кого ;).
Здравствуйте! Вы очень интересно и точно объяснили. Спасибо!
Отличный обзор архитектур и очень рад что в наше хипстерское время всё ещё есть сторонники монолитов!
Хочу подсветить одну особенность микросервисов, о которой не было сказано. Они позволяют инкапулировать не только логику, но и зависимости. Бывало ли у вас такое, что вы используете библиотеку и в одном месте вам нужна версия 15, а в другом, несовместимая с версией 15, версия 18? Например у них конфликтуют зависимости. Микросервисы позволяют отлично решить эту проблему- на каждый кусок логики у вас будут свои собственные зависимости.
Один из основных плюсов микросервисов - горизонтальная масштабируемость и отказоустойчивость. Кроме того, более эффективное распределение ресурсов, потому что цпу/ио/ГПУ привязанные вещи можно разнести по разным машинам. Странно что про них здесь не упомянули.
Самый простой пример - одна часть приложения вытаскивает данные откуда-то и завязана тол ко на инпут/аутпут, другая обрабатывает каким-то дорогим алгоритмом, мл моделька условная, каким образом поселить обе эти части в одном проекте сделает проект проще и эффективнее?
Мне кажется Сергей имел ввиду именно микросервисы. Просто распилить монолит на три четыре части ничего страшного. Страшно становится когда микросервисов тысячи, и пример тому твиттер.
@@tomiyoshi ну, микросервисов не обязательно должно быть много, это зависит от размера проекта и правил, по которому часть логики уезжать жить в отдельный сервис. В твиттере их тысячи, потому что Твиттер очень большой, а для скромного онлайн-магазинчика их будет штук 5-10, но если мы распиливаем монолит на несколько частей, то получаем микросервисы. Сергей в начале видео говорит, что монолит - когда живём в одном адресном пространстве, а микросервисы - когда в разных. Так что если у нас логика юзеров в одном приложении, склада в другом, а рекомендации в третьем - это уже микросервисы, как по мне)
@@ivanpriz4547Вот для любителей онлайн магазинчиков с 5ю микросервисами он этот ролик и выпустил)
@@ivanpriz4547нет. Микросервисы - это когда почти любая фича изолирована от остальных. Чем меньше в микросервисе функций и зависимостей, тем лучше. Идеальный микросервис - это тот, который выполняет ровно одну задачу, завязан, как максимум, на свою бд и имеет какое то внешнее апи, по которому с ним могут взаимодействовать пользователи из интерфейса
Хороший монолит, та вещь которую никто не видел, но всё о нём говорят)
Как и микросервисы. Только говнокод собран в разных местах)
@@KREKER8331Netflix с тобой поспорит
Наконец-то я знаю теперь что это и я узнал что оказывается на пайтон можно писать что то большое, спасибо)
Сергей, спасибо за видео. Вопрос: что вы понимаете под маленьким, большим приложением. Сложно наверное оценить, но если в, допустим, строчках кода? Это сколько? Откуда начинается большое приложение?
Если в голову одного условного разработчика перестает помещаться весь контекст приложения то оно точно большое
мне это напомнило холивары в конце 90-х, начале 00-х: "алгоритмическое программирование или ооп". побеждали алгоритмы с ровно теми же доводами 🙂
p.s. я был сторонником алгоритмического подхода, в первую очередь из-за скорости работы
p.p.s. ждем этот же ролик через 10-15 лет 😀
в те времена лишняя память под объекты заметно влияла на производительность, а сейчас нет
ООП не исключает алгоритмическое программирование и наоборот. Любое большое корпоративное приложение пишется с использованием ООП, и поверьте, там довольно много нетривиальных алгоритмов, котрых нет ни в каких библиотеках. Другое дело что , как правило, те, кто много изучают алгоритмы, мало изучают ООП или даже совсем его не знают.
@@backendtv1345 в 90-х пам'ять вже не парила.
@@backendtv1345 не лишняя память, а особенность ООП - указатели и ссылки, которые надо еще грамотно использовать, чтобы промахов кешей было меньше, таблицы виртуальных методов, менеджеры куч и обьектов, все это в совокупности нехило так нагружало тогдашнее железо, это сейчас от большой лени разработчики порой плевать хотели на оптимизацию. Поэтому мы и имеем теже казуальные игры, что греют телефон, как будто это онлайн ММО с тыщей игроков. Либо калькулятор, что жрет больше 100 мб памяти...
@@kohubo6opohe803 бінго. Чи ви думаєте ситуація з монолітом та мікросервісами буде інакшою? :)
оооо какие приятные слова! я подозревал что-то такое, но не был уверен
Качественная документация помогает построить микросервисы. Если есть хорошие аналитики, то и архитектура такая пойдёт хорошо
насчет "архитектурной работы" - интересно.
В плане, "я считаю" что и там и там должна быть модульность и версионность, просто в монолите все модули работают внутри одного приложения (и то не факт, очевидно, это не в камне выбито), а в микросервисах - модули взаимодействуют через АПИ (который тоже можно контролировать, документировать). Причем в обоих случаях лично я (как далекий от софтвер инженеринга человек) не вижу большой разницы, и там и там надо понимать что и как передается, и контролировать эти потоки (через словари и фильтры допустим).
Послушал дальше - ну так это же реализуется через разные версии АПИ. Какие-то используют старую версию, какие-то новую.
Кстати, отсюда и "минус" монолита - невозможность "разнести" монолит по модулям на разные серверы/воркеры. Сразу приходит на ум Tableau, который съедает абсолютно все доступные ресурсы, но не скейлится в широкие кластера (10 физических серверов с любыми ресурсами съедает на раз и еще просит). Так что "производительность" как преимущество - это тоже вопрос, зависит от размера приложения и обрабатываемых данных.
З монолітом особливо весело коли він на Java, запускається 10 хвилин і займає пів сервера. Ну і якщо лиш один модуль під великим навантаженням, то не доцільно запускати ще 10 таких монолітів + якщо додаток statefull і архітектурно distribution не передбачений, то буде проблемно. Але випливаючи з цього, якраз згідний з минулими коментаторами, що краще створити моноліт з хорошою модульною архітектурою а далі якщо проект вистрілить, то розбивати на сервіси по потребі. Той самий модуль можна або винести в окремий сервіс і на моноліті замінити імплементацію на мережевий виклик, а сервіс взагалі переписати на іншу мову.
Не використовував ще в реальному житті gRPC, але на скільки бачу з прикладів, він повинен зменшити час latency між сервісами і тим самим пришвидшити роботу всієї системи
Не согласен с тем, что микросервисы выбирают потому что они "модные" и что они подходят только для проекта написанных на языках с динамической типизацией. Микросервисы усложняют систему в целом, но значительно упрощают работу для одной конкретной команды.
Я сталкивался с проектами (на java), в которых один "жирный" сервис может билдиться около получаса. И это только лишь один из сервисов. Если бы проект был бы монолитом, то он бы наверное билдился бы больше суток. В такой системе "хот фикс" можно было бы отменить. Особенно будет весело когда в самом конце билда подобного монолита билд по какой-то причине зафейлиться, тогда впереди ждёт следующее испытание: в мегабайтах логов огромного монолита найти кусок, который зафейлился и понять почему. Да и банальное индексирование проекта в IDE даже для просто большого микросервиса занимает значительное время и оператива на компе заметно подъедается. В случае с монолитом попросту не хватит нервных клеток для внесения малейшего изменения, так как комп будет тупить.
Следующий недостаток работы с большим монолитом - это то, что начинался он в незапамятные времена. И тут на конференциях рассказывают про Spring 6, Project Loom и новые интересные вещи. А на проекте с монолитом будут те технологии, которые были тогда, когда проект стартовал. Какая-нибудь Java 8 и Spring 4, и нет надежды на то, что это когда-нибудь обновиться. Это прямой путь к выгоранию.
Также не согласен, что монолит работает значительно быстрее микросервисов. Он работает значительно быстрее системы с очень сильной связанностью сервисов. А если микро сервисы имеет минимальное количество интеграций - то они будут работать быстрее. Рассмотрим в качестве примера банковское приложение. Если это будет монолит - то один и тот же сервер будет в один и тот же момент времени обновлять аватарку пользователя 1, вычитывать перечень транзакций пользователя 2, выполнять оплату коммуналки для пользователя 3 и принимать решение, какой кредитный лимит установить пользователю 4. И при этом для всех этих операций монолит будет лезть в одну базу.
В общем, если проект - стартап, который пока не приносит денег, то конечно же лучше начинать с монолита, так как нужно как можно раньше выкинуть на рынок что-то, что начнёт приносить деньги + поменьше тратить на cloud провайдера. Но если проекту много-много лет, над разными фичами работают разные команды, и его до сих пор не подробили на микросервисы - то это очень странный проект и явно не то, на чем хотелось бы работать.
"почему монолит предпочтительней микросервисов" чтобы что?
Из ваших слов выходит, что:
1. Микросервисы пишут только на ЯП с динамической типизацией.
2. Под каждый сервис поднимают отдельный кластер 0_0.
3. Сервисы невозможно дебажить.
4. Нужно развёртывать все сервисы одновременно.
Я правильно понял?
(прошу прощения за мою резкую критику)
Вы невнимательно смотрели. По вашим тезисам он говорил следующее:
1. Разработчики на ЯП с динамической типизацией имеют тягу к написанию микросервисов.
2. Если нужно поднять много экземпляров одного микросервиса нужен кластер.
3. Дебажить взаимодействие микросервисов - это нетривиальная задача.
4. Развертывание обновлений требует обдумывания каждый раз какие микросервисы в каком порядке деплоить.
основная задача микросервисов, это привести разработку в соответствие с организационной структурой компании. разграничить права доступа, разделить ответственность, SLA у разных частей системы разный.
Это для местной публики сложно :)
А как происходит деплой монолита? Собирается один большой билд и выкатывается? То есть все пулл-реквесты тестируются вместе? Мне просто, как человеку пришедшему с проекта с со временем сборки в час интересно разобраться. Потому, что когда у тостера есть несколько устройств, то тестирование не является проблемой, н в ряд ли же каждому тостеру выделяется по серверу. И включение/откат фичи как в этом случае выглядит?
В обычных условиях при монолите заданные вами вопросы решают merge queue и feature flags. У нас к примеру довольно крупный монолит развертывается по такой схеме, общее время на сборку, все автотесты и деплой это около 15 минут. В специфических проектах с более длинным временем сборки и большим количеством пулл реквестов можно как вариант пробовать сборные реквесты по фичам, командам, или другим принципам группировки. Либо смотреть, откуда растут ноги у такого времени сборки. Пока мы не распараллелили тесты у нас тоже минут за 40-50 время доставки улетало легко.
3:48 я конечно таки дико извиняюсь, но Python имеет не мало недостатков, и главный из которых - обратная совместимость. Сам пишу и к сожалению недавно столкнулся с маленькой, но важной проблемой. В версии 3.12 появилась возможность делать перенос строк прямо в строке с join, то есть вот так: '
'.join(anyvariables). До версии 3.12 такую простую манипуляцию в языке делать не получится. Вроде бы напрашивается простое решение - апдейтить до версии 3.12 и будет всем счастье. Но фишка в том, что некоторые пакеты в req.txt просто отказываются обновлятся и будут ссылаться на ошибки при попытке их установить на новую версию 3.12. То есть к примеру в том же aiogram 3 с использованием новой версии python у вас будут сыпаться ошибки.
Или если вы вдруг писали код на python 2.7, а потом попробовали тот же код написать на python 3, работать у вас эта портянка просто не будет, из-за несовместимости версий языка. В Java с этим(обратной совместимостью) проблем нет. Старый код будет работать на новых версиях.
Сергей, один вопрос что такое "большое приложение"??)
Crm это большая система или среденего размера интернет магазин?)
Якщо CRM це Salesforce, то так.
@@woodzimierz9621 а где эта грань?
Крутое обяснение, согласен на все 100%! Один вопрос: в последнем пайтоне добавили довольно строгую типизацию, почему на нем нельзя написать большой монолит?
Потому , что, это не модно 😅
Да большие монолиты на той же джанге писали и в эпоху чисто динамического питона (не настолько чудовищно огромные конечно, как можно встретить на жабе, но на несколько миллионов строк кода вполне).
Сейчас жэ на таких проектах в основном обмазываются типизацией, пища от радости.
Хотя встречаются и адепты только динамики, и последователи идеи "а давайте типизировать только ответственные участки кода".
Хорошо, что-то сообажаешь. На 3+ сойдет, давай зачетку!
Монолит или микросервисы?
ЗА МОНОЛИТ!
За здравый смысл
Микросервисы. Их масштабировать проще и дешевле.
Вопрос не имеет смысла. На него всегда разный ответ в разнос контексте 😅
универсальный ответ переводчика. "зависит от контекста" )))
При распределении вычислений на несколько(или много) узлов в любом случае что-нибудь да пострадает, и частота ошибок возрастает. И, следовательно, больше тратится на перестраховку и коррекцию этих ошибк. Даже если это размноженный монолит. Т.ч. не всё так однозначно и кучеряво, как описывает аффтар. 🙂
если у вас 30-40 микросервисов, можно положить их модулями в один проект в IDEA, тогда вы увидите, где что используется.
но по сути это разработка как монолит.
еще плюс микросервисов - много разрабов не натыкаются на конфликты при разработке, или редко.
Это работает, но rpc вызовы все равно ide нормально не проверит в отличии от вызова метода напрямую.
@SergeyNemchinskiy добрый день. В вашем видео не хватает обсуждения про микрофронтенд
Превьюха прям крутая 👍🙂
Автор говорит, что в микросервисной архитектуре сложно перенести функционал одного микросервиса в другой. Можно пример?
На мой взгляд, микросервисы имеют еще 2 преимущества:
(1) система в целом может продолжать работать даже если один или несколько микросервисов легли. Например, если в онлайн магазине перестала работать корзина, все равно можно смотреть каталог товаров.
(2) для микросервисов подходит методология agile. Значит, продукт можно сделать быстрее.
Как насчет этих же пунктов в монолите?
Интересная информация. 😏
Грамотная модульная архитектура позволяет собирать проект как в монолит, так и в микросервисы. И нивелирует большую часть болей разработки микросервисов.
Архитектор делает правильно, и только новичок - модно ;)
Была песенка:
"Подошёл я тут к тимлиду: "нужно нам внедрить блокчейн", -
Он, дурак, засомневался, говорит: "А нам зачем?"
"Как зачем, ведь это ж модно!", но тимлид ответил: "Нет!"
Всё, достало, увольняюсь, буду делать свой проект!
=
имхо, классике не хватает второй части, про микросервисы =)
а якщо проблеми з перформансом (чи інші нюанси), що заважає частину коду винести в мікросервіс, замість того щоб робити весь мікросервісами?
За рубежом, между прочим, на Ruby написано много крупных систем, бэкенд того же Экс/Твиттера и Airbnb, например.
там вже все давно переписано
По зарубежным сервисами это и видно.
Почему не назван минус монолита, что запускать для тестирования очень долго.
У знакомого монолит 1+ млн файлов.
Запуск 6+ часов.
Не работает и по новой ....
П.с. Переписывают на микросервсы сейчас
потому что автору не выгодно такое говорить, все вспомнят про Джаву в негативном ключе)
Есть еще ситуевина когда монолит не влазит в железо на одном запросе, а не потому что запросов много. И тогда кластер монолитов не поможет, а микросервис поможет, так как можно будет распаралелить на больше компов чем ядер или винтов на одном
Вы непосредственно сталкивались с такой проблемой? Какого рода система?
@@bubblesort6368 просто теория. Как пример пул майнинга биткоина. Каждый отдельный клиент - микросервис
Сергей, сделайте пожалуйста видео о том, какой проект выбрать начинающему фронтендеру для резюме
возьми друга и напиши ему сервис который решит какие-то его работы
А для рзюме бэкенд разработчика?
да, ведь таких видео в интернете совсем нет, никто же об этом никогда не снимал видео и не писал посты
Что происходит с системой когда монолитный сервис падает? Отказывает вся система. При такой архитектуре нужно всегда дежарать второй екземпляр монолита прогретый и готовый принять трафик на случай disaster, а это может быть довольно дорого. Также очень часто бывает что монолитное приложение начинает отваливаться при попытке поднять несколько екземпляров (например обработчики cron джоб, которые зачастую могут жить только в 1 екземпляре). Очевидно что при старте проекта не стоит сразу упарывываться в микросервисы так как это очень дорого, но по мере развития проекта выдилять высокангруженые компоненты в отдельные сервисы может очень сильно увеличить стабильность/производительность, очень хороший пример этого - uklon
твои слова имеют больше аргументации, чем этот ролик на 20 минут
А что происходит, когда отказывает один или часть микросервисов? Приложение сохраняет видимость работы, но при этом на любое действие сообщает пользовалю, что не может выполнить его запрос, потому что что-то там где-то доступно?
@@yuriy.kostenkoтогда, при правильном проектировании, отказывает только часть (причем весьма незначительная) приложения. К примеру, в банковском приложении может не отображаться история транзакций, но работать переводы
Монолит, вернись к покинутым детям своим.
Монолит - это свет и знание, знание и свет.
всякий, кто хоть раз пытался просто собрать денег на новую крышу над протекающим крыльцом подъезда в домовом чатике - будет против микросервисов.
Как правило любой монолит интегрируется со множеством других программ и так же делает это по сети - вот тебе и микросервисы. Так что возникновение микросервисов неизбежно и закономерно. А выбирать надо то что модно так как если ты программист то проще будет найти работу а если ты работодатель капиталист то проще будет найти работничков
чет какой-то холивар ради холивара, вставлю свои 5 копеек)
кмк стоит начать с того, что оба подхода имеют плюсы и минусы и всегда подход/архитектура/инструмент подбирается под задачи + различные условия, например имеющиеся в команде скиллы
а дальше могу предположить, что если вы не метите в хайлоад с миллионами рпс, то логично начать с хорошо написанного монолита, с хорошим разделением кода на модули/интерфейсы/классы и т.п.
таким образом, что если вдруг ваш проект становится популярным и теперь надо обслуживать многа-многа юзеров, вы идете и выносите нужный модуль в отдельный сервис с минимальными усилиями
ну или прям заранее видите узкое место и сразу его выносите
ну и да, кажется что какой-нибудь кубер или облака, это уже мастхэв в современном мире
поднимать/масштабировать сервисы при этом очень дешево, а если недешево - то нафиг такое облако вам нужно
Будь-що можна зіпсувати кривими руками. Мікросервіси це природнє продовження ідей інженерії, що дає можливість писати гетерогенні системи і розбити проект на компоненти, горизонтально масштабувати їх.
Погана спроектовану чи продуману мікросервісну архітектуру дійсно важче рефакторить/вдосконалювать.
Якщо є контракти, описані апішки - немає проблем. Зміна функціоналу вирішуєтьс зміною версії API. Старі сервіси працюють на старих апі, нові на нових.
Горизонтальне масштабування з коробки (Spring Cloud)
Мікросервіси можна легко перенести в serverless.
Мікросервіси це не модно, це необхідність. Не завжди. На це повинні бути чіткі причини. Якщо ваш моноліт не спроектований так, щоб його частини можна було винести в мікросервіс при необхідності - це погана архітектура.
Эм.. Я тут немного в осадок выпал. Какое-то очень однобокое сравнение с незамысловатой идеей, что микросервисы - это просто модно. И лучше их не использовать, а делать монолит, а микросервисы - это от безысходности.
Во-первых, если бы было так, то вот вопрос "на подумать". Почему многие энтерпрайз решения перепиливают с монолита на микросервисы, если рабочий продукт уже есть и это рабочий монолит, написанный *цать лет назад? Банки, маркетплейсы, CRM / ERP - очень многие перепиливают. И это дорого, на это нужны специалисты высокого уровня и бизнес это готов оплатить. Вряд ли это ради участия в конференциях или ради имиджа. Так вот такие системы распиливают по одной простой причине - декомпозиция. Такая же как в Чистом коде - лучше 5 небольших методов, чем один длинный и большой. Это такая же концепция, перенесенная на один уровень выше. И оказывается, что действительно проще поддерживать такой код, если есть четкое понимание, где его границы.
Во-вторых, что бизнесу прозрачнее в плане учета человеко-часов( и дешевле, как следствие) - один огромный монолит, пусть хоть состоящий из идеальных модулей, или тысяча мелких микросервисов. Новый сотрудник может быстрее влиться и понять, начать работать с каким-то одним проектом и потом расти до нормального уровня. Разработчик меньше тратит времени на изучение кода, нежели на непосредственное его написание, просто потому, что понятнее границы (не всегда, конечно, но в разы проще чем с монолитом). Сюда же можем вспомнить, что многие разрабатывают программы на стороне и опять же проще и понятнее можно ставить задачи и осметчивать стоимость. Ведь уже есть и контракты, и архитектура, и шина - нужно только что-то конкретное под конкретное требование и все. Сложнее накрутить теперь человеко-часы и содрать больше денег.
И в-третьих, самая главная - это экономия средств на проде. И дело не только в том, что ноды поднимать, а в том, что каждый отдельный микросервис можно админить отдельно, следить за ресурсами и в какие-то пиковые моменты разворачивать только нужные экземпляры и потом сворачивать их обратно. И это в масштабах больших систем будет существенно дешевле развертки кластера. И деплоить проще не в том плане, что вместо двух кнопок нужен девопс, а в скорости. Добавить новую фичу, сделать перерасчет ставки какой-либо, какая-то новая акция или открылся новый пункт выдачи и нужно учитывать логистику - что угодно. Просто быстрее написать новый код, покрыть тестами его, упаковать в образ и развернуть в проде, общяась с нужными данными через API.
Выбирать микросервисы сходу, это то же самое что покупать фуру для езды по городу при покупке машины) или что покрупнее.
@SergeyNemchinskiy Сделайте курс по Python для DevOps и SRE, я к вам приду учиться.
Микросервисы возникли не просто так, например самым большим преимуществом является их масшабируемость. Вообще обычно пишут монолит как POC, а потом дробят его на сервисы
Лично я не согласен 🙂
Самая дорогая проблема монолита - баг в проде
Особенно если это баг из за которой умирает jvm
В таком случае работать не будет ничего , в случае микросервисов, работать не будет только тот функционал, который ходит к сервису который упал.
Да, монолит работает быстрее, но микросервисы не должны лежать в разных пространствах, что б ходили через интернет друг к другу, микросервисы которые лежат в одной сети, тоже работают, достаточно быстро. (Не быстрее монолита), но в случае если есть внешние зависимости - например какие то апи из интернета, то разница в скорости для пользователя каправило незаметна)
Второй плюс микросервисов простота деплоя - не нужно продумывать очередность и зависимость компонентов
Для высоконагруженых приложений есть еще проблема - колво потоков на сервере, колво коннектов к бд, это все решается, но оно всплывает намного чаще и регулярнее чем в микросервисах, у которых естественно нагрузка меньше и такие проблемы всплывают реже, если функционал правильно разделен по ответственностям
Микросервисы это не просто хайп если бы бизнесу это не нужно было, этого бы не было, микросервисы решают множество проблем бизнеса на котором теряется огромное кол-во денег
Ни один бизнес не позволил бы потратить кучу времени и переписать монолит на микросервисы просто потому что «разработчики хотят похайпить»
Сейчас в моменте, да, монолит выглядит привлекательным, но в перспективе это дорого.
Другой вопрос что не нужно упарываться - и делать на каждую модель по сервису, тогда конечно толку не будет от этого
Просто поделился своим мнением
браво!
Считаю что не уместно говорить что лучше микросервисы или монолиты. Тут зависит от того какая задача. Архитектура это понятие субъективное разные задачи разные решения.
Да микросервисы просто расхайповали, половина людей вообще не понимает зачем они нужны и когда их применять. Зато звучит солидно... 😂
СОЛИДно
Так большей части проектов это не нужно физически
Пропущен момент траблшутинга. Когда не понятно где в каскаде вызовов происходит ошибка. Помню статью от нетфликса на эту тему, а они как раз кучу библиотек написали для микросервисов, и в статье они писали, что нужно прям хорошо и много подумать если вы думаете перейти на микросервисы. Оверхед на все про все огромный.
Я не нетфликс, но как при правильном разделении логики можно не понять, где возникла ошибка? ) Типа сломалась у нас оплата, но мы пойдем смотреть сервис каталогов?))
Провокация.. Любой маленький развивающийся монолит превращается в большой проект, который в случае монолита станет колом. и тут хочешь или нет - будешь архитектурить или умри или на край развивайся на одном месте без оперативного расширения. Каждая доработка будет стоить .. да что я тут пишу .. и так все понятно .... Про написание автотестов в монолите - отдельная тема. Есть еще момент.. если у тебя команда, которая завтра сбежит поджав хвост, то не о каком монолите вообще не может идти и речи. а если у тебя команда "монолитчиков" - это вообще веселый дружный коллектив.
В чем преимущества микросервисной архитектуры для языков с динамической типизацией?
Я нашёл только одно - изоляция модулей, а следовательно проблемы в одном "не будут влиять" на работоспособность других. Есть ли другие?
Да все дураки просто, умный только Немчинский те кто с ним согласны
давайте поставим точки на i, большая система это сколько строк? в чем она измеряется? что это за величина?
Как программист который переносит логику со scala на go хочу выразить свое "почтение" прошлым коллегам.
Как программист который писал монолит по решению одного архитектора и разбивал(непонятно зачем) по решению другого хочу передать привет.
друг,как то можно лично связаться ,пару вопросов по теме задать?
тоже подумал что только для масштабирования выносить модули в отдельный сервис норм
По мне главная беда микросервисов - чрезмерное дробление чуть ли не до состояния нано.
Там, где модульный монолит состоял бы из десятка модулей, вполне могут навертеть 50 а то и 100 микросервисов. И вместо изначальной идеи одна команда - один сервис получается по десятку микросервисов на одном разработчике.
Да, каждый сервис тут выходит примитивным, но сложность уходит на уровень межсервисного взаимодействия.
И вдобавок нехило растут затраты на инфраструктуру, ибо всё это надо обмазывать куберами, мониторингом и прочими опентрейсами.
Что то мне подсказывает, что тут проблема в проектировании) Сервисы по идее должны быть автономными и законченными, а не дробиться почкованием "патамушиа эта крута"
Микросервисы это мираж в пустыне програмиррвания, кажется вот оно спасение) название такое манящее.
Монолиты тоже разные бывают. Поддерживать монолит из 1500 таблиц, тысячи файлов миграций бд и млн. строк кода просто невозможно. И жди очереди на мр по 2 дня.
Дякую за світло в цій темі. Може багато хто просто не розуміє в чому різниця. Тому і обирають хайпові речі.
вам фонариком всего лишь посветили, успокойтесь)
@@yehortverytinov5478 інші і того не роблять. 🙂
Я согласен с Сергеем, большинство приложений вполне устроит архитектура монолита. Микросервисы это модно, почему то их сторонники забывают про накладные расходы при их взаимодействии.
По хорошему, этого взаимодействия просто не должно быть вовсе. Если его дофига, то проект где то свернул не туда и на микросервисы логика разделена неправильно
На старте фигачить сервисы наркомания полная, надо не иметь мозгов в голове. У нас как раз и был монолит на пыхе, мы не одного архитектора потеряли в попытках что там переделать 😂 а вообще все по делу, пока всех устраивает монолит и бизнес и ати подразделение рыпаться нет смысла в сторону сервисов, ибо оверхеду и ебли оно добавляет экспоненциально, те кто строил что то с нуля в курсе. Да да, на 5 языках взяли и написали сотню сервисов, а теперь контора годами выпиливает и переписывает их в попытке оставить хотя бы 2. Всем Мир.
Согласен с каждым словом!
Доброго дня. В одному з відео бачив як ви згадували про книгу "Clean code - Robert Martin". Зацікавило, почав читати, сподобалось. Буду дуже вдячний якщо надасте рекомендацію по книжкам які допоможуть стати краще у своєму напрямку 🙂 Працюю у банку як software dev.(angular, nestjs). Або якщо є вже таке відео буду вдячний за посилання.
Реклама курса топ, на контрасте
Почему не было сказано о маштабирование? А о отказоустойчивости?
Вот где микросервисы выигрывают.
И монолит же может упереться в предел ресурсов машины.
Так же несколько раз делался упор на то, что php онли динамическая типизация.
Да это так, но внешне уже есть возможность запретить оставлять не типизированные переменные. Для пользователя все будет выглядеть как статическая типизация, а то, как оно под капотом уже не столь важно, в плане поддержки больших проектов.
Монолиты отлично масштабируются. Преимущества микросервисов тут вообще не факт что работают. Nginx давно умеет распределять нагрузку между сотнями инстансов и в 99% этого достаточно. Базы данных давным давно умеют в репликацию, шардирование и прочие радости. Отткуда-же отказоустойчивость. И без этих ваших распределенных транзакций.
@@gaxeliyодин монолит в развороте кушает 100к рублей, а один сервис вычислений 10к, хм... Дайте как подумать, что выгоднее?
Я думаю Сергей когда говорил о динамической типизации скорее подразумевал компиляцию. На пыхе типы то есть, но из-за отсутствия компиляции и проверки в рантайме оно может непредсказуемо упасть
@@bubblesort6368 тогда лучше не рассказывать ему, что в любом мало-мальски зрелом продакшене хоть на PHP, хоть на Python, типы проверяются статически...
@@gaxeliyплохо они масштабируются. В приложении могут быть разные кусочки, которые требуют разных ресурсов. В случае микросервисы это все гибко настраивается, а в случае монолита будьте добры ещё одну ноду для всего функционала, даже если для большей его части и одной ноды достаточно. А что касается отказоустойчивости... То всего одна ошибка может положить сразу весь монолит и ни какие репликации и пр. тут не помогут. А в микросервисах, максимум упадет сам микросервис и те, кто от него зависят. Подумайте о том, почему те же браузеры живут в разных процессах, а не в одном)
А единорог разве не какает радугой? Или радугой его тошнит?
Или я с другой планеты, или чего-то не понимаю, но наверное пора дать определение термину "большой проект". Вот "большой" это насколько большой, чтобы на пыхе его было сделать и поддерживать сложнее, а то и невозможно, зато на яве или шарпе это бы решалось левой ногой? Примеры хоть какие-то можно?
Фейсбук - типовий приклад, був на PHP до певного моменту.
@@woodzimierz9621 , в том и прикол, что ФБ, ВК, 2гис (вообще на yii был) и еще куча всякого на php есть. Если память не изменяет, то Shopify на симфони. Ну вот я и думаю: это достаточно большое, или нужно что-то другое? Просто добрая половина веба на пхп вертится, пишут проекты от мал до велика, но может я реально не понимаю что такое "большой проект" и всё что я считаю больщим это просто детская песочница? ... хз...
@@woodzimierz9621Ну він і зараз на ПХП, просто фейсбук розробив його діалект - Hack, для своєї віртуальної машини
Вставлю свои 5 копеек: всё ещё зависит от того, что за проект вы пишите, например для ПО для встраиваемых систем, вообще нет смысла разбивать на микросервисы, там как правило нет разделения адресного пространства (из-за ненадобности), и микросервисы всё только усложняют без преимуществ. С другой стороны, если вы пишите ядро ОС, или ПО для каких-то супернадёжных систем, типа ПО для самолётов, ракет, атомных станций, то там у микросервисов появляется дополнительное преимущество, как отказоустойчивость, но опять же к этому надо очень грамотно подойти, т.к. некоторые особо критичные вещи нельзя выделять в микросервисы, потому что если они завалились, то вся система по любому накроется. В общем к озвученному в видео есть ещё куча ньюансов о которых не получится рассказать, т.к. нужно быть погруженным в свою специфику. Собственно даже я сейчас описываю вещи, только по собственному опыту программиста ПО для встраиваемых систем, который писал код как для гражданской авиации, так и для холодильников, при этом я понятия не имею как обстоят дела в банках, веб, и прочих отраслях.
В Сергее слышен надрывный визг практика. Есть ещё научное объяснение гарантированного П с микросервисами. В теории надежности, вероятность безотказной работы системы есть произведение вероятностей безотказной работы всех частей системы. Тоесть, если монолит покрыт юнит тестами и интеграшен тестами, то его вероятность безотказной работы можно дотянуть до 0.95. При таких-же условиях, в случае двух микросервисов, имеем 0.95*0.95 = 0.9025 . Тоесть микросервисы сразу дуншифтят надежность. Дальше вмешиваются системные факторы, типа бардака в чердаках, криворукость и общая жопоголовость, что доводит микросервисные решения до состояния "фифти фифти, коробку в руки и до выхода на лифте".
На мой взгляд, единственное место микросервисов, это если вы пишете систему типа фейсбука с огромным количеством пользователей и контента. В случае моего клиента, одновременно в системе ни разу не работало более десяти человек. Лог кластеров лоад балансера показывает, что ни один из сервисов не был в критической нагрузке и не был даже продублирован. Т.е. миграция на микросервисы была лишней тратой бабла компании.
Разумно, ты не понимаешь, зачем нужны микросервисы на проектах, где 10 человек в онлайне. И когда твой проект настолько прост, что хватает монолита. И я тоже не понимаю. Только это вопрос не против микросервисной архитектуры, ведь она решает совсем другие проблемы.
За моноліт!)
If you know what I mean)))
Преимущества монолитов в кратце (как я понял из видео, своего мнения по этому вопросу не имею):
Хуяк-хуяк, и можно в продакшн!
Проблема поддержки большого по объему кода на ПХП решается не выплатой зарплаты пока не будет написана вменяемая документация и в коде, и отдельным документом. ИМХО
Нормально написаный монолит (ну типа следуя более-менее SOLID, KIS, DRY и паттернам) на C# или JAVA документации не требует ни в коде, ни отдельным документом, т.к. всё понятно просто читая код в IDE. Максимум требуется документация объясняющая какую-то специфичную для бизнес-домена логику.
Трудовое законодательство мировое склонно с вами не согласиться. Хорошо, что обществом не программисты с тираническими наклонностями управляют 😂
про быстродействие - при монолите можно упереться в железо !? микросервисы - разбросаны и большие задачи не затормозят всё ?
Если монолит разбит на модули, у него может быть разграничен доступ к исходному коду для разных команд?
Ну может линтер на прекомите запрещающий редачить файлики из другой папки разве что. Ну или плагинная архитектура.
Жиза... То чувство когда у тебя на горбу монолит на PHP (немаленький) и ты несешь его как крест на Голгофу...
А в целом я с Сергеем согласен. То, что я сейчас пишу больше на Python и PHP - скорее дань моде и простоте с удобством, но у меня опа с критикой Сергея не горит, просто потому что я признаю его правоту, это факт, что монолит лучше.
Пропоную "Спагетті архітектуру" - де співіснує моноліт із мікросервісами, наприклад ресурсоємними сервісами, які не часто викликаються.
Несколько раз в течение ролика сказал, что даже спорить не будет, но в конце предложил поспорить в комментариях. Видимо нам друг с другом))
А вообще - если реально можно вынести кусок тяжёлых вычислений за пределы монолита, и это таки ускорит выполнение запросов от туевой хучи пользователей, насилующих сервер одновременно, то почему бы его туда и не вынести. Не обязательно же разводить тысячи сервисов на все случаи жизни.😳
Сергей просто пришел из тех времен, когда нагрузки были другие и микросервисы не были нужны. Сейчас бизнесы тратят огромные деньги, чтобы перевести свои существующие монолиты на микросервисы, потому что без этого они не смогут масштабировать системы и соответственно конкурировать на рынке. Таковы реалии
Микросервисы это хорошо в плане масштабирования и свободы выбора языка реализации, но...
Есть попаболь. Интерфейсы, за изменениями которых надо следить, медленно и транзакции.
Вообще это вторично. Зависит от задачи
видео из разряда "я не умею писать микросервисы"
Сергей, вы забыли упомянуть главную киллинг фичу микросервисов - масштабируемость
Под масштабируемостью здесь, включая автора, понимают возможность нарастить горизонтально мощностей путем покупки новых серверов. Топором по микроскопу, не углубляясь в проблематику.
Да он часто забывает упоминать преимущества того что ему не нравится
Монолит проще сломать, труднее тестировать, сложно деплоить. А ещё, в случае чего, монолит падает весь и сразу, ровно как и деплоится
Эм. вот вообще не так. Монолит СЛОЖНЕЕ сломать (так как там только код и нет сетевых взаимодействий, внутреннего секьюрити и так далее). Его ПРОЩЕ тестировать, так как гораздо проще деплоить и разворачивать тестовую среду. Микросервисы падают все от падения ОДНОГО сервиса. В чем разница?
@@SergeyNemchinskiy там может и нет сетевых взаимодействий, зато неявных взаимодействий между частями монолита хоть отбавляй. В случае микросервисов после изменений, если небыло изменений контрактов, нужно тестировать только сам микросервис. В случае монололита нужно тестировать его целиком. Микросервис, без изменения его контрактов, можно сломать только в рамках его границ. Монолит можно сломать целиком даже меняя только небольшую часть его функционала. А что касается микросервисов, то они не падают все от падения одного от слова совсем. Если вы так проектирует микросервисы, то это проблема именно в проектировании, а не самом подходе. Нормальные микросервисы строго ограничены, самодостаточны и с четкими границами ответственности. Поэтому если падает только один микросервис, то отказывает только часть функционала, причем пользователи этого даже могут не заметить, потому что приложение в целом вполне себе работает. А вот если откажет монолит, то вообще весь бизнес компании полетит к чертям и компания попадает на бабки.
Я дико извиняюсь, вы вообще работали с чем то сложнее одностраничного сайта типа визитки? Вы сталкивались с проблемами работы над монолитом командой больше одного человека? Вы занимались тестированием сложного монолита?
Сергей почти во всём прав, но! Микросервисы работают быстро, если использовать grpc + масштабировать горизонтально можно бесконечно, в отличии от монолита
15:18 непосопоставимая😂
А как же отказоустойчивость, монолит если сломается полетит вся система
😢
Я так розумію - відео для джунів, які не шарять:) Реальна перевага міксосервісів в можливості збалансовано скейлити сервіси в залежності від навантаження + якщо мікросервіси написані під асинхронну роботу - вони ще й можуть бути відмовостійкими
Моноліти працюють якщо кількість функціональності не дуже висока і її легко скейлити, якщо ж там 20+ модулів - то бажаю вдачи його підтримувати... А якщо у вас все ж таки моноліт досяг тих самих 20+ модулів, то потім тому хто таки обрав моноліт(якщо він все ще там працює) прилітає по шапці і вас чекає купа місяців(якщо не років) міграції з моноліту на мікросервіси:)