G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
В том, что можно отвязать циклы разработки свистоперделок от ключевой функциональности.
Не работает звук "врруууууум" при запуске двигателя — и фиг бы с ним, голова пусть болит у разработчика сервиса, который этот звук подгружает.
G>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Да.
Это очень важное преимущество для "менеджеров среднего звена". Видишь ли, менеджер одного программиста, это... не круто. И денег немного.
То ли дело, менеджер у сотни.
SD>Это прошлый век. SD>Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает. Но только у части юзеров, и только часть функциональности. Скажем, не подгружается третья сверху строчка пикселей видеофайла, у жителей Новой Зеландии.
Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
Вопрос в ответственном отношении к работе.
Хотя, для детских проектов с тремя пользователями сойдет.
Здравствуйте, SkyDance, Вы писали:
SD> Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает.
Так в любом проде в любой момент времени где-то что-то не работает. Docker здесь только множит как количество проблем, так и их качество. И если с количеством еще можно как-то бороться, то их качество выводит стоимость эксплуатации на совсем другой уровень.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
можно вообще без всего, и без этого тоже, и без вопросов зачем можно тоже можно. Это инструмент. Используется тогда, когда необходимо решать задачи, которые он решает — фиксация бинарного окружения для проекта. Шеридана слушать не надо, у него знания уровня селюка-настройщика один-эсс и программиста экселя. Докер очень удобен, я просто тащусь. Никогда деплой не был таким лёгким. Господь расплакался когда увидел докер.
Микросервисы нужны только там где необходимо горизонтальное масштабирование. Во всех других случаях профита меньше чем геморроя.
Здравствуйте, namespace, Вы писали:
N>Вопрос в ответственном отношении к работе.
N>Хотя, для детских проектов с тремя пользователями сойдет.
умение допускать некоторый контролируемый уровень фейлов и за счёт этого иметь гораздо больше архитектурной свободы это гораздо круче умения их вообще не допускать. Но это умение обычно нужно в очень крутых проектах, на миллионы пользователей.
Здравствуйте, Мирный герцог, Вы писали:
N>>Хотя, для детских проектов с тремя пользователями сойдет. МГ>умение допускать некоторый контролируемый уровень фейлов и за счёт этого иметь гораздо больше архитектурной свободы это гораздо круче умения их вообще не допускать. Но это умение обычно нужно в очень крутых проектах, на миллионы пользователей.
Ну да, ну да. Правильно ли я понял, что для проектов с миллионом пользователей нужно стараться, а для всего остального —
?
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
Ой не факт.
Например, AI с какой-то хитровывернутой логикой может писать команда, которая с java не дружит, а на python пишет привычно. Какую-нибудь другую логику может писать другая команда уже на java. Попытка же найти, собрать и организовать единую команду, которая пишет именно то, что нужно именно на том, на чем хочется — может вылиться в огромный геморрой.
И может оказаться, что состыковать между собой зоопарк разных технологий (не обязательно именно через микросервисы, а возможно и каким-то другим способом, например через адаптеры) — это меньшее из зол.
Здравствуйте, Vetal_ca, Вы писали:
V_>так кроме программ там еще БД, прокси, message brokers и куча всего прочего, уже кем-то написанного. Они уже есть и написаны на разных языках
Только это НЕ микросервисная ахитектура.
Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Здравствуйте, SkyDance, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
SD>В том, что можно отвязать циклы разработки свистоперделок от ключевой функциональности. SD>Не работает звук "врруууууум" при запуске двигателя — и фиг бы с ним, голова пусть болит у разработчика сервиса, который этот звук подгружает.
А что мешает добиться того же в обычной программе? Речь тоько об ингорировании ошибок вызовов некоторых функций.
Б>>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>>Но дешевле все сделать на одном языке. На той же java.
K>Ой не факт.
Не факт. Но матожидание (красивое слово для "среднего") стоимости монолитной программы на java будет ниже, чем программы на нескольких языках.
K>Например, AI с какой-то хитровывернутой логикой может писать команда, которая с java не дружит, а на python пишет привычно.
В соучае с AI такие проблемы уже решены. Можно создавать и обучать модель на python, а дергаеть её из кода на java. Модель по факту вообще можно зааутсорсить.
K>Какую-нибудь другую логику может писать другая команда уже на java. Попытка же найти, собрать и организовать единую команду, которая пишет именно то, что нужно именно на том, на чем хочется — может вылиться в огромный геморрой.
Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад.
K>И может оказаться, что состыковать между собой зоопарк разных технологий (не обязательно именно через микросервисы, а возможно и каким-то другим способом, например через адаптеры) — это меньшее из зол.
Вопрос не в стыковке. Это как раз не сложно.
Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах.
Здравствуйте, gandjustas, Вы писали:
Б>>Профит микросервисов в их независимости друг от друга: G>Я тоже слышал эти лозунги, но преимущества в чем?
Преимущество — можно раздуть размер команды на ровном месте, обосновать заказчику и в результате получить с него много денег. Это если массовое применение. Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени.
Здравствуйте, gandjustas, Вы писали:
G>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Несколько примеров,
— чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся.
Да, можно это сделать в коде, но
1) Зачем, если есть отлаженный инструмент
2) Не упереться в вертикальный лимит
3) разный уровень сервиса или надежность. Что-то работает постоянно, что-то перезагружается/падает.
У нас, например, проблема с одним из powershell модулей ms-online. В нем внутри утечка. Индусы про это "знают" уже годами. Не падать же всему приложению. Вот и работает как набор отдельных Workers, освобождается на уровне процесса по сигналу health check.
Это прекрасно работает. А если бы ждали по заветам Шеридана, то до сих пор бы ждали пока починят, поляна бы заросла продуктами конкурентов. Которые гонят отсталых сельских админов-идеалистов на периферию.
Здравствуйте, elmal, Вы писали:
E>Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени.
А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, gandjustas, Вы писали:
G>>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
V_>Несколько примеров, V_>- чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся.
Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
V_>Да, можно это сделать в коде, но V_>1) Зачем, если есть отлаженный инструмент V_>2) Не упереться в вертикальный лимит V_>3) разный уровень сервиса или надежность. Что-то работает постоянно, что-то перезагружается/падает.
Про какой код речь?
V_>У нас, например, проблема с одним из powershell модулей ms-online. В нем внутри утечка. Индусы про это "знают" уже годами. Не падать же всему приложению. Вот и работает как набор отдельных Workers, освобождается на уровне процесса по сигналу health check. V_>Это прекрасно работает. А если бы ждали по заветам Шеридана, то до сих пор бы ждали пока починят, поляна бы заросла продуктами конкурентов. Которые гонят отсталых сельских админов-идеалистов на периферию.
Как в этом случае поможет микросервисная архитекктура?
Я напомню что речь именно об архитектуре когда разработчики разбивают свое приложение на слабосвязанные сервисы, которые могут работать по-отдельности. Это не тоже самое что деплоить пару-тройку компонентов приложения в контейнерах.
V_>Это пара примеров, причин больше, на самом деле.
К соажлению даже эта пара примеров не является достаточно внятным обоснованием для микросервисов. Имхо конечно.
Здравствуйте, gandjustas, Вы писали:
G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
То мешает, что узким местом является определенный код. Соответственно то, что является узким местом, нужно оформлять как микросервис, чтоб там было ничего лишнего, и далее масштабировать. Но вообще, ключевое, даже сейчас умные люди на докладах рассказывают что успешные архитектуры — это сначала монолит, а далее этот монолит, когда скорости не хватает — пилят на микросервисы. Таким образом экономится куча времени и денег. Но сейчас толпы народа сразу хреначат микросервисы, и в результате время разработки, количество команд и стоимость возрастает в разы, а то и десятки раз. Но аутсорсу это выгодно, потому сейчас аутсорс монолиты не предлагает, предлагают сразу микросервисы и огромные команды по 100 человек там, где справились бы и 5 за меньшее время .
Здравствуйте, gandjustas, Вы писали:
E>>Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени. G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
1. Микросервисов не существует.
2. Сервисная архитектура позволяет, прежде всего, позволяет очень чисто разделять ответственность между разными командами.
Здравствуйте, gandjustas, Вы писали:
G>Только это НЕ микросервисная ахитектура. G>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Я вот тут плюсану. Уже на этапе проектирования микросервисов приходишь к выводу, как правило, что нужно просто монолит горизонтально масштабировать... При этом монолит может быть распределен по контейнерам вполне. И наброшу немного: DDD рулит!
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Б>Профит микросервисов в их независимости друг от друга:
Полная независимость возможна только если сервисы друг друга не вызывают.
Если кто-то может делить приложение на слабосвязные части, зачем после этого выносить эти части в отдельные процессы?
Б>- можно создавать на разных языках/платформах, упрощается дизайн сервисов
Дизайн приложения как целого, состоящего из множества микросервисов, как раз усложняется.
И кроссервисные рефакторинги в будущем будут на порядок сложнее, чем внутри "мАкросервиса".
Возможность писать на разных языках/платформах на практике нужна примерно никогда, работодатели обычно наоборот стремятся все унифицировать, чтобы сделать разработчиков взаимозаменяемыми.
Б>- можно гибко масштабировать — увеличивать количество только нужных сервисов
На первый взгляд звучит как что-то умное. Но в чем преимущество перед масштабированием "мАкросервиса"?
G>Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
Если приложение небольшое, то можно. Если большое, то понимание придет само в процессе преодоления проблем роста и разбивания монолита
G>Про какой код речь?
Приложение и вспомогательные сервисы.
G>Как в этом случае поможет микросервисная архитекктура? G>Я напомню что речь именно об архитектуре когда разработчики разбивают свое приложение на слабосвязанные сервисы, которые могут работать по-отдельности. Это не тоже самое что деплоить пару-тройку компонентов приложения в контейнерах.
Микросервис A работает. А микросервис B, его workers, перегружаются по мере накопления утекшей памяти. Никак не влияя на работоспособность A.
Если бы это был один монолитный процесс, то на момент периодической перезагрузки приложение было бы недоступно.
G>К соажлению даже эта пара примеров не является достаточно внятным обоснованием для микросервисов. Имхо конечно.
Если текущая задача не требует, то переусложнять "на вырост" не нужно.
