@@НиколайКочубей-ы8э Я с канал буду видео про десктоп убирать. Так как я разочаловался в себе как в ютубере. Канал перепрофилирую как профессиональный дневник. Но топ будет. Изучал этот вопрос решил рассказать.
Бро, если тебя не затруднит, покажи как зайти с мобильника на сервер? на компе все настроил с первого раза без проблем, спокойно захожу на сервак и на андройд, в андройд поставил termux и openssh а зайти ни куда не могу, возможно там требуются не много другие настройки конфига...
Все зависит от того, какое приложение, насколько большое, насколько нагруженное будет. Бывают случаи, когда приложение помещается в один сервис-монолит и необходимости в микросервисах просто нет. Вообще если какой-то новый проект, то лучше его начинать как монолит и уже потом переходить на микросервисы, т.к. разработка монолита особенно на первых этапах (когда комада маленькая, непонятно какая нагрузка будет, и т.д.) намного быстре микросервисов. В ходе жизни приложение, если выростает нагрузка на определенные модули уже их выносить в отдельный микросервис. Ну и для интеграции с внешними системами тоже микросервисы подходят - каждая интеграция свой сервис. Какой-то идеальный архитектуры попросту нет, каждая архитктура хороша в определенный случаях и плоха в других. Все зависит от бизнеса, конкретного приложения, задачи и команды.
У вас была одна проблема, решили взять микросервисы, теперь у вас две проблемы: eventual consistency, SAGA и прочие паттерны распределенных систем ну и конечно же инструменты для оркестрирации.
Что важно в хорошем ютубере? A- хороший звук B- склонность автора к рефлексии B- интересный зрителю контент. Учитывая тематику этого канала - познавательный контент. Про линуксы очень интересно слушать почти что угодно: выгоду применений и пр. C- не панибратский визуальный стиль F- огонь в сердце ютубера рассказывающего о своём. ^ это мой личный порядок актуальности в хорошем канале. По мне, А...С - на великолепном уровне подачи. F - тоже есть, но он и не столь важен, когда остальное огонь.
Наконец кто-то объяснил разницу между микросервисами и сервисно-ориентированной архитектурой. Второе видел в банке, и не мог понять, что это, и чем отличается)
Потрясающий видос! Я как начинающий проджект впитала максимально легко, почти без проблем) Пришлось местами погуглить, и осталось пара вопросов, но это мелочи. Очень полезно! Спасибо!
Спасибо за информативное видео. Практически каждый тезис стоит того, что бы развернуть его в полноценное видео. Со своей же стороны позволю себе вставить следующее мнение: Не нужно путать монолит как способ разработки програмного обеспечения и монолитность как свойство систем. Основная проблема сегодняшних Enterprize(и не только!) приложений это сложность. Сегодня часто противопоставляют монолитам микросервисы, считая, что переписав проект с использованием микросервисов автоматически сделает систему менее сложной. К сожалению это не так. Можно представить себе микросервисы, которые являют собой монолитную систему, а можно написать монолит, который не обладает свойствами монолитности. Монолитность это такое свойство систем, не позволяющее изучать их по частям. Их можно изучать только целиком. При попытке их декомпозировать, тоесть разделить на отдельные части и изучить только помодульно, бесмысленно, потому что этот модуль сам по себе ничего не означает. Он означает только в связке с другими модулями и сам он с ними связан. Это плохо.
Я думал это включить, но потом решил рассказать более простым языком с позиции эксплуатации. Хорошее видео на этот счет есть у Жени @S0er возможно на втором канале. Он там рассказывает с позиции архитектора.
прям подсел на ваши видео, спасибо вам огромное. Сам пока новичок и всасываю все, что вы даете и подача у вас прям что надо, однозначно лайк, подписаться не могу, к сожалению, так как уже очень давно подписан :)
Монолит: 1. Обнаруженная ошибка в цельном приложении может положить его целиком. 2. Сборка тяжёлого цельного приложения после правки занимает ценное дорогое время. 3. Найти ошибку проще, чем при микросервисах. 4. Единая платформа, единый язык и технологии для всего приложения, сложно все переписать. Микросервисы: 1. Более удобное выделие участков логики для больших сложных приложений с возможностью раздельных реализаций. Подходит для больших команд, чтобы уменьшить взаимосвязи и влияние. Сборка происходит быстрее. Обновления проще, незаметнее и быстрее. 2. Необходимо мониторить ошибки в каждом сервисе, покрывать метриками/тестами всю функциональность, тк отказ или ошибка в сервисе неочевидна. 3. Бывает сложно распилить на независимые сервисы функционал и проще ему жить в монолите.
Спасибо за разъяснения! Пока смотрел ролик, не покидало ощущение что смотрю канал "Клуб рыбаков" с Михалычем... Уж очень вы похожи и внешне и по голосу... ;)))
как по мне весь бек нужно начинать писать в монолите (если не планируется высокая нагрузка), но при этом сохранять независимость модулей, чтоб при необходимости в любой момент без серьезных затрат перейти на микросервис
Cмысл топить всегда за микросервисы - это тот факт что если приложение придется масштабировать, то можно очень сильно пожалеть что сразу не начал микросервисы делать. Так же монолит если не маленький - то задолбаешься его разрабатывать в большой команде. Единственный смысл делать монолит - это если ты точно знаешь что приложение никогда не потребуется масштабировать(например pet-проект).
14:12 всм в монолитной архитектуре проще добавлять новый функционал? в микро легче же, потому что там можно обновлять отдельный сервис вместо всего приложения. P.s. я плохо разбираюсь) как раз написал, чтобы лучше понять
Спасибо за информацию. Очень полезно. К сожалению у меня опыт только в монолитах. Последнее время пытаюсь разобраться в микросервисной архитектуре и понять нужны они в работе или нет.
Я видел как распил монолита удорожал проект и при этом небыло выхлопа от этого. Просто микросервисов ради микросервисов. В итоге и поиск проблем увеличился и команды небыли раздроблены и разбили это на такие маленькие сервисы что отдельный микросервис был зависим причем сильно от других. Ужас ппц
@@pavlenkoat спасибо большое за информацию. Ваш комментарий заставил задуматься. Действительно не стоит делить монолит если нет постоянной команды и тем более аргументированного ответа на вопрос зачем? Как понимаю делить монолит надо в тех случаях, когда есть несколько команд и каждая которая отвечает за конкретный самодостаточный функционал. Или в тех случаях если есть самодостаточный функционал на который идёт большая нагрузка. Всё это Вы хорошо показали на видео. Ещё раз спасибо, что помогли понять.
Если разбить монолит на множество библиотек, то многие плюсы микросервисов перейдут и в плюсы монолита, да зачастую будут все лежать в одном месте, Но программирование это совершенствование новых технологий в виде перехода на облачные технологии на разные сервера, но концепция не меняется фронтенд бэкэнд бд связка остаётся неизменной
Эххх ... Попробуй копнуть теорию еще глубже. Тебе есть еще куда копать. Из важного что ускользнуло из твоего внимания: Одной из фундаментальных проблем концепции микросервисов являются накладные расходы железа на само существование этой концепции. Суть проблемы состоит в том что велична этих расходов может изменятся на много *ПОРЯДКОВ* без очевидных причин. Я лично не связывался бы с этой концепцией если проэкт не написан на языке go.
у меня для Вас новость, существует 8 архитектурных подходов в постороении приложения и понимая особенности каждого можно сделать заключение насколько точно будет подходить контейнеризция для того или иного подхода
Монолит + упрощенная разработка + проще развертывать + поддержка и поиск проблем проще + лучшая производительность - сложность внедрения новых технологий - кодовая база растет и порог вхождения тоже -+ масштабируемость Сервис - ориентированная архитектура + независимость развертывания и масштабируемости сервисов + изолирование бд под задачи + внедрение/отключение сервисов - централизованная логика - сложность в поиске проблем Микросервис + гетерогенность(независимый набор технологий)\ + независимость + децентрализованное управление данными + безопасность на уровне каждого сервиса + независимость команд - сложность проектирования - сложность устранения неполадок (необходимо правильно логировать весь комплекс и правильно его мониторить) - сложность тестирования
Благодарим Тебя за то, что раскрыл слугам Твоим козни врагов наших. Озари сиянием твоим души тех, кто отдал жизнь во исполнение воли Твоей. В бой, защитники Монолита! В бой! Отомстим за павших братьев наших, Да будет благословенно вечное их единение с Монолитом. Смерть! Лютая смерть тем, Кто отвергает Его священную силу!
пилю большой монолит, на самом деле, монолит потребляет очень много ресурсов. например 40 серверов полноценных с кодом монолита, плюс кластер мускула на 10 серверов. под микросервисы, 10 нод кубернетиса сейча, 5 нод кафки, 8 виртуалок для серверов бд микросервисов, где есть нагрузка. Обычно это NoSQL + CQRS. мысли про то, что начинать с мс архитектуры не нужно поддерживаю, без опытной слаженной команды это будет провал скорее всего. Хотя если есть опыт и крутая команда девопсов, и на микросервисах можно быстро выехать в прод. не медленнее монолита. но это дороже. однозначно дороже. нужно разрабов больше в несколько раз. и про деплой, деплоить микросервисы - быстро, а монолит долго, потому что когда монолит доживает до стадии - нужны микросервисы, он уже раздулся и горизонтально и вертикально ого-го как. интересно за два года взгляды на мс поменялись или еще нет? :)
Все верно вы пишите, достаточно опыта в большом монолите (а именно такими они со временем и становятся) и становится очевидно, что это заведомо не масштабируемое решение, которое подходит на начальном этапе жизни проекта. Но у автора адепты микросервисов - недалекие айтишнки, а монолит - это топ, и производительность и простота разработки и масштабируемость и т.п
Такое чувство, что автор только небольшие приложения писал. Упрощенная разработка в монолите ? Пока это первый месяц приложения - да, все можно сделать по-быстрому в рамках одного сервиса. Со временем, когда монолит обрастает логикой, появляется куча зависимостей, код становится связным, предвидеть последствия изменений становится сложно - придется думать о взаимодействии в рамках одного проекта. Масштабируемость?) Достаточно просто арендовать новый сервер?) Если для вас масштабируемость - это просто развернуть копию проекта, то да, но тогда это применимо и микросервисам. Кодовая база неконтролируемо разрастается и увеличивает сложность проекта, какая тут масштабируемость? Любой отказ в монолите - какого-либо хранилища, базы данных, редиса, диска - это отвал всего приложения. В микросервисах же максимум отвалится какая-то отдельная пользовательская функция. В общем, "недалекие айтишники" и большая часть рынка веб-разработки не просто так уходят сейчас от монолита.
В микросервисов ресурсы тратятся на преобразование в транзакции для обмена данными между сервисами, это неизбежно, лучше грамотный монолит чем корявый микросервис
Вообще Service-Oriented Architecture переусложнена и в целом уже мертва, честно говоря даже с Event Driven Architecture работать значительно проще, хотя и кажется сходу EDA, что простая, но сколько же я с ней пострадал.
А что про него рассказывать? Что это такое? Он на слуху. Применение? И так знаете где применять. Обзор? Никто не даст мне его показывать на живом сервере.
@@pavlenkoat Можно было бы просто рассказать что это, зачем и с чем его едят для совсем новичков-эникеев. Я понимаю что таких видео полно, но у вас отличная подача материала :) Спасибо за видео, кстати
О полезности материала уже в комментариях написано,напишу кое-что другое.Антон, в следующих видео, пожалуйста, вернитесь к старому формату съемки(камеру чуть дальше от лица), а то у меня при просмотре на ПК сложилось ощущение,что по ту сторону стола сидит начальник и за что-то ругает... Не приятное ощущение, стоит сказать...
А этим всем не системный архитектор должен заниматься? А то похоже, что девопс это и сисадмин, и опс инженер. А тут ещё и архитектура. Хотя может я путаю архитектуру с инфраструктурой
Это надо понимать. А так все зависит от организации. Я сисадминством например не занимаюсь. Занимается другой отдел. А вот понимать архитектуру и взоимрдействия сервисов мне надо. Да и без понимании архитектуры приложения не построишь инфраструктуру.
@@pavlenkoat Спасибо за ответ и за видео! Мне оно помогло структурировать то немногое, что я знал про микросервисы и монолит. А про сервис-ориентированную архитектуру вообще не знал :)
После просмотра видео жду твое мнения в комментарии. Спасибо.
А как же десктопный топ
@@НиколайКочубей-ы8э Я с канал буду видео про десктоп убирать. Так как я разочаловался в себе как в ютубере. Канал перепрофилирую как профессиональный дневник. Но топ будет. Изучал этот вопрос решил рассказать.
@@pavlenkoat где и когда
Бро, если тебя не затруднит, покажи как зайти с мобильника на сервер? на компе все настроил с первого раза без проблем, спокойно захожу на сервак и на андройд, в андройд поставил termux и openssh а зайти ни куда не могу, возможно там требуются не много другие настройки конфига...
@@pavlenkoat что думаете о минт
Монолит vs свобода vs долг
Все зависит от того, какое приложение, насколько большое, насколько нагруженное будет.
Бывают случаи, когда приложение помещается в один сервис-монолит и необходимости в микросервисах просто нет.
Вообще если какой-то новый проект, то лучше его начинать как монолит и уже потом переходить на микросервисы, т.к. разработка монолита особенно на первых этапах (когда комада маленькая, непонятно какая нагрузка будет, и т.д.) намного быстре микросервисов. В ходе жизни приложение, если выростает нагрузка на определенные модули уже их выносить в отдельный микросервис.
Ну и для интеграции с внешними системами тоже микросервисы подходят - каждая интеграция свой сервис.
Какой-то идеальный архитектуры попросту нет, каждая архитктура хороша в определенный случаях и плоха в других. Все зависит от бизнеса, конкретного приложения, задачи и команды.
Отлично!
Читал, смотрел и не понимал, пришёл сюда и наконец получил ответ что такое та как оно работает.
Спасибо!
Ваши видео достойно того, чтобы их активно распространять :)
У вас была одна проблема, решили взять микросервисы, теперь у вас две проблемы: eventual consistency, SAGA и прочие паттерны распределенных систем ну и конечно же инструменты для оркестрирации.
После третьего видео привык к мимике и дикции Антона и начал получать удовольствие от роликов, помимо полезной информации =)
Да, свой шарм.
Аналогично))
Я думал, что это запах сарказма.
больше таких видео! особенно с примерами сайтов и путями их построения. Именно то, что искал. Спасибо
Что важно в хорошем ютубере?
A- хороший звук
B- склонность автора к рефлексии
B- интересный зрителю контент. Учитывая тематику этого канала - познавательный контент. Про линуксы очень интересно слушать почти что угодно: выгоду применений и пр.
C- не панибратский визуальный стиль
F- огонь в сердце ютубера рассказывающего о своём.
^ это мой личный порядок актуальности в хорошем канале. По мне, А...С - на великолепном уровне подачи. F - тоже есть, но он и не столь важен, когда остальное огонь.
Наконец кто-то объяснил разницу между микросервисами и сервисно-ориентированной архитектурой. Второе видел в банке, и не мог понять, что это, и чем отличается)
Спасибо Антон! Как всегда с юмором и без воды))
Потрясающий видос! Я как начинающий проджект впитала максимально легко, почти без проблем)
Пришлось местами погуглить, и осталось пара вопросов, но это мелочи.
Очень полезно! Спасибо!
Спасибо за видео! очень важная тема
Спасибо что смотрите
Спасибо за информативное видео. Практически каждый тезис стоит того, что бы развернуть его в полноценное видео. Со своей же стороны позволю себе вставить следующее мнение:
Не нужно путать монолит как способ разработки програмного обеспечения и монолитность как свойство систем. Основная проблема сегодняшних Enterprize(и не только!) приложений это сложность. Сегодня часто противопоставляют монолитам микросервисы, считая, что переписав проект с использованием микросервисов автоматически сделает систему менее сложной. К сожалению это не так. Можно представить себе микросервисы, которые являют собой монолитную систему, а можно написать монолит, который не обладает свойствами монолитности. Монолитность это такое свойство систем, не позволяющее изучать их по частям. Их можно изучать только целиком. При попытке их декомпозировать, тоесть разделить на отдельные части и изучить только помодульно, бесмысленно, потому что этот модуль сам по себе ничего не означает. Он означает только в связке с другими модулями и сам он с ними связан. Это плохо.
Я думал это включить, но потом решил рассказать более простым языком с позиции эксплуатации. Хорошее видео на этот счет есть у Жени @S0er возможно на втором канале. Он там рассказывает с позиции архитектора.
прям подсел на ваши видео, спасибо вам огромное. Сам пока новичок и всасываю все, что вы даете и подача у вас прям что надо, однозначно лайк, подписаться не могу, к сожалению, так как уже очень давно подписан :)
Супер, спасибо, очень полезное видео.
Спасибо что смотрите
Монолит:
1. Обнаруженная ошибка в цельном приложении может положить его целиком.
2. Сборка тяжёлого цельного приложения после правки занимает ценное дорогое время.
3. Найти ошибку проще, чем при микросервисах.
4. Единая платформа, единый язык и технологии для всего приложения, сложно все переписать.
Микросервисы:
1. Более удобное выделие участков логики для больших сложных приложений с возможностью раздельных реализаций. Подходит для больших команд, чтобы уменьшить взаимосвязи и влияние. Сборка происходит быстрее. Обновления проще, незаметнее и быстрее.
2. Необходимо мониторить ошибки в каждом сервисе, покрывать метриками/тестами всю функциональность, тк отказ или ошибка в сервисе неочевидна.
3. Бывает сложно распилить на независимые сервисы функционал и проще ему жить в монолите.
Никогда бы не подумал, что аквамен будет учить меня программированию...
Очень хорошее видео (четко и понятно). Спасибо автору!
Отличный разбор темы!
Спасибо за разъяснения! Пока смотрел ролик, не покидало ощущение что смотрю канал "Клуб рыбаков" с Михалычем... Уж очень вы похожи и внешне и по голосу... ;)))
Спасибо. Все доходчивао объяснили с аргументами и фактами)
Хороший выпуск!. Регулярно смотрю Ваш канал
Спасибо большое
Алекстайм рассказывает мне про микросервисную архитектуру. До чего мы дожили, детка...
как по мне весь бек нужно начинать писать в монолите (если не планируется высокая нагрузка), но при этом сохранять независимость модулей, чтоб при необходимости в любой момент без серьезных затрат перейти на микросервис
Cмысл топить всегда за микросервисы - это тот факт что если приложение придется масштабировать, то можно очень сильно пожалеть что сразу не начал микросервисы делать. Так же монолит если не маленький - то задолбаешься его разрабатывать в большой команде. Единственный смысл делать монолит - это если ты точно знаешь что приложение никогда не потребуется масштабировать(например pet-проект).
Видео топчик, сижу готовлюсь к собесам)
14:12 всм в монолитной архитектуре проще добавлять новый функционал? в микро легче же, потому что там можно обновлять отдельный сервис вместо всего приложения.
P.s. я плохо разбираюсь) как раз написал, чтобы лучше понять
Спасибо огромное!!! Наконец благодаря вам я поняла что такое микросервисы 😅
Спасибо за информацию. Очень полезно. К сожалению у меня опыт только в монолитах. Последнее время пытаюсь разобраться в микросервисной архитектуре и понять нужны они в работе или нет.
Все зависит от проекта.
@@pavlenkoat Вы правы.
Я видел как распил монолита удорожал проект и при этом небыло выхлопа от этого. Просто микросервисов ради микросервисов. В итоге и поиск проблем увеличился и команды небыли раздроблены и разбили это на такие маленькие сервисы что отдельный микросервис был зависим причем сильно от других. Ужас ппц
@@pavlenkoat спасибо большое за информацию. Ваш комментарий заставил задуматься. Действительно не стоит делить монолит если нет постоянной команды и тем более аргументированного ответа на вопрос зачем?
Как понимаю делить монолит надо в тех случаях, когда есть несколько команд и каждая которая отвечает за конкретный самодостаточный функционал.
Или в тех случаях если есть самодостаточный функционал на который идёт большая нагрузка.
Всё это Вы хорошо показали на видео. Ещё раз спасибо, что помогли понять.
@@kor-elf Плюс код сложно поддерживать. Но да микросервис отличается тем что он практически независим
Очень хорошо объяснили. Все понятно. Спасибо!
Какой же вы классный и харизматичный!)) Спасибо за актуальную тему) собес через полчаса, я аналитик, надо обновить понимание)
Спасибо.
Спасибо за доступное для планктона объяснение
Огромное спасибо, очень полезная информация!
Очень крутое видео, все супер разжеванно, спасибо большое за труды!
Пожалуйста.
Так, ютаб, я не понял какого куя нет уведомлений? Колокольчик стоит
Тут выход только телеграмм канал)))
Интересная тема, вдохновила на создание своих сервисов
Было полезно и интересно. Спасибо!
Это было интересно. Можно раскрыть эту тему более глубоко? Какие технологии и так далее
Спасибо. Можно более подробно. Технологии для чего? Для написания сервисов? Они разные.
Если разбить монолит на множество библиотек, то многие плюсы микросервисов перейдут и в плюсы монолита, да зачастую будут все лежать в одном месте, Но программирование это совершенствование новых технологий в виде перехода на облачные технологии на разные сервера, но концепция не меняется фронтенд бэкэнд бд связка остаётся неизменной
Год уже в вашем линукс чате и только что узнал что у вас есть ютуб канал
Прикольно
У меня на самом деле 2 канала
Эххх ... Попробуй копнуть теорию еще глубже. Тебе есть еще куда копать.
Из важного что ускользнуло из твоего внимания:
Одной из фундаментальных проблем концепции микросервисов являются накладные расходы железа на само существование этой концепции. Суть проблемы состоит в том что велична этих расходов может изменятся на много *ПОРЯДКОВ* без очевидных причин.
Я лично не связывался бы с этой концепцией если проэкт не написан на языке go.
Можно пример пресловутого "масштабирования функционала"?
Кайф, спасибо! Лучший ролик с прекраснейшими примерами
Спасибо за интересный ролик!
Подалуйста
Как раз размышлял по поводу разбиения сайта на севисы, спасибо за инфу
Сразу говорю это абстрактный пример. Декомпазировать надо аккуратно и в большинстве своем это делают с проблемным и часто изменяющимся функционалом.
Всем привет. Дайте, пожалуйста, ссылку на телегу
у меня для Вас новость, существует 8 архитектурных подходов в постороении приложения и понимая особенности каждого можно сделать заключение насколько точно будет подходить контейнеризция для того или иного подхода
Это не новость)))) возможно когда-нибудь и остальных расскажу. Просто видео и так длинное получилось
Выбираю горизонтально масштабируемый и гибко конфигурируемый монолит. Это моё "Пепси"!
Монолит
+ упрощенная разработка
+ проще развертывать
+ поддержка и поиск проблем проще
+ лучшая производительность
- сложность внедрения новых технологий
- кодовая база растет и порог вхождения тоже
-+ масштабируемость
Сервис - ориентированная архитектура
+ независимость развертывания и масштабируемости сервисов
+ изолирование бд под задачи
+ внедрение/отключение сервисов
- централизованная логика
- сложность в поиске проблем
Микросервис
+ гетерогенность(независимый набор технологий)\
+ независимость
+ децентрализованное управление данными
+ безопасность на уровне каждого сервиса
+ независимость команд
- сложность проектирования
- сложность устранения неполадок (необходимо правильно логировать весь комплекс и правильно его мониторить)
- сложность тестирования
Расскажите про паттерн(антипаттерн?) "Распределенный монолит"
Благодарим Тебя за то,
что раскрыл слугам Твоим
козни врагов наших.
Озари сиянием твоим
души тех, кто отдал жизнь
во исполнение воли Твоей.
В бой, защитники Монолита! В бой!
Отомстим за павших братьев наших,
Да будет благословенно
вечное их единение с Монолитом.
Смерть! Лютая смерть тем,
Кто отвергает Его священную силу!
Спасибо, очень полезно!
Микросервисы получается - это для крупного бизнеса?
Отлично обьясняете. Спасибо!
В подписи ко второму плюсу монолита ошибка в слове "простота". Нужно через А. А так все круто!
Спасибо. Недоглядел
@@pavlenkoat вам спасибо за видосы!
Я думал это фишка такая - Упращенная, Маштабирование)
Спасибо! Очень хорошая философия. Удивително как она похожа на суету вокруг ядер
На самом деле да. По большей степени пофиг какая у тебя архитектура главное что ты зарабатываешь на этом всем.
Хорошо когда SOAP знаешь только в теории и только в теории.
Я на практике поддерживал
@@pavlenkoat позвольте узнать для интереса, чем вы wsdl генерировали?
Кастомный модуль был.
Спасибо за отличное информативное видео!
пилю большой монолит, на самом деле, монолит потребляет очень много ресурсов. например 40 серверов полноценных с кодом монолита, плюс кластер мускула на 10 серверов. под микросервисы, 10 нод кубернетиса сейча, 5 нод кафки, 8 виртуалок для серверов бд микросервисов, где есть нагрузка. Обычно это NoSQL + CQRS. мысли про то, что начинать с мс архитектуры не нужно поддерживаю, без опытной слаженной команды это будет провал скорее всего. Хотя если есть опыт и крутая команда девопсов, и на микросервисах можно быстро выехать в прод. не медленнее монолита. но это дороже. однозначно дороже. нужно разрабов больше в несколько раз.
и про деплой, деплоить микросервисы - быстро, а монолит долго, потому что когда монолит доживает до стадии - нужны микросервисы, он уже раздулся и горизонтально и вертикально ого-го как.
интересно за два года взгляды на мс поменялись или еще нет? :)
Все верно вы пишите, достаточно опыта в большом монолите (а именно такими они со временем и становятся) и становится очевидно, что это заведомо не масштабируемое решение, которое подходит на начальном этапе жизни проекта.
Но у автора адепты микросервисов - недалекие айтишнки, а монолит - это топ, и производительность и простота разработки и масштабируемость и т.п
премьера, расходимся
Почему? Я тут.
Очень толковое видео!
Спасибо
шикарне пояснення👍
Спасибо. Что ещё по этой теме интересно?
Возможно любовь к микросервисам вызвана принципом из unix - каждая программа должна делать что-то одно.
Мне тоже нравится этот подход, но я понимаю что он не всегда оправдан
Спасибо. Все очень понятно.
Такое чувство, что автор только небольшие приложения писал.
Упрощенная разработка в монолите ? Пока это первый месяц приложения - да, все можно сделать по-быстрому в рамках одного сервиса.
Со временем, когда монолит обрастает логикой, появляется куча зависимостей, код становится связным, предвидеть последствия изменений становится сложно - придется думать о взаимодействии в рамках одного проекта.
Масштабируемость?) Достаточно просто арендовать новый сервер?) Если для вас масштабируемость - это просто развернуть копию проекта, то да, но тогда это применимо и микросервисам.
Кодовая база неконтролируемо разрастается и увеличивает сложность проекта, какая тут масштабируемость?
Любой отказ в монолите - какого-либо хранилища, базы данных, редиса, диска - это отвал всего приложения. В микросервисах же максимум отвалится какая-то отдельная пользовательская функция.
В общем, "недалекие айтишники" и большая часть рынка веб-разработки не просто так уходят сейчас от монолита.
В микросервисов ресурсы тратятся на преобразование в транзакции для обмена данными между сервисами, это неизбежно, лучше грамотный монолит чем корявый микросервис
Вы не можете масштабировать монолит или можете 🤣🤣🤣 топчик
наконец понял что это за такая священная корова у многих ит-манагеров
У манагеров она просто модно можно продать
Оч хорошее объяснение , спасибк
Спасибо! Все четко и по делу.
Пожалуйста.
Шикарный видос
Модульная архитектура, альтернатива микросервисной, все же лучше монолита и тоже может писаться на разных языках
Спасибо за видео! осталось выйти из зоны комфорта и свалить с windows админа =(
Пожалуйста.
Вообще Service-Oriented Architecture переусложнена и в целом уже мертва, честно говоря даже с Event Driven Architecture работать значительно проще, хотя и кажется сходу EDA, что простая, но сколько же я с ней пострадал.
микросервисы это такое Гггг, 500 раз один и тот же api запрашивать при каждом чихе (((
Очень не хватает примеров настоящих приложений с разными архитектурами
а, я-то подумал, что речь идёт про архитектуры ядер...
Я уже до железа в проф деятельности не опускался давно.
@@pavlenkoat -- ну, я имел ввиду архитектуры ядер операционных систем, я невнятно высказался вначале ;)
Ааааа. На самом деле все похоже. Линус доказал что главное чтобы все работало.
@@pavlenkoat -- похоже ;) именно поэтому и мелкомягкие, и яблочники имеют гибридную архитектуру.
на 2:38 - какая разработка? :)
Отличное видео
Спасибо
Антон , может сделаете видео по Дженкинсу? было бы здорово
А что про него рассказывать? Что это такое? Он на слуху. Применение? И так знаете где применять. Обзор? Никто не даст мне его показывать на живом сервере.
@@pavlenkoat Можно было бы просто рассказать что это, зачем и с чем его едят для совсем новичков-эникеев. Я понимаю что таких видео полно, но у вас отличная подача материала :)
Спасибо за видео, кстати
На канале ADV-IT есть
ruclips.net/p/PLg5SS_4L6LYvQbMrSuOjTL1HOiDhUE_5a
Полезно. Спасибо
Пожалуйста.
Спасибо за видео.
Пожалуйста.
Спасибо!!
serverless архитектуру забыли
Супер
Отличная вводная!
Спасибо.
Разве девопс выбирает архитектуру сервиса ?
В большинстве своем Нет. Но понимать что зачем должен и влиять может на решения. Правда это в нормальных компаниях.
Микросервисы это и есть SOA, доведенная до абсудра.
Хороший материал
2:38 Как ИПшник в РФ, знаю только слово упрОщенная.
Очень хорошее объявление
Спасибо
О полезности материала уже в комментариях написано,напишу кое-что другое.Антон, в следующих видео, пожалуйста, вернитесь к старому формату съемки(камеру чуть дальше от лица), а то у меня при просмотре на ПК сложилось ощущение,что по ту сторону стола сидит начальник и за что-то ругает... Не приятное ощущение, стоит сказать...
Пока не могу объектив сменил теперь ремонт надо делать.
@@pavlenkoat понятно :(
В последних видео отодвинулся немного.
@@pavlenkoat вот теперь в самый раз
🖤💣💥
Модульный Монолит.
Можно и так
До ньюмена про микросервисы куча народа говорила. Афтор конечно кое как в теме
Спасибо
спасибо!
Грамотное объяснение.
А этим всем не системный архитектор должен заниматься?
А то похоже, что девопс это и сисадмин, и опс инженер. А тут ещё и архитектура. Хотя может я путаю архитектуру с инфраструктурой
Это надо понимать. А так все зависит от организации. Я сисадминством например не занимаюсь. Занимается другой отдел. А вот понимать архитектуру и взоимрдействия сервисов мне надо. Да и без понимании архитектуры приложения не построишь инфраструктуру.
Я могу простой пример привести. Без умения читать чертежи ты деталь не вытачешь.
@@pavlenkoat
Спасибо за ответ и за видео!
Мне оно помогло структурировать то немногое, что я знал про микросервисы и монолит. А про сервис-ориентированную архитектуру вообще не знал :)
Пожалуйста
На самом деле ответ на собеседовании для девопсов максимум в 3 предложениях. В видео раскрыл тему для большего понимания