Здравствуйте, Ziaw, Вы писали:
НС>>Тебе показалось. Не стоит претензии к написанному тобой переносить на себя лично. Z>Не показалось. Претензии можно привязать к фактам, хамство — обтекаемо и оценочно.
Хамство обтекаемо?
НС>>Это тебе повезло, можно расслабиться и не иметь никаких четких рамок. В современном мире облачных сервисов не так чтобы частая ситуация, мало кто хочет использовать сервис, который в один прекрасный момент начнет тормозить и никаких обязательств по этому поводу ни у кого не будет. Z>Сервис который используют другие бизнесы не весь мир, а довольно узкий класс приложений в сегменте b2b и еще чуть-чуть в b2g.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Опять ничего не понял. Ты точно понимаешь что такое докер и длоя чего он нужен. S>>Изоляция и простота деплоя. НС>Нет. В первую очередь это снижение оверхеда ВМ, т.е. контейнер это быстрее и дешевле. Потому что альтернатива докеру это прежде всего виртуалки.
А простота деплоя не предполагает снижение оверхеда ВМ?
НС>>>Ты точно понимаешь что такое рефакторинг? S>>Возврат тех. долга. НС>Возврат техдолга это не только рефакторинг, так что неверно.
Failure to perform refactoring can result in accumulating technical debt; on the other hand, refactoring is one of the primary means of repaying technical debt.
S>>Свитч на 50 кейсов делать не разумно. А на 49 или 36 самое то? НС>А как по твоему?
Без понятия, никогда в таком разрезе об этом не думал. Просто смущает нелепость постановки и выбор конкретных чисел.
S>>НС>Количество, оно со временем переходит в качество, слышал про такое? S>>К чему эта крайне странная фраза написана? НС>К разговору. Количественные значения приводят к качественным скачкам.
Хорошо, спрошу иначе -- сформулируйте это в контексте кода. Т.е. кол-во кода перейдет в его качество?
S>>К количеству кода, т.е. чем больше кода тем лучше? НС>Удивительная логика. Не пояснишь?
См. выше.
S>>>>, типа 49 свитчей еще рано, а вот 50 уже самое то. НС>>>Сам придумал, сам посмеялся. S>>Придумал не я, я только посмеялся.
НС>Нет, какую то абсолютную границу придумал именно ты. И именно над ее абсолютностью и посмеялся. Т.е. посмеялся сам над собой. У Чапека этот прием называется имаго.
О, началось, боевая имага в ход пошла.
НС>В целом, у тебя какое то странное восприятие для инженера. Это вполне нормально, когда некая конструкция имеет оверхед, зависящий от количественных показателей. И на каком то количестве оверхед превышает пользу, на каком то польза сравнивается, а на каком то начинает превышать. Совершенно стандартная в инженерии ситуация, почему она вызывает у тебя какие то неуемные фантазии мне непонятно.
Хорошее определение, никаких фантазий. Сформулируйте внятно теперь как это связано с кодом и паттернами?
Просто 50 свичей или визитор это было словоблудие. Должно быть какое-то внятное правило или закон.
S>>>>Скорее важно уметь читать, т.е. для монолитов важен навык чтения и понимания. А вот при переходе на мс арх-ру код приходится писать. НС>>>Ты сам прочти что ты пишешь. В монолите писать код не надо? S>> Для мс писать приходится чуточку больше кода, так лучше? НС>Доказательства где? Перейдя с общей сложности системы на количество кода, который надо писать, ты ступил на совсем тонкий лед. Потому что для микросервисов существует масса софта, который реализовывает то, что в монолите тебе придется велосипедить.
А интегрируется в BL это все автоматически, или надо каждую необходимую ф-ть интегрировать путем написания кода?
Велосипедостроение заменилось интеграцией.
НС>И даже если ты используешь этот софт в монолите, количество разных чужих сервисов существенно приблизят твой монолит к микросервисам.
Опять странное заявление -- т.е. если я своем монолите буду использовать n-ое кол-во "разных чужих сервисов", то начиная
с какого-то n мой монолит становится микросервисом. Каково ограничение снизу на это n?
НС>К примеру, твой монолит умеет хелсчеки, и чтобы если хелсчек стал выдавать проблему, сервис бы автоматически рестартанул? Если да, то как это реализовано?
Ну как вариант, завершить все текущие операции, или скинуть их состояние на диск, сделать fork (или поднять новый процесс), а
сам процесс может себя прибить. Как-то так. А что докажет ответ на этот вопрос?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Занятся оптимизацией, НС>Оптимизацией чего?
Есть варианты?
S>> покамест масштабировать через LB или очередь. НС>Это если оно масштабируется.
На нет и суда нет.
НС>>>И чем это отличается от микросервисов? S>>Тем что наше приложение по-прежнему монолит (см.выше если что). НС>Монолит отличается от микросервисов тем что он монолит. Прекрасно.
Ну т.е. если мы на 4-5 машинах запустили наш инстанс монолита, то теперь у нас микросервисная арх-ра. Ясно.
НС>>>У тебя есть еще какие то варианты? S>>Я первый спросил. НС>Т.е. нет. ЧТД.
Жду правильный ответ!
НС>>>Как и в монолите. S>>А nosql в монолитах сильно нужен? НС>Ровно настолько же, насколько и в микросервисах. У тебя по прежнему какое то крайне странное представление о микросервисах. Монолиты у тебя почему то что то довольно маленькое, без особой нагрузки, без требований к даунтайму, масштабируемости и НА.
Очередной уход от конкретного ответа. Таким ответом можно все что угодно обосновать.
Складывается ощущение, что монолит вообще от мс ничем не отличается, везде "и там и там".
Они прям ноздря в ноздрю идут.
S>>Зависит от. НС>От чего?
Здравствуйте, Ziaw, Вы писали:
C>>Ошибку такого подхода поняли достаточно быстро, но полный переход на сервисы занял что-то около 10 лет. Z>Облачные провайдеры и прочие госуслуги легко бьются на слабо-связанные куски, это отличные кандидаты на разбиение на множество кусков-приложений.
Я бы не сказал, что "легко". Запуск виртуалки на EC2 требует что-то около четырёх-пяти десятков сервисов.
Z>А вот будет ли это хотя бы близко к классике микросервисов: один микро-сервис — одна простая функция — одно хранилище — один разработчик, вопрос открытый. Z>Лично я их подход вижу как несколько монолитов слабо связанных по ресту и небольшой набор общих сервисов.
Скорее среднего размера, не микросервисы, но и не монолиты в миллионы строк.
Масса. Но вопрос был о другом. Прежде чем заниматься оптимизацией, надо понять что оптимизировать.
S>>> покамест масштабировать через LB или очередь. НС>>Это если оно масштабируется. S>На нет и суда нет.
Что это означает на практике? Тормозит, да и бог с ним?
S>Ну т.е. если мы на 4-5 машинах запустили наш инстанс монолита, то теперь у нас микросервисная арх-ра. Ясно.
Опять борьба с чучелком.
НС>>Ровно настолько же, насколько и в микросервисах. У тебя по прежнему какое то крайне странное представление о микросервисах. Монолиты у тебя почему то что то довольно маленькое, без особой нагрузки, без требований к даунтайму, масштабируемости и НА. S>Очередной уход от конкретного ответа.
Это не уход от ответа, это отсутствие конкретных вопросов и попытка переложить на меня бпремя по доказательству твоих утверждений.
S>Складывается ощущение, что монолит вообще от мс ничем не отличается, везде "и там и там". S>Они прям ноздря в ноздрю идут.
В целом да, это не два разных мира, и грань между монолитами и микросервисами не так чтобы четкая.
S>>>Зависит от. НС>>От чего? S>Требований, бизнес домена.
Да ты прям КО. Ну и? Вот бизнес пришел и затребовал перф, заведомо превышающий возможности хранилища без шардинга. Ты как, таки потащишь распределенные технологии в монолит или пошлешь бизнес в жопу?
НС>>Я не буду все это читать в поисках доказательств тому, что ты тут заявляешь. Есть конкретно список тем, которые нужны в микросервисах и не нужны в аналогичного масштаба монолите? S>API Gateway Design Pattern,
Нужен как только в кластере у тебя становится больше одного сервиса. Монолит вовсе не означает что сервис у тебя строго один. Для иллюстрации, чтобы ты понял о чем речь:
пусть у тебя есть внутри кластера некий storage сервис. Чтобы у тебя не было потуг втащить его в монолит, предположим что сервис делаешь не ты, ты используешь готовый (требование бизнеса). И есть некий бэк, который из стораджа читает пользовательские данные для работы.
Теперь у нас есть сценарий, когда пользователь грузит некие файлы в хранилище, а потом бэк их обрабатывает. Варианты реализации:
* Проксируем все обращения к хранилищу через твой бэк
* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем средствами хранилища (SAS токены, policy на бакеты/контейнеры etc)
* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем при помощи еще одного сервиса-прокси, реализующего auth, аналогичный бэку
* Делаем один прокси и на бэк и на хранилище, уберая всю auth логику из обоих сервисов
Что выберешь и почему?
S> Access token pattern,
Это, по твоему, специфика микросервисов? А в монолите ты что, будешь креды в каждом запросе гонять?
S> side car pattern.
Ну а тут где специфика?
Возьмем пример, приведенный выше. Предположим, бизнес решил не изобретать велосипед и не рукописать логику авторизации прямо в коде, цементируя ее в продукте. Вместо этого он хочет воспользоваться готовым решением с возможностью настраивать правила авторизации без правки кода. Для конкретики, пусть это будет OPA.
Вопрос — ты OPA сайдкаром навесишь, поднимешь отдельным сервисом или будешь пытаться инсталировать его прямо в ВМ со своим монолитом?
S>https://microservices.io/patterns/observability/distributed-tracing.html
В монолите тебе трейсинг не нужен? Смелый ты.
S>Сойдет, для затравки?
Здравствуйте, Sharov, Вы писали:
НС>>Нет. В первую очередь это снижение оверхеда ВМ, т.е. контейнер это быстрее и дешевле. Потому что альтернатива докеру это прежде всего виртуалки. S>А простота деплоя не предполагает снижение оверхеда ВМ?
А она есть, простота? Чем образ контейнера проще образа ВМ? Скорее наоборот, у контейнера есть ограничения по хостовой ОС, а у образа ВМ нет.
А то что вместо образа в ВМ иногда пытаются накатывать прикладное решение скриптами, так это исключительно по причине все того же оверхеда, так как готовые образы в облаках уже на ВМ накачены или лежат в близком кеше, а твой кастомный образ нужно будет выкачать из хранилища, а он, в силу наличия в нем полноценной ОС, имеет немаленький размер. Что, в свою очередь, удар по яйцам автоскейлинга, где каждая секунда на счету.
НС>>Возврат техдолга это не только рефакторинг, так что неверно.
S>Вики не совсем согласно, что неверно -- https://en.wikipedia.org/wiki/Code_refactoring#Motivation: S>
S>Failure to perform refactoring can result in accumulating technical debt; on the other hand, refactoring is one of the primary means of repaying technical debt.
У тебя как с логикой? Из утверждения что отсутствие рефакторинга накапливает техдолг не следует, что рефакторинг борется только с техдолгом. Отсутствие лопаты приводит к накоплению снега перед крыльцом, но это не означает что лопата может чистить только снег перед крыльцом, андерстенд?
S>>>Свитч на 50 кейсов делать не разумно. А на 49 или 36 самое то? НС>>А как по твоему? S>Без понятия, никогда в таком разрезе об этом не думал.
Так подумай.
S> Просто смущает нелепость постановки и выбор конкретных чисел.
Ну так зачем тогда ты выбрал конкретные числа? Я ж говорю, сам придумал, сам посмеялся.
НС>>К разговору. Количественные значения приводят к качественным скачкам. S>Хорошо, спрошу иначе -- сформулируйте это в контексте кода. Т.е. кол-во кода перейдет в его качество?
Я уже сформулировал, вернись и перечитай, только теперь без своих фантазий.
S>>>К количеству кода, т.е. чем больше кода тем лучше? НС>>Удивительная логика. Не пояснишь? S>См. выше.
Что я там должен увидеть? Ответь на вопрос, а не посылай неизвестно куда.
НС>>Нет, какую то абсолютную границу придумал именно ты. И именно над ее абсолютностью и посмеялся. Т.е. посмеялся сам над собой. У Чапека этот прием называется имаго. S>О, началось, боевая имага в ход пошла.
Так не применяй подобные приемчики.
S>Просто 50 свичей или визитор это было словоблудие.
До свидания, бисер закончился.
S>Опять странное заявление -- т.е. если я своем монолите буду использовать n-ое кол-во "разных чужих сервисов", то начиная S>с какого-то n мой монолит становится микросервисом.
Ты опять приписал мне то, чего я не говорил. То ли у тебя проблемы с логикой и пониманием написанного, то ли окончательно аргументы закончились.
НС>>К примеру, твой монолит умеет хелсчеки, и чтобы если хелсчек стал выдавать проблему, сервис бы автоматически рестартанул? Если да, то как это реализовано? S>Ну как вариант, завершить все текущие операции, или скинуть их состояние на диск, сделать fork (или поднять новый процесс), а S>сам процесс может себя прибить. Как-то так. А что докажет ответ на этот вопрос?
Что ты изобрел велосипед и написал кучу кода. А в микросервисах это все умеет оркестратор искаропки, тебе достаточно только сам хелсчек написать, обычно совсем примитивный. Так что твое утверждение:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Какой руководитель команды, какие ГОСТы? Твои продажники подписывают с клиентом контракт, где прописаны конкретные цифры. И за несоответствие этим цифрам клиент вправе потребовать прописанную в договоре же компенсацию. В каком месте тут может помочь твоя мухлефилософия про магию в реальном мире? Z>>Что-то у тебя какое-то совсем неприкрытое хамство пошло.
НС>Тебе показалось. Не стоит претензии к написанному тобой переносить на себя лично.
Типичная хамлофилософия.
НС>Это тебе повезло, можно расслабиться и не иметь никаких четких рамок. В современном мире облачных сервисов не так чтобы частая ситуация, мало кто хочет использовать сервис, который в один прекрасный момент начнет тормозить и никаких обязательств по этому поводу ни у кого не будет.
Я тут походил по конторам, которые ты называешь продуктовыми, и услышал, что:
— оптимизации слишком дорогие, т.к. время разработчика стоит конских денег
— оптимизации дают не сильно много профита на единицу времени разработчика
— фичи дают денег гораздо больше, на порядки
— железо-клауд намного дешевле чем стоимость труда тестеров-разработчиков
— в большинстве случаем проще докинуть мощностей в самом клауде
— а если выкинуть тестеров, то можно и в хороший плюс выйти, и багов будет меньше, а то с тестерми девелоперы расслабляются
— а что бы сэкономить на девелоперах, надо их загрузить всем подряд — девопс, тестирование, бизнес-анализ, солюшн-архитектура, не говоря про мелкий багфикс которого всегда прорва
На таком вот фоне "начнет тормозить" не выглядит большим риском.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Есть варианты? НС>Масса. Но вопрос был о другом. Прежде чем заниматься оптимизацией, надо понять что оптимизировать.
Код, естественно.
НС>>>Это если оно масштабируется. S>>На нет и суда нет. НС>Что это означает на практике? Тормозит, да и бог с ним?
Монолит. Не масштабируется. Тормозит. Такого не встречал. Что можно сделать -- ну смотреть узкие места в коде.
S>>Ну т.е. если мы на 4-5 машинах запустили наш инстанс монолита, то теперь у нас микросервисная арх-ра. Ясно. НС>Опять борьба с чучелком.
Логичные выводы из Ваших заявлений, не более.
НС>>>Ровно настолько же, насколько и в микросервисах. У тебя по прежнему какое то крайне странное представление о микросервисах. Монолиты у тебя почему то что то довольно маленькое, без особой нагрузки, без требований к даунтайму, масштабируемости и НА. S>>Очередной уход от конкретного ответа. НС>Это не уход от ответа, это отсутствие конкретных вопросов и попытка переложить на меня бпремя по доказательству твоих утверждений.
Именно уход, ибо через "Ровно настолько же, насколько и в микросервисах" можно объяснить все что угодно. Читой воды казуистика.
Слабый довод, но вот я в гугл забил "nosql monolithic architecture" и ничего кроме nosql и микросервисов не получил. Т.е.
не особо кому интересно это сочетание, так что скорее всего nosql и монолиты встречаются крайне и крайне редко.
Приведите пример обратного.
S>>Складывается ощущение, что монолит вообще от мс ничем не отличается, везде "и там и там". S>>Они прям ноздря в ноздрю идут. НС>В целом да, это не два разных мира, и грань между монолитами и микросервисами не так чтобы четкая.
Ноздря в ноздрю же идут.
S>>Требований, бизнес домена. НС>Да ты прям КО. Ну и? Вот бизнес пришел и затребовал перф, заведомо превышающий возможности хранилища без шардинга. Ты как, таки потащишь распределенные технологии в монолит или пошлешь бизнес в жопу?
Буду думать что можно сделать.
НС>>>Я не буду все это читать в поисках доказательств тому, что ты тут заявляешь. Есть конкретно список тем, которые нужны в микросервисах и не нужны в аналогичного масштаба монолите? S>>API Gateway Design Pattern,
НС>Нужен как только в кластере у тебя становится больше одного сервиса. Монолит вовсе не означает что сервис у тебя строго один. Для иллюстрации, чтобы ты понял о чем речь: НС>пусть у тебя есть внутри кластера некий storage сервис. Чтобы у тебя не было потуг втащить его в монолит, предположим что сервис делаешь не ты, ты используешь готовый (требование бизнеса). И есть некий бэк, который из стораджа читает пользовательские данные для работы. НС>Теперь у нас есть сценарий, когда пользователь грузит некие файлы в хранилище, а потом бэк их обрабатывает. Варианты реализации: НС>* Проксируем все обращения к хранилищу через твой бэк НС>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем средствами хранилища (SAS токены, policy на бакеты/контейнеры etc) НС>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем при помощи еще одного сервиса-прокси, реализующего auth, аналогичный бэку НС>* Делаем один прокси и на бэк и на хранилище, уберая всю auth логику из обоих сервисов НС>Что выберешь и почему?
Выберу, чтобы Вы не уводили беседу в сторону и не разводили казуистику. Читая интернеты понял, что API Gateway Design Pattern
чуть ли не первый паттерн, который используют для перевода монолита на мс арх-ру.
S>> Access token pattern, НС>Это, по твоему, специфика микросервисов? А в монолите ты что, будешь креды в каждом запросе гонять?
Для монолитов не увидел в нем необходимости. Да и интернеты не очень чтобы видят эту необходимость.
S>> side car pattern. НС>Ну а тут где специфика? НС>Возьмем пример, приведенный выше. Предположим, бизнес решил не изобретать велосипед и не рукописать логику авторизации прямо в коде, цементируя ее в продукте. Вместо этого он хочет воспользоваться готовым решением с возможностью настраивать правила авторизации без правки кода. Для конкретики, пусть это будет OPA. НС>Вопрос — ты OPA сайдкаром навесишь, поднимешь отдельным сервисом или будешь пытаться инсталировать его прямо в ВМ со своим монолитом?
Never use a Sidecar Pattern for synchronous activities that must complete prior to generating a user response. Doing so will add some delay to end-user response times.
In terms of micro-service architecture, one service responsible to one business capability or other strategies that you can read here. This leads to the need of tracing multi-separated service which much harder than tracing monolith architecture. In monolith architecture the whole process life-cycle is on one project, but in micro-service architecture to handle one request it needs to call n other services.
You may thinks that it is enough to create separate log service that records all request log for each services. But, when your API hits by hundreds request per second, how do you know that one request log in service A corresponds to log in service B and so on?
… distributed tracing helps you, as a developer, to know deeply about your software behavior.
S>>Сойдет, для затравки? НС>Нет, все варианты мимо.
Я даже не сомневался. Я даже хотел сначала написать имеет ли смысл отвечать на этот вопрос, по скольку Вы все равно все вывернете
наизнанку. Ну а вдруг? Нет, Вы стабильны. Стабильность -- признак мастерства.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А простота деплоя не предполагает снижение оверхеда ВМ? НС>А она есть, простота? Чем образ контейнера проще образа ВМ? Скорее наоборот, у контейнера есть ограничения по хостовой ОС, а у образа ВМ нет. НС>А то что вместо образа в ВМ иногда пытаются накатывать прикладное решение скриптами, так это исключительно по причине все того же оверхеда, так как готовые образы в облаках уже на ВМ накачены или лежат в близком кеше, а твой кастомный образ нужно будет выкачать из хранилища, а он, в силу наличия в нем полноценной ОС, имеет немаленький размер. Что, в свою очередь, удар по яйцам автоскейлинга, где каждая секунда на счету.
Резюмирую -- ВМ проще для деплоймента, но хуже для автоскейлинга. Верно?
НС>>>Возврат техдолга это не только рефакторинг, так что неверно. S>>Вики не совсем согласно, что неверно -- https://en.wikipedia.org/wiki/Code_refactoring#Motivation: S>>
S>>Failure to perform refactoring can result in accumulating technical debt; on the other hand, refactoring is one of the primary means of repaying technical debt.
НС>У тебя как с логикой?
Вы слишком категоричны. Надо было писать не "так что неверно", а "верно отчасти". Потому как цитата из вики
говорит, что это именно верно отчасти -- т.е. одна из целей рефакторинга возврат тех. долга.
S>> Просто смущает нелепость постановки и выбор конкретных чисел. НС>Ну так зачем тогда ты выбрал конкретные числа? Я ж говорю, сам придумал, сам посмеялся.
А в реальности:
НС>Не надо все сводить до абсурда. Давай я тебе примером проиллюстрирую. Вот есть такой паттерн Посетитель. Если у тебя 2 реализации — точно нужно его использовать, вместо того чтобы написать просто свитч? А если реализаций 50 штук — разумно ли будет писать свитч на 50 кейсов?
Стабильность!
НС>>>К разговору. Количественные значения приводят к качественным скачкам. S>>Хорошо, спрошу иначе -- сформулируйте это в контексте кода. Т.е. кол-во кода перейдет в его качество? НС>Я уже сформулировал, вернись и перечитай, только теперь без своих фантазий.
Где? Я никакой внятной формулировки не увидел.
S>>>>К количеству кода, т.е. чем больше кода тем лучше? НС>>>Удивительная логика. Не пояснишь? S>>См. выше. НС>Что я там должен увидеть? Ответь на вопрос, а не посылай неизвестно куда.
Не могу пояснить, пока не получу ответ на свой вопрос (см. болд).
S>>Просто 50 свичей или визитор это было словоблудие. НС>До свидания, бисер закончился.
S>>Опять странное заявление -- т.е. если я своем монолите буду использовать n-ое кол-во "разных чужих сервисов", то начиная S>>с какого-то n мой монолит становится микросервисом. НС>Ты опять приписал мне то, чего я не говорил. То ли у тебя проблемы с логикой и пониманием написанного, то ли окончательно аргументы закончились.
Бисер таки нашелся. "Ты опять приписал мне то, чего я не говорил."
НС>И даже если ты используешь этот софт в монолите, количество разных чужих сервисов существенно приблизят твой монолит к микросервисам.
Повторю вопрос -- сколько надо разных и чужих, чтобы монолит в микросеврис?
НС>>>К примеру, твой монолит умеет хелсчеки, и чтобы если хелсчек стал выдавать проблему, сервис бы автоматически рестартанул? Если да, то как это реализовано? S>>Ну как вариант, завершить все текущие операции, или скинуть их состояние на диск, сделать fork (или поднять новый процесс), а S>>сам процесс может себя прибить. Как-то так. А что докажет ответ на этот вопрос? НС>Что ты изобрел велосипед и написал кучу кода. А в микросервисах это все умеет оркестратор искаропки, тебе достаточно только сам хелсчек написать, обычно совсем примитивный. Так что твое утверждение: НС>
НС>Для мс писать приходится чуточку больше кода
НС>Оказалось точным до наоборот.
А почему для монолита это не так? Почему там я не могу сделать это из коробки?
Здравствуйте, Sharov, Вы писали:
S>>>Есть варианты? НС>>Масса. Но вопрос был о другом. Прежде чем заниматься оптимизацией, надо понять что оптимизировать. S>Код, естественно.
НС>>Что это означает на практике? Тормозит, да и бог с ним? S>Монолит. Не масштабируется. Тормозит. Такого не встречал. Что можно сделать -- ну смотреть узкие места в коде.
И как будем искать? Вот в микросервисах все понятно, тебе сразу видно в каком сервисе заткнулось, прям в реальном времени. А в монолите?
S>>>Ну т.е. если мы на 4-5 машинах запустили наш инстанс монолита, то теперь у нас микросервисная арх-ра. Ясно. НС>>Опять борьба с чучелком. S>Логичные выводы из Ваших заявлений, не более.
Нет, придуманное тобой и никак не следующее из моих слов.
НС>>Это не уход от ответа, это отсутствие конкретных вопросов и попытка переложить на меня бпремя по доказательству твоих утверждений. S>Именно уход, ибо через "Ровно настолько же, насколько и в микросервисах" можно объяснить все что угодно.
Нельзя, если ты начнешь наконец приводить конкретику, а не общие слова ни о чем. А на общие слова ты закономерно получил такой же ответ.
S>Слабый довод, но вот я в гугл забил "nosql monolithic architecture" и ничего кроме nosql и микросервисов не получил.
Там может потому что использование NoSql и архитектура никак не связаны? Да не, не может быть.
НС>>В целом да, это не два разных мира, и грань между монолитами и микросервисами не так чтобы четкая. S>Ну! Откуда вдруг снижение к требованиям квалификации -- http://rsdn.org/forum/design/8191560
Я опять полет твоей мысли не уловил. Как из отсутствия четкой грани следует отсутствие снижения требований к квалификации?
НС>>Да ты прям КО. Ну и? Вот бизнес пришел и затребовал перф, заведомо превышающий возможности хранилища без шардинга. Ты как, таки потащишь распределенные технологии в монолит или пошлешь бизнес в жопу? S>Буду думать что можно сделать.
И чего надумаешь? Опять пытаешься на конкретные вопросы отделаться общими словами?
НС>>Нужен как только в кластере у тебя становится больше одного сервиса. Монолит вовсе не означает что сервис у тебя строго один. Для иллюстрации, чтобы ты понял о чем речь: НС>>пусть у тебя есть внутри кластера некий storage сервис. Чтобы у тебя не было потуг втащить его в монолит, предположим что сервис делаешь не ты, ты используешь готовый (требование бизнеса). И есть некий бэк, который из стораджа читает пользовательские данные для работы. НС>>Теперь у нас есть сценарий, когда пользователь грузит некие файлы в хранилище, а потом бэк их обрабатывает. Варианты реализации: НС>>* Проксируем все обращения к хранилищу через твой бэк НС>>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем средствами хранилища (SAS токены, policy на бакеты/контейнеры etc) НС>>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем при помощи еще одного сервиса-прокси, реализующего auth, аналогичный бэку НС>>* Делаем один прокси и на бэк и на хранилище, уберая всю auth логику из обоих сервисов НС>>Что выберешь и почему? S>Выберу, чтобы Вы не уводили беседу в сторону
Слив засчитан. Ты опять в ответ на конкретные примеры написал порожняк.
S>Читая интернеты понял, что API Gateway Design Pattern S>чуть ли не первый паттерн, который используют для перевода монолита на мс арх-ру.
На вопрос ответь, а потом паттерны обсудим.
S>>> Access token pattern, НС>>Это, по твоему, специфика микросервисов? А в монолите ты что, будешь креды в каждом запросе гонять? S>Для монолитов не увидел в нем необходимости.
Я задал конкретный вопрос. Где ответ? Каким образом ты собрался осуществлять аутентификацию без токена?
НС>>Вопрос — ты OPA сайдкаром навесишь, поднимешь отдельным сервисом или будешь пытаться инсталировать его прямо в ВМ со своим монолитом? S>Не знаю каким боком тут sidecar
И правда. Каким боком. Я уже понял что ты даже не понимаешь о чем пишешь.
S>У нас авторазация, напоминаю. Так что sidecar не выберу.
Чего блин? Какая связь между авторизацией и сайдкаром?
На всякий случай, а то у тебя опять какая то фантастика в голове, рекомендации с сайта ОРА:
To integrate with OPA outside of Go, we recommend you deploy OPA as a host-level daemon or sidecar container. When your application or service needs to make policy decisions it can query OPA locally via HTTP. Running OPA locally on the same host as your application or service helps ensure policy decisions are fast and highly-available.
Так почему ты не выберешь сайдкар? Нравится лишняя латентность на каждый внешний запрос (some delay to end-user response times)? Вкупе с отсутствием токенов прям прекрасное архитектурное решение. System design interview у меня бы ты точно не прошел, вне зависимости от твоего опыта с микросервисами, просто в силу проблем с базовой архитектурой распределенных систем.
S>>>https://microservices.io/patterns/observability/distributed-tracing.html НС>>В монолите тебе трейсинг не нужен? Смелый ты.
S>Ну-ну, зачем же так? Речь об распределенном трейсенге:
Как только у тебя сервисов больше одного — трейсинг, внезапно, становится распределенным. Даже в монолитах. Ты ж сам написал про кролика. В таких условиях трейсинг должен протрекать все путешествие сообщения, от входящего вызова, его породившего, через очередь, и до получения клиентом конечного результата.
S>>>Сойдет, для затравки? НС>>Нет, все варианты мимо. S>Я даже не сомневался. Я даже хотел сначала написать имеет ли смысл отвечать на этот вопрос, по скольку Вы все равно все вывернете S>наизнанку.
Чувак, я тебе на конкретных примерах все объяснил, даже человек не в теме начнет что то понимать, а ты решил что это так я выворачиваюсь. Ну и какой смысл мне тебе что то объяснять, если ты не прошибаем и игнорируешь все что тебе пишут? Тем более что я далеко не сторонник микросервисов, просто не согласен с той чушью что тут по их поводу поназаявляли.
Оставайся в своих заблуждениях, мне то что.
Здравствуйте, Sharov, Вы писали:
S>Резюмирую -- ВМ проще для деплоймента, но хуже для автоскейлинга. Верно?
Не только автоскейлинга, в целом в плане потребляемых ресурсов. Да, это основная причина появления контейнеров.
S>Вы слишком категоричны. Надо было писать не "так что неверно", а "верно отчасти".
Не надо мне указывать что писать. Я, в отличие от тебя, проблем в логике не допускал.
S>>>с какого-то n мой монолит становится микросервисом. НС>>Ты опять приписал мне то, чего я не говорил. То ли у тебя проблемы с логикой и пониманием написанного, то ли окончательно аргументы закончились. S>Бисер таки нашелся.
Решил дописать до конца ответ, не ты один форум читаешь.
НС>>Что ты изобрел велосипед и написал кучу кода. А в микросервисах это все умеет оркестратор искаропки, тебе достаточно только сам хелсчек написать, обычно совсем примитивный. Так что твое утверждение: НС>>
НС>>Для мс писать приходится чуточку больше кода
НС>>Оказалось точным до наоборот. S>А почему для монолита это не так? Почему там я не могу сделать это из коробки?
Ну ты же не сделал, верно? Ты рассказал как будешь писать велосипед. Почему?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Вы слишком категоричны. Надо было писать не "так что неверно", а "верно отчасти". НС>Не надо мне указывать что писать. Я, в отличие от тебя, проблем в логике не допускал.
S>>Бисер таки нашелся. НС>Решил дописать до конца ответ, не ты один форум читаешь.
Да, похоже, нашу перепалку никто особо не читает, раз нету комментариев. Было замечание от Спанчекрякса и все.
НС>>>Что ты изобрел велосипед и написал кучу кода. А в микросервисах это все умеет оркестратор искаропки, тебе достаточно только сам хелсчек написать, обычно совсем примитивный. Так что твое утверждение: НС>>>
НС>>>Для мс писать приходится чуточку больше кода
НС>>>Оказалось точным до наоборот. S>>А почему для монолита это не так? Почему там я не могу сделать это из коробки? НС>Ну ты же не сделал, верно? Ты рассказал как будешь писать велосипед. Почему?
С брокером был вариант вообще ничего не делать, без брокера я только набросал общие идеи, которые
тут же были объявлены велосипедом, хотя и тут есть наверняка какие-то общие и известные решения. Но может Вы
таки покажете мастер класс и расскажете как такое реализовать? А то все я да я...
Здравствуйте, Sharov, Вы писали:
S>тут же были объявлены велосипедом, хотя и тут есть наверняка какие-то общие и известные решения. Но может Вы S>таки покажете мастер класс и расскажете как такое реализовать? А то все я да я...
Я тебе уже прямым текстом написал — это все делается при помощи готовых решений, а не велосипедится самостоятельно. Что непонятно?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Код, естественно. НС>
Ожидаемая реакция.
S>>Монолит. Не масштабируется. Тормозит. Такого не встречал. Что можно сделать -- ну смотреть узкие места в коде. НС>И как будем искать? Вот в микросервисах все понятно, тебе сразу видно в каком сервисе заткнулось, прям в реальном времени. А в монолите?
Профилировщик?
S>>Слабый довод, но вот я в гугл забил "nosql monolithic architecture" и ничего кроме nosql и микросервисов не получил. НС>Там может потому что использование NoSql и архитектура никак не связаны? Да не, не может быть.
Сильно. Как можно было сделать такой вывод -- я Так не связаны, что только в мс архитектурах и используются.
НС>>>В целом да, это не два разных мира, и грань между монолитами и микросервисами не так чтобы четкая. S>>Ну! Откуда вдруг снижение к требованиям квалификации -- http://rsdn.org/forum/design/8191560
НС>Я опять полет твоей мысли не уловил. Как из отсутствия четкой грани следует отсутствие снижения требований к квалификации?
Как из отсутствия следует отсутствие. И ведь не поспоришь.
НС>>>Да ты прям КО. Ну и? Вот бизнес пришел и затребовал перф, заведомо превышающий возможности хранилища без шардинга. Ты как, таки потащишь распределенные технологии в монолит или пошлешь бизнес в жопу? S>>Буду думать что можно сделать. НС>И чего надумаешь? Опять пытаешься на конкретные вопросы отделаться общими словами?
Спрошу тогда Вашего совета. Что посоветуете?
НС>>>Нужен как только в кластере у тебя становится больше одного сервиса. Монолит вовсе не означает что сервис у тебя строго один. Для иллюстрации, чтобы ты понял о чем речь: НС>>>пусть у тебя есть внутри кластера некий storage сервис. Чтобы у тебя не было потуг втащить его в монолит, предположим что сервис делаешь не ты, ты используешь готовый (требование бизнеса). И есть некий бэк, который из стораджа читает пользовательские данные для работы. НС>>>Теперь у нас есть сценарий, когда пользователь грузит некие файлы в хранилище, а потом бэк их обрабатывает. Варианты реализации: НС>>>* Проксируем все обращения к хранилищу через твой бэк НС>>>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем средствами хранилища (SAS токены, policy на бакеты/контейнеры etc) НС>>>* Выставляем хранилище отдельно наружу, аутентификацию и авторизацию делаем при помощи еще одного сервиса-прокси, реализующего auth, аналогичный бэку НС>>>* Делаем один прокси и на бэк и на хранилище, уберая всю auth логику из обоих сервисов НС>>>Что выберешь и почему? S>>Выберу, чтобы Вы не уводили беседу в сторону НС>Слив засчитан. Ты опять в ответ на конкретные примеры написал порожняк.
Ну-ну, голубчик, держите себя в руках. Мы не в кпз.
S>>Читая интернеты понял, что API Gateway Design Pattern S>>чуть ли не первый паттерн, который используют для перевода монолита на мс арх-ру. НС>На вопрос ответь, а потом паттерны обсудим.
1) Я не на допросе;
2) Чтобы я не ответил, все равно все это вывернется наизнанку и пропадет в словоблудии;
3) На всякий случай этот вариант " аутентификацию и авторизацию делаем средствами хранилища " ибо
монолит(т.е.кодовую базу) лишний раз трогать не надо (а то мало ли -- тут уберем auth, а тут понадобиться);
4) Но скорее всего речь идет о прокси и об этом -- https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy
Что-то есть общее, да, но это далеко не одно и то же.
S>>>> Access token pattern, НС>>>Это, по твоему, специфика микросервисов? А в монолите ты что, будешь креды в каждом запросе гонять? S>>Для монолитов не увидел в нем необходимости. НС>Я задал конкретный вопрос. Где ответ? Каким образом ты собрался осуществлять аутентификацию без токена?
Через reverse proxy. Т.е.прячем все за LB.
НС>>>Вопрос — ты OPA сайдкаром навесишь, поднимешь отдельным сервисом или будешь пытаться инсталировать его прямо в ВМ со своим монолитом? S>>Не знаю каким боком тут sidecar НС>И правда. Каким боком. Я уже понял что ты даже не понимаешь о чем пишешь.
Ну кто бы сумлевался.
S>>У нас авторазация, напоминаю. Так что sidecar не выберу. НС>Чего блин? Какая связь между авторизацией и сайдкаром?
Предсказуемо!
НС>Возьмем пример, приведенный выше. Предположим, бизнес решил не изобретать велосипед и не рукописать логику авторизации прямо в коде, цементируя ее в продукте. Вместо этого он хочет воспользоваться готовым решением с возможностью настраивать правила авторизации без правки кода. Для конкретики, пусть это будет OPA.
Т.е. речь об авторизации. Есть ли смысл в асинхронной авторизации? Далее, привел цитату
Never use a Sidecar Pattern for synchronous activities that must complete prior to generating a user response. Doing so will add some delay to end-user response times.
Где я не прав? (Ответ знаю -- везде ).
НС>На всякий случай, а то у тебя опять какая то фантастика в голове, рекомендации с сайта ОРА: НС>
НС>To integrate with OPA outside of Go, we recommend you deploy OPA as a host-level daemon or sidecar container. When your application or service needs to make policy decisions it can query OPA locally via HTTP. Running OPA locally on the same host as your application or service helps ensure policy decisions are fast and highly-available.
НС>Так почему ты не выберешь сайдкар? Нравится лишняя латентность на каждый внешний запрос (some delay to end-user response times)? Вкупе с отсутствием токенов прям прекрасное архитектурное решение.
Ну что пристовать к человеку, который в мс арх-ре не работал? Что нагуглил то и показал. Что я могу сделать, если противоречие?
НС>System design interview у меня бы ты точно не прошел, вне зависимости от твоего опыта с микросервисами, просто в силу проблем с базовой архитектурой распределенных систем.
Свят, свят, свят.
S>>Ну-ну, зачем же так? Речь об распределенном трейсенге: НС>Как только у тебя сервисов больше одного — трейсинг, внезапно, становится распределенным. Даже в монолитах. Ты ж сам написал про кролика. В таких условиях трейсинг должен протрекать все путешествие сообщения, от входящего вызова, его породившего, через очередь, и до получения клиентом конечного результата.
Логично, конечно. У rmq есть своя панель и ui для управления, мониторинга и tracing'а + еще один наш монолит. Что делать?
Впендюирть распеределенный трейсинг для 2-х сервисов, у одно из которых tracing и мониторинг встроены by design.
Люди используют распределенный трейсинг для 10, а то 100 или более сервисов, а мы для 2х. Выкусите все!
Дайте угодаю -- Вы из Челябинска?
НС>>>Нет, все варианты мимо. S>>Я даже не сомневался. Я даже хотел сначала написать имеет ли смысл отвечать на этот вопрос, по скольку Вы все равно все вывернете S>>наизнанку. НС>Чувак, я тебе на конкретных примерах все объяснил, даже человек не в теме начнет что то понимать, а ты решил что это так я выворачиваюсь. Ну и какой смысл мне тебе что то объяснять, если ты не прошибаем и игнорируешь все что тебе пишут? Тем более что я далеко не сторонник микросервисов, просто не согласен с той чушью что тут по их поводу поназаявляли.
В ответ назаявляли неменьшую без доказательную чушь. Клин клином, как говорится.
Здравствуйте, SkyDance, Вы писали:
C>>Я бы не сказал, что "легко". Запуск виртуалки на EC2 требует что-то около четырёх-пяти десятков сервисов. SD>Вот прям "требует", или "историческая реализация такова, что"?
Да, требуют. Так как надо найти и зарезервировать физический узел, виртуальные сетевые интерфейсы, IP-адреса, EBS, настроить маршрутизацию и т.д. К этому добавляются тонкости типа учёта Reserved Instances, проверки безопасности, интеграция с биллинговой системой.
А ещё бывают сложности типа Launch Group — это требование запустить несколько узлов, которые физически находятся поблизости.
SD>Сколько из них могут лежать (и потом, eventually, добраться в нужную кондицию)?
Практически всё будет критично.
Ну тогда понятно, почему AWS так периодично ложится. Лично мое мнение, если на критическом пути столько компонентов, это лишь вопрос времени, когда оно в очередной раз накернится.
Разве что там традиционная индус-трия, когда старые сервисы принципиально стараются не трогать, поддерживая as-is, а все новые фичи приделывают параллельно, без рефакторинга существующей инфраструктуры.
Хм, учитывая что ты писал про "захотелось мне, и сделал я копию со своими перламутрами", кажется, так оно и обстоит. И, само собой, это легко оправдать "бизнес точкой зрения".
Здравствуйте, SkyDance, Вы писали:
C>>Практически всё будет критично. SD>Ну тогда понятно, почему AWS так периодично ложится. Лично мое мнение, если на критическом пути столько компонентов, это лишь вопрос времени, когда оно в очередной раз накернится.
Обычно сам EC2 не ложится. Кроме того, контрольная плоскость построена по принципу "статической стабильности". Т.е. если отломается сервис, то уже запущенные системы/сессии не будут затронуты. Так что если хочется надёжности, то можно использовать классический EC2 + EBS + Load Balancer, и он на практике будет железно надёжным.
SD>Разве что там традиционная индус-трия, когда старые сервисы принципиально стараются не трогать, поддерживая as-is, а все новые фичи приделывают параллельно, без рефакторинга существующей инфраструктуры.
Нет, это просто реально сложная задача. Кстати, весь стек неиндусы переписали всего несколько лет назад.
SD>Хм, учитывая что ты писал про "захотелось мне, и сделал я копию со своими перламутрами", кажется, так оно и обстоит. И, само собой, это легко оправдать "бизнес точкой зрения".
За EC2 в AWS следят строго, а вот в сервисах вокруг него — случается. Например, я бы не рекомендовал Lambda для чего-то критичного.
Для мс писать приходится чуточку больше кода, так лучше?
Так не связаны, что только в мс архитектурах и используются.
