Именно после таких видосов некоторые люди такие: сейчас мы перейдем на микросервисы, и решим наши проблемы 💪🏻 На самом деле нужно понимать что микросервисы нужны не там как сказал автор если разработка вашего приложения больше месяца, или у вас более N строк кода, и нужно понимать что если ваша команда не может написать хорошо монолит, скорее всего она не осилит микросервисы Чтобы снизить сложность в разработке монолита при его масштабировании, необходимо делать его модульным, DDD и возможно чистая архитектура вам в помощь Если вам не нужно поддерживать приложение на разных инстансах, нет в этом необходимости, то микросервисами вы только усложните разработку включая инфраструктуру
Ломал голову, чтобы кристально чисто понять зачем нужен докер, кубернетис, системы сборки, git. А оказывается есть короткий путь, нужно понять, что такое микросервисы, и это объясняет все. В принципе, логично, ведь современные инструменты соответствуют современной разработке, которая зависит от сложности программ, следующей из потребностей обычных людей и бизнеса. Благодарю, теперь всё собралось воедино.
@@СергейГубко-б3р Здесь речь идёт о такой практике проектирования микросервисов как "На каждый микросервис по БД" (далее именную это как микросервисная БД) Есть также практика, которая противоречит микросервисной архитектуре - "Одна БД на всё приложение" (далее называю это монолитной БД) БД и прога могут всегда быть выполнены в разных связках К примеру миркосервисное прилоложение и микросервисная БД миркосервисное прилоложение и монолитная БД Монолит приложение и монолит БД Монолит приложение и микросервисная БД Смысл микросервисной БД такой же как микросервисного приложения - отделение одного от другого и удобство маштабирования, использование для каждого сервиса своей более подходящей СУБД Сложность такого подхода заключается в правилах ACID - решение недавно глядел и обычно чаще всего используют его и его модификации - Проектирование Саг Как реализовывать саги ты выбираешь сам, но в любом случае раскидывая данные по разным БД ты отказываешься от некоторых аспектов - сам в этом в данный момент подробностей мало имею, лучше почитать, я как раз и занимаюсь сейчас изучением этого всего чуда
Оличное видео, спасибо! Все по полочкам, и в целом, доступным языком. Мне, как джуну-тестеру, много терминов ещё не знакомы, но всё равно тема микросервисов стала более понятна
Я ещё до конца не дошёл, а уже могу точно сказать, что этот видос рекомендую всем кто готовится пройти тех интервью 😂 P S Автор красава чётко получилось
Привет. Очень хорошо рассказал про микросервисную архитектуру. Просмотрев 1 раз, в это время я еще играл в игру ) Я понял про все, что ты рассказал мне, и теперь я знаю и могу рассказать, что такое микросервисная архитектура и что она из себя представляет, а так же знаю, где лучше использовать монолит, а в каких случаях микросервисы
А твой "большой проект" какие задержки будет иметь ганяя данные от одного микросервиса к другому вместо нормального обмена в монолите в рамках единого приложения?) или "пофиг на продуктивность, просто более мощное железо поставим если что"?)
Доброе время суток! Если в Django rest, несколько приложений со своими моделями и вьюшками они общаются через эндпоинты, всё это в одном Django проекте, это будет микросервисная архитектура или это монолит с приложениями в нём?
Максим, подскажи, как ты искал вакансии на позициою junior go developer, по моему таких вакансих не то что мало - их нет, я долго работаю devops инженером и хочу немного перейти в go, но смотрю на вакансии - везде от 2х лет комерческой разработки.
Не пиши что джуниор) подавай резюме на мидл позицию, но пиши в резюме правду. Бывает что они собеседуют и тому, кто на позицию не проходит делают оффер на мидла. Поэтому на джуна почти нет вакансий: у HRa гора резюме всегда на джуна
@@johnnysuedy Не ушёл в go, писать на go мелкие проекты - приятно и интересно, но программирование за деньги не всегда приятно и интересно - это вывод исходя из того что я вижу у ребят в команде. Продолжаю заниматься devops/администрированием - почти перестал писать на go к сожалению
Очень хороший формат, только хотелось бы, чтобы когда ты объяснял, картинка в презентации становилась миниатюрой, а изображение с тобой становилось полноэкранным)
Мне кажется, это уже далеко зашло. Микросервисы оповещают микросервисы. Апи для апи. Господа, это клиника. Тут нужен хороший психиатр и длительный курс лечения. Какие паттерны микросервисов? Все паттерны описаны в ГОФ. Извините, я ошибся - не все паттерны, ведь есть ещё паттерны, о которых можно почитать в Википедии - их около 100 и их становиться всё больше. А есть и антипаттерны. Появляется новый программист и изобретает свой паттерн, свой велосипед, чтобы другие программисты не писали свои велосипеды, а использовали его велосипед. Круто. Или изобретает акроним - это такое красивое слово, под которое подводиться теоретическая база. А если во всем этом начать разбираться, паттерны, принципы, применение, критика, сильные и слабые стороны - то там просто всё противоречит всему. По теме ролика - никаких преимуществ микросервисов не вижу. Микросервис - это просто разделенный монолит и цель разделения, чтобы никто физически не залез туда, куда не надо. Вот этот кусок этой команде, этот той. И общайтесь через апи. Никакой простоты разработки и понимания. Больше команд, сервисов, сущностей, ответственности, планирования, согласования. Время запуска не ниже - развернуть 100+ микросервисов и согласовать их работу. ... Нет увеличенной работоспособности при частичном отказе системе, если откажет основная часть. Микросервисы это - мы пишем что то большое и через пару лет не будем понимать как оно работает. Поэтому мы инкапсулируем часть функционала в микросервис-черный ящик с интерфейсом и будем дергать его по апи. Как оно там работает мы уже не знаем - люди уволились. Поэтому мы ничего не будем трогать (изменять, привет open closed solidу), а будем расширять функционал путем создания новых модулей (аля наследование) общающихся с этим непонятным, но работающим ящиком, по апи (через его интерфейс).
ты какой-то олух или неопытный, он в видео явно говорит - попробуй в монолите выдели мощность на одном сервере для одного модуля кода, а если упрешься в лимиты хостера? поэтому выделяются отдельные сервера для гибкости под каждую задачу и общаются они между собой через запросы. а деплоятся все микросервисы аж через docker-compose, чуть ли не с одним файлом, вот же ж ужасно и сложно это все делается. а еще можно запустить отдельно от всего приложения микросервис, протестировать и задеплоить отредактированные другие микросервисы по очереди и поэтому приложение не упадет на несколько часов в нерабочий отпуск - вы там как-то ждите сидите работнички и клиенты. а еще можно закрыть дыру в скорости какого-то модуля и написать его на c++, когда все остальное на python для быстрой разработки, но с медленным исполнением. попробуешь это реализовать без микросервисов, умнейший? не, ну объективно тебе не светит стартап на уровне амазона, поэтому и не парься со своим wordpress
Максим, два вопроса - твой будущий курс будет на микросервисной архитектуре или на мононолите? В каком редакторe нарисованы схемы? Выглядит профессионально.
"высокая сложность при росте приложения" и "Сложно применить новую технологию" Если вы не можете этого сделать с монолитом, то у вас будут все теже проблемы и на микросервисах.
Именно после таких видосов некоторые люди такие: сейчас мы перейдем на микросервисы, и решим наши проблемы 💪🏻
На самом деле нужно понимать что микросервисы нужны не там как сказал автор если разработка вашего приложения больше месяца, или у вас более N строк кода, и нужно понимать что если ваша команда не может написать хорошо монолит, скорее всего она не осилит микросервисы
Чтобы снизить сложность в разработке монолита при его масштабировании, необходимо делать его модульным, DDD и возможно чистая архитектура вам в помощь
Если вам не нужно поддерживать приложение на разных инстансах, нет в этом необходимости, то микросервисами вы только усложните разработку включая инфраструктуру
"микросервис это маленький монолит" - ты просто красава, от души !!!
Ломал голову, чтобы кристально чисто понять зачем нужен докер, кубернетис, системы сборки, git. А оказывается есть короткий путь, нужно понять, что такое микросервисы, и это объясняет все.
В принципе, логично, ведь современные инструменты соответствуют современной разработке, которая зависит от сложности программ, следующей из потребностей обычных людей и бизнеса. Благодарю, теперь всё собралось воедино.
Автор просто не слышал о контейгнрах
Ну без гита и с монолитом не очень удобно будет. Докер тоже не помешает. А вообще, прежде чем начать пилить микросервисы, надо 20 раз подумать
Супер! очень нагладно и максимально простым языком! очень ценю как ИТ аналитик. спасибо большое
Супер! очень нагладно и максимально простым языком!
Максим, было бы классно подробнее про партиции баз данных. Темный лес для меня ) Спасибо за видео.
Хорошая мысль ! Однозначно в топ !)
Одна из глав в книге "С кабанчиком" больше информации даст
Партиции вроде бы в топике Кафка?! или я что-то прослушал ?
@@СергейГубко-б3р Здесь речь идёт о такой практике проектирования микросервисов как "На каждый микросервис по БД" (далее именную это как микросервисная БД)
Есть также практика, которая противоречит микросервисной архитектуре - "Одна БД на всё приложение" (далее называю это монолитной БД)
БД и прога могут всегда быть выполнены в разных связках
К примеру миркосервисное прилоложение и микросервисная БД
миркосервисное прилоложение и монолитная БД
Монолит приложение и монолит БД
Монолит приложение и микросервисная БД
Смысл микросервисной БД такой же как микросервисного приложения - отделение одного от другого и удобство маштабирования, использование для каждого сервиса своей более подходящей СУБД
Сложность такого подхода заключается в правилах ACID - решение недавно глядел и обычно чаще всего используют его и его модификации - Проектирование Саг
Как реализовывать саги ты выбираешь сам, но в любом случае раскидывая данные по разным БД ты отказываешься от некоторых аспектов - сам в этом в данный момент подробностей мало имею, лучше почитать, я как раз и занимаюсь сейчас изучением этого всего чуда
@@dgdarkking266 интрересно, получаетсяЫ, у каждого микросервиса должен быть свой адаптер для БД?
00:00 Вступ
00:30 Моноліт
05:20 Переваги моноліту
06:34 Проблеми моноліту
10:25 Мікросервіси
15:27 Переваги мікросервісів
18:52 Недоліки мікросервісів
24:28 Патерни для мікросервісів
26:38 Висновок
Отличная презентация, отличная подача и речь, отличная графика и пояснение! Спасибо большое за работу!
блин, очень круто рассказал!
спасибо большое и продолжай в том же духе!
Оличное видео, спасибо! Все по полочкам, и в целом, доступным языком. Мне, как джуну-тестеру, много терминов ещё не знакомы, но всё равно тема микросервисов стала более понятна
Я ещё до конца не дошёл, а уже могу точно сказать, что этот видос рекомендую всем кто готовится пройти тех интервью 😂
P S Автор красава чётко получилось
Спасибо за видео, Максим.
Привет Макс, офигенный ролик про микросервисы, подкину тебе идею для ролика, расскажи про udp протокол
Круто ! Спасибо, видео классное!
Максим, благодарю вас. Очень круто все обьяснили.
Привет! Подписался смотрю, спасибо за труд
Отличное видео. Спасибо ❤
Хайп не только среди разрабов, но и среди работодателей, почти в каждой вакансии есть хоть какое то упоминание либо требование микросервисов
Отличная подача, спасибо!
спасибо, хорошее обьяснение
Отличное видео
Очень четко и понятно пояснил эту тему с примерами, респект
Спасибо, отличное видео!
Видно что ты теоретик.
круто объяснил, спасибо
Привет. Очень хорошо рассказал про микросервисную архитектуру. Просмотрев 1 раз, в это время я еще играл в игру ) Я понял про все, что ты рассказал мне, и теперь я знаю и могу рассказать, что такое микросервисная архитектура и что она из себя представляет, а так же знаю, где лучше использовать монолит, а в каких случаях микросервисы
молодец отлично про gateway
спасибо большое за видео, очень грамотная подача материала!!
Спасибо!)
Полезное видео, спасибо
👍Спасибо
Подробнейший обзор!
Спасибо!
Спасибо большое, удивительно, но очень понятно
Четко!!!
классно объяснено
А твой "большой проект" какие задержки будет иметь ганяя данные от одного микросервиса к другому вместо нормального обмена в монолите в рамках единого приложения?) или "пофиг на продуктивность, просто более мощное железо поставим если что"?)
Дуже якісне пояснення, дякую Максим!
🙌🏻
Получается, ендпоинты в API, это путь к отдельному сервису, в монолите их не бывает?
Максим, ОГРОМНОЕ спасибо тебе за твои видосы! Я столько полезного извлекаю
"Преимущество монолита: у нас всё находится в одном месте".
Тут не поспоришь, главное сказать в каком и как оно называется 😂
Интересно. Комменты исключительно положительные. Имхо нужно разобраться с камерой т.к. сой автофокуса подбешивает и уменьшить материал, т.к. долго.
Ролик топ топыч!
Доброе время суток! Если в Django rest, несколько приложений со своими моделями и вьюшками они общаются через эндпоинты, всё это в одном Django проекте, это будет микросервисная архитектура или это монолит с приложениями в нём?
Если у них свои таблицы в бд да
почему хексагон? может гексагон. Потому что hex это к 16, а гекса к 6
Отличная вводная лекция! Спасибо)
У всех подходов один недостаток - деплоймент)
Крассавчик , полезная инфа
Максим, подскажи, как ты искал вакансии на позициою junior go developer, по моему таких вакансих не то что мало - их нет, я долго работаю devops инженером и хочу немного перейти в go, но смотрю на вакансии - везде от 2х лет комерческой разработки.
Не пиши что джуниор) подавай резюме на мидл позицию, но пиши в резюме правду. Бывает что они собеседуют и тому, кто на позицию не проходит делают оффер на мидла. Поэтому на джуна почти нет вакансий: у HRa гора резюме всегда на джуна
Привет, нашёл работу, почему из девопса решил уйти? Я сам хочу из сетевик в девопс перейти
Сколько получал девопсом?
@@johnnysuedy Не ушёл в go, писать на go мелкие проекты - приятно и интересно, но программирование за деньги не всегда приятно и интересно - это вывод исходя из того что я вижу у ребят в команде. Продолжаю заниматься devops/администрированием - почти перестал писать на go к сожалению
Максим, хороший контент, спасибо за разъяснения.
"да, то есть, по сути" - чуть кровь из ушей не пошла. Профильтруй речь, пожалуйста :)
Слышал еще одно одно неофициальное правило микросервисов, что они должни состоять не более чем из 10000 строк кода не считая кода библиотек.
Архитектурный паттерн говорит о логике разбиения, привязываться к количеству строчек - глупо.
Приветствую. А чем отличается msa от soa?
Привет, на ютубе видел отдельное видео на эту тему
Получи полный набор тем и список ресурсов для изучения Backend разработки
www.zhashkevych.com/backend-roadmap?
Максим, расскажи, пожалуйста, про собеседования) Что обычно спрашивают у джунов/миддлов/сеньоров гошников?
На следующей неделе как раз будет видео на канале про собесы для го разработчиков)
@@MaksimZhashkevych лучший, спасибо!
thanks!
крутая инфографика, что за редактор? я про черно-зеленые схемы
Привет, картинки похожи на те, что есть в книге Криса Ричардсона (но могу ошибаться). М.б их просто из презентации или чего-то подобного взяли
👍
Очередной раз подтверждается фраза "видишь программиста работающего на маке значит он джуниор"
Где таймкоды?
Не стоило про монолиты рассказывать, если нет опыта
Хайпануть нужно вовремя
монолит - это в сталкере
Очень хороший формат, только хотелось бы, чтобы когда ты объяснял, картинка в презентации становилась миниатюрой, а изображение с тобой становилось полноэкранным)
Мне кажется, это уже далеко зашло.
Микросервисы оповещают микросервисы. Апи для апи. Господа, это клиника. Тут нужен хороший психиатр и длительный курс лечения.
Какие паттерны микросервисов? Все паттерны описаны в ГОФ.
Извините, я ошибся - не все паттерны, ведь есть ещё паттерны, о которых можно почитать в Википедии - их около 100 и их становиться всё больше.
А есть и антипаттерны.
Появляется новый программист и изобретает свой паттерн, свой велосипед, чтобы другие программисты не писали свои велосипеды, а использовали его велосипед. Круто.
Или изобретает акроним - это такое красивое слово, под которое подводиться теоретическая база.
А если во всем этом начать разбираться, паттерны, принципы, применение, критика, сильные и слабые стороны - то там просто всё противоречит всему.
По теме ролика - никаких преимуществ микросервисов не вижу. Микросервис - это просто разделенный монолит и цель разделения, чтобы никто физически не залез туда, куда не надо. Вот этот кусок этой команде, этот той. И общайтесь через апи.
Никакой простоты разработки и понимания. Больше команд, сервисов, сущностей, ответственности, планирования, согласования.
Время запуска не ниже - развернуть 100+ микросервисов и согласовать их работу.
...
Нет увеличенной работоспособности при частичном отказе системе, если откажет основная часть.
Микросервисы это - мы пишем что то большое и через пару лет не будем понимать как оно работает. Поэтому мы инкапсулируем часть функционала в микросервис-черный ящик с интерфейсом и будем дергать его по апи. Как оно там работает мы уже не знаем - люди уволились. Поэтому мы ничего не будем трогать (изменять, привет open closed solidу), а будем расширять функционал путем создания новых модулей (аля наследование) общающихся с этим непонятным, но работающим ящиком, по апи (через его интерфейс).
ты какой-то олух или неопытный, он в видео явно говорит - попробуй в монолите выдели мощность на одном сервере для одного модуля кода, а если упрешься в лимиты хостера? поэтому выделяются отдельные сервера для гибкости под каждую задачу и общаются они между собой через запросы.
а деплоятся все микросервисы аж через docker-compose, чуть ли не с одним файлом, вот же ж ужасно и сложно это все делается.
а еще можно запустить отдельно от всего приложения микросервис, протестировать и задеплоить отредактированные другие микросервисы по очереди и поэтому приложение не упадет на несколько часов в нерабочий отпуск - вы там как-то ждите сидите работнички и клиенты.
а еще можно закрыть дыру в скорости какого-то модуля и написать его на c++, когда все остальное на python для быстрой разработки, но с медленным исполнением.
попробуешь это реализовать без микросервисов, умнейший?
не, ну объективно тебе не светит стартап на уровне амазона, поэтому и не парься со своим wordpress
Лайк только за последнюю фразу "не усложняйте" а так конечно вода и трата времени(
Максим, два вопроса - твой будущий курс будет на микросервисной архитектуре или на мононолите?
В каком редакторe нарисованы схемы? Выглядит профессионально.
cool
Крутий матеріал, а буде приклад простого додатку з мікросервісів.
можешь чуток убрать громкость своего голоса и повысить музыку на заднем фоне :)
Я за ))
Макс, видЕо надо сокращать в разы. Очень много лирики, повторений, ненужных перечислений. Бери пример с Алексея Земскова.
видео*
@@MaksimZhashkevych, понятно же, что это была дурацкая опечатка...
У него мак. Что вы пристали к подростку. Ему просто нужно показать что у него мак.
"высокая сложность при росте приложения"
и
"Сложно применить новую технологию"
Если вы не можете этого сделать с монолитом, то у вас будут все теже проблемы и на микросервисах.
Дякую
Я манал дебажить микросервиси 😢
Ты же вроде подстригся. Как за короткий промежуток времени ты отрастил волосы?
у меня хороший шампунь)
у тебя и мак хороший)
@@MaksimZhashkevych 😂😄😄😄😄
Разработчик на мак это отдельная ветвь деволюции.
Хватит белого фона)
Мы что 1С разрабы что-ли тебе
Шшшшшшутка избалованных )
не бизнес-логика, а просто ЛОГИКА. Не хексагон, а гексагон. И вообще, слишком много воды. Все пересмотрел на перемотке.
Зачем так мучал себя?
Это принято называть бизнес логикой
@@shanewalsch а чего не криминал-логикой? Поменяем традиции.
ох холивар
Много воды
одна теория. бла бла... покажи код!
Спасибо, отличное видео!