Микросервисы Простыми Словами за 1 Час

[@fakng-engineer]

Шпаргалка по Микросервисам: www.faang.school/java-junior-library? Мой Java Буткемп: www.faang.school/? Java Magics. Курс для начинающих: www.faang.school/java-magics?

[@DenysGarbuz]

Можешь дать топ 10 тулзов спринга которые ты юзаешь на проектах и которые востребованы

[@ТимаКама]

ХАХАХАХАХАХ "Микросервисы Простыми Словами за 1 Час" КЛЮЧЕВОЕ СЛОВО "ПРОСТЫМИ И ЧЕЛЫЫЫЙ ЧАС"

[@SamuraiAltezza]

классно что ссылка не рабочая 1ая

[@Ivan-t8l1r]

@@ТимаКама что имеешь в виду?

[@ХанасисЕвгений]

Бро, сделай подобное видео про Kubernetes. Лайк, кто за)

[@СергейДенисов-ф6б]

Да зачем он нужен, этим девопс занимается, программисту это не к чему

[@alexshutov5442]

@@СергейДенисов-ф6б не совсем согласен. Всё чаще и чаще от девелоперов требуют разбираться в оркестраторах. Не везде есть штатные девопсы.

[@katekomlevaJD]

​@@СергейДенисов-ф6б супер супер спорно. Многим разработчикам очень нужны знание кубера

[@АлександрКоробейников-м3я]

@@СергейДенисов-ф6б чтобы пет-проекты в соло поднимать хотя бы)

[@Deletedeletedelete]

@@СергейДенисов-ф6б с таким мышлением ты ограничиваешь свое развитие и как следствие доходы

[@goodvideobro]

ждём про кафку всей маршруткой

[@Ivan-t8l1r]

уже есть

[@igordek9494]

Просто аплодирую стоя 👏👏👏👏👏👏 Я недавно начал обучение, потихоньку вникаю во всю эту кухню, но нигде не видел такой обширной информации, которая рассказывает весь широкий спектр работы над проектами и работы разработчика в целом. Везде только и говорят, нужно научиться кодить, но никто не заикнулся о десятках других инструментах, которые необходимы, чтобы ваш код появился на свет. Это как сказать, повару, что он будет готовить борщ и промолчать о всех инструментах и продуктах, в конце концов тонкостях, которыми он должен уметь пользоваться (ну с борщом ясно пример лёгкий, потому что все знают как он готовиться ), но не каждый хоть раз в своей жизни видел (не говоря о делал) как с нуля рождается приложение. У меня всё. Спасибо! Всё ещё аплодирую 😂😂😂 👏👏👏👏👏

[@ДмитрийСамойленко-р8ы]

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

[@arteria-circumflexa6527]

Влад, ждём кафку, спасибо за видосы!

[@Капустка-й6г]

Капустка обглядела и поставила лайк. Капустка одобряет.

[@mvo5450]

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

[@SadovskayaEliz]

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

[@АлександрЛюбимов-я1ы]

Редко пишу коментарри, но после простмотра почти всех видео Влада, хочу поблагодарить за очень классные видеою. Я так понимаю что ты восновном работаешь в java, я учусь на python но из-за хорошей подачи информации мне очень интересно смотреть. Жду больше видео.

[@myfoxeyes]

НА 24.30 мин. вместо микросервисов нужно сказать монолит) А видео просто великолепное!

[@pablo8896]

Да, я в какой то момент подумал что я что то прослушал

[@ВалентинаЗамотаева-у9н]

Спасибо большое Вам за уроки! Все понятно даже новичку) Отдельный респект за приятную грамотную речь)

[@user-ym7ir4ut8c]

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

[@CaiN805]

Очень крутое видео, классный автор канала, так легко все объясняет, что даже мне стало понятно! Отдельное спасибо за прекрасную инфографику, представляю сколько труда в нее вложено! Вы большой молодец!

[@darya_andreyuk]

Огромнейшее спасибо! 2ой день смотрю ваши объяснения. Всё так понятно и доступно, давно такого контента не видела.

[@bromanovv]

Вы так круто и понятно рассказываете, респект 😊 Сделайте, пожалуйста, про REST подобное видео

[@MyNameIsYou900]

поддежка

[@АнтонФедотов-д4д]

