Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Как Вы себе представляете монолит на контейнерах? НС>А в чем проблема?
А это точно будет монолит?
НС>>>Возможность перезапуска критична для любой архитектуры, включая монолиты. S>>Для монолитов этот код надо писать не всем разработчикам.
НС>И в микросервисах тоже не всем. Пока у тебя нет необернутого в транзакции изменения персистентного стейта тебе не нужно париться по поводу рестарта, что в мололите, что в микросервисах. А если есть — надо и там и там.
В монолите это зачем? Если что-то упадет, то будут рестартовать все приложение, а не части.
НС>В очередной раз убеждаюсь что у тебя какое то очень странное понимание микросервисов.
Суть микросервисов — выделение сравнительно небольшого функционала в сервис, связанный с остальным функционалом только через REST API (grpc, message bus etc). А изоляция хранилищ уже следствие, так как при расшаривании хранилища между несколькими сервисами между ними появляются плохо контролируемые паразитные связи.
Такое же видение, разве что разный взгляд на приоритет изоляции хранилища.
S>>То что они не эквивалентны согласен, но ведь микросервисная арх-ра осуществляется поверх распр. систем, т.е.
НС>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой.
Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было.
Сложный деплоймент, настройки, но система распределенная и нету никаких микросервисов.
S>>Как минимум на российском рынке, на хх, регулярно пишут про распил монолита на мс. НС>Распил монолита не означает распила БД с историей разработки в десятилетия. Из того что я от тех кто приходит на собеседования слышал пилят как правило веб-сервисы со своей собственной БД, причем эта БД зачастую что то простенькое типа MySQL с минимумом логики, а то и с code first подходом. А вот чтобы банк свой опердень на микросервисы пилил — про такое я не слышал.
Райфайзен этим занимался. Правда про опердни я не уверен, но что-то такое внутри делали.
S>>Не уверен я, что это проходит мимо разработчиков мс. НС>Учитывая твой нулевой опыт в микросервисах — не вижу смысла твою уверенность обсуждать. Аргументы есть, или одни ощущения?
Довод maxkar'a вполне считаю аргументом. Выше требования к квалификации, а обратное пока не убеждает. Ничья в лучшем случае.
S>>Почему я это должен доказывать? Заявление было что для мс требования к квалификации разработчиков ниже, а не выше. НС>И было приведено обоснование, почему. А в ответ ничего путного ты возразить не можешь, одна "баба яга против". Есть что по делу возразить или одни ощущения?
В ответ была ссылка на ресурс, приведенный же Вами, которая разумеется была проигнорированна:
Team expertise: The benefits of microservices are moot without a prepared staff. You should assess the skills of your team members before moving forward with a microservices architecture.
С Вашей стороны ничего кроме
Стал проще код интеграционный.
не последовало. Только причем здесь разработчики, если про интеграцию отвечают девопсы?
S>>Пока все что Вы написали в пользу своего довода сводится к тому, что требования к квалификации никак не меньше чем S>>для разработчиков монолитов. НС>Ну что за бред?
см. выше
S>>как и к мс, т.е. 1:1. А выигрыш тогда где? НС>В изоляции узких доменов, как следствие в уменьшении размеров конкретных сервисов, снижении требований к суммарной компетенции команды, вынесение инфраструктурных компетенций за пределы сервиса и даже разрабатываемого программного кода, в возможности более тонкой настройки масштабируемости, в возможности независимого деплоймента небольших частей системы, в большей свободе по выбору инструментальных средств и подходов к разработке каждой конкретной командой, в снижении требований на коммуникации между командами. Статья в википедии содержит развернутый ответ. НС>Я последний раз отвечаю на этот вопрос. Если захочется еще раз спросить — предыдущие сообщения в твоем распоряжении.
По ссылке про квалификацию разработчиков нет ни слова:
Modularity: This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[5] This benefit is often argued in comparison to the complexity of monolithic architectures.
Как из этой цитаты следует
снижении требований к суммарной компетенции команды,
?
Быстрее релизный цикл, новые фичи и управляемость(командами) -- да. Требования к квалификации -- далеко не факт.
Более того, в последнее время всех гоняют по System design interview, с прицелом для работы над
мс архитектурой, чего раньше(лет 6-7 ) не было. С чего это вдруг помимо прочего это стало актуально,
наоборот, все должно быть просто. Главное, чтобы разработчик со стула не падал, а мс арх-ра сделает
свое дело.
S>>Но это простота бизнес кода приходит не бесплатно, а с учетом ненадежной (враждебной окружающей среды. НС>Опять какие то ощущения или есть конкретика?
Конкретика была от maxkar'а.
S>>Т.е. сложность переехала в другое место. Ее не стало меньше, она стала другой. НС>Только часть этой сложности переехала в cloud native софт, который уже написан. Тебе не надо, как в монолите, самому писать свой собственный велосипедный кубер, к примеру.
Здравствуйте, Sharov, Вы писали:
НС>>Не в этом случае. Так было с SOA. А вот с микросервисами ситуация обратная — сперва были реальные системы, а потом уже действующие подходы оформили в концепцию. S>А как много было реальных систем, чтобы можно было с уверенностью сказать, что это правильный путь развития?
Системы были недостаточно истинными шотландцами?
S>Т.е. почему было понятно, что если это работает у Нетфликса или гугла, то заработает и в фирме на 20 программистов?
Здравствуйте, Sharov, Вы писали:
S>>>Как Вы себе представляете монолит на контейнерах? НС>>А в чем проблема? S>А это точно будет монолит?
Как контейнеры противоречат определению монолита?
НС>>И в микросервисах тоже не всем. Пока у тебя нет необернутого в транзакции изменения персистентного стейта тебе не нужно париться по поводу рестарта, что в мололите, что в микросервисах. А если есть — надо и там и там. S>В монолите это зачем?
Затем же, зачем и в микросервисах.
S>Если что-то упадет, то будут рестартовать все приложение, а не части.
Микросервис это вполне себе самостоятельное приложение, там нет никакой специфики в плане рестарта.
НС>>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой. S>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было.
Да. И? В чем противоречие моим словам?
S>Райфайзен этим занимался. Правда про опердни я не уверен, но что-то такое внутри делали.
Ну вот сперва узнай что это такое.
S>>>Не уверен я, что это проходит мимо разработчиков мс. НС>>Учитывая твой нулевой опыт в микросервисах — не вижу смысла твою уверенность обсуждать. Аргументы есть, или одни ощущения? S>Довод maxkar'a вполне считаю аргументом. Выше требования к квалификации
Это не довод, это было просто заявление.
S>В ответ была ссылка на
На сайт, требующий обязательной регистрации. Сразу в мусор.
S> ресурс,
Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа.
S>Team expertise: The benefits of microservices are moot without a prepared staff.
Опять бездоказательные тезисы.
S> You should assess the skills of your team members before moving forward with a microservices architecture.
И? Для монолита что, экспертиза не нужна?
S>С Вашей стороны ничего кроме
Ложь
S>По ссылке про квалификацию разработчиков нет ни слова:
В вопросе твоем тоже.
S>Быстрее релизный цикл, новые фичи и управляемость(командами) -- да. Требования к квалификации -- далеко не факт.
Ну да, то теоретики, а ты практик, ты точно знаешь, и твои заявления в доказательствах не нуждаются.
S>Более того, в последнее время всех гоняют по System design interview, с прицелом для работы над S>мс архитектурой,
При этом не знаешь что такое serverless. Жесть. Как твоя контора называется?
S>>>Но это простота бизнес кода приходит не бесплатно, а с учетом ненадежной (враждебной окружающей среды. НС>>Опять какие то ощущения или есть конкретика?
S>Конкретика была от maxkar'а.
Т.е. нету. ЧТД.
S>>>Т.е. сложность переехала в другое место. Ее не стало меньше, она стала другой. НС>>Только часть этой сложности переехала в cloud native софт, который уже написан. Тебе не надо, как в монолите, самому писать свой собственный велосипедный кубер, к примеру. S>А зачем для монолита нужен кубер, для начала?
А какие функции, по твоему, кубер выполняет? И точно все из них бесполезны для монолита? На всякий случай напомню, что монолит не означает единственный сервер, а то тебя опять понесет не в ту степь.
Здравствуйте, Sharov, Вы писали:
НС>>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой. S>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было. S>Сложный деплоймент, настройки, но система распределенная и нету никаких микросервисов.
В Гугле была сервисная система с самого начала, со своим аналогом контейнеров. Не знаю про MS.
Сервисы были не "микро", это да. Но именно микро-сервисы не очень-то нужны.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А это точно будет монолит? НС>Как контейнеры противоречат определению монолита?
Никак, просто они про изоляцию и простоту деплоймента.А монолиты не про изоляцию.
НС>>>И в микросервисах тоже не всем. Пока у тебя нет необернутого в транзакции изменения персистентного стейта тебе не нужно париться по поводу рестарта, что в мололите, что в микросервисах. А если есть — надо и там и там. S>>В монолите это зачем? НС>Затем же, зачем и в микросервисах.
А что там рестартовать, кроме всего приложения?
НС>>>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой. S>>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было. НС>Да. И? В чем противоречие моим словам?
Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов
S>>В ответ была ссылка на НС>На сайт, требующий обязательной регистрации. Сразу в мусор.
Некто НС выше дал ссылку на этот сайт, я прошел по ссылке данной мне ссылке. К нему вопросы.
S>> ресурс, НС>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа.
Это утверждение требует доказательства
S>>Team expertise: The benefits of microservices are moot without a prepared staff. НС>Опять бездоказательные тезисы.
Вы бы сами пример доказательства хоть чему-нибудь из Вами сказанного привели, подали пример.
А то не совсем понятно как в мире идей, манифестов и концепций можно что-то доказать. Цитатами из вики?
S>> You should assess the skills of your team members before moving forward with a microservices architecture. НС>И? Для монолита что, экспертиза не нужна?
Что и? Экспертиза для всего нужна, но кто-то утверждал, что для мс арх-ры ее нужно меньше.
На всякий случай, я полагаю экспертиза~квалификации.
S>>Быстрее релизный цикл, новые фичи и управляемость(командами) -- да. Требования к квалификации -- далеко не факт. НС>Ну да, то теоретики, а ты практик, ты точно знаешь, и твои заявления в доказательствах не нуждаются.
Я то тут причем?
Итак, мы начали с противоположенного мнения к требования квалификации разработчиков в проектах
с микросервисной арх-ой. Я утверждаю, что требования к квалификации разработчиков на подобных проектах выше, Вы -- что ниже.
У меня нету практического опыта над подобными проектами и я об этом сразу оговорился.
Поэтому в своих наблюдениях опираюсь на умозрительные и косвенные наблюдения.
1) Когда человек работает в мс арх-рах ему необходимо вот это все время держать в голове
-- https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Т.е. это не самая простая среда для программирования, требует определенной подготовки, т.е.
как минимум знать и понимать о чем пишут по ссылке. Для монолита, в силу высокой связанности,
многие вещи по приведенной выше ссылки не актуальны. Все натурально может быть в одном адр. пр-ве.
Но на мн-ве серверов, да.
2) Вакансии на хх стали изобиловать некоторым кол-вом новых баззвордов типа докер, k8, инструменты
мониторинга и т.п. Все это требует инвестиций на изучение, и вообще это новые требования к разработчикам,
которых лет 5 назад еще не было. Т.е. вроде обещали простоту, а по факту новые баззворды.
И да, речь идет именно об изучение, чтобы понимать, что под капотом, а не просто черный ящик.
3) За бугром, во фаанг и, следовательно, много где еще, появился новый этап в собеседованиях под
названием System design interview. Есть смутные подозрения, что едва ли людей дрючат на этом
этапе для работы над монолитными арх-ми. Стало быть дело в чем-то другом, в других арх-ых
подходах. Беру на себя смелость (без доказательств!) утверждать, что это необходимо для
разработчиков в микросервисных проектах. Подготовка, т.е. курсы, книги, ютюб, к подобным
интервью это некий прирост в экспертизе и навыках разработчиков. Т.е. помимо всего прочего --
знание языка, бд, dsl вроде sql, предметной области (желательно), добавляется целый пласт
необходимых знаний. С чего это вдруг, когда некоторые утверждают что мс арх-ра чудо как
хороша и разрабатывалась с учетом того, что над соотв. проектами могут работать программисты не самый высокой квалификации.
Натурально со стула не падают -- и хорошо! Дальше мс арх-ра + девопсы вывезут.
. И по косвенным признаками что-то такое говорит SkyDance,
дескать легко злоупотребить и улететь в распределенный монолит. Едва ли квалифицированные
разработчики такое смогут учудить.
Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in number of microservices. Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications.
Independent deployment of microservices is complicated.
Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls results into network latency.
Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
Debugging is difficult as the control flows over many microservices and to point out why and where exactly the error occurred is a difficult task.
Собственно вот -- не доказательство, но есть некое, кмк, здравое зерно.
S>>Более того, в последнее время всех гоняют по System design interview, с прицелом для работы над S>>мс архитектурой, НС>При этом не знаешь что такое serverless. Жесть.
И что, нельзя высказать свое мнение теперь?
НС>Как твоя контора называется?
Вы бы сами для начала представились, а то все обо мне да обо мне.
НС>>>Только часть этой сложности переехала в cloud native софт, который уже написан. Тебе не надо, как в монолите, самому писать свой собственный велосипедный кубер, к примеру. S>>А зачем для монолита нужен кубер, для начала? НС>А какие функции, по твоему, кубер выполняет?
Деплоймент, версионирование+ много чего еще специфичного для мс.
НС>И точно все из них бесполезны для монолита? На всякий случай напомню, что монолит не означает единственный сервер, а то тебя опять понесет не в ту степь.
Не все, конечно, но если у нас сложный деплоймент, то есть ли в кубере смысл?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А почему связанность модулей намного выше? НС>Ты зачем мне задаешь вопросы, на которые уже получил ответ?
Кроме вопроса на вопрос я обычно от Вас ничего не получаю. Приходится переспрашивать.
S>> Если взаимодействие через api, in-proc rest какой-нибудь? НС>Если. И даже если так — остается связность по потребляемым ресурсам (CPU, mem), по проходу по памяти, по используемым технологиям (managed и unmanaged код объединять не самое удобное решение, к примеру), по скейлингу, и что самое важное — по процедуре деплоймента.
Ясно , благодарю.
НС>>>RMQ на одной машине? Необычная архитектура. S>>RMQ -- это отдельная машина в сети, а мн-во обработчиков на др. машине, которые прослушивают очередь rmq. НС>Все обработчики на одной машине,
Нет, по машинам раскиданы.
НС>при этом message broker выделен в отдельный сервис — тоже весьма странное решение.
Отдельная машина в локальной сети.
НС>message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process.
Здравствуйте, Sharov, Вы писали:
НС>>>>RMQ на одной машине? Необычная архитектура. S>>>RMQ -- это отдельная машина в сети, а мн-во обработчиков на др. машине, которые прослушивают очередь rmq. НС>>Все обработчики на одной машине, S>Нет, по машинам раскиданы.
Т.е., несмотря на монолитность распределенность имеем в полный рост. ЧТД.
НС>>message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process. S>Это как, и mq и обработчики in proc?
А в чем проблема, если все равно все на одной машине?
Здравствуйте, Sharov, Вы писали:
S>>>А это точно будет монолит? НС>>Как контейнеры противоречат определению монолита? S>Никак, просто они про изоляцию и простоту деплоймента.А монолиты не про изоляцию.
Ну и с чем ты тогда споришь?
НС>>>>И в микросервисах тоже не всем. Пока у тебя нет необернутого в транзакции изменения персистентного стейта тебе не нужно париться по поводу рестарта, что в мололите, что в микросервисах. А если есть — надо и там и там. S>>>В монолите это зачем? НС>>Затем же, зачем и в микросервисах. S>А что там рестартовать, кроме всего приложения?
Так и в микросервисах рестартует приложение. Ты опять выдумываешь какие то несуществующие проблемы.
НС>>>>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой. S>>>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было. НС>>Да. И? В чем противоречие моим словам?
S>Распределения арх-ра может быть и без микро-сервисов -- http://rsdn.org/forum/design/8190024
Именно это я и утверждал несколькими абзацами выше. И десять раз тебе написал, что распределенность ортогональна микросервисам. Теперь ты пытаешься мне это доказать?
S>Т.е. противоречие вот тут: S>
S>Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов
Нет тут противоречия если не выхолащивать контекст.
S>>>В ответ была ссылка на НС>>На сайт, требующий обязательной регистрации. Сразу в мусор.
S>Некто НС выше дал ссылку на этот сайт, я прошел по ссылке данной мне ссылке. К нему вопросы.
Некто НС дал ссылку, которой не нужна регистрация, в отличие от некто Sharov.
S>>> ресурс, НС>>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа. S>Это утверждение требует доказательства
Смотри, начинает доходить.
S>>>Team expertise: The benefits of microservices are moot without a prepared staff. НС>>Опять бездоказательные тезисы. S>Вы бы сами пример доказательства хоть чему-нибудь из Вами сказанного привели, подали пример.
Я их тут приводил неоднократно.
S>А то не совсем понятно как в мире идей, манифестов и концепций можно что-то доказать. Цитатами из вики?
Логикой, мой друг, логикой.
S>>> You should assess the skills of your team members before moving forward with a microservices architecture. НС>>И? Для монолита что, экспертиза не нужна? S>Что и? Экспертиза для всего нужна, но кто-то утверждал, что для мс арх-ры ее нужно меньше.
Да. Ты же зачем то пытаешься доказать что она другая. Да, другая. Но другая не значит больше. Для монолитов точно так же нужна экспертиза в обращении с огромными объемами кода, и эта экспертиза куда дороже и реже, чем базовый стафф про микросервисы.
S>Тут что гуглил на тему, и набрел на еще один сайт -- https://www.geeksforgeeks.org/monolithic-vs-microservices-architecture/ S>
S>Disadvantages of microservices:
S> Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in number of microservices.
S> Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications.
S> Independent deployment of microservices is complicated.
S> Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls results into network latency.
S> Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
S> Debugging is difficult as the control flows over many microservices and to point out why and where exactly the error occurred is a difficult task.
S>Собственно вот -- не доказательство, но есть некое, кмк, здравое зерно.
А кто то утверждал что у микросервисов нет недостатков? Даже я про некоторые писал тут. Ты опять ломишься в открытые двери.
S>>>Более того, в последнее время всех гоняют по System design interview, с прицелом для работы над S>>>мс архитектурой, НС>>При этом не знаешь что такое serverless. Жесть. S>И что, нельзя высказать свое мнение теперь?
Речь не про высказывание мнения, а про
гоняют по System design interview, с прицелом для работы над мс архитектурой
НС>>Как твоя контора называется? S>Вы бы сами для начала представились, а то все обо мне да обо мне.
Я не аппелирую к собственной экспертности.
НС>>А какие функции, по твоему, кубер выполняет? S>Деплоймент,
Для монолита не нужен? Вот так новость.
S> версионирование+
Версионирование? О чем ты?
S> много чего еще специфичного для мс.
Что? Я вот так, навскидку, из крупного вспоминаю только балансировку гетерогенной нагрузки, которая монолиту не нужна в силу отсутствия самой возможность балансировки. Что еще?
НС>>И точно все из них бесполезны для монолита? На всякий случай напомню, что монолит не означает единственный сервер, а то тебя опять понесет не в ту степь. S>Не все, конечно, но если у нас сложный деплоймент, то есть ли в кубере смысл?
Что такое сложный деплоймент и почему он нивелирует потребность во всем функционале кубера?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Нет, по машинам раскиданы. НС>Т.е., несмотря на монолитность распределенность имеем в полный рост. ЧТД.
Если у нас монолиты запущены на нескольких машинах -- через gateway или шину, то, наверное, можно говорить
о распр. системе. Если я где-то (где?) утверждал обратное, то был неправ.
НС>>>message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process. S>>Это как, и mq и обработчики in proc? НС>А в чем проблема, если все равно все на одной машине?
А зачем mq тогда, не проще обраотчику иметь какой-нибудь персистентный буфер для задач?
С трудом представляю такую арх-ру с RabbitMq.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Никак, просто они про изоляцию и простоту деплоймента.А монолиты не про изоляцию. НС>Ну и с чем ты тогда споришь?
Явно не с этим.
S>>А что там рестартовать, кроме всего приложения? НС>Так и в микросервисах рестартует приложение. Ты опять выдумываешь какие то несуществующие проблемы.
Разработчику какого-нибудь компонента монолита зачем ломать об этом голову?
НС>>>Да. И? В чем противоречие моим словам? S>>Распределения арх-ра может быть и без микро-сервисов -- http://rsdn.org/forum/design/8190024
. НС>Именно это я и утверждал несколькими абзацами выше. И десять раз тебе написал, что распределенность ортогональна микросервисам. Теперь ты пытаешься мне это доказать?
Ортогональность предполагает независимость (как минимум в математике). Т.е. мы выяснили, что распределенная система
может строится, например, на монолитах. Или необязательно микро-сервисах. А вот микросервисы ну никак без
распределенности. Т.е. явная зависимость одного от другого, т.е. никакая не ортгональность.
Т.е. то, что Вы утверждали, а именно:
НС>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов.
неверно.
S>>Т.е. противоречие вот тут: S>>
S>>Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов
НС>Нет тут противоречия если не выхолащивать контекст.
О, как! Взял на заметку! Это оказывается, не Вы ошиблись или в чем-то неправы, а контекст выхоластился (или как он там задиспойзился?).
S>>Некто НС выше дал ссылку на этот сайт, я прошел по ссылке данной мне ссылке. К нему вопросы. НС>Некто НС дал ссылку, которой не нужна регистрация, в отличие от некто Sharov.
Ссылка на один и тот же сайт, у меня ничего не требует.
S>>Вы бы сами пример доказательства хоть чему-нибудь из Вами сказанного привели, подали пример. НС>Я их тут приводил неоднократно.
S>>А то не совсем понятно как в мире идей, манифестов и концепций можно что-то доказать. Цитатами из вики? НС>Логикой, мой друг, логикой.
Или казуистикой, уводом темы в сторону, вопросом на вопрос или переходом на личности.
S>>>> You should assess the skills of your team members before moving forward with a microservices architecture. НС>>>И? Для монолита что, экспертиза не нужна? S>>Что и? Экспертиза для всего нужна, но кто-то утверждал, что для мс арх-ры ее нужно меньше. НС>Да. Ты же зачем то пытаешься доказать что она другая. Да, другая. Но другая не значит больше.
Да, пытаюсь. От разработчиков мс требуется существенно больше компетенций в такой непростой среде как
распределенные системы. Т.е. требуется больше экспертизы в распр. системах. Сохраняя при этом все требования
при работе с монолитами. Т.е. другая экспертиза(квалификация) и именно больше.
НС>Для монолитов точно так же нужна экспертиза в обращении с огромными объемами кода,
А можно подробнее, что требуется? Знание шорткатов ide по навигации по коду, знание шорткатов по для всяческих
рефакторингов? Кто-то и как проводит собеседования на выявление соотв. навыков и экспертизы?
Ничего окромя классических паттренов GoF и ООП в голову не приходит, но кто сказал что для
мс они не нужны? Ну, ок, еще DDD можно добавить. Для мс все ровно также + ...
НС>и эта экспертиза куда дороже и реже, чем базовый стафф про микросервисы.
Возможно. Но, кмк, это экспертиза называется "умение читать и понимать код", которая нужна и там и там.
Вероятно, с учетом этого навыка людей и гоняют по System design, чтобы понимали что и почему написано.
S>>Тут что гуглил на тему, и набрел на еще один сайт -- https://www.geeksforgeeks.org/monolithic-vs-microservices-architecture/ S>>
S>>Disadvantages of microservices:
S>> Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in number of microservices.
S>> Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications.
S>> Independent deployment of microservices is complicated.
S>> Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls results into network latency.
S>> Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
S>> Debugging is difficult as the control flows over many microservices and to point out why and where exactly the error occurred is a difficult task.
S>>Собственно вот -- не доказательство, но есть некое, кмк, здравое зерно. НС>А кто то утверждал что у микросервисов нет недостатков? Даже я про некоторые писал тут. Ты опять ломишься в открытые двери.
Вы упорно отрицаете вот этот недостаток:
Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications
НС>>>При этом не знаешь что такое serverless. Жесть. S>>И что, нельзя высказать свое мнение теперь? НС>Речь не про высказывание мнения, а про НС>
НС>гоняют по System design interview, с прицелом для работы над мс архитектурой
И что не так с цитатой? Телепаты в отпуске.
S>>Вы бы сами для начала представились, а то все обо мне да обо мне. НС>Я не аппелирую к собственной экспертности.
Я тоже.
НС>>>А какие функции, по твоему, кубер выполняет? S>>Деплоймент, НС>Для монолита не нужен? Вот так новость.
Пожалуйста, читайте до конца мой ответ, т.е. буфферизируйте, а не в режиме потока. Ибо ниже об этом написано.
S>> версионирование+ НС>Версионирование? О чем ты?
Мог что-то перепутать, просто k8 вроде бы может помогать с переходом с одной версии api на другую, т.е.
работает и старая версия и новая потихоньку накатывается.
S>> много чего еще специфичного для мс. НС>Что? Я вот так, навскидку, из крупного вспоминаю только балансировку гетерогенной нагрузки, которая монолиту не нужна в силу отсутствия самой возможность балансировки. Что еще?
Не знаю, это же не я предложил кубер для монолитов использовать. Вот и думайте что еще.
S>>Не все, конечно, но если у нас сложный деплоймент, то есть ли в кубере смысл? НС>Что такое сложный деплоймент и почему он нивелирует потребность во всем функционале кубера?
Много сложных зависимсотей, наверное. Т.е. если он что-то не может упростить, а для другого безполезен,
то какой в нем смысл?
Здравствуйте, Sharov, Вы писали:
S>>>Нет, по машинам раскиданы. НС>>Т.е., несмотря на монолитность распределенность имеем в полный рост. ЧТД. S>Если у нас монолиты запущены на нескольких машинах -- через gateway или шину, то, наверное, можно говорить S>о распр. системе.
Наверное?
S>Если я где-то (где?) утверждал обратное, то был неправ.
Ты утверждал что при разработке монолита знания о распределенных системах не нужны.
НС>>>>message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process. S>>>Это как, и mq и обработчики in proc? НС>>А в чем проблема, если все равно все на одной машине? S>А зачем mq тогда,
Для буферизации.
S>не проще обраотчику иметь какой-нибудь персистентный буфер для задач? S>С трудом представляю такую арх-ру с RabbitMq.
Я вроде нигде не писал что нужно именно rmq использовать.
Здравствуйте, Sharov, Вы писали:
S>>>Никак, просто они про изоляцию и простоту деплоймента.А монолиты не про изоляцию. НС>>Ну и с чем ты тогда споришь? S>Явно не с этим.
Тогжа как понимать это?
Dockerfile писать надо? Надо. Т.е. надо изучать docker.
S>>>А что там рестартовать, кроме всего приложения? НС>>Так и в микросервисах рестартует приложение. Ты опять выдумываешь какие то несуществующие проблемы. S>Разработчику какого-нибудь компонента монолита зачем ломать об этом голову?
А кому ломать? Если компонент полагается на нетранзакционный персистентный стейт — кто должен бороться с последствиями сбоев? И чем, по твоему, нужно бороться авторам микросервисов?
Вобщем, давай вместо общих фраз ты продемонстрируешь конкретную проблему, которую нужно решать в микросервисе и не нужно в монолите.
НС>>Именно это я и утверждал несколькими абзацами выше. И десять раз тебе написал, что распределенность ортогональна микросервисам. Теперь ты пытаешься мне это доказать? S>Ортогональность предполагает независимость (как минимум в математике).
Цепляешься к словам? Прекрасно.
S> Т.е. мы выяснили, что распределенная система может строится, например, на монолитах.
Не мы, а ты.
S>неверно.
Просто ты неверно понял что написано. Или сделал вид, когда аргументы кончились.
S>Или казуистикой, уводом темы в сторону, вопросом на вопрос или переходом на личности.
Переход на личности начался с того, что ты вместо аргументации начал применять обороты вроде "я не уверен". Ну и чего мне с твоей неуверенностью делать?
НС>>Да. Ты же зачем то пытаешься доказать что она другая. Да, другая. Но другая не значит больше. S>Да, пытаюсь. От разработчиков мс требуется существенно больше компетенций в такой непростой среде как S>распределенные системы.
И существенно меньше в такой непростой среде как огромный монолитный проект. И?
При этом, как мы вроде бы разобрались, от компетенций в распределенности монолит нифига не спасает.
S> Т.е. требуется больше экспертизы в распр. системах.
Или нет. Ты опять бросаешься бездоказательными утверждениями. Какой конкретно кейс будет проблемой, требующей особой экспертизы в микросервисах, и не будет в монолите?
НС>>Для монолитов точно так же нужна экспертиза в обращении с огромными объемами кода, S>А можно подробнее, что требуется?
Огромное количество знаний и навыков, позволяющих создавать loosely coupled и high cohesion решения. Чем больше размер и сложность кода, тем больше ресурсов и умений надо вкладывать в архитектуру программного кода.
S>Ничего окромя классических паттренов GoF и ООП в голову не приходит, но кто сказал что для S>мс они не нужны?
Тебе точно надо объяснять, что важность и потребность в паттернах прямо зависит от объема кода? Что если у тебя кода десяток килобайт — тащить туда гору сложных паттернов не нужно?
НС>>и эта экспертиза куда дороже и реже, чем базовый стафф про микросервисы. S>Возможно. Но, кмк, это экспертиза называется "умение читать и понимать код",
Нет, экспертиза называется умение писат легко читаемый и модифицируемый код.
НС>>А кто то утверждал что у микросервисов нет недостатков? Даже я про некоторые писал тут. Ты опять ломишься в открытые двери. S>Вы упорно отрицаете вот этот недостаток: S>
S> Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications
Ложь. Я отрицаю что монолит позволяет обойтись без skilled.
S>>>Вы бы сами для начала представились, а то все обо мне да обо мне. НС>>Я не аппелирую к собственной экспертности. S>Я тоже.
Да? А как тогда трактовать "я не уверен" в качестве аргумента?
НС>>>>А какие функции, по твоему, кубер выполняет? S>>>Деплоймент, НС>>Для монолита не нужен? Вот так новость. S>Пожалуйста, читайте до конца мой ответ, т.е. буфферизируйте, а не в режиме потока. S>Ибо ниже об этом написано.
Я его прочел. Не понимаю что не так.
S>>> версионирование+ НС>>Версионирование? О чем ты?
S>Мог что-то перепутать, просто k8 вроде бы может помогать с переходом с одной версии api на другую, т.е. S>работает и старая версия и новая потихоньку накатывается.
Это называется update rollout. И это одна из тех фич, которую мне пришлось велосипедить на прошлом проекте, который был монолитом (поверх VMSS, ага). Если тебе в твоем проекте наплевать на даунтайм, то это не потому что он монолит, а потому ваши продакты не требуют отсутствия даунтайма сервиса когда вы накатываете очередной апдейт. Как только понадобится — будете свое велосипедить.
S>>> много чего еще специфичного для мс. НС>>Что? Я вот так, навскидку, из крупного вспоминаю только балансировку гетерогенной нагрузки, которая монолиту не нужна в силу отсутствия самой возможность балансировки. Что еще? S>Не знаю,
Ну зашибись, чо.
S> это же не я предложил кубер для монолитов использовать. Вот и думайте что еще.
Ну вот, к примеру, update rollout чтобы руками не фигачить. Или автоскейлинг. Cron jobs. Init containers. Да даже, блин, банально Lens использовать для управления кластером. Мало?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, VladiCh, Вы писали:
VC>>Ну это не обязательно, чтоб распределенный монолит получить это еще постараться надо. Это как — сервисы завязаны один на другой и не могут деплоиться независимо? VC>>Разные сервисы работают с одной и тем же слоем хранения? Ну как бы сделать то такое конечно можно, но кто в здравом уме будет?
S>Ну все сервисы зависят от авторизации например, и без этого сервиса ничего работать не будет. Также и возможны некоторые бизнес S>зависимости, т.е. доменные зависимости, которые и на уровне микросервисов сохраняются. Вот и распределенный монолит.
То что у них есть бизнес зависимости никак не означает, что они не могут деплоиться и скейлиться независимо.
Авторизация — ну и что авторизация? Есть какой-то внешний авторизационный сервис, который опять же релизится независимо и обычно является частью платформы, а не конкретного приложения.
Им все пользуются. И что?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
НС>>>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой. S>>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было. S>>Сложный деплоймент, настройки, но система распределенная и нету никаких микросервисов. C>В Гугле была сервисная система с самого начала, со своим аналогом контейнеров. Не знаю про MS.
C>Сервисы были не "микро", это да. Но именно микро-сервисы не очень-то нужны.
Микро или нет — это понятие растяжимое конечно, но в каких-то пределах. "Микро" здесь для утверждения разницы по сравнению с монолитами. Чем больше сервис по размеру тем он ближе к монолиту и его проблемам и наоборот.
То есть в реальности существует спектр конечно, от сервисов поменьше до сервисов побольше, но на каком-то масштабе размер становится таким что проявляются уже проблемы специфические для монолитов
и значит этот сервис скорее всего нужно дробить на более мелкие.
Здравствуйте, VladiCh, Вы писали:
VC>То что у них есть бизнес зависимости никак не означает, что они не могут деплоиться и скейлиться независимо.
Не знаю, насколько это возможно и тем более правильно в мс арх-ре, но допустим при запуске сервису А
надо сходить в сервис В, т.е. без этого он не сможет работать. Соотв. у нас имеется четкая зависимость.
Речь идет именно об инициализации, я не думаю, что это правильно так делать в мс арх-ре, но вот надо.
И вот у нас зависимость при деплое. Про масштабирование не спорю.
Здравствуйте, Sharov, Вы писали:
НС>>Для монолитов точно так же нужна экспертиза в обращении с огромными объемами кода, S>А можно подробнее, что требуется? Знание шорткатов ide по навигации по коду, знание шорткатов по для всяческих S>рефакторингов? Кто-то и как проводит собеседования на выявление соотв. навыков и экспертизы?
В некоторых больших проектах не работает нормально даже автодополнение в IDE.
S>Ничего окромя классических паттренов GoF и ООП в голову не приходит, но кто сказал что для S>мс они не нужны? Ну, ок, еще DDD можно добавить. Для мс все ровно также + ...
Организация репозитория и структуры работы вокруг неё, тестирование (бывает, что тесты часами работают), и т.д.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
НС>>>Для монолитов точно так же нужна экспертиза в обращении с огромными объемами кода, S>>А можно подробнее, что требуется? Знание шорткатов ide по навигации по коду, знание шорткатов по для всяческих S>>рефакторингов? Кто-то и как проводит собеседования на выявление соотв. навыков и экспертизы? C>В некоторых больших проектах не работает нормально даже автодополнение в IDE.
Ну т.е. требуется навык писать как минимум компилируемый код в блокноте, чтобы лишний раз компилятор не гонять, ибо долго?
Или как, к чему это замечание?
S>>Ничего окромя классических паттренов GoF и ООП в голову не приходит, но кто сказал что для S>>мс они не нужны? Ну, ок, еще DDD можно добавить. Для мс все ровно также + ... C>Организация репозитория и структуры работы вокруг неё, тестирование (бывает, что тесты часами работают), и т.д.
А к разработчику-то какие требования в связи с этим? Ну организовали репо, структуру работы с кодом.
Это делается один раз и в начале проекта. Ну понятно, приходится больше думать над кодом, т.к.
лишний раз гонять компилятор и тесты дорого. Довод, согласен. В мс с компиляцией проще, но думать
тоже желательно.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, VladiCh, Вы писали:
VC>>То что у них есть бизнес зависимости никак не означает, что они не могут деплоиться и скейлиться независимо.
S>Не знаю, насколько это возможно и тем более правильно в мс арх-ре, но допустим при запуске сервису А S>надо сходить в сервис В, т.е. без этого он не сможет работать. Соотв. у нас имеется четкая зависимость. S>Речь идет именно об инициализации, я не думаю, что это правильно так делать в мс арх-ре, но вот надо. S>И вот у нас зависимость при деплое. Про масштабирование не спорю.
Не вижу где здесь зависимость при деплое. Сервис A деплоится отдельно, сервис B отдельно.
Соответственно у приложения есть часто изменяющиеся куски, которые могут деплоиться хоть по несколько раз в день, а есть части которые деплоятся раз в год.
То кто куда ходит при старте не имеет значения.
Это для сравнения с монолитом, который всегда деплоится целиком (что как бы очевидно, на то он и монолит).
Здравствуйте, VladiCh, Вы писали:
S>>Не знаю, насколько это возможно и тем более правильно в мс арх-ре, но допустим при запуске сервису А S>>надо сходить в сервис В, т.е. без этого он не сможет работать. Соотв. у нас имеется четкая зависимость. S>>Речь идет именно об инициализации, я не думаю, что это правильно так делать в мс арх-ре, но вот надо. S>>И вот у нас зависимость при деплое. Про масштабирование не спорю. VC>Не вижу где здесь зависимость при деплое. Сервис A деплоится отдельно, сервис B отдельно.
Темпоральная зависимость же -- сначала приходиться деплоить В, затем А. Это ниразу не критично,
но все же зависимость сохраняется хотя на уровне деплоя.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Если у нас монолиты запущены на нескольких машинах -- через gateway или шину, то, наверное, можно говорить S>>о распр. системе. НС>Наверное?
Цепляетесь к словам? Прекрасно.
S>>Если я где-то (где?) утверждал обратное, то был неправ. НС>Ты утверждал что при разработке монолита знания о распределенных системах не нужны.
1) Возможно, хотелось бы цитату целиком.
2) Что нужно, можно грубо прикинуть.
Далее, у нас имеется разработчик модуля в монолите, который пишет сугубо свой доменный код, взаимодействует
с 2-3 другими модулями подсистемы, и ему для работы нужен доступ к бд. Он в курсе про ООП, паттерны, sql.
Все зависимости он получает через IoC, например, через конструктор.
Где у него могу возникнуть проблемы при работе над монолитом? Кроме бд я ничего такого больше не вижу,
все остальное находится в адресном пространстве процесса. Вот у нас возникли проблемы с бд по среди доменных
вычислений или бизнес операций, т.е. что-то не так
с сетью (одно из "The network is reliable", "Latency is zero", "Bandwidth is infinite" ). Что он
может сделать? Ну выставит таймаут, ну стрельнет таймаут, попробует повторить операцию, после
повторов ему ничего кроме как залоггировать ошибку и прокинуть исключение в вызывающий код
делать больше не надо. Более того, а что он собственно, кроме повторов может сделать?
О consistency думать ему не надо, за это движок бд отвечает или соседний модуль. Локально что-то сохранить?
Ну, зависит от. Про рестарты в рамках монолита думать ему тоже не надо.
Ну и что ему нужно знать о распределенных системах?
По сути кроме "The network is reliable",
т.е. могут быть проблемы со взаимодействием с бд, которые выражаются в таймауте, и которые
как-то через повторы можно обработать или прокинуть исключение наверх, больше особых знаний и не требуется.
Рассмотрим теперь ту же ситуацию, но в микросервисной арх-ре. Соотв. взаимодействие с 2-3 другими
модулями у нас распределено, т.е. через сеть. Далее цитата:
На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет. Распределенные транзакции идее микросервисов противоречат и технически вряд ли возможны (у каждого сервиса может быть свой стек технологий). Эта неконсистентность сразу вызывает вопросы надежности (reliability). Очень часто нужно уметь надежно доставлять состояние между сервисами. Или надежно знать, что данные не доставлены. А в HTTP есть состояние неопределенности. Запрос отправили, ответ не получили. И вот что это значит? Сервер запрос вообще не получил? Или получил, обработал, но ответ отправить не сумел? Поэтому практически в каждом с сервисе с зависимостями возникает необходимость повторов (retry) и соответствующих внутренних состояний. Кроме того, в сервисах с зависимостями есть проблема устойчивости (robustness). Например, сервис A вызывает сервис Б. Сервис Б обычно отвечал за 10 миллисекунд, а стал — за 10 секунд. Вопрос — что будет с сервисом A? Я видел ситуацию, когда пул HTTP-соединений между A->Б был установлен в настройки по умолчанию (и это было четыре соединения). Поэтому все операции выстраивались в длинную очередь и латентность ответов от А взлетала до небес.
Т.е. теперь взаимодействие с 2-3 другими модулями это лютый головняк -- много что может пойти не так, и это
многое надо уметь корректно обрабатывать. Т.е. требования к написанию кода многократно возросли, это теперь не просто
вызвать ф-ию. Это простое взаимодействие с 2-3 модулями, это еще даже до CAP не дошли. Да и сложности предметной области
никуда не делись.
The architecture introduces additional complexity and new problems to deal with, such as network latency, message format design,[50] Backup/Availability/Consistency (BAC),[51] load balancing and fault tolerance.[44] All of these problems have to be addressed at scale. The complexity of a monolithic application does not disappear if it is re-implemented as a set of microservices. Some of the complexity gets translated into operational complexity.[52] Other places where the complexity manifests itself is in increased network traffic and resulting slower performance. Also, an application made up of any number of microservices has a larger number of interface points to access its respective ecosystem, which increases the architectural complexity.[53] Various organizing principles (such as HATEOAS, interface and data model documentation captured via Swagger, etc.) have been applied to reduce the impact of such additional complexity.
В общем, дело дрянь -- знать надо до фига и больше, а не только со стула не падать.
S>>С трудом представляю такую арх-ру с RabbitMq. НС>Я вроде нигде не писал что нужно именно rmq использовать.
Зачем вообще mq какое-то использовать, если самодельного буффера за глаза хватит?
окружающей среды.
, благодарю.
