Что спрашивают о микросервисах в крупных компаниях | Senior Developer | Jetbulb

[@PashaK-h5r]

Огонь, спасибо.

[@egorzdioruc7831]

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

[@artems4638]

Спасибище!!! Сколько не учись - всю жизнь что-то новое узнаешь)) Крутой материал!

[@КостяБерков]

Наконец-то петличка, а не микрофон на все лицо в кадре)). Крутой материал!

[@pogrommist]

отличная подача материала! Радуют примеры собеседований и вопросов для более продвинутого уровня. Было бы круто поработать вместе на реальных проектах :)

[@МаксМакс-ч8к]

Очень полезно! Макс, спасибо👍👍👍

[@dimdimono2258]

Спасибо! Актуально и увлекательно❤

[@best1kable]

Невероятное количество полезной информации, благодарю!

[@ciph3erjan664]

Говоря о Circuit Breaker, если брать электрические термины, то Апв как аналогия больше подходит. А вообще спасибо за очень полезный ролик, смог некоторые концепции для себя разложить по полочкам

[@МитяКараченцев]

Очень полезно, спасибо!

[@bxneslxrd2224]

вот это я понимаю контент, спасибо вам большое

[@Artur-hn8sg]

Самое глубокое и информативное объяснение

[@mikhail1566]

Максим, щиро тобі дякую за твою роботу та бажання зробити цей світ кращим)

[@alevadnaya]

Макс, сколько новых слов 😅 Спасибо большое!

[@olegchumin6634]

Огромное спасибо автору за краткую систематизацию основных паттернов проектирования мисросервисов. Как раз реализовывали недавно timeout retry через webhook-и

[@НиколайПопов-ъ2ь]

Очередной коммент для продвижения авансом. Спасибо)

[@zhabassov]

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

[@Jetbulb]

Да, в ТГ-канале уже было неоднократно про реактивы) И будет еще))) Спасибо за отзыв!

[@SanyaBackend]

Подача огонь! Спасибо)

[@zhabassov]

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

[@jorgemorningstar2206]

Спасибо Максим, как всегда очень круто! Когда я хотел попасть в престижную консалтинговую компанию меня минут 20 расспрашивали о microservices. Сначала в ролевой игре надо было убедить клиента использовать у себя microservices architecture. Он очень жёстко держался за свой монолит. :) А ещё спросили о microservices orchestration tools таких как Kafka или Zeeba

[@Torbjorn-ph7rt]

Самое прикольное было бы если бы в том же собеседовании попросили "а теперь убеди меня использовать монолит"

[@prazdnick]

CQRS родился не совсем из EventSourcing-а, изначально был Command-query separation (CQS) который решает проблему сильной разницы в количестве запросов на чтение и запись. И в видео больше сказано именно про него, в то время как у CQRS имеет более строгие ограничения в реализации, главный из которых состоит в том что Comand никогда не возвращает данные, и работа идет в двумя разными бд который синхронизируются обычно через очередь. Этот подход крайне удобен для EventSourcing-а

[@alexplishkin5811]

Ну вопрос синхронизации это уже другой вопрос это могут быть просто master-slave реплики. Если это это база данных одного типа, какой то постгрес например. Если это sql+nosql то тогда нужно свой солюшин писать для синхронизации.

[@АндрейАндреев-з2о9у]

Классная подача) Интересно смотреть

[@artem8547]

Как всегда! Просто лучший формат видео!

[@СергейПлатонов-н1е]

Огинище!!!! Сейчас готовлюсь к собесу в крупный банк на работу мечты!!))) И тут такой материал!!!)))) Благодарность огромная!!! Тысячу бы лайков поставил!!!) Но можно только один!)))

[@Jetbulb]

Один лайк уже как тысяча)) Респект!

[@MrRomanvideo]

С других аккаунтов ставь :)

[@Dmitri915]

Сбер на 250к?)

[@yanslow9083]

​@@Dmitri915 450

[@MarynaSapiton]

Как работа?

[@inzagher]

Микросервисная архитектура - это стиль) Не шаблон. Специально смотрел этот момент и у Ричардсона и на других ресурсах типа azure arcitecture. Большое спасибо за материал, очень много нужного можно почерпнуть)

