Не надо обманывать народ. Вы зазываете их всех и потом народ в обломе больше никогда не берётся за сферу IT. Нереально НОРМАЛЬНЫМ DevOps стать не то что за 4 месяца, там вообще во всех этих направлениях учиться всю жизнь. За 4 месяца более менее человека можно научить работать с командной строкой, разделение дистрибутивов, работа с установщиками ПО в каждом поотдельности, настройка сети и вообще основы блин TCP/IP, далее можно какой-то разобрать даже файер вроде ufw , но ни о каком iptables и всех на его базе речи не будет. И ты смотри мы ещё не дошли соответственно до разбора API и даже разбор протокола HTTP. Мы даже ещё не затронули что-то вроде сертификатов SSL. Ой, а ещё море баз данных вроде Mysql. Там как бы тоже различий много и если придётся работать с MS SQL или PostgreSQL, то мне жалко того девопса, который только Mysql или MariaDB изучал. В общем если было не 4 месяца, а год записано, то и в этом случае очень сложно. Да чего далеко ходить, какой-нибудь арч линукс с нуля без мануала кто-то установит? Вот ни разу не заглянув в мануалы установите? :) Это я сейчас не закидываю какашками, а просто пытаюсь объяснить, что все уже который год рекламируют сферу IT, но мало кто понимает сколько лет труда, бессонных ночей, нервов это будет стоить.
@@GSSG70Год-два это ни о чем время. В жизни 60-100 лет. Потратить пару лет и дальше всю жизнь развиваться в выбранной сфере, при этом не выискивая акции в пятерочке очень выгодно с точки зрения планирования жизни. Понятно, что не всем такой путь по душе. Ну а рекламой они занимаются ради собственной выгоды. Это их хлеб.
Видео краткое и понятное А монолит нужен там: - где нет запредельных нагрузок, так как с масштабированием проблема, но оно дешевле, так как при масштабировании микросервисов нужно на каждый сервис отдельно нода - где важна скорость взаимодействия, так как в монолите вся функциональность находится в одной кодовой базе и ноде, и соответственно все быстрее функционирует - где команда разработчиков способна работать в одном стиле и с одним языком программирования, все же дебажить монолит проще, чем микросервисы
В монолите если что-то лежит, лежит все приложение. Но и наоборот в микросервисах никогда полностью не работает приложение - обязательно что-то лежит :D
Как всегда, в видео кто-то получает по жопе, зато понятно и забавно) А монолитную архитектуру проще использовать в маленьком приложении, которое даже если и будет обновляться и масштабироваться, все-равно вызовет намного меньше боли, чем реализация его с использованием микросервисной архитектуры. Например какой-нибудь новостной сайт
А какая разница ? Если другие команды не лезут в другие сервисы то все ок. У каждой команды свои бранчи и все в монорепе это удобно. Скачал репу на мастере и поднял всю инфраструктуру локально через docker compose. Нужны другие сервисы подтянул к себе в бранчу бранчи других сервисов - это даже удобнее чем в отдельных репах
Монолит использоваться можно смело в случае маленьких проектов, например с фреймворком Django, можно создавать другие приложения в других каталогах, и при этом делать это зависимо и не зависимо, выходит можно разграничивать логику и при этом использовать одну кодовую базу. А в случае с большими проектами исключительно микро сервисы.
Микросервисы - это только одна из нескольких распределенных архитектур. Есть SOA, в свое время словившая хайп не меньше, чем недавно микросервисы. Вдобавок еще есть service based и event driven архитектуры.
Микросервисы нужны только для разделения труда в больших проектах. Они не добавляют скорости приложению (наоборот) и стабильности. Если в "монолите" будет ошибка в api для авторизации, остальные эндоинты продолжат нормально работать точно также. Если внесены изменения только в модуль авторизации, его тоже можно загрузить отдельно точно также, а не весь проект. Зачем сбивать людей с толку такими видео.
А теперь представь синтаксическую ошибку в общем ядре - и вот уже ни одна страничка не открывается,😢, ни один метод апи не работает. Или та же ошибка, но например на более высоком уровне, например в базовом контроллере или одном из классов, которые он использует как зависимости - и вот уже отвалилось все апи сайта, и нет возможности ни каталог открыть, ни корзину ю
@@tomasddf синтаксическая ошибка в общем микросервисе для извлечения данных из бд вызовет тоже самое. Правда он не скомпилируется скорее всего, но точно также, как и typescript код. И не будет меняться долгое время, но опять точно также, как и обычные базовые модули. Во вторых, с чего бы таким общим классам, от которых все зависят, вообще быть, меня никто не заставляет их делать, если я хочу более модульную архитектуру. Микромодули они и так есть в любой нормальной архитектуре приложения. Весь стек технологий для именно микросервисов нужно тянуть только в том случае, если это реально упростит жизнь команде и она точно знает зачем ей это. Если команда будет их делать потому что "так в фейсбуке и так сказал чел с ютуба" жизнь усложнится очень быстро, а с возросшим бюджетом на разработку заказчик может послать куда подальше.
@@wildcat4435 "синтаксическая ошибка в общем микросервисе для извлечения данных из бд". А это как? Каждый микросервис самостоятельно ходит в свою БД. Причем у каждого микросервиса эти БД могут быть разного типа, в зависимости от потребности
@@BOPHAKOHE мО мнение подкреплено тем, что это исторический факт и его никто не отрицает. Иди лучше внедряй микросервисную архитектуру в лендинг пейдж своей мамы, а не пиши глупые комментарии
Монолиты можно использовать при реализации mvp продукта, тк это сильно дешевле, чем микросервисы пилить:) Если гипотеза взлетает, то можно уже делать полноценный продукт на микросервисной архитектуре. Хотя…нет ничего более постоянного, чем временные решения😢
0:27 "Благодарим Тебя за то, что раскрыл слугам Твоим козни врагов наших. Озари сиянием Своим души тех, кто отдал жизнь во исполнение воли Твоей. В бой, защитники Монолита! В бой! Отомстим за павших братьев наших. Да будет благословенно их вечное единение с Монолитом! Смерть… Лютая смерть тем, кто отвергает Его священную силу!"
не нужно дублировать текст мемом , как по мне. Можно просто заменить мемом слово и станет только лучше. Хотя бы протестировать. Извиняюсь, если сильно раскритиковал
Веб разработчики такие Клоуны. Если у вас не гугл, Яндекс, сбер или что то похожее по размерам. Дрочь с Микро сервисами не нужна. Медленная, дорогая разработка, маленькая производительность, относительно монолитов. Увеличенное кол во программистов
Че насчет транзакции, которая должна пройти через несколько микросервисов? И если посредине этой транзакции, когда часть процессов на определенных сервисах закончилисиь, возникает ошибка и нужно все изменения откатить. Монолит в этой ситуации рулит...
Вообще, лучше монолит. Микросервисы - если у вас нормальный архитектор, который понимает: вот тут по другому ну ВАЩЕ никак. У нас на работе микросервисное и оно мальца без доков кумарит
А у нас монолит, и оно без доков тот еще ад. Лучше бы распилили на сервисы, чтобы уменьшить связность, и разграничить зоны ответственности между командами. А также в этом случае можно было бы получить преимущества благодаря независимости : у каждого сервиса свои задачи, которые эффективнее решать какими-то своими инструментами, в монолите же все вынуждены страдать, оставаясь в рамках одного общего языка и архитектуры, изобретая велосипеды, вместо того чтобы просто воспользоваться более подходящими инструментами. Отдельная боль - тестирование монолита. Степень связности там настолько высокая, что ни о каком автоматическом тестировании и речи быть не может, только ручное тестирование, только хардкор и боль. И нет никаких надёжных способов как-то ограничить рост сложности монолита: несколько команд, текучка, хаос, каждый лепит как умеет, количество костылей год от года растет, и разгрести все это ресурсов просто нет. Вместе со сложностью растет и количество ошибок и стоимость поддержки/разработки, контроля становится все меньше, и увеличивается текучка: копаться в этой куче навоза желающих нет, слишком высокий порог входа, слишком больно, и как вишенка нет документации, точнее она моментально устаревает, все держится только на экспертизе старожил, которых с каждым годом становится все меньше и меньше. Люди уходят, я тоже уже подумываю уходить, нервов уже на все это не хватает. Так что лучше уж пачка небольших микросервисов, рост сложности которых ограничен, в которых низкий порог входа и есть возможность всегда найти людей для поддержки, и самое главное, в которых четко ограничена сфера ответственности, на уровне архитектуры, и при всем желании повысить связность и сложность ни у какого отдельного разработчика просто нет возможности. Самая большая беда, когда какой-нибудь не особо умный разработчик пытается срезать углы, прокладывая новые связи там, где их быть не должно - это наиболее сильно влияет на степень сложности и количество ошибок, и это возможно только в монолитной архитектуре, где разработчик ничем не ограничен и может творить грязь.
Я правильно понимаючто микросервисы возможны только со стороны сервера и только если программа сетевая. То есть программа которая устанавливается на телефон или компьютер пользователя она всегда монолитная и если ее надо обновить то надо пересобирать и перезаписывать всю программу и обновить чать программы на устройстве конечного пользователя не возможно?
совсем не обязательно что микросервсное приложение - сетевое. Например возьмем Evernote. Представим, что у него нет сетевых функций, но оффлайн функционал остался. Таким образом, наше приложение (Evernote) может быть поделено на сервисы (Заметки, Календарь, фотографии, тудушка и пр..)
@@dmitryandreew8582 тогда это многомодульный монолит. Про это в видосе не сказали, но можно запилить монолит из нескольких модулей, где у одного модуля может быть даже несколько инстансов, если это понадобится. Разработка модулей ведется сравнительно раздельно, так при деплое можно пересобирать только изменившиеся модули, и можно спокойно разделить команды, чисто технически можно использовать разные языки с учетом того, что четко прописан будет не только API, но и ABI(конвенция вызовов), естсно это работает только для языков с одной платформы, например jvm, .net, llvm или просто компилируемые в машинно-зависимые бинарники
@@xtech3408 Спасибо за пояснения. С монолитами приходилось работать только на стадии раннего мвп и тестирования бизнес идей, посему никогда не копал так глубоко как вы.
Очень не согласен с тем что только в монолите что то одно может сломать совсем другое. На микро сервисной архитектуре словить данный аффект как делать нече, особенно когда микро сервисов только бэковых больше 150 штук. Тут только одной коммуникации становится в 150 раз больше, а потом представь что ты добавляешь какой то атрибут или артефакт не согласовав со смежниками, там еще и Куча сертов, токенов, по взаимодействию и куча транспорта и тд и тп 😂😂😂 сопровождать это довольно большое увеселение. И это я еще молчу про поддержание консистентности данных, балансировку, георезераирование и тд. Там к этому еще прилагается бизнес сторона, где много всякого и интересного, а там еще есть такая штука как бесшовный переход с монолитной архитектуры на микро сервисы, то появляются риски тиражирования и тд и тп. Легко и просто переход будет только на мелко средних проектах типа какого то авита. Действительно крупные штуки просто взять и перевести в микро сервисы очень больно, дорого и трудно. 😂😂😂
По вопросу где лучше имхо для начала стоит рассмотреть структуру подразделений разрабов, вероятно, делить на отдельные репы стоит учитывая этот фактор, если у вас небольшая группа, фиг ли там городить микро?.. если у вас много больших команд, наверное стоит задуматься о гибридных вариантах… имхо. Буду рад, если кто поправит и выскажет свои мысли
Я думаю что архитектура вторична. Попытки все описывать микросервисами - это в некотором роде преждевременная оптимизация. Софт живёт и развивается, и на каждом этапе к нему разные требования. В начале важнее стоимость запуска и сроки, чуть позже становится важнее уже стоимость поддержки и изменчивость, способность противостоять неконтролируемому росту сложности, сохранение низкого порога входа и возможность с лёгкостью находить людей для поддержки. Так что нет ничего плохого в том, что на разных этапах жизненного цикла у софта разная архитектура. Софт меняется исходя из изменения требований к нему: на каком-то этапе отдельные модули монолита так или иначе придется выделять в отдельные сервисы, частично или полностью независимые от монолита. Например на ранних этапах этого процесса к монолиту прикручивают внешние сервисы, такие как например эластик, и формируют вокруг них слой поддержки, а позже все это отпочковывается в отдельный проект, чтобы быть проще, надёжнее, и хорошо выполнять какую одну конкретную функцию
типо это разные html файлы, которые обращаются друг к другу на разных лвлах? не совсем понял суть микросервисов. Ну, да, удобнее работать над проджектом, но как их воссоединить?
Как вывести текущую сессию авторизации например в пользовательскм интерфейсе? Когда они в разных микросервисах. При каждой загрузке сайта дергать другой сервис?
Так фронт разве тоже микросервисно делиться? Если использовать около микросервисную архитектуру (например NX monorepo), то там проблем особо вообще не будет с этим. Или я не правильно понял вопрос?
Это задача апи гейта - это отдельный микросервис, который снаружи виден как монолит с публичным апи, а внутри по факту является диспетчером для всех остальных микросервисов и общается с ними через их отдельные апи или очереди. Так что с этой стороны все ок, фронт получит сессию авторизации точно также, как получил бы ее в монолите. Ну а под капотом апи гейт собирает ответ для фронта из данных от множества других сервисов. Но он их не дёргает каждый запрос, т.к. в таких системах обязательно применяется многоуровневое кеширование: он эту сессию каждый запрос будет доставать из какого-нибудь быстрого кеша, так что по затратам это будет сравнимо с отдачей статики. Сервис авторизации в свою очередь будет контролировать этот кеш: воссоздавать его при авторизации и инвалидировать при деавторизации или истечении срока жизни сессии.
Монолиты хороши когда надо сделать что-то быстро и, скажем, протестировать какую-то бизнес-идею. Собрал мвп, выплюнул в фокус группу / реальных пользователей и смотри как оно работает. Работает - можем пилить на мс. Не работает - штош, не велика беда
Да нет никаких раньше и сейчас - монолитная архитектура имеет право на существование и никуда не денется. Новый проект проще, быстрее и гораздо дешевле реализовывать через монолит, чтобы не так жалко было осознавать, что он не взлетел и загибается, ну а если выстрелит, нагрузки и прибыли поползут вверх - тогда уже имеет смысл переписать его на микросервисную архитектуру. 🤔
Жаль, что вводит в заблуждение, выдает желаемое за действительное. Low coupling прекрасно возможен в монолите и нарушить его запросто можно и в микросервисах. Микросервисы это в первую очередь история о том, что команда разработки начинает сильно превышать оптимум из 7-12 человек, по этому одна команда разбивается на несколько отдельных команд, которым надо независимо друг от друга уметь релизиться и вот тут микросервисы будут уже ой как кстати.
@@ЗайнудинГаджиев-р9з А еще транзакционность поддерживать между запросами... А еще всякие BFF для каждого микросервиса А про общий shared код - вообще молчу) его педалят все... и ломается оно сразу у всех 😂
Несколько не согласен, что в монолите все перекомпилировать и пересобирать. Даже элементарные более оптимальные построения классов позволяют компилить только то, что создано вновь либо модифицировано. Потом, почему речь идёт только о монолите и микро?.. а где гибриды, скажем проекты, взаимодействующие длл или иными способами? Сборка одного длл конечно подразумевает общую сборку проекта в деплой, но речь не идёт о компиле или сборки с нуля всей кодовой базы
Чувак, который создавал ролик видно какой-то программер? Скажи мне мил человек где ты последний раз видел программера, который бы САМ что-то любил оптимизировать? Может лет 20-25-30 назад были такие, которые были ограничены аппаратными ресурсами. Я вот например писал всякие системные штуки. Создатели игр тоже вынуждены были оптимизировать, потому чтобы в массы что-то пошло приходилось всё же двиги вылизывать. Но опять тут тоже ключевые слова ВЫНУЖДЕНЫ и ПРИХОДИЛОСЬ. Так за последующие 25 лет я ни разу не встретил разраба, который бы по своей воле что-то начинал оптимизировать. Конечно если писали какую-то уж очень дичь и какой-то запрос на кассе занимал по полминуты, то конечно некоторым ума хватало оптимизировать. Сегодня таких нет. Но зачем всем этим вообще заниматься? А давайте поделим всю эту хрень на кирпичи и всучим им совершенно другим кадрам. Пусть они мучаются. Как результат получили кучу новых технологий. Штук 12 точно, которые почему-то всем и сразу бывают нужны. Взаимозаменяемость? Не, не слышали. Написать в одном проекте? Не, тоже не слышали. И получается интересная вещь, что по сути все эти проблемы нагрузили на админов. Да да, тех самых самых обычных админов, которыем надо было с системой возиться, либо с сетью. Ну а кто бы ещё кроме них весь этот винигрет потянул? Проблема заключается ещё в том, что и классическое понимание каких-то инженеров, сисадминов, сетевиков изживает себя. Смотришь вакансию и не понимаешь, написано скажем хотят просто айти администратора, а вот функционал там как у начальника отдела поддержки по запуску ракет в космос. Или скажем позиция сисадмина, но функционал хотят тот же - работа с облаками, куча всяких кафок, докеров, шмокеров, кубернетисов. Так и хочется всех этих хитрозадых спросить - вам что в лом было написать что вы хотите вообще ДевОпса? Ну вы же Девелопера уже девелопером называете и от девелопера даже администрирования баз данных не требуете? В общем зажирается начальство в айти секторах. Если кто не понял поясню. Разница в зарплатах и нагрузке в разы. Потому никто даже правильно не пишет чего им надо на самом деле, но юзать тебя будут как девопса. Но есть ещё один нюанс. Даже если вы проработаете условно сисадмином на позиции для девопса, то вы даже в резюме своём это не сможете легально записать. В общем надеюсь понятно объяснил.
Добрый день! Отвечая на ваш вопрос касаемо разраба, которого мы видели и он любит что то оптимизировать - видели его в пятницу (2 дня назад) крайний раз!
@@merionacademyИ чего и зачем он пооптимизировал? Ну без подробностей конечно. Сегодня нет каких-то фанатиков или энтузиастов, которые будут пилить код до идеала. В основном все пашут чтобы просто работало. Конечно есть вспомогательные средства проверки кода, даже софт проверки на уязвимости, но по сути это так. Даже компании гиганты вроде Майкрософт, РедХат и т.д. этим не занимаются. А это как бы написание осей.
@@merionacademy Да ладно. Мне то какое дело человеку с 27 годиками опыта и 10 годиками образования. Я просто высказал своё мнение. И в подтверждение моих слов можно послушать что тот же Гейтс когда-то говорил сколько памяти кому хватит, потом посмотреть на современные сначала десктоп системы с потреблением памяти, потом на всякий случай глянуть потребление последними версиями андроида и в конец посмотреть уже тех характеристики роутеров и их осей. Ни в одной области оптимизацией написанного кода и не пахнет. Ни один фактически компилятор не выдаёт оптимальный код (мингва более менее ещё). Да вообще как махина типа ВС размерами в 50 и более гигов инсталяшки может оптимально что-то собрать? Её саму надо оптимизировать и оптимизировать. А новое никто ничего не создаёт, нормальное, компактное, безопасное и быстрое. Потому код уже по определению не может быть нормальным.
Стань DevOps инженером за 4 месяца обучения! 🙌
wiki.merionet.ru/merion-academy/courses/devops-inzhener-s-nulya/?YT&
You are breathtaking! Я на канале минут 20, и каждое видео максимально понятное. Спасибо за ваш труд!
Не надо обманывать народ. Вы зазываете их всех и потом народ в обломе больше никогда не берётся за сферу IT.
Нереально НОРМАЛЬНЫМ DevOps стать не то что за 4 месяца, там вообще во всех этих направлениях учиться всю жизнь. За 4 месяца более менее человека можно научить работать с командной строкой, разделение дистрибутивов, работа с установщиками ПО в каждом поотдельности, настройка сети и вообще основы блин TCP/IP, далее можно какой-то разобрать даже файер вроде ufw , но ни о каком iptables и всех на его базе речи не будет. И ты смотри мы ещё не дошли соответственно до разбора API и даже разбор протокола HTTP. Мы даже ещё не затронули что-то вроде сертификатов SSL. Ой, а ещё море баз данных вроде Mysql. Там как бы тоже различий много и если придётся работать с MS SQL или PostgreSQL, то мне жалко того девопса, который только Mysql или MariaDB изучал. В общем если было не 4 месяца, а год записано, то и в этом случае очень сложно. Да чего далеко ходить, какой-нибудь арч линукс с нуля без мануала кто-то установит? Вот ни разу не заглянув в мануалы установите? :)
Это я сейчас не закидываю какашками, а просто пытаюсь объяснить, что все уже который год рекламируют сферу IT, но мало кто понимает сколько лет труда, бессонных ночей, нервов это будет стоить.
@@GSSG70Год-два это ни о чем время. В жизни 60-100 лет. Потратить пару лет и дальше всю жизнь развиваться в выбранной сфере, при этом не выискивая акции в пятерочке очень выгодно с точки зрения планирования жизни.
Понятно, что не всем такой путь по душе. Ну а рекламой они занимаются ради собственной выгоды. Это их хлеб.
Видео краткое и понятное
А монолит нужен там:
- где нет запредельных нагрузок, так как с масштабированием проблема, но оно дешевле, так как при масштабировании микросервисов нужно на каждый сервис отдельно нода
- где важна скорость взаимодействия, так как в монолите вся функциональность находится в одной кодовой базе и ноде, и соответственно все быстрее функционирует
- где команда разработчиков способна работать в одном стиле и с одним языком программирования, все же дебажить монолит проще, чем микросервисы
поправка: на каждый сервис не нужна отдельная нода
@@shurik4493бывает, что нужна
факты, которые не имеют отношения к современной кодовой разработке
@@roninsh4341а какие факты имеют отношение к современной кодовой разработке
Классный формат. Для начинающих так вообще идеально, все сжато и весело подается. Очень удобно повторять перед собеседованиями
Формат - понос Тинькоффский. Нельзя по-человечески что ли объяснять? Обязательно петросянить?
Если хочешь сурьёзный нудный формат - иди на просторы интернета, там полно материала про микросервисы.
Это же обзор, что из этого можно использовать на собеседовании? 😮
В монолите если что-то лежит, лежит все приложение.
Но и наоборот в микросервисах никогда полностью не работает приложение - обязательно что-то лежит :D
Как всегда, в видео кто-то получает по жопе, зато понятно и забавно)
А монолитную архитектуру проще использовать в маленьком приложении, которое даже если и будет обновляться и масштабироваться, все-равно вызовет намного меньше боли, чем реализация его с использованием микросервисной архитектуры. Например какой-нибудь новостной сайт
Не забываем положить все микросервисы в монорепо 😍😍😍
А какая разница ?
Если другие команды не лезут в другие сервисы то все ок. У каждой команды свои бранчи и все в монорепе это удобно. Скачал репу на мастере и поднял всю инфраструктуру локально через docker compose. Нужны другие сервисы подтянул к себе в бранчу бранчи других сервисов - это даже удобнее чем в отдельных репах
и использовать под каждый микрофронтент ФСД архитектуру
@@hackyou497 фсд это просто структура папок. и все
0:01
Я думаю, надо же, еще не видела это видео, а оно только вышло)
Люблю вас за то что даже я понимаю)
Монолит использоваться можно смело в случае маленьких проектов, например с фреймворком Django, можно создавать другие приложения в других каталогах, и при этом делать это зависимо и не зависимо, выходит можно разграничивать логику и при этом использовать одну кодовую базу. А в случае с большими проектами исключительно микро сервисы.
Микросервисы - это только одна из нескольких распределенных архитектур. Есть SOA, в свое время словившая хайп не меньше, чем недавно микросервисы. Вдобавок еще есть service based и event driven архитектуры.
разница СОА / микросервисы, на примере ?
@@Georgii1212
тут дядька подробно рассказывает
soa
ruclips.net/video/9fn4vGEKFs8/видео.html
микросервисы
ruclips.net/video/UZQMUiVqpFs/видео.html
Лайк если у тебя микросервисов больше чем пользователей
😂😂😂
😂
Микросервисы нужны только для разделения труда в больших проектах. Они не добавляют скорости приложению (наоборот) и стабильности. Если в "монолите" будет ошибка в api для авторизации, остальные эндоинты продолжат нормально работать точно также. Если внесены изменения только в модуль авторизации, его тоже можно загрузить отдельно точно также, а не весь проект. Зачем сбивать людей с толку такими видео.
А теперь представь синтаксическую ошибку в общем ядре - и вот уже ни одна страничка не открывается,😢, ни один метод апи не работает.
Или та же ошибка, но например на более высоком уровне, например в базовом контроллере или одном из классов, которые он использует как зависимости - и вот уже отвалилось все апи сайта, и нет возможности ни каталог открыть, ни корзину ю
@@tomasddf синтаксическая ошибка в общем микросервисе для извлечения данных из бд вызовет тоже самое. Правда он не скомпилируется скорее всего, но точно также, как и typescript код. И не будет меняться долгое время, но опять точно также, как и обычные базовые модули. Во вторых, с чего бы таким общим классам, от которых все зависят, вообще быть, меня никто не заставляет их делать, если я хочу более модульную архитектуру. Микромодули они и так есть в любой нормальной архитектуре приложения. Весь стек технологий для именно микросервисов нужно тянуть только в том случае, если это реально упростит жизнь команде и она точно знает зачем ей это. Если команда будет их делать потому что "так в фейсбуке и так сказал чел с ютуба" жизнь усложнится очень быстро, а с возросшим бюджетом на разработку заказчик может послать куда подальше.
@@wildcat4435 "синтаксическая ошибка в общем микросервисе для извлечения данных из бд". А это как? Каждый микросервис самостоятельно ходит в свою БД. Причем у каждого микросервиса эти БД могут быть разного типа, в зависимости от потребности
Чем подкреплено тво мнение ?
@@BOPHAKOHE мО мнение подкреплено тем, что это исторический факт и его никто не отрицает. Иди лучше внедряй микросервисную архитектуру в лендинг пейдж своей мамы, а не пиши глупые комментарии
Монолиты можно использовать при реализации mvp продукта, тк это сильно дешевле, чем микросервисы пилить:)
Если гипотеза взлетает, то можно уже делать полноценный продукт на микросервисной архитектуре.
Хотя…нет ничего более постоянного, чем временные решения😢
Монолит лучше, где не требуется масштабировать, ну например гос сайт узкого направления. Микросервисы удобны масштабированием. Ну и тд.
По факту, каждый гос сайт узкого направление это и есть микросервис.
0:27 "Благодарим Тебя за то, что раскрыл слугам Твоим козни врагов наших. Озари сиянием Своим души тех, кто отдал жизнь во исполнение воли Твоей. В бой, защитники Монолита! В бой! Отомстим за павших братьев наших. Да будет благословенно их вечное единение с Монолитом! Смерть… Лютая смерть тем, кто отвергает Его священную силу!"
Все, уверовал... Теперь учу микросервисную архитектуру...
не нужно дублировать текст мемом , как по мне. Можно просто заменить мемом слово и станет только лучше. Хотя бы протестировать. Извиняюсь, если сильно раскритиковал
Спасибо, учтём)
Микросервисы нужны в первую очередь там где хайлоад. В противном случае у вас кратно увеличивается стоимость и время разработки и поддержки.
Веб разработчики такие Клоуны. Если у вас не гугл, Яндекс, сбер или что то похожее по размерам. Дрочь с Микро сервисами не нужна. Медленная, дорогая разработка, маленькая производительность, относительно монолитов. Увеличенное кол во программистов
Еще есть протокол LDAP, что,для чего и где, было бы не плохо с такой подачей :)
О, открыли для себя flaticon :)
автор легко и по красоте пояснил за творящийся ад🤣 лайк,само собой
Сделай gRPC vs REST vs http vs http2
Вы прям в самую точку, следующий видос - про это!
Уже даже озвучен.
Подписывайтесь, чтоб не пропустить)
@@merionacademy круто!
Монолиты удобно использовать в маленьких проектах с использованием clean архитектурой p.s. Хочется видос по DDD
Че насчет транзакции, которая должна пройти через несколько микросервисов? И если посредине этой транзакции, когда часть процессов на определенных сервисах закончилисиь, возникает ошибка и нужно все изменения откатить. Монолит в этой ситуации рулит...
как вам идея создать видео, в котором расскажите, в каком порядке нужно учить тему сеть (networking)?
Для меня самый неожиданный момент , что в таких случиях можно писать на разных языках .
Можно узнать название саундтрека к вашим роликам? Контент очень краткий и интересный!
Божественная подача, спасибо! лайк подписка колокольчики и тд
А где у Вас в курсе SQL , AWS или GCP ,Kafka? Prometheus???
А чем микросервисы от модулей отличаются?
Как всегда очень полезно, чётко и по делу. Красавцы чё! 😊
Вообще, лучше монолит. Микросервисы - если у вас нормальный архитектор, который понимает: вот тут по другому ну ВАЩЕ никак.
У нас на работе микросервисное и оно мальца без доков кумарит
А у нас монолит, и оно без доков тот еще ад. Лучше бы распилили на сервисы, чтобы уменьшить связность, и разграничить зоны ответственности между командами. А также в этом случае можно было бы получить преимущества благодаря независимости : у каждого сервиса свои задачи, которые эффективнее решать какими-то своими инструментами, в монолите же все вынуждены страдать, оставаясь в рамках одного общего языка и архитектуры, изобретая велосипеды, вместо того чтобы просто воспользоваться более подходящими инструментами.
Отдельная боль - тестирование монолита. Степень связности там настолько высокая, что ни о каком автоматическом тестировании и речи быть не может, только ручное тестирование, только хардкор и боль. И нет никаких надёжных способов как-то ограничить рост сложности монолита: несколько команд, текучка, хаос, каждый лепит как умеет, количество костылей год от года растет, и разгрести все это ресурсов просто нет. Вместе со сложностью растет и количество ошибок и стоимость поддержки/разработки, контроля становится все меньше, и увеличивается текучка: копаться в этой куче навоза желающих нет, слишком высокий порог входа, слишком больно, и как вишенка нет документации, точнее она моментально устаревает, все держится только на экспертизе старожил, которых с каждым годом становится все меньше и меньше. Люди уходят, я тоже уже подумываю уходить, нервов уже на все это не хватает. Так что лучше уж пачка небольших микросервисов, рост сложности которых ограничен, в которых низкий порог входа и есть возможность всегда найти людей для поддержки, и самое главное, в которых четко ограничена сфера ответственности, на уровне архитектуры, и при всем желании повысить связность и сложность ни у какого отдельного разработчика просто нет возможности. Самая большая беда, когда какой-нибудь не особо умный разработчик пытается срезать углы, прокладывая новые связи там, где их быть не должно - это наиболее сильно влияет на степень сложности и количество ошибок, и это возможно только в монолитной архитектуре, где разработчик ничем не ограничен и может творить грязь.
@@tomasddf Отличный комментарий по делу, испытал все это на своей шкуре
Я правильно понимаючто микросервисы возможны только со стороны сервера и только если программа сетевая. То есть программа которая устанавливается на телефон или компьютер пользователя она всегда монолитная и если ее надо обновить то надо пересобирать и перезаписывать всю программу и обновить чать программы на устройстве конечного пользователя не возможно?
совсем не обязательно что микросервсное приложение - сетевое.
Например возьмем Evernote.
Представим, что у него нет сетевых функций, но оффлайн функционал остался.
Таким образом, наше приложение (Evernote) может быть поделено на сервисы (Заметки, Календарь, фотографии, тудушка и пр..)
@@dmitryandreew8582 тогда это многомодульный монолит. Про это в видосе не сказали, но можно запилить монолит из нескольких модулей, где у одного модуля может быть даже несколько инстансов, если это понадобится. Разработка модулей ведется сравнительно раздельно, так при деплое можно пересобирать только изменившиеся модули, и можно спокойно разделить команды, чисто технически можно использовать разные языки с учетом того, что четко прописан будет не только API, но и ABI(конвенция вызовов), естсно это работает только для языков с одной платформы, например jvm, .net, llvm или просто компилируемые в машинно-зависимые бинарники
@@xtech3408 Спасибо за пояснения. С монолитами приходилось работать только на стадии раннего мвп и тестирования бизнес идей, посему никогда не копал так глубоко как вы.
@@dmitryandreew8582 И что тут глубокого продемонстрировано?
Очень не согласен с тем что только в монолите что то одно может сломать совсем другое.
На микро сервисной архитектуре словить данный аффект как делать нече, особенно когда микро сервисов только бэковых больше 150 штук. Тут только одной коммуникации становится в 150 раз больше, а потом представь что ты добавляешь какой то атрибут или артефакт не согласовав со смежниками, там еще и Куча сертов, токенов, по взаимодействию и куча транспорта и тд и тп 😂😂😂 сопровождать это довольно большое увеселение.
И это я еще молчу про поддержание консистентности данных, балансировку, георезераирование и тд. Там к этому еще прилагается бизнес сторона, где много всякого и интересного, а там еще есть такая штука как бесшовный переход с монолитной архитектуры на микро сервисы, то появляются риски тиражирования и тд и тп.
Легко и просто переход будет только на мелко средних проектах типа какого то авита. Действительно крупные штуки просто взять и перевести в микро сервисы очень больно, дорого и трудно. 😂😂😂
Спасибо за вашу работу! Очень хотелось бы увидеть ролик про брокеры сообщений)
По вопросу где лучше имхо для начала стоит рассмотреть структуру подразделений разрабов, вероятно, делить на отдельные репы стоит учитывая этот фактор, если у вас небольшая группа, фиг ли там городить микро?.. если у вас много больших команд, наверное стоит задуматься о гибридных вариантах… имхо.
Буду рад, если кто поправит и выскажет свои мысли
Я думаю что архитектура вторична. Попытки все описывать микросервисами - это в некотором роде преждевременная оптимизация. Софт живёт и развивается, и на каждом этапе к нему разные требования. В начале важнее стоимость запуска и сроки, чуть позже становится важнее уже стоимость поддержки и изменчивость, способность противостоять неконтролируемому росту сложности, сохранение низкого порога входа и возможность с лёгкостью находить людей для поддержки. Так что нет ничего плохого в том, что на разных этапах жизненного цикла у софта разная архитектура. Софт меняется исходя из изменения требований к нему: на каком-то этапе отдельные модули монолита так или иначе придется выделять в отдельные сервисы, частично или полностью независимые от монолита. Например на ранних этапах этого процесса к монолиту прикручивают внешние сервисы, такие как например эластик, и формируют вокруг них слой поддержки, а позже все это отпочковывается в отдельный проект, чтобы быть проще, надёжнее, и хорошо выполнять какую одну конкретную функцию
Большое спасибо за видео!
Мне понадобилось 48 часов...
типо это разные html файлы, которые обращаются друг к другу на разных лвлах?
не совсем понял суть микросервисов. Ну, да, удобнее работать над проджектом, но как их воссоединить?
Рано тебе ещё сюда. Лэндинги пили на реакте)
теперь про микрофронтеды пожалуйста
Видео о том, какой важный и нужный канал. Себя не похвалишь, никто не похвалит
А можно пожалуйста еще гачистов в мемы, плз?
Ну это в теории так работает. В реальности пишут монолиты и вяжут каким-нибудь нгинксом молясь на прокси
все объяснено простыми словами в доступной форме, огромное спасибо!
За МОНОЛИТ!
А куда делось видео про кубер?
Оно там же, где и прежде 🙂
а где исходник примера.
Как вывести текущую сессию авторизации например в пользовательскм интерфейсе? Когда они в разных микросервисах. При каждой загрузке сайта дергать другой сервис?
Так фронт разве тоже микросервисно делиться? Если использовать около микросервисную архитектуру (например NX monorepo), то там проблем особо вообще не будет с этим. Или я не правильно понял вопрос?
Это задача апи гейта - это отдельный микросервис, который снаружи виден как монолит с публичным апи, а внутри по факту является диспетчером для всех остальных микросервисов и общается с ними через их отдельные апи или очереди. Так что с этой стороны все ок, фронт получит сессию авторизации точно также, как получил бы ее в монолите. Ну а под капотом апи гейт собирает ответ для фронта из данных от множества других сервисов. Но он их не дёргает каждый запрос, т.к. в таких системах обязательно применяется многоуровневое кеширование: он эту сессию каждый запрос будет доставать из какого-нибудь быстрого кеша, так что по затратам это будет сравнимо с отдачей статики. Сервис авторизации в свою очередь будет контролировать этот кеш: воссоздавать его при авторизации и инвалидировать при деавторизации или истечении срока жизни сессии.
Монолиты хороши когда надо сделать что-то быстро и, скажем, протестировать какую-то бизнес-идею.
Собрал мвп, выплюнул в фокус группу / реальных пользователей и смотри как оно работает.
Работает - можем пилить на мс. Не работает - штош, не велика беда
болтуна видно сразу
@@andynaz7044 поделитесь своим мнением
Ура, новое видео!
Контент очень крутой, и полезный, как раз сейчас на работе занимаюсь тем что разбираю монолит, и переношу его на мса)
Нюхали как то “монолит”
Вы как всегда лучшие, обожаю смотреть ваши видео😂, так держать👍🏻🤝
А у меня микрозарплата
спасибо за видео
Мне как hr было полезно и понятно) спасиб)
Спасибо!😅
Большое спасибо за информацию.
микросервисы - микрослоники, напевал я , перенося полтерабайтные контейнеры со старого сервера на новый.
Специально кладу сайт, чтобы получить по жопе.
Да нет никаких раньше и сейчас - монолитная архитектура имеет право на существование и никуда не денется. Новый проект проще, быстрее и гораздо дешевле реализовывать через монолит, чтобы не так жалко было осознавать, что он не взлетел и загибается, ну а если выстрелит, нагрузки и прибыли поползут вверх - тогда уже имеет смысл переписать его на микросервисную архитектуру. 🤔
За монолит!
Ну девопсы не то чтобы прям легко с этим справляются 😂
Я сейчас только монолит и пишу. Допустим боты на Python
Хороший ролик, для понимания топ
Жаль, что вводит в заблуждение, выдает желаемое за действительное. Low coupling прекрасно возможен в монолите и нарушить его запросто можно и в микросервисах.
Микросервисы это в первую очередь история о том, что команда разработки начинает сильно превышать оптимум из 7-12 человек, по этому одна команда разбивается на несколько отдельных команд, которым надо независимо друг от друга уметь релизиться и вот тут микросервисы будут уже ой как кстати.
Как всегда годната
Спасибо за старания и контент. Грузим лукас.
Теперь хрен сделаешь магазин, стольким сервисам плотить, разве что наркоту продавать и то не везде, цены упали а сервисы умножились..
Монолиты это жесть, особенно если они были написаны 10+ лет назад и их не хотят обновлять
Еще и на скриптах 😅 кайф легаси, смерть развитию
Лол. Это как ругать родителей, что ты есть.
Монолит намного проще ,ACID из коробки и нет гемора с сетью между сервисами)
@@ЗайнудинГаджиев-р9з
А еще транзакционность поддерживать между запросами...
А еще всякие BFF для каждого микросервиса
А про общий shared код - вообще молчу) его педалят все... и ломается оно сразу у всех 😂
@@rayman4x4 программирование это не связь ребенка с родителем, здесь если ты не развиваешься - ты не просто стоишь на месте, а деградируешь
А есть смешанный формат? Типа и то и другое, плюсы одного и другого
Несколько не согласен, что в монолите все перекомпилировать и пересобирать. Даже элементарные более оптимальные построения классов позволяют компилить только то, что создано вновь либо модифицировано. Потом, почему речь идёт только о монолите и микро?.. а где гибриды, скажем проекты, взаимодействующие длл или иными способами? Сборка одного длл конечно подразумевает общую сборку проекта в деплой, но речь не идёт о компиле или сборки с нуля всей кодовой базы
Рассказали бы лучше про курс подробнее, а то ссылкой тычите уже год
Вы можете узнать детали пройдя по ссылке, или пройти вводный урок! 🙂
@@merionacademy там стандартный лендинг, ничего интересного
пройдите вводный урок, там будет интереснее! 🙂
5039 нах ) ps спасибо ребят за вашу работу очень познавательно
хорошее видео
пушка
Спешу всех расстроить , на курсах devoos вы не научитесь🎉
А что за курсы по devoos?
02:28; 02:57
Чувак, который создавал ролик видно какой-то программер?
Скажи мне мил человек где ты последний раз видел программера, который бы САМ что-то любил оптимизировать?
Может лет 20-25-30 назад были такие, которые были ограничены аппаратными ресурсами. Я вот например писал всякие системные штуки. Создатели игр тоже вынуждены были оптимизировать, потому чтобы в массы что-то пошло приходилось всё же двиги вылизывать. Но опять тут тоже ключевые слова ВЫНУЖДЕНЫ и ПРИХОДИЛОСЬ. Так за последующие 25 лет я ни разу не встретил разраба, который бы по своей воле что-то начинал оптимизировать. Конечно если писали какую-то уж очень дичь и какой-то запрос на кассе занимал по полминуты, то конечно некоторым ума хватало оптимизировать. Сегодня таких нет. Но зачем всем этим вообще заниматься? А давайте поделим всю эту хрень на кирпичи и всучим им совершенно другим кадрам. Пусть они мучаются. Как результат получили кучу новых технологий. Штук 12 точно, которые почему-то всем и сразу бывают нужны. Взаимозаменяемость? Не, не слышали. Написать в одном проекте? Не, тоже не слышали. И получается интересная вещь, что по сути все эти проблемы нагрузили на админов. Да да, тех самых самых обычных админов, которыем надо было с системой возиться, либо с сетью. Ну а кто бы ещё кроме них весь этот винигрет потянул? Проблема заключается ещё в том, что и классическое понимание каких-то инженеров, сисадминов, сетевиков изживает себя. Смотришь вакансию и не понимаешь, написано скажем хотят просто айти администратора, а вот функционал там как у начальника отдела поддержки по запуску ракет в космос. Или скажем позиция сисадмина, но функционал хотят тот же - работа с облаками, куча всяких кафок, докеров, шмокеров, кубернетисов. Так и хочется всех этих хитрозадых спросить - вам что в лом было написать что вы хотите вообще ДевОпса? Ну вы же Девелопера уже девелопером называете и от девелопера даже администрирования баз данных не требуете? В общем зажирается начальство в айти секторах. Если кто не понял поясню. Разница в зарплатах и нагрузке в разы. Потому никто даже правильно не пишет чего им надо на самом деле, но юзать тебя будут как девопса. Но есть ещё один нюанс. Даже если вы проработаете условно сисадмином на позиции для девопса, то вы даже в резюме своём это не сможете легально записать. В общем надеюсь понятно объяснил.
Добрый день! Отвечая на ваш вопрос касаемо разраба, которого мы видели и он любит что то оптимизировать - видели его в пятницу (2 дня назад) крайний раз!
@@merionacademyИ чего и зачем он пооптимизировал? Ну без подробностей конечно. Сегодня нет каких-то фанатиков или энтузиастов, которые будут пилить код до идеала. В основном все пашут чтобы просто работало. Конечно есть вспомогательные средства проверки кода, даже софт проверки на уязвимости, но по сути это так. Даже компании гиганты вроде Майкрософт, РедХат и т.д. этим не занимаются. А это как бы написание осей.
Добрый вечер! Отвечая на ваш вопрос: оптимизировал процесс планирования смен операторов!
@@merionacademy Да ладно. Мне то какое дело человеку с 27 годиками опыта и 10 годиками образования. Я просто высказал своё мнение. И в подтверждение моих слов можно послушать что тот же Гейтс когда-то говорил сколько памяти кому хватит, потом посмотреть на современные сначала десктоп системы с потреблением памяти, потом на всякий случай глянуть потребление последними версиями андроида и в конец посмотреть уже тех характеристики роутеров и их осей. Ни в одной области оптимизацией написанного кода и не пахнет. Ни один фактически компилятор не выдаёт оптимальный код (мингва более менее ещё). Да вообще как махина типа ВС размерами в 50 и более гигов инсталяшки может оптимально что-то собрать? Её саму надо оптимизировать и оптимизировать. А новое никто ничего не создаёт, нормальное, компактное, безопасное и быстрое. Потому код уже по определению не может быть нормальным.
Можете просто какую-то дичь рассказывать в таком стиле, всё равно буду смотреть и в ладоши хлопать!
Действуй бро
микрочл
Когда вместо "функционал" начнете использовать "функциональность", будет совсем хорошо )
Молодец, теперь возвращайся за парту, умник
@@arinazlatko5435 лососни моего тунца, детка. Я за партой был 27 лет назад.
@@arinazlatko5435 да поумнее тебя буду. И постарше. Это тут ты мнение имеешь, а на улице бы рот не открыла.
Я первый
⁶⁷⁹
Дурацкую музыку можно потише?
Извините, но ответ на ваш вопрос - нет, нельзя. Спасибо, что спросили!
Пока не прочёл комментарий, вообще не заметил что там музыка есть на фоне.
:)
@@merionacademy
@@merionacademy музыка тематическая и допустимая, но вас там не слышно, так что хотите берите ко сведению хотите нет
Дизлайк за вставочки-смехууечки. Это дно.
Что такое "дно"? пивнуха в Самаре? дизлайк за нипанятнае арго.
Спидран по микросервисам
Кликбейт!! Написано 8 минут, по факту 8 минут и одна секунда!
Везде ложь…
@@blackandyellow7125 не ложь а клади