👨‍💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 ukposts.info/have/v-deo/hp5-ZYWbaIp8xXU.html

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте! Вы очень интересно и точно объяснили. Спасибо!

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

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

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

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

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

Наконец-то я знаю теперь что это и я узнал что оказывается на пайтон можно писать что то большое, спасибо)

Сергей, спасибо за видео. Вопрос: что вы понимаете под маленьким, большим приложением. Сложно наверное оценить, но если в, допустим, строчках кода? Это сколько? Откуда начинается большое приложение?

Качественная документация помогает построить микросервисы. Если есть хорошие аналитики, то и архитектура такая пойдёт хорошо

@SergeyNemchinskiy добрый день. В вашем видео не хватает обсуждения про микрофронтенд

Грамотная модульная архитектура позволяет собирать проект как в монолит, так и в микросервисы. И нивелирует большую часть болей разработки микросервисов.

А как происходит деплой монолита? Собирается один большой билд и выкатывается? То есть все пулл-реквесты тестируются вместе? Мне просто, как человеку пришедшему с проекта с со временем сборки в час интересно разобраться. Потому, что когда у тостера есть несколько устройств, то тестирование не является проблемой, н в ряд ли же каждому тостеру выделяется по серверу. И включение/откат фичи как в этом случае выглядит?

Автор говорит, что в микросервисной архитектуре сложно перенести функционал одного микросервиса в другой. Можно пример? На мой взгляд, микросервисы имеют еще 2 преимущества: (1) система в целом может продолжать работать даже если один или несколько микросервисов легли. Например, если в онлайн магазине перестала работать корзина, все равно можно смотреть каталог товаров. (2) для микросервисов подходит методология agile. Значит, продукт можно сделать быстрее. Как насчет этих же пунктов в монолите?

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

Архитектор делает правильно, и только новичок - модно ;)

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

оооо какие приятные слова! я подозревал что-то такое, но не был уверен

Сергей, один вопрос что такое "большое приложение"??) Crm это большая система или среденего размера интернет магазин?)

а якщо проблеми з перформансом (чи інші нюанси), що заважає частину коду винести в мікросервіс, замість того щоб робити весь мікросервісами?

Была песенка: "Подошёл я тут к тимлиду: "нужно нам внедрить блокчейн", - Он, дурак, засомневался, говорит: "А нам зачем?" "Как зачем, ведь это ж модно!", но тимлид ответил: "Нет!" Всё, достало, увольняюсь, буду делать свой проект! = имхо, классике не хватает второй части, про микросервисы =)

Монолит или микросервисы?

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

давайте поставим точки на i, большая система это сколько строк? в чем она измеряется? что это за величина?

Почему не назван минус монолита, что запускать для тестирования очень долго. У знакомого монолит 1+ млн файлов. Запуск 6+ часов. Не работает и по новой .... П.с. Переписывают на микросервсы сейчас

Интересная информация. 😏

"почему монолит предпочтительней микросервисов" чтобы что? Из ваших слов выходит, что: 1. Микросервисы пишут только на ЯП с динамической типизацией. 2. Под каждый сервис поднимают отдельный кластер 0_0. 3. Сервисы невозможно дебажить. 4. Нужно развёртывать все сервисы одновременно. Я правильно понял? (прошу прощения за мою резкую критику)

Крутое обяснение, согласен на все 100%! Один вопрос: в последнем пайтоне добавили довольно строгую типизацию, почему на нем нельзя написать большой монолит?

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

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

Есть еще ситуевина когда монолит не влазит в железо на одном запросе, а не потому что запросов много. И тогда кластер монолитов не поможет, а микросервис поможет, так как можно будет распаралелить на больше компов чем ядер или винтов на одном

Согласен с каждым словом!

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

Превьюха прям крутая 👍🙂