Ляяяяяяяяяяяяя Пушка бомба аллигатор Жирный плюс за то что он поясняет что сервак это отдельный комп Как я раннее писал под одним видосом Что так же при введений нового слова Диплойд ( так же объяснил и рассказал что это такое и с чем его едят) Так же очень круто что он не забывает показывать все это дело в картинках ( в схемах) , а так же что бы все двигалось Так же круто он ввел новую фичу с ценником 1000$ или же 3000$ ( новые пользователи лучше усваивают и понимают , для чего и за чем Так как на деньгах тоже проще объяснить ) Не забывает повторять и объяснять все те же слова что были в предыдущих видео (повторение мать учения) Что подчеркивает , внимательность Влада , а так же понимание и улучшения скила в учительском понимание Что бы донести информацию до любого человека и без разницы чем он занимается или же кем работает Работа учитель донести информацию до любого человека хоть сантехник, хоть бухгалтер, хоть парикмахер Монолит и микро -сервис знал чем отличаются Больше всего я смотрел как он работает над собой и как он качественно доносит информацию до зрителя И это просто пушка А не как у меня на курсах , ментор знает за программирование, но ни черта толком не может объяснить порой на человеческом - колхозном языке Что бы людям было понятно Программист который способен объяснить и разжевать на простом человеческом языке Это прям высший пилотаж ® ► ♫ ☼ ◄ Зачет √

[@АлександрГерасимов-я6я]

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

[@chernikov_ilya]

Было очень интересно смотреть, всё понятно с первого раза. Спасибо за такой контент! 👏👏👏

[@maxpain177]

Поинт про масштабирование монолита и нагрузку на железо неверный. В микросервисах нагрузка на CPU, память и особенно сеть в разы выше и затраты на железо куда больше. Связано это с тем, что в микросервисах очень много сетевой активности, и вместо того чтобы дешево вызвать метод в монолите, в микросервисах нужно делать RPC запросы либо через gRPC, что менее накладно, либо через http. Плюс появляется нехилый оверхед из-за latency. Также по памяти требования намного выше, если раньше у вас было 10 инстансов монолита и они жрали по 500мб памяти, то после распила на микросервисы это будет 100 инстансов по 200-300мб, потому что оверхед на рантайм всегда есть, глупо его игнорировать.

[@slayers2966]

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

[@antonkhotoolev4214]

@@slayers2966 уже сейчас есть большой спрос не спецов, которые умеют "фарш обратно" провернуть. За прошлую декаду натворили. И дело тут не в том, что микросервисы это плохо. А в том что их повпихивали там где это не нужно не думая о цене. А цены кусаются: девопс + инфра + замедление цикла + доп разработчики. За 5 лет на средней руки проэкте это выбивается в 500k $. Уменеджмента волосы дыбом встают когда они видят что этот выбор им стоил примерно как новенькая яхта.

[@FreemanFromSteppe]

@@slayers2966 модульный монолит

[@djooraTech]

А есть разница между "micro services" и " web services". или это одно и тоже?

[@dmitriiandrukhiv3579]

Вы описали проблемы сервисной архитектуры. В микросервисной архитектуре синхронные веб-вызовы (http, grpc, ...) не используются вообще. Использование веб-вызовов - это признак того, что у вас что-то вроде распределенного монолита, но точно не микросервисная архитектура

[@_HedgehogNSK]

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

[@FRED-qo2xd]

Буду ждать ролик всё о работе инженера нагрузочного тестирования))

[@konstantinanimitsa1909]

1. Разработчик ленты сальтерил в бд таблицу изменив колонку с varchar2 на clob, а остальные сервисы ожидают тот же varchar2 - куда пойдут все микросерсисы? 2. Масштабирование - как правило это все на ВМ и гипервизор становится тем что ранее был монолит и т.о. только усложняется все , без полезного выхлопа. 3. Обмен между сервисами очень неприятен для отделов безопасности и доставляет проблемы при работе, т.к. могут вводиться правила-запреты которые сведут на нет работоспособность.

[@zonky9694]

На счет первого. На примере . net если разраб поменял колонку то он скорее всего и модель на которую маппит таблицу тоже обновил и тогда апи модель поменяется и можно обновить нугет пакет нашего сервиса. И все проблемы нет все остальные сервисы обновят нугет пакет и будут ждать уже новый тип

[@dmitrysavkin5981]

Можно также монолит пилить в разных репозиториях. Делаешь артифакт, через зависимость подключаешь к основному ппроекту

[@predatel_rodini]

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

[@el1uz598]

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

[@АнастасияКузнецова-д6т]

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

[@JoannsEngels-ej3rz]

