Микросервисы Простыми Словами за 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ая

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

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

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

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

[@alexshutov5442]

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

[@katekomlevaJD]

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

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

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

[@Deletedeletedelete]

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

[@goodvideobro]

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

[@igordek9494]

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

[@darya_andreyuk]

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

[@bromanovv]

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

[@MyNameIsYou900]

поддежка

[@mvo5450]

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

[@dddryinside]

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

[@dmitrysergeev4124]

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

[@CaiN805]

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

[@yaarecords6658]

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

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

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

[@myfoxeyes]

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

[@pablo8896]

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

[@user-ym7ir4ut8c]

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

[@JoannsEngels-ej3rz]

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

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

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

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

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

[@internetnickname8923]

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

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

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

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

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

[@Nashe_osobennoye_detstvo]

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

[@arteria-circumflexa6527]

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

[@ATambovtsev]

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

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

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

[@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, ...) не используются вообще. Использование веб-вызовов - это признак того, что у вас что-то вроде распределенного монолита, но точно не микросервисная архитектура

[@gggg-ky3pf]

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

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

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

[@_HedgehogNSK]

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

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

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

[@aleksey2408]

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

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

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

[@maxsimusmaxsimus6016]

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

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

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

[@eugeneantonyuk]

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

[@emrahhakan5462]

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

[@detwait]

Как связаны монолит и coupling ? Кто заставляет все модули связывать между собой ? Условно модуль отправки сообщений может знать не знать о каких то доменных модулях. Да и доменный модуль может напрямую не импортировать модуль отправки сообщений, а использовать ту или иную реализацию ивентов.

[@konstantinanimitsa1909]

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

[@zonky9694]

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

[@programmer-inwall]

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

[@FRED-qo2xd]

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

[@skyplayer5718]

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

[@vasilsuarez5075]

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

[@qwertyUtil]

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

[@max_livi]

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

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

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

[@ManticoreRoko]

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

[@el1uz598]

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

[@Csenonify]

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

[@realcnbs]

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

[@Java_Kava]

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

[@ilyuwkaaa]

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

[@dreamerNight]

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

[@SergeyKucherenosov]

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

[@dmitrysavkin5981]

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

[@YlwDrknss]

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

[@InvincibleXXX]

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

[@firstmirror]

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

[@vegatv5474]

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

[@sergedota2509]

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

[@SergPuhoff]

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

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

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

[@hamidaxtamov1]

Let'sss gooo!🔥🔥🔥

[@alinazavr6127]

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

[@AtlasinfoAtlasinfo]

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

[@TSUNAMIBEATSONE]

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

[@alenaabrosimava2900]

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

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

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

[@mrsuhrob1334]

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

[@sergejhofmann3200]

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

[@Vivavatnik]

Супер!

[@petefedorov2955]

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

[@user-fn2up4px1m]

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

[@andrew-ld1jg]

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

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

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

[@4ala-bloger-asaKew]

Спасибо)

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

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

[@igorlitvintsev2427]

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

[@sevangulov]

Лайк !

[@stanislavkuprienko6475]

Спасибо, Влад, очень интересно рассказываешь. За*6иcь 👍

[@MyNameIsYou900]

спасибо!

[@RadikKarimov-f4n]

Ну как говорится... За мналиииит

[@eugene_mountainland]

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

[@VictorDubiniuk]

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

[@borisblade1403]

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

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

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

[@structureandconquer]

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

[@iiiyiiia6775]

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

[@kmt_1145]

За монолит!

[@Завтрабудетлучше-ф6ж]

Очень понятно, даже для полных нулей)

[@Бензини]

Лайк

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

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

[@youngsawe]

отличная прическа🔥

[@Adikapad]

Влад, выхожу на маркет через пару месяцев, обучаюсь в буткемпе уже 8 й месяц. Интересно, можно ли с тобой провести пару индивидуальных курсов? За видео огромное спасибо, просто нереально, тебе нужно на английском выпускать тоже, уверен аудитория увеличится в разы.

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

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

[@TheAlexBell]

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

[@the2x548]

Офигенно

[@legalelegage5498]

В монолите компоненты тоже могут быть изолированы друг от друга. А насчёт Кафки и другой хуеты для реализации взаимодействия компонентов помимо сложности самих этих инструментов, сами компоненты должны стать сложнее по части ipc

[@TheDustyChannel3334]

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

[@crazybaber6433]

крутое видео

[@grishat2]

Тут много толковых комментариев про неочевидные преимущества микросервисов над монолитами. Но мне кажется не поднята основная тема - это докеры и соответственно Kubernets. Именно они позволили сравнительно легко оперировать и поднимать образы микросервисов при нагрузках. Хайп на микросервы только из-за докеров IMHO.

[@vanilastorm438]

❤

[@user-0xDEEDBEEF]

Я согласен в общем но, процесс деплоймента у вас не продуман ибо в нормальной компании есть несколько систем, например дэв->тест->препродакшен->продакшен. В этом случае баги никогда не достигнут продакшен независимо от типа приложения.

[@nerpa3056]

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

[@alexsoftdev1]

Скорость внесения изменений.- да Скорость исправления недочетов - да Изолированность .... хехе :) ну-ка, сломайте ивент, который шлет микросервис и на которой подвязана лента новостей и посмотрите как "изолированно" вы ничего не поломали