насчет "архитектурной работы" - интересно. В плане, "я считаю" что и там и там должна быть модульность и версионность, просто в монолите все модули работают внутри одного приложения (и то не факт, очевидно, это не в камне выбито), а в микросервисах - модули взаимодействуют через АПИ (который тоже можно контролировать, документировать). Причем в обоих случаях лично я (как далекий от софтвер инженеринга человек) не вижу большой разницы, и там и там надо понимать что и как передается, и контролировать эти потоки (через словари и фильтры допустим). Послушал дальше - ну так это же реализуется через разные версии АПИ. Какие-то используют старую версию, какие-то новую. Кстати, отсюда и "минус" монолита - невозможность "разнести" монолит по модулям на разные серверы/воркеры. Сразу приходит на ум Tableau, который съедает абсолютно все доступные ресурсы, но не скейлится в широкие кластера (10 физических серверов с любыми ресурсами съедает на раз и еще просит). Так что "производительность" как преимущество - это тоже вопрос, зависит от размера приложения и обрабатываемых данных.

Микросервисы возникли не просто так, например самым большим преимуществом является их масшабируемость. Вообще обычно пишут монолит как POC, а потом дробят его на сервисы

А как же отказоустойчивость, монолит если сломается полетит вся система

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 с этим(обратной совместимостью) проблем нет. Старый код будет работать на новых версиях.

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

Хорошо, что-то сообажаешь. На 3+ сойдет, давай зачетку!

А единорог разве не какает радугой? Или радугой его тошнит?

Как правило любой монолит интегрируется со множеством других программ и так же делает это по сети - вот тебе и микросервисы. Так что возникновение микросервисов неизбежно и закономерно. А выбирать надо то что модно так как если ты программист то проще будет найти работу а если ты работодатель капиталист то проще будет найти работничков

По мне главная беда микросервисов - чрезмерное дробление чуть ли не до состояния нано. Там, где модульный монолит состоял бы из десятка модулей, вполне могут навертеть 50 а то и 100 микросервисов. И вместо изначальной идеи одна команда - один сервис получается по десятку микросервисов на одном разработчике. Да, каждый сервис тут выходит примитивным, но сложность уходит на уровень межсервисного взаимодействия. И вдобавок нехило растут затраты на инфраструктуру, ибо всё это надо обмазывать куберами, мониторингом и прочими опентрейсами.

При распределении вычислений на несколько(или много) узлов в любом случае что-нибудь да пострадает, и частота ошибок возрастает. И, следовательно, больше тратится на перестраховку и коррекцию этих ошибк. Даже если это размноженный монолит. Т.ч. не всё так однозначно и кучеряво, как описывает аффтар. 🙂

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

Считаю что не уместно говорить что лучше микросервисы или монолиты. Тут зависит от того какая задача. Архитектура это понятие субъективное разные задачи разные решения.

тоже подумал что только для масштабирования выносить модули в отдельный сервис норм

Что происходит с системой когда монолитный сервис падает? Отказывает вся система. При такой архитектуре нужно всегда дежарать второй екземпляр монолита прогретый и готовый принять трафик на случай disaster, а это может быть довольно дорого. Также очень часто бывает что монолитное приложение начинает отваливаться при попытке поднять несколько екземпляров (например обработчики cron джоб, которые зачастую могут жить только в 1 екземпляре). Очевидно что при старте проекта не стоит сразу упарывываться в микросервисы так как это очень дорого, но по мере развития проекта выдилять высокангруженые компоненты в отдельные сервисы может очень сильно увеличить стабильность/производительность, очень хороший пример этого - uklon

В чем преимущества микросервисной архитектуры для языков с динамической типизацией? Я нашёл только одно - изоляция модулей, а следовательно проблемы в одном "не будут влиять" на работоспособность других. Есть ли другие?

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

Или я с другой планеты, или чего-то не понимаю, но наверное пора дать определение термину "большой проект". Вот "большой" это насколько большой, чтобы на пыхе его было сделать и поддерживать сложнее, а то и невозможно, зато на яве или шарпе это бы решалось левой ногой? Примеры хоть какие-то можно?