Спасибо, Влад! Я благодаря твоим видосам начинаю понимать, что у меня на работе происходит ))

[@AlexanderAk]

Плюсы микросервисов надуманные получается, а вот минусы весомые )) Спасибо за видео

[@dmitrysergeev4124]

Очень классная подача!! Очень интересно смотреть и слушать. Благодарю за труд.

[@Nashe_osobennoye_detstvo]

Таня привет! Очень интересный влог, здорово, что у вас много разных мероприятий, которые собирают людей для общения, да ещё такое разнообразие по интересам. Покупки супер! Правильно, себя надо тоже баловать❤

[@АлександрГерасимов-я6я]

Про ТУЗы интересно,сам процесс подключения к БД, к Кафке и т.д. Про установку SSL сертов. Много в общем вопросов по инфраструктуре во всех контурах.

[@aleksey2408]

Спасибо, Влад. Очень полезное видео!

[@yaarecords6658]

Шикарный контент, много полезной инфы без воды, отдельное спасибо за иллюстрации, с ними лучше запоминается и усваивается. К сожалению почитав комменты сложилось впечатление, что не все пункты на 100% истина, хотя вероятно в IT не бывает тем по которым все поддерживают какое-то мнение и не имеют своего))

[@YlwDrknss]

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

[@andrewbondaryuk]

О, ещё один поклонник карго культа 😀

[@vegatv5474]

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

[@eugeneantonyuk]

Хорошее видео для новичков

[@InvincibleXXX]

Это же "чистая архитектура"! Привет дяде Бобу!

[@maxsimusmaxsimus6016]

КРАСАВЧИК ВСЁ ПОНЯТНО ОБЪЯСНИЛ РЕСПЕКТ.

[@gggg-ky3pf]

Спасибо вам огромное! , очень наглядное и познавательное видео!

[@internetnickname8923]

Чел спасибо тебе за кучу сэкономленного времени и денег) Я понял, что для микро стартапа нужен монолит)

[@ВладимирКузнецов-щ8х]

Полезное видео, все доступно и понятно рассказано!

[@firstmirror]

Смотрю перед собесом на системного аналитика, очень круто структурирует информацию

[@АлександрГерасимов-я6я]

Спасибо за видос!Доступно, красиво!

[@skyplayer5718]

Крутой и очень понятный разбор. Жду теперь ролик про Kafka

[@ДарьяБулат]

Спасибо! Ждем новые видео)

[@СергійЧалий-ч8и]

Крутое видео, спасибо!❤

[@ATambovtsev]

Молодец. Разжевываешь очень хорошо. Спасибо тебе за это. Лайк и подписка

[@andrew-ld1jg]

Хотелось бы видео про load balancer. Спасибо за труд!

[@ДенисСкворцов-м5я]

Супер разбор. Никогда не думал что пойму эту казалось сложную тему за 49 минут. Большое спасибо. Но слово "Ошибка" пишется через букву И )) Не знаю по приколу ты написал через Ы или по правде ошибся, но бросилось в глаза в самом последней части на 47 минуте :)

[@mrsuhrob1334]

Огонь, жду видео про service discovery, service registry, service mesh, saga, kubernets...

[@Arman_127]

большое спасибо за анимации они очень помогают

[@Csenonify]

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

[@realcnbs]

шш! тише ты, нельзя такое говорить еще :)

[@Ivan-t8l1r]

а как масштабировать монолит?

[@Csenonify]

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

[@Ivan-t8l1r]

@@Csenonify чем поднять один инстанс монолита проще?

[@Csenonify]

@@Ivan-t8l1r тем что это 1 инстанс, а не n

[@petefedorov2955]

На мой взгляд, лучшее объяснение микросервисов из всех, что видел. Спасибо огромное за простую и лаконичную подачу столь сложного материала! 🙏🏽

[@alexanderkuznietsov932]

А самое паршивое в микросервисах это необходимость резать базу данных под каждый сервис. Если вам нужно вытащить клиента и его покупки, то нужно вытащить данные из двух микросервисов ("клиент", "заказы") и связать их вручную в памяти. Вместо простейшего запроса с join в случае единой БД. Если нужно записать нового клиента и создать ему карту лояльности - нужно сохранять в двух МС, но как быть если клиент успешно создан, а в сервисе лояльности сбой? Нужно откатить сохранение в сервисе клиентов. То что элементарно решается транзакцией в единой БД превращается в цирк с хлопушками. Потом взяли смасштабировали - развернули три сервиса рекомендаций товаров. Поменяли цены и нужно их сохранить во всех экземплярах БД этих трех инстансов микросервиса. Если один фейлнулся, а два сохранили, что с этим делать? И таких проблем куча и ведерко. ps. к конце как раз есть об этом