[@abcdefghi1489]

@Petr Dobrov Насмешил

[@Jetbulb]

Для справки Application architecture patterns Monolithic architecture - architect an application as a single deployable unit Microservice architecture - architect an application as a collection of loosely coupled, services

[@inzagher]

@@Jetbulb я написал ответ про путаницу у того же Ричардсона на всех его ресурсах. Кто то потер коммент)

[@oeaoo]

Скоро этот академический пафос спадет. Я еще угораю с понятия CAP теорема. Так жеж умничают люди, при этом они даже теорему Пифагора не докажут.

[@inzagher]

@@oeaooя сам мягко говоря не поддерживаю собеседования в стиле телевикторины. Но раз уж так повелось в отрасли, то надо быть точным. Ну и насчёт теоремы cap я бы не был настолько категоричен.

[@satenikkartashyan3336]

Спасибо! 👍👍👍

[@aleksandrtimakov533]

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

[@poloplopol9791]

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

[@Denis-sds]

Джунам ничего из этого ещё долго не пригодится, да и 100% на джуновском собесе таких вопросов не будет

[@poloplopol9791]

@@Denis-sds сейчас вроде такая ситуация, что бы стать джуном нужно знать инфу на мидла

[@alexbreadwinner3301]

Благодарю!

[@prazdnick]

И добавлю что в описании Circuit Breaker стоит описывать состояния не как открытый или закрытый а OPEN - разрыв цепи, CLOSED - соединение цепи, на русском как то это будет понятнее.

[@AleksandrKir-p9s]

Круто! спасибо!! Не совсем понял про снапшоты на 12:30

[@ismelnikov]

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

[@eld4j]

спасибо за видео !!1!1

[@alexplishkin5811]

Про CQRS ничего не понял из объяснения. Приемущества cqrs в том что для записи можно использовать один сторейдж например mysql а для чтения совсем другой, например dynamodb и апликухи, которые конектятся к этим сторейджам можно горизонтально скейлить независимо друг от друга. Например если запись в write model у тебя может быть 20 раз в день, а чтение с read model 20 млн в день. То возможно на чтение лучше поставить базу, которая работает быстрее на чтение и отдает например не нормализованные данные, сразу json as is.

[@zeus2521]

Полезно, спасибо

[@yuriy.kostenko]

При таком перекосе, думаю ее же можно использовать и для записи. Уж 20 раз в день она что-то записать, думаю, сможет. И на скорость чтения єто повлияет примерно никак.

[@alexplishkin5811]

@@yuriy.kostenko Так это образно. В реальных проектах совсем другие цифры.

[@Torbjorn-ph7rt]

Одна база может выполнять очень тяжёлую работу тормозящую всю базу, например получает каталог из какой нибудь 1С и смерживает с каталогом для сайта, результат реплицируется в базу с которой происходит показ каталога на сайте. Более близкий к паттерну пример - заказ получает с сайта одна база для обработок, воркфлоу итп, и реплицируется в другую базу "в переваренном виде" для показа на сайте в списке заказов клиента. Третий пример классика - логирование идёт в одну базу, а чтение обработанных логов делается из другой базы. Ну и естественно реплик для чтения можно иметь сколько хочешь что повышает скорость и устойчивость.

[@oeaoo]

Короче, что я понял. Самое главное в микросервисах что? Не угадаете. Сторителлинг!

[@ivanmalik1375]

Полезно👍

[@georgeshchennikov6423]

Скажи, пожалуйста, с какой книги можно начать, чтобы войти в эту тему? С кабаном?

[@Jetbulb]

мне заходит microservices.io/ на этом сайте более чем подробно все расписано. как точка вхождения отлично помогает

[@dmytro4312]

Привіт Макс, чи можеш підказати, як дізнатися чи можна скейлити Спрінг Бут сервіс? Можливо знаєш якийсь ресурс де можна почитати. Буду дуже вдячний)

[@Jetbulb]

Привіт)) На мій погляд, за посиланням можливо знайти все що треба www.baeldung.com/spring-boot Також рекомендую офіційну документацію docs.spring.io/spring-boot/docs/current/reference/htmlsingle/