На старте фигачить сервисы наркомания полная, надо не иметь мозгов в голове. У нас как раз и был монолит на пыхе, мы не одного архитектора потеряли в попытках что там переделать 😂 а вообще все по делу, пока всех устраивает монолит и бизнес и ати подразделение рыпаться нет смысла в сторону сервисов, ибо оверхеду и ебли оно добавляет экспоненциально, те кто строил что то с нуля в курсе. Да да, на 5 языках взяли и написали сотню сервисов, а теперь контора годами выпиливает и переписывает их в попытке оставить хотя бы 2. Всем Мир.

Почему не было сказано о маштабирование? А о отказоустойчивости? Вот где микросервисы выигрывают. И монолит же может упереться в предел ресурсов машины. Так же несколько раз делался упор на то, что php онли динамическая типизация. Да это так, но внешне уже есть возможность запретить оставлять не типизированные переменные. Для пользователя все будет выглядеть как статическая типизация, а то, как оно под капотом уже не столь важно, в плане поддержки больших проектов.

За рубежом, между прочим, на Ruby написано много крупных систем, бэкенд того же Экс/Твиттера и Airbnb, например.

видео из разряда "я не умею писать микросервисы"

Будь-що можна зіпсувати кривими руками. Мікросервіси це природнє продовження ідей інженерії, що дає можливість писати гетерогенні системи і розбити проект на компоненти, горизонтально масштабувати їх. Погана спроектовану чи продуману мікросервісну архітектуру дійсно важче рефакторить/вдосконалювать. Якщо є контракти, описані апішки - немає проблем. Зміна функціоналу вирішуєтьс зміною версії API. Старі сервіси працюють на старих апі, нові на нових. Горизонтальне масштабування з коробки (Spring Cloud) Мікросервіси можна легко перенести в serverless. Мікросервіси це не модно, це необхідність. Не завжди. На це повинні бути чіткі причини. Якщо ваш моноліт не спроектований так, щоб його частини можна було винести в мікросервіс при необхідності - це погана архітектура.

@SergeyNemchinskiy Сделайте курс по Python для DevOps и SRE, я к вам приду учиться.

Микросервисы это мираж в пустыне програмиррвания, кажется вот оно спасение) название такое манящее.

Вставлю свои 5 копеек: всё ещё зависит от того, что за проект вы пишите, например для ПО для встраиваемых систем, вообще нет смысла разбивать на микросервисы, там как правило нет разделения адресного пространства (из-за ненадобности), и микросервисы всё только усложняют без преимуществ. С другой стороны, если вы пишите ядро ОС, или ПО для каких-то супернадёжных систем, типа ПО для самолётов, ракет, атомных станций, то там у микросервисов появляется дополнительное преимущество, как отказоустойчивость, но опять же к этому надо очень грамотно подойти, т.к. некоторые особо критичные вещи нельзя выделять в микросервисы, потому что если они завалились, то вся система по любому накроется. В общем к озвученному в видео есть ещё куча ньюансов о которых не получится рассказать, т.к. нужно быть погруженным в свою специфику. Собственно даже я сейчас описываю вещи, только по собственному опыту программиста ПО для встраиваемых систем, который писал код как для гражданской авиации, так и для холодильников, при этом я понятия не имею как обстоят дела в банках, веб, и прочих отраслях.

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

Лично я не согласен 🙂 Самая дорогая проблема монолита - баг в проде Особенно если это баг из за которой умирает jvm В таком случае работать не будет ничего , в случае микросервисов, работать не будет только тот функционал, который ходит к сервису который упал. Да, монолит работает быстрее, но микросервисы не должны лежать в разных пространствах, что б ходили через интернет друг к другу, микросервисы которые лежат в одной сети, тоже работают, достаточно быстро. (Не быстрее монолита), но в случае если есть внешние зависимости - например какие то апи из интернета, то разница в скорости для пользователя каправило незаметна) Второй плюс микросервисов простота деплоя - не нужно продумывать очередность и зависимость компонентов Для высоконагруженых приложений есть еще проблема - колво потоков на сервере, колво коннектов к бд, это все решается, но оно всплывает намного чаще и регулярнее чем в микросервисах, у которых естественно нагрузка меньше и такие проблемы всплывают реже, если функционал правильно разделен по ответственностям Микросервисы это не просто хайп если бы бизнесу это не нужно было, этого бы не было, микросервисы решают множество проблем бизнеса на котором теряется огромное кол-во денег Ни один бизнес не позволил бы потратить кучу времени и переписать монолит на микросервисы просто потому что «разработчики хотят похайпить» Сейчас в моменте, да, монолит выглядит привлекательным, но в перспективе это дорого. Другой вопрос что не нужно упарываться - и делать на каждую модель по сервису, тогда конечно толку не будет от этого Просто поделился своим мнением

