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

K>Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.

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

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

_>>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
S>За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться.

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

·>Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться.

До десятка доводить не нужно, но пока есть старые клиентs, сохранять совместимость. Как клиенты обновяться, прибить инстансы со старым api.

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

_>>И есть противоположный этому вроде как современных подход (на мой взгляд никчемное убожество) — это когда ты на одной и той же машине (ну да, их таких может быть множество, но это опять же не суть) запускаешь множество демонов разного назначения, которые совместно решают целевую задачу. Это и есть те самые микросервисы.
F>почему обязательно на одной машине?

В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий.

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

НС>>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.
S>Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.

Феерично.

Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами.

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

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

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

S>·>Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться.
S>До десятка доводить не нужно, но пока есть старые клиентs, сохранять совместимость. Как клиенты обновяться, прибить инстансы со старым api.
В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть.

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

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

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

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

_>Феерично.

_>Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами.

Феерии не вижу, в случае выше совместная обработка задачи. Это, вестимо, не микросервисы.

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

F>>почему обязательно на одной машине?
_>В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий.

я просто пытаюсь связать "на одной машине" и "убожество"

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

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

·>В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть.

Заставьте всех в netflix'е, а я посмотрю. Проще выкатывать новую функц. не ломая старой.

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

НС>>Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости.
DO>Вот это вряд ли. Когда мы хотим узнать границы применимости, мы говорим где мы их хотим узнать.

Звучит как бред. Если мы хотим узнать границы, мы должны сказать где границы.

DO>Границы применимости это весьма конкретная характеристика задачи.

Границы применимости это вообще не характеристики задачи, это характеристики инструмента.

DO> Смотрим ТЗ, задаемся вопросом: «В чем смысл микросервисов для данной конкретной задачи?» В этом случае можно рассчитывать на конкретный ответ.

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

DO>А вот когда задается вопрос вообще, это больше похоже на наброс, с целью разжигания срача.

И ты с удовольствием решил уж точно превратить топик в срач?
Вот смотри — почти все кроме тебя таки ответили по делу, хоть и не все правильно. И только ты увидел в вопросе то, чего там не было, и не увидел то что там было. На что я тебе и намекнул.

В том, что новое это хорошо забытье старое, учитывая то, что я писал здесь

Автор: igor-booch
Дата: 13.11.18

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

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

S>·>Здравствуйте, Sharov, Вы писали:
S>·>В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть.
S>Заставьте всех в netflix'е, а я посмотрю. Проще выкатывать новую функц. не ломая старой.
Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.

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

·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.

Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.

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

S>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
S>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
Но если не ждать — будет десяток старых версий.

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

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

S>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.

S>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.

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

S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.

А это Вы не мне объясняйте, а точке. Я с этим тезисом полностью согласен.

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

S>>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
Такое реально только в тривиальных случаях. А в тривиальных случаях почти все способы работают, неинтересно.

Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.

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

S>>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
Хуже того, ты подразумеваешь, что есть какой-то код, который где-то лежит у богом забытых клиентов и хлеба не просит. А в реальной жизни старые версии сервиса таки надо поддерживать, ибо их надо разворачивать, управлять ими, применять секьюрити-апдейты и прочее. Или вот что-то упало у клиента древней версии — и тебе надо разобраться что же случилось. Ну да, можно достать старую версию исходников, но она уже не собирается, т.к. тулзы у тебя поменялись и прав на запись в "C:/" у тебя вдруг не стало. И в итоге через неделю археологических раскопок очень приятно узнать что эта бага была пофкишена два года назад и благополучно всеми забыта. Так что весь этот старый код, если он хоть кем-то используется — типичный технический долг.