[@dreamer_vi905]

Дисклеймер в начале в самое сердечко. ❤

[@nicholasnobody7412]

Ну хоть сейчас до вас дошло, что мир это хорошо, а нападать на другие страны - это плохо. Столько лет вы ничего не замечали.

[@dreamer_vi905]

@@nicholasnobody7412 до кого до вас? Эти Вы с тобой в одной комнате?

[@nicholasnobody7412]

@@dreamer_vi905 до тебя и тебе подобных.

[@nicholasnobody7412]

@@dreamer_vi905 до тебя и тебе подобных. Могу потом ещё пару раз, если медленно доходит.

[@Torbjorn-ph7rt]

​​@@nicholasnobody7412разумеется замечали - ирак, ливия, югославия, палестина, .......... . К сожалению если какая то страна нацепила на себя маску всемирного полицейского, она всегда будет пытаться решить свои проблемы военным путём под видом полицейской операции. Ну а к России у этой страны особое отношение, поэтому украина просто попала между молотом и наковальней, точнее стала полем боя для больших стран, а украинцы послужили в качестве одноразовых пулек в этом страйкболе, причём добровольно.

[@arturbarkou6347]

Спасибо за видео. В целом, вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то толковые объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?

[@ГошаТиунов2]

Здравствуйте! А что посоветуете по микросервисам для джуна?)

[@Jetbulb]

Неплохой точкой вхождения может стать материал по ссылке ниже microservices.io/

[@wsawsawsa]

Отличное видео, затмевает только увы картинка про корабль и т. П.

[@Mancelian]

Большое спасибо за интересный ролик. В тему(или не очень) микросервисов, уважаемы Максим, хотелось бы узнать ваше мнение насчёт DDD. Недавно начал изучать тему, читаю книгу Вона Вернона, но пока все выглядит немного абстрактно и на уровне лозунгов. Возможно приходилось применять этот подход на практике?

[@alexplishkin5811]

Axon Framework вам в помощь

[@Jetbulb]

Совсем скоро будет новый выпуск. Он будет посвящен DDD. Там можно будет получить много ответов )) Если кратко, DDD это и есть форма абстракции при которой бизнес-потребности могут быть обрисованы на языке понятном для технических специалистов. Таком себе контракт между "технарем" и "нетехнарем".

[@sergiocoder]

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

[@К.ОТяра]

J2EE разве уже не актуальны? Шикарные книжки были для подготовки к сдаче на Sun Certified Enterprise Architect.. Рано списывать то, на чем строили монолиты - вполне себе можно и внутри микросервисов применять. А по микросервисам ничего толкового я не припомню.. мало кто вообще может внятно сформулировать - для чего именно нужен Spring Boot? Включая коучей всяких..

[@Firsalex]

Как у нас стали любить все эти красивые фразы на английском и шаблоны... Суть элементарна - есть какой-то метод, обернутый в API, который решает очень маленькую узкую задачу... Тысячи эти методов и образуют микросервисы. Один запросил, второй отдал, третий положил в Kafka, четвертый прочитал и раскидал.... Но ты должен с умным видом все это описывать, оперируя "модными" аббревиатурами ))

[@milovidov42]

Если бы все было так просто) может быть сага, это тоже что-то такое простое и есть аналогии, типа, это просто ... )))

[@ParamPamPams]

Правильно долой этой английский,надо на старославянском программу писать

[@chuckchuck1749]

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

[@Rogov_Oleg]

Голова болит от этих микросервисов

[@CiCLoDoL]

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

[@Jetbulb]

Отличный вопрос 👍 Но тут все просто. Времени столько нет чтобы сервисы организовывать, базы подключать. Если хочется проверить дизайнерские возможности кандидата, то как правило дают задачу на дом. Тогда человек в спокойной обстановке сможет все обдумать и собрать. За 1,5 часа познакомиться, вникнуть в задачу, прояснить детали и решить… просто нереально. Конечно же дают задачи. Но такие задачи отражают предметную область и не требуют сложных манипуляций. Как правило, это задачи на системный дизайн из предметной области бизнеса. Вот пример реальный: «Реализуйте метод для перевода средств с одного счета на другой». Разумеется там выдвигается куча требований: - многопоточка - отсутствие овердрафтов - проверки валидности данных - возможность работы в распределениях системах - и тд