Слишком абстрактные определения, особенно не понятен масштаб этого "микро". Что это за такая функциональная единица, коих может 1000 быть в среднем приложении, и я так понимаю это еще каждая в отдельном контейнере (докер и тп) работает (без учета масштабирования, 1000 разных контейнеров). В докерхабе скажем масштаб приложений куда крупнее, разные СУБД, веб-серверы, брокеры сообщений там. Мне кажется примерно соразмерно контейнеры все и делают, но я бы не назвал это микро.

Доброго дня. В одному з відео бачив як ви згадували про книгу "Clean code - Robert Martin". Зацікавило, почав читати, сподобалось. Буду дуже вдячний якщо надасте рекомендацію по книжкам які допоможуть стати краще у своєму напрямку 🙂 Працюю у банку як software dev.(angular, nestjs). Або якщо є вже таке відео буду вдячний за посилання.

Реклама курса топ, на контрасте

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

Как программист который переносит логику со scala на go хочу выразить свое "почтение" прошлым коллегам. Как программист который писал монолит по решению одного архитектора и разбивал(непонятно зачем) по решению другого хочу передать привет.

В Сергее слышен надрывный визг практика. Есть ещё научное объяснение гарантированного П с микросервисами. В теории надежности, вероятность безотказной работы системы есть произведение вероятностей безотказной работы всех частей системы. Тоесть, если монолит покрыт юнит тестами и интеграшен тестами, то его вероятность безотказной работы можно дотянуть до 0.95. При таких-же условиях, в случае двух микросервисов, имеем 0.95*0.95 = 0.9025 . Тоесть микросервисы сразу дуншифтят надежность. Дальше вмешиваются системные факторы, типа бардака в чердаках, криворукость и общая жопоголовость, что доводит микросервисные решения до состояния "фифти фифти, коробку в руки и до выхода на лифте". На мой взгляд, единственное место микросервисов, это если вы пишете систему типа фейсбука с огромным количеством пользователей и контента. В случае моего клиента, одновременно в системе ни разу не работало более десяти человек. Лог кластеров лоад балансера показывает, что ни один из сервисов не был в критической нагрузке и не был даже продублирован. Т.е. миграция на микросервисы была лишней тратой бабла компании.

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

Несколько раз в течение ролика сказал, что даже спорить не будет, но в конце предложил поспорить в комментариях. Видимо нам друг с другом))

А в целом я с Сергеем согласен. То, что я сейчас пишу больше на Python и PHP - скорее дань моде и простоте с удобством, но у меня опа с критикой Сергея не горит, просто потому что я признаю его правоту, это факт, что монолит лучше.

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

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

Преимущества монолитов в кратце (как я понял из видео, своего мнения по этому вопросу не имею): Хуяк-хуяк, и можно в продакшн!

Жиза... То чувство когда у тебя на горбу монолит на PHP (немаленький) и ты несешь его как крест на Голгофу...

Микросервысы на PHP vs монолин на PHP - тоже самое как на jave ) Реально почитай спеку уже php 8 - там тебе и типизация, и ООП просто чудесный... Я хз - чего ты вцепился в эту мертвую 5.6 ))))