[@dimaguka]

Спасибо за видос, круто объясняешь.

[@SergeyKucherenosov]

Хорошее видео получилось, прям смотрю и вижу архитектуру нашего приложения. Только есть кажется неточность относительно Prometheus. На сколько я понимаю Prometheus сам ходит за метриками к сервисам на определённые ендпоинты сервисов, которые и выдают определённые метрики.

[@hamidaxtamov1]

Let'sss gooo!🔥🔥🔥

[@РустамНургалиев-у9й]

Бро, от души благодарю

[@igorlitvintsev2427]

Привет из Воронежа)))

[@max_livi]

Спасибо! Кратко, понятно, полезно!!!

[@user-fn2up4px1m]

8 минут и всё уже в целом понятно, но интересно что дальше.. смотрим, подписываемся..

[@ЕвгенияПопова-з8м5е]

Офигеть! Супер круто))) спасибо)

[@TheDustyChannel3334]

12:48 боже, Леонардо ДиКаприо в лучшие годы...

[@emrahhakan5462]

Спасибо тебе за такое информативное видео

[@AtlasinfoAtlasinfo]

TL;DR: Очень притянуто за уши и местами выводы весьма странные, местами вообще противоречивые. 1) Изолированность. То что преподносится как "отличие" монолитов - жесткое связывание, на самом деле проблема кода и (не)соблюдения SOLID, хотя на самом деле при верном проектировании мы получаем абсолютно тот же обмен данными как в монолите (мы передаем данные через DTO, либо четко следуем интерфейсам и используем геттеры и сеттеры), но передача данных осуществляется внутри приложения, а не на разных серверах, что сильно быстрее и не имеет тех проблем обмена данными, имеющихся в МС. 2) Ответственность. Ну и деплой сразу. В любом случае - монолит или МС - вы должны знать что делают другие части, по сути в обоих случаях вы используете АПИ другого объекта. Так что все равно надо понимать как работают другие части, как бы не хотелось ограничиться чисто своим кусочком кода. И не знаю как в "больших компаниях", но в тех где я работал обычно есть правило - один комит по задачам не деплоится с другим. Все идут в своем порядке. Тогда откат одной фичи не ломает остальной рабочий функционал. Ну и это более актуально для компилируемых приложений, для условного пхп фикс не требует отдельного сервера и прочих танцев для замены 1 файла. 3) Надежность. В принципе, обсуждаются те же проблемы что и с остальным - связанность, которая как бы не проблема монолита, а проблема кода. И проблема сложных зависимостей и связанных с ней багов так же остается в МС (компоненты так же обмениваются данными, просто это происходит чуть сложнее), теперь ее просто сложнее отследить. К слову, при "отваливании" каких-нибудь нотификаций, монолит абсолютно так же не развалится и не пойдет в разнос, просто пропадут нотификации. А при отваливании авторизации проблемы будут при любой архитектуре во всем приложении. 4) Масштабирование. Тут немного странно это подается, так как нагрузка в современных приложениях это не "код ленты не вывозит", а в 99% случаев это либо нагрузка на бд, либо запросы с внешних апи, которые имеют свою пропускную способность и лимиты/квоты. И тут как бы вы не масштабировали сервера ленты, база быстрее не заработает. Предположим, что у ленты свои сервера бд, которые имеют чисто свои данные по ленте, и больше ничего, все остальное что напрямую не относится к новостям. Тогда мы разворачиваем кластер и добавляем пару серверов для бд ленты... Беда в том, что как и говорил автор, все компоненты связаны, не напрямую, но запрос ленты тянет за собой запрос на рекомендации, на пользовательские данные, на еще кучу всего, и при этом все это не бегает внутри приложения, а бегает по внешним сервисам, которые в итоге получают практически такую же нагрузку, но все это еще накладывается на накладные расходы промежуточных линкующих сервисов/сетей... Молчу о том что есть "небольшой" нюанс - в итоге будет дешевле поставить +пару серверов для монолита, чем расставлять на каждом поднагруженном сервере по паре серверов послабее, так как чем мощнее сервер, тем дешевле он выходит на условное количество операций/сек. 5) Гибкость/изоляция МС как преимущества: Две основные фичи - изоляция (о чем я выше говорил) и разные стеки для разных микросервисов. С изоляцией спорно, "но окэй", а вот зоопарк стеков технологий это прям киллер фича микросервисов. Собсно рождение МС как концепции начиналось именно с выноса кусков монолита в отдельный сервис, так как этот кусок на текущем стеке "не вывозит". Дальше эксперименты по разбивке всего на все и вот эти все попытки связать кучу всего в одно работающее распределенное приложение. На сегодня это уже +-отлаженный процесс, так что особо прям фантазии для построения МС архитектуры много ума не надо, читаем доки, настраиваем, профит. И по скилам - особо от монолита не отличается (так как по сути мы и пишем маленький монолит), проблемы начинаются на этапе связывания, синхронизации, проверки консистентности и кучи бд, состоящих из частично надцать раз дублирующихся данных, что больше задача для архитекторов и сеньоров. То есть реально спецов там нужно мизер, но это именно "сливки" сообщества, которых и так нифига нет и охота за ними идет похлеще чем за синей птицей. Что создает определенные проблемы, особенно в свете последних событий. Вывод в отдельном коменте.