[@CiCLoDoL]

@@Jetbulb На спрингбуте с гуглом любой достойный кандитат успеет что-нибудь да сделать. Я скорее про то, что частенько дают задачи, которые не имеют смысла в применении в реальной жизни. Я это по собственному опыту сужу, а также по Вашим видео.В целом, на интервью очень много теории, которая не дает гарантии хорошего кодинга, в чем я лично вижу разницу между джуном, мидом и синьором. Решить задачу может любой, а вот сделать ее хорошо - совсем другое дело. Я менторю людей по кодингу, и не понимаю, как некоторые из них прошли интервью на сеньор позиции. С большинством интервью явно что-то не так, но не могу сказать, как это сделать лучше )))).

[@arturbarkou6347]

Спасибо за видео. Вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?

[@nikolay4362]

бро, ну хватит троллить, когда сделаешь новую серию доктора дью?

[@ЯщикПочтовый-ш4х]

Жаль, что нет тайм-кодов по паттернам

[@hiryu70]

Неее. В дагонку полетит вопрос, если для нас так критична последовательность транзакций, то как быть если один сервис уже обработал т1, т2 и т3, а другой ещё не закончил обработку т1.

[@СмрадЛилит]

Изоляция?

[@АлександрС-г8ж]

Спасибо автору за видео. Согласен с начальной заставкой. Ее поддержали бы также жители Белграда, Ливии, Ирака, городов Газы. Странно только при этом видеть картинку с солдатом известного военного блока на заднем фоне. Я немного застал советское время. О многом в истории просто не знал, многое трактовал субъективно. Чтобы не вестись на идеологическую пропаганду, важно пытаться сохранять критический взгляд и пользоваться разными источниками информации, а не только слушать то, что вещает рупор в стране твоего проживания. Иначе совершенно очевидные противоречия будут для тебя незаметны.

[@Torbjorn-ph7rt]

В результате каждый микросервис разрастается толще монолита.

[@zhabassov]

Loose coupling это слабая связность, а high cohesion сильная сцеппленность

[@valerystepanenko6040]

Офигеть, какой актуальный эпиграф. Индеец Соколиный глаз через 8 лет обнаружил, что в камере нет одной стены.

[@Torbjorn-ph7rt]

Осталось только понять в чём преимущество микросервисной архитектуры если гемора больше чем у монолита.

[@showrun4747]

Из 40 минут 4 воды в начале. 10 % это очень много даже для скорости 1.5

[@Николай-с5е1з]

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

[@dmitriyobidin6049]

Микросервисы на джаве это почти оксюморон :)

[@leetvin]

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

[@leetvin]

Короче меня запишите в хейтеры. Слишком поверхностно и оттого неверно.

[@Warrior_Shade]

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

[@Torbjorn-ph7rt]

​@@Warrior_Shadeдополню насчёт каши - он её ещё и на нас вылил. Горшочек не вари!

[@ILyaCyclone]

боже, сколько лишних слов... И как их мало по существу.

[@dizzy5398]

Слишком много болтовни

[@Boria7777]

На 10-й минуте смутила фраза про то что каждый экземпляр сервиса может иметь свою базу данных. Никогда такого подхода не видел ранее. Обычно экземпляры одного сервиса работают с одной базой. Максим вы используете такой подход в ваших реальных проектах? И как в этом случае организовано масштабирование? Каждый раз вместе с инстансом сервиса поднимется и новая база данных? Вообще не понятно

[@nice_and_steady]

скорее он имел ввиду про то, что для множества инстансов одного сервиса существует 1 база

[@svetlanafedorova654]

Очень очень много лишнего текста

[@shsh01212]

тошо микросервисы мертвы - ща серверлесс

[@Qnoize]

не придумывай) монолиты еще живей всех)

[@нко-ю9х]

Нафіга стільки води лити

[@Qnoize]

это шоб на собесе ни спросили того, че ни знаешь)

[@АнтонСорокин-о6д]

ого ты накуренный!!!!!!