Эм.. Я тут немного в осадок выпал. Какое-то очень однобокое сравнение с незамысловатой идеей, что микросервисы - это просто модно. И лучше их не использовать, а делать монолит, а микросервисы - это от безысходности. Во-первых, если бы было так, то вот вопрос "на подумать". Почему многие энтерпрайз решения перепиливают с монолита на микросервисы, если рабочий продукт уже есть и это рабочий монолит, написанный *цать лет назад? Банки, маркетплейсы, CRM / ERP - очень многие перепиливают. И это дорого, на это нужны специалисты высокого уровня и бизнес это готов оплатить. Вряд ли это ради участия в конференциях или ради имиджа. Так вот такие системы распиливают по одной простой причине - декомпозиция. Такая же как в Чистом коде - лучше 5 небольших методов, чем один длинный и большой. Это такая же концепция, перенесенная на один уровень выше. И оказывается, что действительно проще поддерживать такой код, если есть четкое понимание, где его границы. Во-вторых, что бизнесу прозрачнее в плане учета человеко-часов( и дешевле, как следствие) - один огромный монолит, пусть хоть состоящий из идеальных модулей, или тысяча мелких микросервисов. Новый сотрудник может быстрее влиться и понять, начать работать с каким-то одним проектом и потом расти до нормального уровня. Разработчик меньше тратит времени на изучение кода, нежели на непосредственное его написание, просто потому, что понятнее границы (не всегда, конечно, но в разы проще чем с монолитом). Сюда же можем вспомнить, что многие разрабатывают программы на стороне и опять же проще и понятнее можно ставить задачи и осметчивать стоимость. Ведь уже есть и контракты, и архитектура, и шина - нужно только что-то конкретное под конкретное требование и все. Сложнее накрутить теперь человеко-часы и содрать больше денег. И в-третьих, самая главная - это экономия средств на проде. И дело не только в том, что ноды поднимать, а в том, что каждый отдельный микросервис можно админить отдельно, следить за ресурсами и в какие-то пиковые моменты разворачивать только нужные экземпляры и потом сворачивать их обратно. И это в масштабах больших систем будет существенно дешевле развертки кластера. И деплоить проще не в том плане, что вместо двух кнопок нужен девопс, а в скорости. Добавить новую фичу, сделать перерасчет ставки какой-либо, какая-то новая акция или открылся новый пункт выдачи и нужно учитывать логистику - что угодно. Просто быстрее написать новый код, покрыть тестами его, упаковать в образ и развернуть в проде, общяась с нужными данными через API.

15:18 непосопоставимая😂

Сергей почти во всём прав, но! Микросервисы работают быстро, если использовать grpc + масштабировать горизонтально можно бесконечно, в отличии от монолита

Я согласен с Сергеем, большинство приложений вполне устроит архитектура монолита. Микросервисы это модно, почему то их сторонники забывают про накладные расходы при их взаимодействии.

Микросервисы это хорошо в плане масштабирования и свободы выбора языка реализации, но... Есть попаболь. Интерфейсы, за изменениями которых надо следить, медленно и транзакции. Вообще это вторично. Зависит от задачи

Худший сон Сергея Немчинского - закон о запрете монолита

Кто-то наконец сказал это

Монолиты тоже разные бывают. Поддерживать монолит из 1500 таблиц, тысячи файлов миграций бд и млн. строк кода просто невозможно. И жди очереди на мр по 2 дня.

Дякую за світло в цій темі. Може багато хто просто не розуміє в чому різниця. Тому і обирають хайпові речі.

Провокация.. Любой маленький развивающийся монолит превращается в большой проект, который в случае монолита станет колом. и тут хочешь или нет - будешь архитектурить или умри или на край развивайся на одном месте без оперативного расширения. Каждая доработка будет стоить .. да что я тут пишу .. и так все понятно .... Про написание автотестов в монолите - отдельная тема. Есть еще момент.. если у тебя команда, которая завтра сбежит поджав хвост, то не о каком монолите вообще не может идти и речи. а если у тебя команда "монолитчиков" - это вообще веселый дружный коллектив.

За моноліт!) If you know what I mean)))

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

Масштабирование

😢