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

  Рет қаралды 40,988

Sergey Nemchinskiy

Sergey Nemchinskiy

Күн бұрын

Пікірлер: 354
@SergeyNemchinskiy
@SergeyNemchinskiy 8 ай бұрын
👨‍💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 kzbin.info/www/bejne/hJ-wYoKaZrl-mqM
@РоманДейкаловский
@РоманДейкаловский Жыл бұрын
Наконец то не про джунов и какой язык выбрать. Тема зачётная. Даже отвлёкся от работы.
@ЮрийКарпов-э3ч
@ЮрийКарпов-э3ч Жыл бұрын
В микросервисах еще не раскрыты темы транзакционной целостности, каскадных откатов, саг, оркестрации, дебага и т.д. там тоже всплывает куча проблем) ну и конечно размер команды...и перекладывание оргструктуры на микросервисы. Одна команда - один сервис - две пиццы.
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
А там вообще по другому надо думать. Например, темы транзакционной целостности надо решать в рамках одного домена.
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
@@GK-tw7nu любой плохой проект ведет себя подобным образом.
@hsv000
@hsv000 Жыл бұрын
@@GK-tw7nu прикольно. И че, как жизнь теперь? Сколько вы в таком режиме?
@timurkash
@timurkash Жыл бұрын
Тема оркестрации решается кубером! Дебаг решается делвом, IDE, printLn и др. Каскадные откаты, они же транзакционная целостность, сага решаются инструментарием, типа temporal. Почаще заходите на CNCF. Куча проблем это какие? Конкретно надо идентифицировать и почти под каждую есть свой развитый инструментарий и почти всегда есть изящное решение. Проблем у монолита дохрена! Как логируем? Как мы используем inMemoryDB? Как решаем проблему идентификации и аутентификации? Как мы решаем проблему очередей? Как мерить перфоманс? Как делать тесты и интеграционные тесты? Как делегировать разработку/поддержку сервиса другой команде по причине того, что нынешняя залупилась.В МСА это решается изучением решений. Да, это муторно бывает, но ты решишь все равно так или иначе... А в монолите ты не решишь в принципе! Мой backgound из Oracle. Так что я знаю о чем идет речь! В Oracle я был 20 лет. И ни разу не пожалел, что с ним больше не работаю с ним!
@Kirmakoff
@Kirmakoff Жыл бұрын
Если быть реалистами, то плохой монолит лучше, чем плохие микросервисы. А хороший монолит и хорошие микросервисы никто нигде не видел 🙂 Респект Сергею за то, что не побоялся поднять острую тему
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
Странно, ты не смотрел Нетфликс? Да и ютьюб, сомневаюсь, что это монолит раскиданый по серверам для масштабирования, как там говорил автор
@JDM239
@JDM239 Жыл бұрын
Ты пишешь ютуб или нетфликс? в 99.9% микросервисная архитектура излишня для проекта
@murchenko99
@murchenko99 Жыл бұрын
Не слова не сказал про то что микросервисы легче масштабировать в ширь. При монолите при большой нагрузке - пойдёте поднимать кол-во инстансов монолитов. В этом и основной смысл микросервисов. Масштабирование будет намного дешевле чем монолита
@nereus169
@nereus169 Жыл бұрын
и про отказоустойчивость - если под нагрузкой приложение помрет, то в случае с монолитом это будет не один модуль, а вся система) хотя про масштабирование на 18й минуте он упоминает, но правда почему-то считает это притянутым за уши)
@ceearrashee
@ceearrashee Жыл бұрын
@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 миллисекунд реакції (будь-який веб додаток), або ви не пишете код для критичної інфраструктури (драйвери, реалтайм контролери) - то моноліт писати не варто. А взагалі - перед початком проєктування подумайте яка вам модель підходить більше, і які плюси та мінуси ви отримаєте від кожної моделі. Вибачте, якщо написав різко.
@murchenko99
@murchenko99 Жыл бұрын
@@ceearrashee ну и да про перенос функционала между микросервисами тоже поржал, кем надо быть чтобы например функционал создания заказа написать сначала на микросервисе пользователей например и только потом его переносить на микросервис заказов/товаров. Обычно функционал сразу пишеться в том микросервисе в котором он хотя бы примерно уместен, а общий функционал мы например выносим в отдельный пакет (composer в случае с PHP) чтобы этот код можно было переиспользовать во всех микросервисов
@ForterLV
@ForterLV Жыл бұрын
@@murchenko99 вы говорите о сферическом коне в вакууме. Если вы новые проекты начинаете клепать с микросервисами и идеальной архитектурой, у меня для вас плохие новости - вы дали нехилую такую фору вашим конкурентам. Микросервисы это инструмент для решения определенных проблем. А преждевременная оптимизация это один главных антипаттернов, которым страдают многие новички, мечтающие писать идеальный код в окружении таких же хипстеров. Соответственно, итерация за итерацей придя к понимаю того, что для решения вашей конкретной проблемы вам нужно разделить ваш монолит (пусть даже и модульный) на микросервисы, вы рискуете попасть в ситуацию, когда что-то куда нужно будет переносить, либо в силу неидеальных архитектурных решений, либо в силу легаси и других исторических причин.
@SerhiiNemchynskyi
@SerhiiNemchynskyi Жыл бұрын
Я так понимаю, вы ничего сложнее системы управления пользователями не видели? А, ну тогда да. Но прочитав все ваши доводы не увидел ни единого факта. Не убедили. Сорян. Практикующим программистом я был 20 лет, если уж вы на личности перешли. Так что давайте фактический довод, с которым мы и будем спорить
@ДенисДенис-ц9в
@ДенисДенис-ц9в Жыл бұрын
Сергей, спасибо за видео. Это какая-то магия. Пришло уведомление о новом видео на вашем канале, посмотрел и поехал на собес. И о чем вы думаете меня спросили??? 😁 Какие плюсы и минусы у монолита и микросервисов 🤣 Спасибо, прям вовремя. Офер пока не получил, но всё прошло норм.
@basvalan
@basvalan Жыл бұрын
Ржали после твоего ответа сразу, или подождали пока дверь закроется?
@zikimzikilus1841
@zikimzikilus1841 Жыл бұрын
Да, только не совсем удобно разрабатывать монолит когда у тебя 100+ разработчиков. Сразу получаем деплои по расписанию, а не тогда когда хочешь ты или твоя команда, деплои будут переноситься почти каждый раз ибо кто-то где-то что-то сломал. Так же в рамках монолита будет сложнее поддерживать логические границу между модулями, в рамках микросервисов эти логические границы можно укрепить физическими. Безусловно микросервисы несут в себе кучу других проблем и головных болей, но говорить что микросервисы нужно только если у вас не строго типизированный язык точно не корректно.
@AlexS-gn9tq
@AlexS-gn9tq Жыл бұрын
я слава богу ко всему этому веб аду отношения не имею, но почему-то мне кажется, что в случае с 100+ разработчиками, расписанием и "кто-то что-то сломал" разница только лишь в том, что в микросервисах если кто-то что-то сломал или сделал breaking change, то узнать об этом заранее на этапе компиляции или pull request'a практически невозможно. И в итоге да, вроде каждый деплоит когда захочет, только проблемы это не решает, а только усугубляет тк. надо все изменения тщательно тестировать прежде чем выкатывать пользователям. Разве нет? Прошу разъяснения.
@ForterLV
@ForterLV Жыл бұрын
Деплои по расписанию мы получаем только в том случае, если мы не смогли придумать рабочую имплементацию merge queue. С оной мы получаем релиз в одну кнопку не глядя, при наличии зеленых статусов, за процессом которого можно даже не следить, если алерты настроены корректно. В случае инцидентов да, можно заблокать всю очередь. Но это скорее уже вопрос к построению процесса QA. Заботу о логических границах можно переложить на дептрак какой-нибудь, и больше об этом не вспоминать. Да и не строго типизированные языки, где они? Под этим грозным словом негласно принято подразумевать пыху, на которой без стрикт режима, мне думается, давно уже никто не пишет, а со стриктом и вменяемым фреймом типа Симфы принципиальные отличия от любого другого силайк языка ещё поискать надо.
@zikimzikilus1841
@zikimzikilus1841 Жыл бұрын
@@AlexS-gn9tq Проблема в том что в монолите (сугубо исходя из моего опыта) часто нарушаются логические границы и кто-то начинают юзать твою внутреннюю логику напрямую, миную твой фасад. В рамках микросервисов это границы ты так просто не сломаешь, ибо поверх них находятся физические границы (networ ). По этой причине "кто-то что-то сломал" происходит реже, ибо никак не получить доступ к твоей внутренней логике, только через интерфейс твоего сервиса.
@TcheburTcheburashka
@TcheburTcheburashka Жыл бұрын
@@zikimzikilus1841 Почитав ваши комментарии, нашел правильную аналогию сравнения монолита с микросервисами, только более понятную обывателю... Разница между монолитом и микросервисом в том, что когда ты строишь небольшой дом, то ты можешь сам его построить, сделать внутреннюю обделку, ремонт и т.д.... но вот когда ты решил построить многоэтажку, то тут увы, ты сам уже не справишься... Т.е. монолит от микросервиса отличается размерами... пока монолит не большой, он удобный и быстро можно там внести изменения, но вот когда у Вас в геометрической прогрессии начинается рост запросов, а еще и разнообразных, то никакой монолит не сможет справится уже с этим потоком запросов, нужно масштабироваться не только вертикально, но и горизонтально, вот тут то и приходим к микросервисам...
@sergeymatpoc
@sergeymatpoc Жыл бұрын
@@zikimzikilus1841 я кстати согласен в этом плане. Думал куда засунуть комментарий, вот это хорошее место. Да, если тебе нужно прикрутить кнопку на сайте - то зачем тебе ждать неделю или месяц? Или если сделать ее чуть круглее, или внести какую-то задержку срабатывания. Пока за функцию этой кнопки отвечает одна группа (даже из пары разработчиков) - абсолютно не имеет никакого смысла "напрягать" остальные 98 человек так или иначе (ха, день потратили на функцию, остальные 4 дня отдыхают?). Для остальных это изменение произойдет незаметно, и даже если что-то пойдет не так - решение проблемы будет на плечах опять же этих 2 человек, а не всех. Да, опять же, релиз трейн из кучи изменений это адский ад в траблшутинге.
@topalidinka
@topalidinka Жыл бұрын
Спасибо, обожаю вас слушать ❤ Запишите, пожалуйста,видео про TDD Очень интересно ваше мнение 🙂
@ivanpriz4547
@ivanpriz4547 Жыл бұрын
Один из основных плюсов микросервисов - горизонтальная масштабируемость и отказоустойчивость. Кроме того, более эффективное распределение ресурсов, потому что цпу/ио/ГПУ привязанные вещи можно разнести по разным машинам. Странно что про них здесь не упомянули. Самый простой пример - одна часть приложения вытаскивает данные откуда-то и завязана тол ко на инпут/аутпут, другая обрабатывает каким-то дорогим алгоритмом, мл моделька условная, каким образом поселить обе эти части в одном проекте сделает проект проще и эффективнее?
@tomiyoshi
@tomiyoshi Жыл бұрын
Мне кажется Сергей имел ввиду именно микросервисы. Просто распилить монолит на три четыре части ничего страшного. Страшно становится когда микросервисов тысячи, и пример тому твиттер.
@ivanpriz4547
@ivanpriz4547 Жыл бұрын
@@tomiyoshi ну, микросервисов не обязательно должно быть много, это зависит от размера проекта и правил, по которому часть логики уезжать жить в отдельный сервис. В твиттере их тысячи, потому что Твиттер очень большой, а для скромного онлайн-магазинчика их будет штук 5-10, но если мы распиливаем монолит на несколько частей, то получаем микросервисы. Сергей в начале видео говорит, что монолит - когда живём в одном адресном пространстве, а микросервисы - когда в разных. Так что если у нас логика юзеров в одном приложении, склада в другом, а рекомендации в третьем - это уже микросервисы, как по мне)
@НатаниэльДампо
@НатаниэльДампо Жыл бұрын
​@@ivanpriz4547Вот для любителей онлайн магазинчиков с 5ю микросервисами он этот ролик и выпустил)
@safindanil
@safindanil 10 ай бұрын
​@@ivanpriz4547нет. Микросервисы - это когда почти любая фича изолирована от остальных. Чем меньше в микросервисе функций и зависимостей, тем лучше. Идеальный микросервис - это тот, который выполняет ровно одну задачу, завязан, как максимум, на свою бд и имеет какое то внешнее апи, по которому с ним могут взаимодействовать пользователи из интерфейса
@6aTbKa_MaxHo
@6aTbKa_MaxHo Жыл бұрын
За монолит! Не Долг со Свободой же выбирать 😁
@Yurec10
@Yurec10 Жыл бұрын
Сижу на монолите, но он разбит на модули
@dondragon6949
@dondragon6949 Жыл бұрын
@Yurec10 круто...модульность это хорошо !!! легче обслуживать код!!!
@MasterSergius
@MasterSergius Жыл бұрын
Сижу на стуле, но он с пиками точеными
@SerhiiNemchynskyi
@SerhiiNemchynskyi Жыл бұрын
Наилучший вариант на сегодняшний момент
@ГеоргийЗенюк
@ГеоргийЗенюк Жыл бұрын
​@@SerhiiNemchynskyi ну не знаю, я бы все же выбрал второй стул. Жопа болеть будет, но хотя бы жив останешься🤷
@condoronwheels6480
@condoronwheels6480 Жыл бұрын
​@@MasterSergiusглавное что б не с дрочоными)))
@VitaliiYakovlev-l5k
@VitaliiYakovlev-l5k Жыл бұрын
Не согласен с тем, что микросервисы выбирают потому что они "модные" и что они подходят только для проекта написанных на языках с динамической типизацией. Микросервисы усложняют систему в целом, но значительно упрощают работу для одной конкретной команды. Я сталкивался с проектами (на java), в которых один "жирный" сервис может билдиться около получаса. И это только лишь один из сервисов. Если бы проект был бы монолитом, то он бы наверное билдился бы больше суток. В такой системе "хот фикс" можно было бы отменить. Особенно будет весело когда в самом конце билда подобного монолита билд по какой-то причине зафейлиться, тогда впереди ждёт следующее испытание: в мегабайтах логов огромного монолита найти кусок, который зафейлился и понять почему. Да и банальное индексирование проекта в IDE даже для просто большого микросервиса занимает значительное время и оператива на компе заметно подъедается. В случае с монолитом попросту не хватит нервных клеток для внесения малейшего изменения, так как комп будет тупить. Следующий недостаток работы с большим монолитом - это то, что начинался он в незапамятные времена. И тут на конференциях рассказывают про Spring 6, Project Loom и новые интересные вещи. А на проекте с монолитом будут те технологии, которые были тогда, когда проект стартовал. Какая-нибудь Java 8 и Spring 4, и нет надежды на то, что это когда-нибудь обновиться. Это прямой путь к выгоранию. Также не согласен, что монолит работает значительно быстрее микросервисов. Он работает значительно быстрее системы с очень сильной связанностью сервисов. А если микро сервисы имеет минимальное количество интеграций - то они будут работать быстрее. Рассмотрим в качестве примера банковское приложение. Если это будет монолит - то один и тот же сервер будет в один и тот же момент времени обновлять аватарку пользователя 1, вычитывать перечень транзакций пользователя 2, выполнять оплату коммуналки для пользователя 3 и принимать решение, какой кредитный лимит установить пользователю 4. И при этом для всех этих операций монолит будет лезть в одну базу. В общем, если проект - стартап, который пока не приносит денег, то конечно же лучше начинать с монолита, так как нужно как можно раньше выкинуть на рынок что-то, что начнёт приносить деньги + поменьше тратить на cloud провайдера. Но если проекту много-много лет, над разными фичами работают разные команды, и его до сих пор не подробили на микросервисы - то это очень странный проект и явно не то, на чем хотелось бы работать.
@Anastasia911
@Anastasia911 2 ай бұрын
Спасибо за такой подробный комментарий. Ты спас меня от ошибки
@xakep2776
@xakep2776 27 күн бұрын
​@@Anastasia911 какой?
@Anastasia911
@Anastasia911 17 күн бұрын
@@xakep2776 делать микросервис не подумав, потому что все говорят что это типа хорошо
@sobchenyuk
@sobchenyuk Жыл бұрын
@SergeyNemchinskiy добрый день. В вашем видео не хватает обсуждения про микрофронтенд
@TonyFlexPromo
@TonyFlexPromo Жыл бұрын
Отличный обзор архитектур и очень рад что в наше хипстерское время всё ещё есть сторонники монолитов! Хочу подсветить одну особенность микросервисов, о которой не было сказано. Они позволяют инкапулировать не только логику, но и зависимости. Бывало ли у вас такое, что вы используете библиотеку и в одном месте вам нужна версия 15, а в другом, несовместимая с версией 15, версия 18? Например у них конфликтуют зависимости. Микросервисы позволяют отлично решить эту проблему- на каждый кусок логики у вас будут свои собственные зависимости.
@spacioclub
@spacioclub 4 ай бұрын
а нахрен было так писать модули чтобы они были в зависимости от разных НЕСОВМЕСТИМЫХ версий зависимостей? Это точно такой же путь в зоопарк и говнокод.
@sergeypekar1058
@sergeypekar1058 Жыл бұрын
А как происходит деплой монолита? Собирается один большой билд и выкатывается? То есть все пулл-реквесты тестируются вместе? Мне просто, как человеку пришедшему с проекта с со временем сборки в час интересно разобраться. Потому, что когда у тостера есть несколько устройств, то тестирование не является проблемой, н в ряд ли же каждому тостеру выделяется по серверу. И включение/откат фичи как в этом случае выглядит?
@ForterLV
@ForterLV Жыл бұрын
В обычных условиях при монолите заданные вами вопросы решают merge queue и feature flags. У нас к примеру довольно крупный монолит развертывается по такой схеме, общее время на сборку, все автотесты и деплой это около 15 минут. В специфических проектах с более длинным временем сборки и большим количеством пулл реквестов можно как вариант пробовать сборные реквесты по фичам, командам, или другим принципам группировки. Либо смотреть, откуда растут ноги у такого времени сборки. Пока мы не распараллелили тесты у нас тоже минут за 40-50 время доставки улетало легко.
@Владислав-е6щ9ъ
@Владислав-е6щ9ъ Жыл бұрын
Очередное видео с ошибкой в названии. Правильное: "Java - самый лучший ЯП"
@Roger-qj4wu
@Roger-qj4wu Жыл бұрын
"а Немчинский - самый умный"
@yuriy.kostenko
@yuriy.kostenko 10 ай бұрын
C#- самый лучший ЯП!!!
@Za-Rossiyu4
@Za-Rossiyu4 18 күн бұрын
C++ ​@@yuriy.kostenko
@dmitryzagorevskiy507
@dmitryzagorevskiy507 Жыл бұрын
И сразу лайк не зная контента, и я думаю понятно почему ;) Возвращение одного из лучших каналов про поговорить и не напрягаясь послушать об IT, тоже я думаю понятно для кого ;).
@Ilya-oj5ey
@Ilya-oj5ey Жыл бұрын
Сергей, один вопрос что такое "большое приложение"??) Crm это большая система или среденего размера интернет магазин?)
@woodzimierz9621
@woodzimierz9621 Жыл бұрын
Якщо CRM це Salesforce, то так.
@Ilya-oj5ey
@Ilya-oj5ey Жыл бұрын
@@woodzimierz9621 а где эта грань?
@АлексВитальевич-ж6е
@АлексВитальевич-ж6е Жыл бұрын
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 с этим(обратной совместимостью) проблем нет. Старый код будет работать на новых версиях.
@АлексейСуббота-ц4п
@АлексейСуббота-ц4п Жыл бұрын
Хороший монолит, та вещь которую никто не видел, но всё о нём говорят)
@KREKER8331
@KREKER8331 Жыл бұрын
Как и микросервисы. Только говнокод собран в разных местах)
@nikitapolevoi
@nikitapolevoi Жыл бұрын
@@KREKER8331Netflix с тобой поспорит
@SergeyNemchinskiy
@SergeyNemchinskiy Жыл бұрын
Монолит или микросервисы?
@влажняв4трушка
@влажняв4трушка Жыл бұрын
ЗА МОНОЛИТ!
@РоманДейкаловский
@РоманДейкаловский Жыл бұрын
За здравый смысл
@linuxoidovich
@linuxoidovich Жыл бұрын
Микросервисы. Их масштабировать проще и дешевле.
@olijenius
@olijenius Жыл бұрын
Вопрос не имеет смысла. На него всегда разный ответ в разнос контексте 😅
@Morok55RUS
@Morok55RUS Жыл бұрын
универсальный ответ переводчика. "зависит от контекста" )))
@u02249
@u02249 Жыл бұрын
основная задача микросервисов, это привести разработку в соответствие с организационной структурой компании. разграничить права доступа, разделить ответственность, SLA у разных частей системы разный.
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
Это для местной публики сложно :)
@stiIlen
@stiIlen Жыл бұрын
Честно говоря не очень понял, буду рад разъяcнениям: 1. "Монолит проще микросервиса и его проще рефакторить" - обычно монолит имеет кучу интерфейсов и абстракций, потому что solid и все дела. Но тем не менее связность кода иногда очень сильная и что-то просто поменять в иерархии классов или не дай Бог пакетов - это иногда просто нереально. В микросервисах зачастую можно вообще выкинуть интерфейсы и делать сразу конкретную реализацию и, если надо, ее же потом менять. Других реализаций все равно не будет, потому что ну не будет. Хочешь, можешь хоть весь микросервис переписать за один день и проблем у тебя не будет. 2. Понятно, что монолит можно надробить на модули и вот тебе те же микросервисы в одном "адресном пространстве", только без копипасты общей стуктуры. - Ну окей, на кластере 6 проектов из +- 10 микросервисов и 50+ общих переиспользуемых ими микросервисов. Делать монолит из 50 модулей? А потом все это поднимать единым инстансом? 3. Перфоманс - в случае с монолитом горизонтальное масштабирование обязывает дублировать на ноде все это гигантское приложение. Да и сама нода должна быть весьма мощной, чтобы вывозить его - вертикальное масштабирование очень быстро обгоняет горизонтальное по себестоимости. А если от всего приложения нагружена только небольшая его часть? В микросервисах можно было бы масштабировать конкретный сервис, а тут придется весь монолит поднимать целиком на другой ноде. 4. Если продукт работает, поддерживается и развивается, то так или иначе и язык и различные фреймворки надо поддерживать в актуальном состоянии (надеюсь не надо пояснять зачем). Перевести микросервисы один за другим на новую версию (или на новый язык даже, может более удобный или подходящий) имхо гораздо проще чем например поменять версию одной зависимости в монолите и словить кучу конфликтов и нерешаемых проблем.
@3fsfqp
@3fsfqp Ай бұрын
1. Радикальное следование SOLID (и другим паттернам и принципам) действительно может испортить архитектуру. Но кто мешает сделать монолит как набор сервисов? То есть вместо веб интерфейсов микросервисов, будут интерфейсы языка программирования. В монолите можно применить более мощные средсва развязки компонентов (паттерны проектирования). Только опять же (начинал с этого) если этим увлечься можно только навредить. С умом надо пользоваться этими средствами исходя из практической ценности, а не для того чтобы потренироваться в использовании какого-нибудь паттерна. Да недостаток монолитов в том, что у программиста руки развязаны и он может излишне усложнить абстракции. В микросервисах руки связаны и так не получится: вот тебе конкретные микросервисы и больше никаких абстракций (разве что только внутри микросервисов, только они там редко нужны, так как микросервисы по определению простые). Но это проблема менеджемента и квалификации программистов. При плохом менеджменте и неквалифицированных программистах можно и проект на миросервисах загубить. 2. Да. А что 50 модулей ( или просто классов-сервисов) в монолите это сложнее или чем-то хуже, что 50 микросервисов? По моему 50 миросервисов сложнее. 3. Ну так можно чтобы 1 инстанц монолита занимался одними запросами конечных пользователей, другой другими. Это настройки балансировщика нагрузки. Не обязательно чтобы каждый инстанц монолита обслуживал все типы внешних запросов. Причём менять правила балансировки проще чем, дублировать миросервисы. 4. Это да. Но в большинстве случаев не всё так драматично. Разработчики стремятся поддерживать обратную совместимость, особенно каких-то основополагающих библиотек и фрейворков, а если проблемы и возникают, то видны они на этапе билда (ошибки компиляции при написании монолита на статическом языке) или при простейших тестах. При возникновении нерешаемых проблем, можно выделить часть монолита в отдельный модуль (java или сборку в C#) и в нём поменять зависимость. По поводу деплоя добавлю, что монолит проще обновлять на проде. Если нашли ошибку в микросервисе, то пока его передеплоишь, часть функциональности становится недоступна. Для монолитов решается зеркалированием. Весь монолит дублируем. Пока меняем 1 экземпляр перезагружаем, пользователи работают с другим. Потом другой меняем и перезагружаем. Зеркалирование нужно ещё и по соображения масштабируемости. В итоге нулевой период недоступности даже части функционала. А в микросервисах пока 1 сервис меняешь, какая-то функциональность будет недоступна, какое-то время. Можно конечно все микро сервисы зеркалировать на всякий случай, только это сложнее чем зеркалировать 1 монолит.
@Serhii-Kostin
@Serhii-Kostin Жыл бұрын
мне это напомнило холивары в конце 90-х, начале 00-х: "алгоритмическое программирование или ооп". побеждали алгоритмы с ровно теми же доводами 🙂 p.s. я был сторонником алгоритмического подхода, в первую очередь из-за скорости работы p.p.s. ждем этот же ролик через 10-15 лет 😀
@backendtv1345
@backendtv1345 Жыл бұрын
в те времена лишняя память под объекты заметно влияла на производительность, а сейчас нет
@kohubo6opohe803
@kohubo6opohe803 Жыл бұрын
ООП не исключает алгоритмическое программирование и наоборот. Любое большое корпоративное приложение пишется с использованием ООП, и поверьте, там довольно много нетривиальных алгоритмов, котрых нет ни в каких библиотеках. Другое дело что , как правило, те, кто много изучают алгоритмы, мало изучают ООП или даже совсем его не знают.
@woodzimierz9621
@woodzimierz9621 Жыл бұрын
@@backendtv1345 в 90-х пам'ять вже не парила.
@cppmake7702
@cppmake7702 Жыл бұрын
@@backendtv1345 не лишняя память, а особенность ООП - указатели и ссылки, которые надо еще грамотно использовать, чтобы промахов кешей было меньше, таблицы виртуальных методов, менеджеры куч и обьектов, все это в совокупности нехило так нагружало тогдашнее железо, это сейчас от большой лени разработчики порой плевать хотели на оптимизацию. Поэтому мы и имеем теже казуальные игры, что греют телефон, как будто это онлайн ММО с тыщей игроков. Либо калькулятор, что жрет больше 100 мб памяти...
@Serhii-Kostin
@Serhii-Kostin Жыл бұрын
@@kohubo6opohe803 бінго. Чи ви думаєте ситуація з монолітом та мікросервісами буде інакшою? :)
@СергейНовоселецкий-ж3ч
@СергейНовоселецкий-ж3ч Жыл бұрын
З монолітом особливо весело коли він на Java, запускається 10 хвилин і займає пів сервера. Ну і якщо лиш один модуль під великим навантаженням, то не доцільно запускати ще 10 таких монолітів + якщо додаток statefull і архітектурно distribution не передбачений, то буде проблемно. Але випливаючи з цього, якраз згідний з минулими коментаторами, що краще створити моноліт з хорошою модульною архітектурою а далі якщо проект вистрілить, то розбивати на сервіси по потребі. Той самий модуль можна або винести в окремий сервіс і на моноліті замінити імплементацію на мережевий виклик, а сервіс взагалі переписати на іншу мову. Не використовував ще в реальному житті gRPC, але на скільки бачу з прикладів, він повинен зменшити час latency між сервісами і тим самим пришвидшити роботу всієї системи
@patutinskiy
@patutinskiy 5 ай бұрын
Сергей, Вы проходите интервью в компанию Interactive Brokers на позицию Software Engineer II. Вас просят задизайнить трейдинговую платформу с доступом к 100 мировым биржам и требованием выполнения приказов до 500 ms. Подскажите, какую архитектуру Вы выберете?
@АнтонЕрмаков-д6щ
@АнтонЕрмаков-д6щ Жыл бұрын
Автор говорит, что в микросервисной архитектуре сложно перенести функционал одного микросервиса в другой. Можно пример? На мой взгляд, микросервисы имеют еще 2 преимущества: (1) система в целом может продолжать работать даже если один или несколько микросервисов легли. Например, если в онлайн магазине перестала работать корзина, все равно можно смотреть каталог товаров. (2) для микросервисов подходит методология agile. Значит, продукт можно сделать быстрее. Как насчет этих же пунктов в монолите?
@ПроМойМаркетплейс
@ПроМойМаркетплейс Жыл бұрын
Почему не назван минус монолита, что запускать для тестирования очень долго. У знакомого монолит 1+ млн файлов. Запуск 6+ часов. Не работает и по новой .... П.с. Переписывают на микросервсы сейчас
@yehortverytinov5478
@yehortverytinov5478 Жыл бұрын
потому что автору не выгодно такое говорить, все вспомнят про Джаву в негативном ключе)
@АртемЛомакин-з1с
@АртемЛомакин-з1с Жыл бұрын
Здравствуйте! Вы очень интересно и точно объяснили. Спасибо!
@opalev
@opalev Жыл бұрын
если у вас 30-40 микросервисов, можно положить их модулями в один проект в IDEA, тогда вы увидите, где что используется. но по сути это разработка как монолит. еще плюс микросервисов - много разрабов не натыкаются на конфликты при разработке, или редко.
@bubblesort6368
@bubblesort6368 Жыл бұрын
Это работает, но rpc вызовы все равно ide нормально не проверит в отличии от вызова метода напрямую.
@paulsheldon8199
@paulsheldon8199 Жыл бұрын
а якщо проблеми з перформансом (чи інші нюанси), що заважає частину коду винести в мікросервіс, замість того щоб робити весь мікросервісами?
@vladarskopin3314
@vladarskopin3314 Жыл бұрын
Качественная документация помогает построить микросервисы. Если есть хорошие аналитики, то и архитектура такая пойдёт хорошо
@Дом-ч7г
@Дом-ч7г Жыл бұрын
В чем преимущества микросервисной архитектуры для языков с динамической типизацией? Я нашёл только одно - изоляция модулей, а следовательно проблемы в одном "не будут влиять" на работоспособность других. Есть ли другие?
@Roger-qj4wu
@Roger-qj4wu Жыл бұрын
Да все дураки просто, умный только Немчинский те кто с ним согласны
@sergeymatpoc
@sergeymatpoc Жыл бұрын
насчет "архитектурной работы" - интересно. В плане, "я считаю" что и там и там должна быть модульность и версионность, просто в монолите все модули работают внутри одного приложения (и то не факт, очевидно, это не в камне выбито), а в микросервисах - модули взаимодействуют через АПИ (который тоже можно контролировать, документировать). Причем в обоих случаях лично я (как далекий от софтвер инженеринга человек) не вижу большой разницы, и там и там надо понимать что и как передается, и контролировать эти потоки (через словари и фильтры допустим). Послушал дальше - ну так это же реализуется через разные версии АПИ. Какие-то используют старую версию, какие-то новую. Кстати, отсюда и "минус" монолита - невозможность "разнести" монолит по модулям на разные серверы/воркеры. Сразу приходит на ум Tableau, который съедает абсолютно все доступные ресурсы, но не скейлится в широкие кластера (10 физических серверов с любыми ресурсами съедает на раз и еще просит). Так что "производительность" как преимущество - это тоже вопрос, зависит от размера приложения и обрабатываемых данных.
@itcloudguy
@itcloudguy Жыл бұрын
"почему монолит предпочтительней микросервисов" чтобы что? Из ваших слов выходит, что: 1. Микросервисы пишут только на ЯП с динамической типизацией. 2. Под каждый сервис поднимают отдельный кластер 0_0. 3. Сервисы невозможно дебажить. 4. Нужно развёртывать все сервисы одновременно. Я правильно понял? (прошу прощения за мою резкую критику)
@arhitutorials
@arhitutorials Жыл бұрын
Вы невнимательно смотрели. По вашим тезисам он говорил следующее: 1. Разработчики на ЯП с динамической типизацией имеют тягу к написанию микросервисов. 2. Если нужно поднять много экземпляров одного микросервиса нужен кластер. 3. Дебажить взаимодействие микросервисов - это нетривиальная задача. 4. Развертывание обновлений требует обдумывания каждый раз какие микросервисы в каком порядке деплоить.
@MXT1GA
@MXT1GA 5 ай бұрын
А в чем разница динамики и строгой? То же самое, только в одном нельзя изменять вид данных переменных без костыля. Это как Автомат и Механику в машине выбирать, просто время экономит, инструменты те же​@@arhitutorials
@arhitutorials
@arhitutorials 5 ай бұрын
@@MXT1GA в современных языках программирования зачастую не только тип переменной нельзя поменять, но даже и её значение) Я имею в виду функциональное программирование, элементы которого в том или ином объеме теперь присутствуют везде. Чем больше ограничений, тем меньше места для ошибок.
@ExcaliburPH
@ExcaliburPH Жыл бұрын
Что происходит с системой когда монолитный сервис падает? Отказывает вся система. При такой архитектуре нужно всегда дежарать второй екземпляр монолита прогретый и готовый принять трафик на случай disaster, а это может быть довольно дорого. Также очень часто бывает что монолитное приложение начинает отваливаться при попытке поднять несколько екземпляров (например обработчики cron джоб, которые зачастую могут жить только в 1 екземпляре). Очевидно что при старте проекта не стоит сразу упарывываться в микросервисы так как это очень дорого, но по мере развития проекта выдилять высокангруженые компоненты в отдельные сервисы может очень сильно увеличить стабильность/производительность, очень хороший пример этого - uklon
@yehortverytinov5478
@yehortverytinov5478 Жыл бұрын
твои слова имеют больше аргументации, чем этот ролик на 20 минут
@yuriy.kostenko
@yuriy.kostenko 10 ай бұрын
А что происходит, когда отказывает один или часть микросервисов? Приложение сохраняет видимость работы, но при этом на любое действие сообщает пользовалю, что не может выполнить его запрос, потому что что-то там где-то доступно?
@safindanil
@safindanil 10 ай бұрын
​@@yuriy.kostenkoтогда, при правильном проектировании, отказывает только часть (причем весьма незначительная) приложения. К примеру, в банковском приложении может не отображаться история транзакций, но работать переводы
@avusar2702
@avusar2702 5 ай бұрын
Люди, объясните незнающему. Если мне нужно, к примеру, чтобы у меня проект состоял из нескольких модулей, включая сервер авторизации, клиентское приложение и собственно API-шки, то это микросервисная архитектура или нет? И если да, то получается, что такую архитектуру гораздо легче масштабировать, потому что можно видеть, какой сервис используется чаще и увеличить используемые ресурсы, ведь так?
@stabby6521
@stabby6521 Жыл бұрын
давайте поставим точки на i, большая система это сколько строк? в чем она измеряется? что это за величина?
@QimAliq
@QimAliq Жыл бұрын
оооо какие приятные слова! я подозревал что-то такое, но не был уверен
@Валентин-т2т
@Валентин-т2т Жыл бұрын
про быстродействие - при монолите можно упереться в железо !? микросервисы - разбросаны и большие задачи не затормозят всё ?
@AntonD-kc9zy
@AntonD-kc9zy Жыл бұрын
За рубежом, между прочим, на Ruby написано много крупных систем, бэкенд того же Экс/Твиттера и Airbnb, например.
@woodzimierz9621
@woodzimierz9621 Жыл бұрын
там вже все давно переписано
@Roger-qj4wu
@Roger-qj4wu Жыл бұрын
По зарубежным сервисами это и видно.
@vasjenm
@vasjenm Жыл бұрын
Эм.. Я тут немного в осадок выпал. Какое-то очень однобокое сравнение с незамысловатой идеей, что микросервисы - это просто модно. И лучше их не использовать, а делать монолит, а микросервисы - это от безысходности. Во-первых, если бы было так, то вот вопрос "на подумать". Почему многие энтерпрайз решения перепиливают с монолита на микросервисы, если рабочий продукт уже есть и это рабочий монолит, написанный *цать лет назад? Банки, маркетплейсы, CRM / ERP - очень многие перепиливают. И это дорого, на это нужны специалисты высокого уровня и бизнес это готов оплатить. Вряд ли это ради участия в конференциях или ради имиджа. Так вот такие системы распиливают по одной простой причине - декомпозиция. Такая же как в Чистом коде - лучше 5 небольших методов, чем один длинный и большой. Это такая же концепция, перенесенная на один уровень выше. И оказывается, что действительно проще поддерживать такой код, если есть четкое понимание, где его границы. Во-вторых, что бизнесу прозрачнее в плане учета человеко-часов( и дешевле, как следствие) - один огромный монолит, пусть хоть состоящий из идеальных модулей, или тысяча мелких микросервисов. Новый сотрудник может быстрее влиться и понять, начать работать с каким-то одним проектом и потом расти до нормального уровня. Разработчик меньше тратит времени на изучение кода, нежели на непосредственное его написание, просто потому, что понятнее границы (не всегда, конечно, но в разы проще чем с монолитом). Сюда же можем вспомнить, что многие разрабатывают программы на стороне и опять же проще и понятнее можно ставить задачи и осметчивать стоимость. Ведь уже есть и контракты, и архитектура, и шина - нужно только что-то конкретное под конкретное требование и все. Сложнее накрутить теперь человеко-часы и содрать больше денег. И в-третьих, самая главная - это экономия средств на проде. И дело не только в том, что ноды поднимать, а в том, что каждый отдельный микросервис можно админить отдельно, следить за ресурсами и в какие-то пиковые моменты разворачивать только нужные экземпляры и потом сворачивать их обратно. И это в масштабах больших систем будет существенно дешевле развертки кластера. И деплоить проще не в том плане, что вместо двух кнопок нужен девопс, а в скорости. Добавить новую фичу, сделать перерасчет ставки какой-либо, какая-то новая акция или открылся новый пункт выдачи и нужно учитывать логистику - что угодно. Просто быстрее написать новый код, покрыть тестами его, упаковать в образ и развернуть в проде, общяась с нужными данными через API.
@Dark3470
@Dark3470 11 ай бұрын
Монолит, вернись к покинутым детям своим. Монолит - это свет и знание, знание и свет.
@Alex-qy9zm
@Alex-qy9zm Жыл бұрын
Микросервисы возникли не просто так, например самым большим преимуществом является их масшабируемость. Вообще обычно пишут монолит как POC, а потом дробят его на сервисы
@youto6ka
@youto6ka Жыл бұрын
чет какой-то холивар ради холивара, вставлю свои 5 копеек) кмк стоит начать с того, что оба подхода имеют плюсы и минусы и всегда подход/архитектура/инструмент подбирается под задачи + различные условия, например имеющиеся в команде скиллы а дальше могу предположить, что если вы не метите в хайлоад с миллионами рпс, то логично начать с хорошо написанного монолита, с хорошим разделением кода на модули/интерфейсы/классы и т.п. таким образом, что если вдруг ваш проект становится популярным и теперь надо обслуживать многа-многа юзеров, вы идете и выносите нужный модуль в отдельный сервис с минимальными усилиями ну или прям заранее видите узкое место и сразу его выносите ну и да, кажется что какой-нибудь кубер или облака, это уже мастхэв в современном мире поднимать/масштабировать сервисы при этом очень дешево, а если недешево - то нафиг такое облако вам нужно
@spiritfrombook
@spiritfrombook Жыл бұрын
Почему не было сказано о маштабирование? А о отказоустойчивости? Вот где микросервисы выигрывают. И монолит же может упереться в предел ресурсов машины. Так же несколько раз делался упор на то, что php онли динамическая типизация. Да это так, но внешне уже есть возможность запретить оставлять не типизированные переменные. Для пользователя все будет выглядеть как статическая типизация, а то, как оно под капотом уже не столь важно, в плане поддержки больших проектов.
@gaxeliy
@gaxeliy Жыл бұрын
Монолиты отлично масштабируются. Преимущества микросервисов тут вообще не факт что работают. Nginx давно умеет распределять нагрузку между сотнями инстансов и в 99% этого достаточно. Базы данных давным давно умеют в репликацию, шардирование и прочие радости. Отткуда-же отказоустойчивость. И без этих ваших распределенных транзакций.
@WildAntonOk
@WildAntonOk Жыл бұрын
​@@gaxeliyодин монолит в развороте кушает 100к рублей, а один сервис вычислений 10к, хм... Дайте как подумать, что выгоднее?
@bubblesort6368
@bubblesort6368 Жыл бұрын
Я думаю Сергей когда говорил о динамической типизации скорее подразумевал компиляцию. На пыхе типы то есть, но из-за отсутствия компиляции и проверки в рантайме оно может непредсказуемо упасть
@gaxeliy
@gaxeliy Жыл бұрын
@@bubblesort6368 тогда лучше не рассказывать ему, что в любом мало-мальски зрелом продакшене хоть на PHP, хоть на Python, типы проверяются статически...
@safindanil
@safindanil 10 ай бұрын
​​​@@gaxeliyплохо они масштабируются. В приложении могут быть разные кусочки, которые требуют разных ресурсов. В случае микросервисы это все гибко настраивается, а в случае монолита будьте добры ещё одну ноду для всего функционала, даже если для большей его части и одной ноды достаточно. А что касается отказоустойчивости... То всего одна ошибка может положить сразу весь монолит и ни какие репликации и пр. тут не помогут. А в микросервисах, максимум упадет сам микросервис и те, кто от него зависят. Подумайте о том, почему те же браузеры живут в разных процессах, а не в одном)
@НиколайНауменко-ч5ш
@НиколайНауменко-ч5ш Жыл бұрын
Лично я не согласен 🙂 Самая дорогая проблема монолита - баг в проде Особенно если это баг из за которой умирает jvm В таком случае работать не будет ничего , в случае микросервисов, работать не будет только тот функционал, который ходит к сервису который упал. Да, монолит работает быстрее, но микросервисы не должны лежать в разных пространствах, что б ходили через интернет друг к другу, микросервисы которые лежат в одной сети, тоже работают, достаточно быстро. (Не быстрее монолита), но в случае если есть внешние зависимости - например какие то апи из интернета, то разница в скорости для пользователя каправило незаметна) Второй плюс микросервисов простота деплоя - не нужно продумывать очередность и зависимость компонентов Для высоконагруженых приложений есть еще проблема - колво потоков на сервере, колво коннектов к бд, это все решается, но оно всплывает намного чаще и регулярнее чем в микросервисах, у которых естественно нагрузка меньше и такие проблемы всплывают реже, если функционал правильно разделен по ответственностям Микросервисы это не просто хайп если бы бизнесу это не нужно было, этого бы не было, микросервисы решают множество проблем бизнеса на котором теряется огромное кол-во денег Ни один бизнес не позволил бы потратить кучу времени и переписать монолит на микросервисы просто потому что «разработчики хотят похайпить» Сейчас в моменте, да, монолит выглядит привлекательным, но в перспективе это дорого. Другой вопрос что не нужно упарываться - и делать на каждую модель по сервису, тогда конечно толку не будет от этого Просто поделился своим мнением
@yehortverytinov5478
@yehortverytinov5478 Жыл бұрын
браво!
@CJSurv
@CJSurv Жыл бұрын
Есть еще ситуевина когда монолит не влазит в железо на одном запросе, а не потому что запросов много. И тогда кластер монолитов не поможет, а микросервис поможет, так как можно будет распаралелить на больше компов чем ядер или винтов на одном
@bubblesort6368
@bubblesort6368 Жыл бұрын
Вы непосредственно сталкивались с такой проблемой? Какого рода система?
@CJSurv
@CJSurv Жыл бұрын
@@bubblesort6368 просто теория. Как пример пул майнинга биткоина. Каждый отдельный клиент - микросервис
@avisalon4730
@avisalon4730 Жыл бұрын
Крутое обяснение, согласен на все 100%! Один вопрос: в последнем пайтоне добавили довольно строгую типизацию, почему на нем нельзя написать большой монолит?
@severin-nalivayko
@severin-nalivayko Жыл бұрын
Потому , что, это не модно 😅
@redneck_prm5429
@redneck_prm5429 Жыл бұрын
Да большие монолиты на той же джанге писали и в эпоху чисто динамического питона (не настолько чудовищно огромные конечно, как можно встретить на жабе, но на несколько миллионов строк кода вполне). Сейчас жэ на таких проектах в основном обмазываются типизацией, пища от радости. Хотя встречаются и адепты только динамики, и последователи идеи "а давайте типизировать только ответственные участки кода".
@АндрейПотапов-с2д
@АндрейПотапов-с2д Жыл бұрын
Провокация.. Любой маленький развивающийся монолит превращается в большой проект, который в случае монолита станет колом. и тут хочешь или нет - будешь архитектурить или умри или на край развивайся на одном месте без оперативного расширения. Каждая доработка будет стоить .. да что я тут пишу .. и так все понятно .... Про написание автотестов в монолите - отдельная тема. Есть еще момент.. если у тебя команда, которая завтра сбежит поджав хвост, то не о каком монолите вообще не может идти и речи. а если у тебя команда "монолитчиков" - это вообще веселый дружный коллектив.
@eq716
@eq716 Жыл бұрын
Будь-що можна зіпсувати кривими руками. Мікросервіси це природнє продовження ідей інженерії, що дає можливість писати гетерогенні системи і розбити проект на компоненти, горизонтально масштабувати їх. Погана спроектовану чи продуману мікросервісну архітектуру дійсно важче рефакторить/вдосконалювать. Якщо є контракти, описані апішки - немає проблем. Зміна функціоналу вирішуєтьс зміною версії API. Старі сервіси працюють на старих апі, нові на нових. Горизонтальне масштабування з коробки (Spring Cloud) Мікросервіси можна легко перенести в serverless. Мікросервіси це не модно, це необхідність. Не завжди. На це повинні бути чіткі причини. Якщо ваш моноліт не спроектований так, щоб його частини можна було винести в мікросервіс при необхідності - це погана архітектура.
@joekerman1114
@joekerman1114 Жыл бұрын
Грамотная модульная архитектура позволяет собирать проект как в монолит, так и в микросервисы. И нивелирует большую часть болей разработки микросервисов.
@sergeytimoshenko5044
@sergeytimoshenko5044 8 ай бұрын
Согласен с каждым словом!
@art-creator
@art-creator Жыл бұрын
всякий, кто хоть раз пытался просто собрать денег на новую крышу над протекающим крыльцом подъезда в домовом чатике - будет против микросервисов.
@ArturKadyrov
@ArturKadyrov Жыл бұрын
Если монолит разбит на модули, у него может быть разграничен доступ к исходному коду для разных команд?
@bubblesort6368
@bubblesort6368 Жыл бұрын
Ну может линтер на прекомите запрещающий редачить файлики из другой папки разве что. Ну или плагинная архитектура.
@GenaTolstij
@GenaTolstij Жыл бұрын
Или я с другой планеты, или чего-то не понимаю, но наверное пора дать определение термину "большой проект". Вот "большой" это насколько большой, чтобы на пыхе его было сделать и поддерживать сложнее, а то и невозможно, зато на яве или шарпе это бы решалось левой ногой? Примеры хоть какие-то можно?
@woodzimierz9621
@woodzimierz9621 Жыл бұрын
Фейсбук - типовий приклад, був на PHP до певного моменту.
@GenaTolstij
@GenaTolstij Жыл бұрын
@@woodzimierz9621 , в том и прикол, что ФБ, ВК, 2гис (вообще на yii был) и еще куча всякого на php есть. Если память не изменяет, то Shopify на симфони. Ну вот я и думаю: это достаточно большое, или нужно что-то другое? Просто добрая половина веба на пхп вертится, пишут проекты от мал до велика, но может я реально не понимаю что такое "большой проект" и всё что я считаю больщим это просто детская песочница? ... хз...
@feddos4227
@feddos4227 Жыл бұрын
​@@woodzimierz9621Ну він і зараз на ПХП, просто фейсбук розробив його діалект - Hack, для своєї віртуальної машини
@vanmihaylovich
@vanmihaylovich Жыл бұрын
Архитектор делает правильно, и только новичок - модно ;)
@-kloani-2937
@-kloani-2937 Жыл бұрын
Сергей, сделайте пожалуйста видео о том, какой проект выбрать начинающему фронтендеру для резюме
@TheAcekon
@TheAcekon Жыл бұрын
возьми друга и напиши ему сервис который решит какие-то его работы
@iteducation1657
@iteducation1657 Жыл бұрын
А для рзюме бэкенд разработчика?
@kimtyatya
@kimtyatya Жыл бұрын
да, ведь таких видео в интернете совсем нет, никто же об этом никогда не снимал видео и не писал посты
@x4sting718
@x4sting718 Жыл бұрын
Подскажите хорошие книги по архитектуре, хорошо бы по геймдеву, но можно хотя бы и для ПО
@deniskhakimov
@deniskhakimov Жыл бұрын
Мне в своё время понравилась книга Роберта Найстрома _"Game Programming Patterns"._ Она с лёгким юмором и на наглядных примерах демонстрирует использование шаблонов проектирования (как базовых, так и довольно специфических) в игровых проектах. Другие книги завязаны на конкретные движки и лишь косвенно касаются таких тем, как повышение быстродействия и правильная архитектура, поэтому не вижу смысла в их перечислении.
@НатаниэльДампо
@НатаниэльДампо Жыл бұрын
Выбирать микросервисы сходу, это то же самое что покупать фуру для езды по городу при покупке машины) или что покрупнее.
@Arlant_co
@Arlant_co Жыл бұрын
Наконец-то я знаю теперь что это и я узнал что оказывается на пайтон можно писать что то большое, спасибо)
@Yauheniush
@Yauheniush Жыл бұрын
А единорог разве не какает радугой? Или радугой его тошнит?
@ilya.davydov
@ilya.davydov Жыл бұрын
Пропущен момент траблшутинга. Когда не понятно где в каскаде вызовов происходит ошибка. Помню статью от нетфликса на эту тему, а они как раз кучу библиотек написали для микросервисов, и в статье они писали, что нужно прям хорошо и много подумать если вы думаете перейти на микросервисы. Оверхед на все про все огромный.
@safindanil
@safindanil 10 ай бұрын
Я не нетфликс, но как при правильном разделении логики можно не понять, где возникла ошибка? ) Типа сломалась у нас оплата, но мы пойдем смотреть сервис каталогов?))
@steazeYT
@steazeYT Жыл бұрын
Я согласен с Сергеем, большинство приложений вполне устроит архитектура монолита. Микросервисы это модно, почему то их сторонники забывают про накладные расходы при их взаимодействии.
@safindanil
@safindanil 10 ай бұрын
По хорошему, этого взаимодействия просто не должно быть вовсе. Если его дофига, то проект где то свернул не туда и на микросервисы логика разделена неправильно
@user-zm2bl8nv5duser-zm2bl8nvd
@user-zm2bl8nv5duser-zm2bl8nvd 11 ай бұрын
Была песенка: "Подошёл я тут к тимлиду: "нужно нам внедрить блокчейн", - Он, дурак, засомневался, говорит: "А нам зачем?" "Как зачем, ведь это ж модно!", но тимлид ответил: "Нет!" Всё, достало, увольняюсь, буду делать свой проект! = имхо, классике не хватает второй части, про микросервисы =)
@АлексВитальевич-ж6е
@АлексВитальевич-ж6е Жыл бұрын
А в целом я с Сергеем согласен. То, что я сейчас пишу больше на Python и PHP - скорее дань моде и простоте с удобством, но у меня опа с критикой Сергея не горит, просто потому что я признаю его правоту, это факт, что монолит лучше.
@SilverBlade001
@SilverBlade001 Жыл бұрын
При распределении вычислений на несколько(или много) узлов в любом случае что-нибудь да пострадает, и частота ошибок возрастает. И, следовательно, больше тратится на перестраховку и коррекцию этих ошибк. Даже если это размноженный монолит. Т.ч. не всё так однозначно и кучеряво, как описывает аффтар. 🙂
@Anastasia911
@Anastasia911 2 ай бұрын
PHP дает большому уму большие возможности. Конечно, не сравнимые с той же Java. PHP существует для определенных задач, в которых он выигрышнее. Проблема в том, что и малому уму он доступен, и получается вордпресс, по которому потом все равняют целый язык
@AlexAlex-jk2tn
@AlexAlex-jk2tn Жыл бұрын
Вставлю свои 5 копеек: всё ещё зависит от того, что за проект вы пишите, например для ПО для встраиваемых систем, вообще нет смысла разбивать на микросервисы, там как правило нет разделения адресного пространства (из-за ненадобности), и микросервисы всё только усложняют без преимуществ. С другой стороны, если вы пишите ядро ОС, или ПО для каких-то супернадёжных систем, типа ПО для самолётов, ракет, атомных станций, то там у микросервисов появляется дополнительное преимущество, как отказоустойчивость, но опять же к этому надо очень грамотно подойти, т.к. некоторые особо критичные вещи нельзя выделять в микросервисы, потому что если они завалились, то вся система по любому накроется. В общем к озвученному в видео есть ещё куча ньюансов о которых не получится рассказать, т.к. нужно быть погруженным в свою специфику. Собственно даже я сейчас описываю вещи, только по собственному опыту программиста ПО для встраиваемых систем, который писал код как для гражданской авиации, так и для холодильников, при этом я понятия не имею как обстоят дела в банках, веб, и прочих отраслях.
@dramaturgpodolsk
@dramaturgpodolsk Жыл бұрын
Хорошо, что-то сообажаешь. На 3+ сойдет, давай зачетку!
@pavlinkuz
@pavlinkuz Жыл бұрын
Слишком абстрактные определения, особенно не понятен масштаб этого "микро". Что это за такая функциональная единица, коих может 1000 быть в среднем приложении, и я так понимаю это еще каждая в отдельном контейнере (докер и тп) работает (без учета масштабирования, 1000 разных контейнеров). В докерхабе скажем масштаб приложений куда крупнее, разные СУБД, веб-серверы, брокеры сообщений там. Мне кажется примерно соразмерно контейнеры все и делают, но я бы не назвал это микро.
@alexeysukhanov7086
@alexeysukhanov7086 Жыл бұрын
В Сергее слышен надрывный визг практика. Есть ещё научное объяснение гарантированного П с микросервисами. В теории надежности, вероятность безотказной работы системы есть произведение вероятностей безотказной работы всех частей системы. Тоесть, если монолит покрыт юнит тестами и интеграшен тестами, то его вероятность безотказной работы можно дотянуть до 0.95. При таких-же условиях, в случае двух микросервисов, имеем 0.95*0.95 = 0.9025 . Тоесть микросервисы сразу дуншифтят надежность. Дальше вмешиваются системные факторы, типа бардака в чердаках, криворукость и общая жопоголовость, что доводит микросервисные решения до состояния "фифти фифти, коробку в руки и до выхода на лифте". На мой взгляд, единственное место микросервисов, это если вы пишете систему типа фейсбука с огромным количеством пользователей и контента. В случае моего клиента, одновременно в системе ни разу не работало более десяти человек. Лог кластеров лоад балансера показывает, что ни один из сервисов не был в критической нагрузке и не был даже продублирован. Т.е. миграция на микросервисы была лишней тратой бабла компании.
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
Разумно, ты не понимаешь, зачем нужны микросервисы на проектах, где 10 человек в онлайне. И когда твой проект настолько прост, что хватает монолита. И я тоже не понимаю. Только это вопрос не против микросервисной архитектуры, ведь она решает совсем другие проблемы.
@sagna6724
@sagna6724 Жыл бұрын
Несколько раз в течение ролика сказал, что даже спорить не будет, но в конце предложил поспорить в комментариях. Видимо нам друг с другом))
@FigisBadralov
@FigisBadralov 6 ай бұрын
Микросервисы - это еще одна опция разработки. А если более детально, то если делать ресурс, то необходимо сначала разрабатывать на условном oracle/delphi и даже пусть это работает в проде! Но мы потом будем упираться во всякие там webRtc, обращения ко всяким внешним системам типа платежным через grpc, со сложной аутентификацией. Да, oracle поддерживает java, но и там могут быть проблемы. В производительности в том числе. Многое можно написать на PL/SQL, но-но-но. Да, всю базу данных можно написать там и логику. Но это все будет в антипатернах.
@_uncle_bob_
@_uncle_bob_ Жыл бұрын
На старте фигачить сервисы наркомания полная, надо не иметь мозгов в голове. У нас как раз и был монолит на пыхе, мы не одного архитектора потеряли в попытках что там переделать 😂 а вообще все по делу, пока всех устраивает монолит и бизнес и ати подразделение рыпаться нет смысла в сторону сервисов, ибо оверхеду и ебли оно добавляет экспоненциально, те кто строил что то с нуля в курсе. Да да, на 5 языках взяли и написали сотню сервисов, а теперь контора годами выпиливает и переписывает их в попытке оставить хотя бы 2. Всем Мир.
@НикитаПархомчик-р2ф
@НикитаПархомчик-р2ф Жыл бұрын
Считаю что не уместно говорить что лучше микросервисы или монолиты. Тут зависит от того какая задача. Архитектура это понятие субъективное разные задачи разные решения.
@redneck_prm5429
@redneck_prm5429 Жыл бұрын
По мне главная беда микросервисов - чрезмерное дробление чуть ли не до состояния нано. Там, где модульный монолит состоял бы из десятка модулей, вполне могут навертеть 50 а то и 100 микросервисов. И вместо изначальной идеи одна команда - один сервис получается по десятку микросервисов на одном разработчике. Да, каждый сервис тут выходит примитивным, но сложность уходит на уровень межсервисного взаимодействия. И вдобавок нехило растут затраты на инфраструктуру, ибо всё это надо обмазывать куберами, мониторингом и прочими опентрейсами.
@safindanil
@safindanil 10 ай бұрын
Что то мне подсказывает, что тут проблема в проектировании) Сервисы по идее должны быть автономными и законченными, а не дробиться почкованием "патамушиа эта крута"
@ulyssesaa
@ulyssesaa Жыл бұрын
Преимущества монолитов в кратце (как я понял из видео, своего мнения по этому вопросу не имею): Хуяк-хуяк, и можно в продакшн!
@НатаниэльДампо
@НатаниэльДампо Жыл бұрын
Микросервисы это мираж в пустыне програмиррвания, кажется вот оно спасение) название такое манящее.
@jack-yurchenko
@jack-yurchenko Жыл бұрын
Доброго дня. В одному з відео бачив як ви згадували про книгу "Clean code - Robert Martin". Зацікавило, почав читати, сподобалось. Буду дуже вдячний якщо надасте рекомендацію по книжкам які допоможуть стати краще у своєму напрямку 🙂 Працюю у банку як software dev.(angular, nestjs). Або якщо є вже таке відео буду вдячний за посилання.
@angelpensive9145
@angelpensive9145 Жыл бұрын
Как программист который переносит логику со scala на go хочу выразить свое "почтение" прошлым коллегам. Как программист который писал монолит по решению одного архитектора и разбивал(непонятно зачем) по решению другого хочу передать привет.
@exhaustedfate2842
@exhaustedfate2842 Жыл бұрын
друг,как то можно лично связаться ,пару вопросов по теме задать?
@ruslan_klimchuk
@ruslan_klimchuk Жыл бұрын
Дякую за світло в цій темі. Може багато хто просто не розуміє в чому різниця. Тому і обирають хайпові речі.
@yehortverytinov5478
@yehortverytinov5478 Жыл бұрын
вам фонариком всего лишь посветили, успокойтесь)
@ruslan_klimchuk
@ruslan_klimchuk Жыл бұрын
@@yehortverytinov5478 інші і того не роблять. 🙂
@jisussestive8977
@jisussestive8977 Жыл бұрын
А как же отказоустойчивость, монолит если сломается полетит вся система
@NikiforovJava
@NikiforovJava Жыл бұрын
Сергей просто пришел из тех времен, когда нагрузки были другие и микросервисы не были нужны. Сейчас бизнесы тратят огромные деньги, чтобы перевести свои существующие монолиты на микросервисы, потому что без этого они не смогут масштабировать системы и соответственно конкурировать на рынке. Таковы реалии
@Kismonavt
@Kismonavt Жыл бұрын
Сергей почти во всём прав, но! Микросервисы работают быстро, если использовать grpc + масштабировать горизонтально можно бесконечно, в отличии от монолита
@SilverBlade001
@SilverBlade001 Жыл бұрын
А вообще - если реально можно вынести кусок тяжёлых вычислений за пределы монолита, и это таки ускорит выполнение запросов от туевой хучи пользователей, насилующих сервер одновременно, то почему бы его туда и не вынести. Не обязательно же разводить тысячи сервисов на все случаи жизни.😳
@MichaelKondrashin
@MichaelKondrashin 10 ай бұрын
Все верно на 100%, кроме масштабирования монолита. Если микросервисы создаются с представлением о том, что каждый из них могут запустить два и более раз (хоть тысячу), то монолитные приложения масштабируются в кластер с большими переделками и кровью. Попробуйте переделать MS Word в кластерное ПО, чтобы действия пользователя синхронизировались между узлами кластера в реальном времени и чтобы все работало быстрее пропорционально числу узлов! Ну бред же. Так что монолит, это кода легко масштабироваться только вертикально, а микросервисы - еще и горизонтально
@safindanil
@safindanil 10 ай бұрын
У Ворда вроде есть одновременное редактирование )
@MichaelKondrashin
@MichaelKondrashin 10 ай бұрын
@@safindanil да, когда открываешь с облаком, где весь бекенд - микросервисы.
@KREKER8331
@KREKER8331 Жыл бұрын
Да микросервисы просто расхайповали, половина людей вообще не понимает зачем они нужны и когда их применять. Зато звучит солидно... 😂
@broken_beyond_belief
@broken_beyond_belief Жыл бұрын
СОЛИДно
@ilyas4467-p8m
@ilyas4467-p8m Жыл бұрын
Так большей части проектов это не нужно физически
@safindanil
@safindanil 10 ай бұрын
Монолит проще сломать, труднее тестировать, сложно деплоить. А ещё, в случае чего, монолит падает весь и сразу, ровно как и деплоится
@SergeyNemchinskiy
@SergeyNemchinskiy 10 ай бұрын
Эм. вот вообще не так. Монолит СЛОЖНЕЕ сломать (так как там только код и нет сетевых взаимодействий, внутреннего секьюрити и так далее). Его ПРОЩЕ тестировать, так как гораздо проще деплоить и разворачивать тестовую среду. Микросервисы падают все от падения ОДНОГО сервиса. В чем разница?
@safindanil
@safindanil 10 ай бұрын
@@SergeyNemchinskiy там может и нет сетевых взаимодействий, зато неявных взаимодействий между частями монолита хоть отбавляй. В случае микросервисов после изменений, если небыло изменений контрактов, нужно тестировать только сам микросервис. В случае монололита нужно тестировать его целиком. Микросервис, без изменения его контрактов, можно сломать только в рамках его границ. Монолит можно сломать целиком даже меняя только небольшую часть его функционала. А что касается микросервисов, то они не падают все от падения одного от слова совсем. Если вы так проектирует микросервисы, то это проблема именно в проектировании, а не самом подходе. Нормальные микросервисы строго ограничены, самодостаточны и с четкими границами ответственности. Поэтому если падает только один микросервис, то отказывает только часть функционала, причем пользователи этого даже могут не заметить, потому что приложение в целом вполне себе работает. А вот если откажет монолит, то вообще весь бизнес компании полетит к чертям и компания попадает на бабки. Я дико извиняюсь, вы вообще работали с чем то сложнее одностраничного сайта типа визитки? Вы сталкивались с проблемами работы над монолитом командой больше одного человека? Вы занимались тестированием сложного монолита?
@Shivalin
@Shivalin Жыл бұрын
@SergeyNemchinskiy Сделайте курс по Python для DevOps и SRE, я к вам приду учиться.
@VaGroz
@VaGroz Жыл бұрын
Одна задача - это уже какая-то лямбда, а не микросервис
@SpaciX
@SpaciX Жыл бұрын
😢
@pasha5760
@pasha5760 Жыл бұрын
Пропоную "Спагетті архітектуру" - де співіснує моноліт із мікросервісами, наприклад ресурсоємними сервісами, які не часто викликаються.
@romabulava899
@romabulava899 9 ай бұрын
тоже подумал что только для масштабирования выносить модули в отдельный сервис норм
@Yurec10
@Yurec10 Жыл бұрын
15:18 непосопоставимая😂
@Immortanjoe789
@Immortanjoe789 Жыл бұрын
Монолиты тоже разные бывают. Поддерживать монолит из 1500 таблиц, тысячи файлов миграций бд и млн. строк кода просто невозможно. И жди очереди на мр по 2 дня.
@MrJloa
@MrJloa Жыл бұрын
Микросервисы это хорошо в плане масштабирования и свободы выбора языка реализации, но... Есть попаболь. Интерфейсы, за изменениями которых надо следить, медленно и транзакции. Вообще это вторично. Зависит от задачи
@Anton_Rozhanskii
@Anton_Rozhanskii Жыл бұрын
Превьюха прям крутая 👍🙂
@mutniytip2000
@mutniytip2000 Жыл бұрын
видео из разряда "я не умею писать микросервисы"
@SergeiPeshalov
@SergeiPeshalov Жыл бұрын
Микросервысы на PHP vs монолин на PHP - тоже самое как на jave ) Реально почитай спеку уже php 8 - там тебе и типизация, и ООП просто чудесный... Я хз - чего ты вцепился в эту мертвую 5.6 ))))
黑天使只对C罗有感觉#short #angel #clown
00:39
Super Beauty team
Рет қаралды 36 МЛН
Как учиться программированию эффективно?
21:35
Что такое Java и как ее выучить?
19:55
Sergey Nemchinskiy
Рет қаралды 155 М.