Здравствуйте, Kolesiki, Вы писали:

K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Пытаться уличить человека, что он гонит дичь и, при этом, гнать дичь самому — конфуз .

Здравствуйте, Ночной Смотрящий, Вы писали:

E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.
НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
E>> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
НС>Нет, не готова.

а где аргументация?

Здравствуйте, Privalov, Вы писали:

P>Похоже, я отстал от жизни. Математики, с которыми я работал, писали исключительно на Фортране. Как их удалось пересадить на Питон?
Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.

Здравствуйте, Kolesiki, Вы писали:

K>Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.

Как раз масштабироваться проще, а балансировкой нагрузки может заниматься сама ОС. Я, например, разбивал систему видеонаблюдения на множество сервисов, каждый из которых занимался анализом видео с отдельной видеокамеры и записывал архив. Система стала легко масштабироваться и выиграла в надёжности: сбои, к сожалению, могут случаться и в этом случае просто перезапускался процесс, занимающийся анализом с конкретной видеокамеры. Надо больше камер? Ставим больше серверов. Стало реально проще.

Здравствуйте, Nikita Lyapin, Вы писали:

NL>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.

Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, elmal, Вы писали:

E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.

НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.

Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.

Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?
В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс).
Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).

Микросервисы это инструмент позволяющий увеличить связанность и уменьшить зацепление на верхнем уровне архитектуры.
Высокая связность и низкое зацепление показатель качества любой архитектуры.
Микросервисы позволяют уменьшить не только design-time, но и run-time зацепление.

Здравствуйте, Cyberax, Вы писали:

NL>>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
C>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.

Почему?
И как делать без транзакций?

Здравствуйте, De-Bill, Вы писали:

S>>Зачем все это? Ради чего?

DB>Чаще всего это resume driven development. Но в некоторых случаях бывает и реально полезно.

Никогда такого выражения не слышал. Оно?

résumé driven development
when you ignore requirements and pick implementation approaches based on how good they look on your resume.

Здравствуйте, MadHuman, Вы писали:

MH>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.

У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл...
Поубивал бы!!!

Здравствуйте, klopodav, Вы писали:

K>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).

Вот этого делать не стоит, так как при недостаточных и неполных данных надо часто рефакторить систему, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. Микросервисы следует использовать только когда мы точно знаем, что нам надо.

Здравствуйте, Философ, Вы писали:

MH>>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
Ф>У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл...
Ф>Поубивал бы!!!

А есть реальные примеры таких проектов?

Здравствуйте, mrTwister, Вы писали:

K>>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).
T>Вот этого делать не стоит, так как при недостаточных и неполных данных надо часто рефакторить систему, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. Микросервисы следует использовать только когда мы точно знаем, что нам надо.

Нивапрос.
Заказчик отдаст свои деньги другим более проворным ребятам.

Здравствуйте, TG, Вы писали:

TG>Нивапрос.
TG>Заказчик отдаст свои деньги другим более проворным ребятам.

Ты имеешь ввиду, что заказчик уйдет к другим более проворным ребятам, которые предложат ему начать сразу с микросервисной архитектуры при недостаточных и неполных исходных данных? Ну удачи ему

Здравствуйте, elmal, Вы писали:

E>Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.

Эх, молодежь... ©

Раньше все математики всё писали на Фортране, и не особо использовали чужие библиотеки. Точнее, числодробительные библиотеки получились в результате их работы.
Когда я работал с командой математиков, там использовалась только одна сторонняя библиотека: Графор. Меня тогда еще попросили сделать к ней подключение из Си. Тогда еще не было таких Интернетов, как сейчас. И математики были старше меня, успели каждый себе написать все, что требовалось.
А сейчас в институтах учат, как подключить к Питону библиотеку. Н-да...

Здравствуйте, mrTwister, Вы писали:

T>а микросервисы делают рефакторинг оооочень дорогим.

Можно ентот тезис подробнее раскрыть?

Здравствуйте, Privalov, Вы писали:

P>Эх, молодежь... ©
P>Раньше все математики всё писали на Фортране, и не особо использовали чужие библиотеки. Точнее, числодробительные библиотеки получились в результате их работы.
P>Когда я работал с командой математиков, там использовалась только одна сторонняя библиотека: Графор. Меня тогда еще попросили сделать к ней подключение из Си. Тогда еще не было таких Интернетов, как сейчас. И математики были старше меня, успели каждый себе написать все, что требовалось.
P>А сейчас в институтах учат, как подключить к Питону библиотеку. Н-да...

короче, вы развлекались за чужой счёт, а молодёжь пытается добиться результата.

Здравствуйте, Sharov, Вы писали:

T>>а микросервисы делают рефакторинг оооочень дорогим.
S>Можно ентот тезис подробнее раскрыть?

тут смотря что подразумевать под "рефакторингом".

если разделение на сервисы плохое, то переделывать всё будет дорого. на границах сред всегда всё дорого.
там и протоколы надо менять, и роутинг, и гейты, и деплой...

Здравствуйте, neFormal, Вы писали:

F>короче, вы развлекались за чужой счёт, а молодёжь пытается добиться результата.

А библиотеки, которыми молодежь пользуется, появились сами, я верно понял?