[@TSUNAMIBEATSONE]

Шикарный комментарий по делу. Прочитал с интересом!

[@programmer-inwall]

Ура! Микросервисы!!! Очень кстати!

[@dreamerNight]

Это было очень интересно!

[@sergedota2509]

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

[@SergPuhoff]

и это ничем не будет отличаться от связанности между компонентами в монолите

[@SergienkoVitaly]

И чем это будет отличаться от модуля реализующего интерфейс, через который с ним нужно работать? Про базы, ну да, конечно сделать один сложный sql запрос это одна проблема, а собрать аналогичный результат через 3 апи это прям легче. Причём в соседнем комменте, утверждается, что наличие http и grpc запросов для общения микросервисов это вообще ни разу не верно...

[@ПавелТалашкин-х7б]

Привет, сделай пожалуйста видео. Разница между веб серверами и серверами приложений.

[@БЛАУГРАНАС]

дядя валера и на джаве и на пайтоне работает, вот это мужик

[@ТимурМулашев]

Крутой видик, спасибо большое за труд

[@ЮрийЧернышев-э6о]

Привет, очень жду docker compose))) логичное продолжение docker

[@РустамРустамов-д9х]

Люто плюсую. Спасибо

[@Java_Kava]

Очень классное объяснение, молодец !👍

[@alenaabrosimava2900]

Спасибо и от тестировщиков!)

[@VictorDubiniuk]

Отказоустойчивость выше - да. Но у майкросервисов тоже бывают конфликты API, а монолит может быть написан по феншую "loose coupling high cohesion"

[@seregadld5318]

с кайфом посмотрел

[@alinazavr6127]

Оооо да ждал такое видео

[@structureandconquer]

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

[@borisblade1403]

Лол, всё думал, что там за микросервисы эти прекрасные существа придумали, а оно вон чё) То, что можно решать в отдельном классе делать отдельной прогой... ихи-хиыы

[@qwertyUtil]

Благодарю за видео. Очень полезно.

[@motivationRoll]

Good job 👍!

[@vasilsuarez5075]

спасибо, хорошие у тебя видео)

[@ManticoreRoko]

Ждём разбор Кафки. А ещё лучше её заменитель - Redpanda. А ещё лучше сравнение обоих

[@Vivavatnik]

Супер!

[@MikhailKorzhov]

Влад, а где тут место для Desktop интерфейса 3:00?

[@ЕгорТупикин-л6ъ]

видос лютая имба, автору +rep

[@Камиль-п9ч6ш]

24:30 преимущества по сравнению с монолитом, оговорочка

[@katekomlevaJD]

Надо видео, как на практике можно реализовать Сагу)

[@ForAge07]

Сделай такой же видос про Rest

[@betherealonee]

Влад опять радует своих подписчиков топовым контентом, спасибо) (Опоздал на премьеру 😢)

[@storm-kd4op]

Влад, спасибо. Кафка, редис, GRPC были бы интересны.

[@iiiyiiia6775]

прикольная прическа на 12:48 ждем видео про кафку и спринг

[@sergei_x1000]

Про CI/CD запиши видосик)

[@TheAlexBell]

Кросавчег. Я только не понял, почему старый добрый принцип изоляции назвали микросервисами. Потому что они связываются через интернет?

[@eugene_mountainland]

Анимации и правда помогают)

[@nerpa3056]

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

[@sergejhofmann3200]

Спасибо Влад, топ