Привет. Хотел бы накинуть тем, которых мало в сети и которые приходится вычленять из выступлений на конференциях. А именно - некоторые нюансы "взрослой разработки". Например моменты с накаткой данных, локальной разработкой/работой на стенде, отличия, когда пилишь проект до UAT(мой случай) и когда у же есть прод и как происходит общение с командой сопровождения. В общем, утрированно - я джун с маленьким коммерческим опытом, собесы достаются трудно (всем нужен опыт), а хочется развиваться не как вкатыш, а используя в петах в перерывах между редкими собесами "взрослые" подходы.
Есть ещё вариант разбить компанию на множество мелких и каждая сама по себе... А ещё послать всех поехать в тайгу поселиться там в лесу, построить дом завести хозяйство и жить... И катись все куда подальше вместе со своими микросервисами и прочей лабудой! Вот...
Так он ничего нового не сказал. Разбить 1 большую задачу на небольшие подзадачи. Помню кино было такое когда одному полководцу древнеримскому предложили сломать колчан со стрелами... он пыжился пыжился никак. А потом предложи это ребёнку... А он просто взял и перелоомал весь колчан по 1-ой стреле... оч показательный пример. Вот это как раз об этом! Так я о чём? Хорошо было там в древнем Риме-то! Никаких тебе микросервисов... Только с лука научиться стрелять надо. Но это легко...
Какой шладкий, вдул бы! Спасибо за видео! Полезно! На хайпе залетели и распили наш php на микросервисы от golang по этому часть вернули назад в монолит, не всегда нужн овсе разбивать на кучу сервисов, в общем в меру все нужно.
Видео полная ерунда. Автор заучил какую-то методичку и цитирует её. На практике плюсы и минусы двух архитектур зависят от рук людей, которые выстраивают эту архитектуру. Я работаю в монолитном проекте и у нас не падает всё приложение если какой-то кусок монолита недоступен
Сомнительно, но окэй) P.s. Я работал с обеими архитектурами, методички мне не нужны. Под недоступностью имелась ввиду недоступность всего сервиса (приложения)
@@kismichel17 ну вот в нашем монолите все приложение не падает, даже если, например, корневая база данных ложится . У нас есть вторая, для кэширования и на случай падения основной. А что будет , если в микросервтсах умрет сервис авторизации и протухнут все токены и ни один пользователь не сможет выполнить действие в приложении? Тоже рухнет, если архитекторы не позаботятся о такой ситуации
Это как раз идеальный кейс для демонстрации плюсов в отказоустойчивости микросервисов) Для критически важных сервисов создаем несколько реплик и разворачиваем их в независимых дата-центрах
Я имел ввиду ситуацию, когда, например, возникает критическая ошибка по типу OOM и сервису нужно перезапуститься, как минимум В случае с монолитом будет даунтайм, в микросервисах трафик будут обрабатывать оставшиеся в балансировке реплики Понятно, что и тут можно поспорить, ведь можно иметь несколько реплик монолита. Но если приложение действительно большое, это будет крайне неэффективно по потреблению ресурсов
Сделай, плиз, видео про мавен, прям полный разбор, про плагины его и т.п.)
Делаешь отличный и полезный контент, продолжай.
Привет. Хотел бы накинуть тем, которых мало в сети и которые приходится вычленять из выступлений на конференциях. А именно - некоторые нюансы "взрослой разработки". Например моменты с накаткой данных, локальной разработкой/работой на стенде, отличия, когда пилишь проект до UAT(мой случай) и когда у же есть прод и как происходит общение с командой сопровождения. В общем, утрированно - я джун с маленьким коммерческим опытом, собесы достаются трудно (всем нужен опыт), а хочется развиваться не как вкатыш, а используя в петах в перерывах между редкими собесами "взрослые" подходы.
Привет) Важные темы, добавил в список для будущих роликов
Привет, как оно ? Спустя 6 месяцев попал куда-нибудь ?
@@tinkerhowtolosetinkerhowto5106 Привет. Нет (
дела индейцев шерифа не интересуют
@@tinkerhowtolosetinkerhowto5106
"Это уже не сомнительно и это уже не окей" 🤣
Есть ещё вариант разбить компанию на множество мелких и каждая сама по себе... А ещё послать всех поехать в тайгу поселиться там в лесу, построить дом завести хозяйство и жить... И катись все куда подальше вместе со своими микросервисами и прочей лабудой! Вот...
Первый вариант уже давно активно используется)
Блин ты супер 🙌 жду твои видосы с нетерпением
Спасибо ☺️🙏
Так он ничего нового не сказал. Разбить 1 большую задачу на небольшие подзадачи. Помню кино было такое когда одному полководцу древнеримскому предложили сломать колчан со стрелами... он пыжился пыжился никак. А потом предложи это ребёнку... А он просто взял и перелоомал весь колчан по 1-ой стреле... оч показательный пример. Вот это как раз об этом! Так я о чём? Хорошо было там в древнем Риме-то! Никаких тебе микросервисов... Только с лука научиться стрелять надо. Но это легко...
дождался?
О что-то новенькое)))))))))))))))))
Даа, скоро ещё видос про алгоритмы)
Эээ, а что, с прыщами уже на ютуб пускают? 😮
Это моя изюминка, ты не шаришь)
@stanislavp1982 какой низкий комментарий
🤡
Какой шладкий, вдул бы! Спасибо за видео! Полезно! На хайпе залетели и распили наш php на микросервисы от golang по этому часть вернули назад в монолит, не всегда нужн овсе разбивать на кучу сервисов, в общем в меру все нужно.
Видео полная ерунда. Автор заучил какую-то методичку и цитирует её. На практике плюсы и минусы двух архитектур зависят от рук людей, которые выстраивают эту архитектуру. Я работаю в монолитном проекте и у нас не падает всё приложение если какой-то кусок монолита недоступен
Сомнительно, но окэй)
P.s. Я работал с обеими архитектурами, методички мне не нужны. Под недоступностью имелась ввиду недоступность всего сервиса (приложения)
@@kismichel17 ну вот в нашем монолите все приложение не падает, даже если, например, корневая база данных ложится . У нас есть вторая, для кэширования и на случай падения основной.
А что будет , если в микросервтсах умрет сервис авторизации и протухнут все токены и ни один пользователь не сможет выполнить действие в приложении? Тоже рухнет, если архитекторы не позаботятся о такой ситуации
Это как раз идеальный кейс для демонстрации плюсов в отказоустойчивости микросервисов)
Для критически важных сервисов создаем несколько реплик и разворачиваем их в независимых дата-центрах
Я имел ввиду ситуацию, когда, например, возникает критическая ошибка по типу OOM и сервису нужно перезапуститься, как минимум
В случае с монолитом будет даунтайм, в микросервисах трафик будут обрабатывать оставшиеся в балансировке реплики
Понятно, что и тут можно поспорить, ведь можно иметь несколько реплик монолита. Но если приложение действительно большое, это будет крайне неэффективно по потреблению ресурсов
@@kismichel17 вот и в монолите также, можно сделать запасной аэродром