Здравствуйте, SkyDance, Вы писали:
SD>Что считать рефакторингом?
code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.
SD>И где граница работы команды?
Какой команды?
SD> Вот, скажем, может ли команда выбирать технологии для постройки микросервиса? А до какого уровня? А можно вместо Linux использовать FreeBSD?
Контейнеры же.
SD> А вместо виртуалок — bare metal?
С кубером это не особо совместимо, а остальные оркестраторы, даже если кто то из них умеет управлять голым железом, медленно и стабильно сползают в маргинальщину.
SD>Но ведь ей, инфре, тоже нужно развиваться. А для этого нужно и рефакторинг производить. Да, в инфре. Это равносильно рефакторингу всех микросервисов сразу.
Далеко не всегда. И это, чаще всего, либо вообще не затрагивает код и команды, его пишущие, либо затрагивает слабо.
SD>О, золотые слова Как обычно, все упирается не в технологии, а в людей и масштабы.
Упирается и в технологии, и в людей, и в кучу чего еще, и оно все между собой сильно связано. А логика "раз у нас с людьми есть проблемы мы положим на технологии болт" работает фигово.
Здравствуйте, Sharov, Вы писали:
S>Serverless, это разве не оно?
Нет, не оно. Это ортогональное понятие. Serverless вполне себе работает вместе с микросервисами. В том же ажуре кластер AKS вполне может выделять и классические виртуалки под ноды, и использовать ACI.
Здравствуйте, SkyDance, Вы писали:
SD>То есть с помощью микросервисов можно "масштабировать компанию". Но не в плане возможностей. А всего лишь в количестве наемных работников, суть расходов на R&D.
Это ты, фактически, процитировал определение микросервисов. С этим кроме Sharov кто то тут не согласен?
SD> Сам продукт при этом поначала будет развиваться быстрее. Это факт, ибо развитие идет в долг (создаются копии, параллельные сервисы, дубликаты инфры и т.п.). Но потом наступает довольно резкая остановка в развитии,
Ровно как и в случае монолита. Причем в микросервисах эта остановка наступает позднее. Ценой того, что само развитие идет заметно медленее монолита.
SD> потому что система превращается в распределенный монолит
Это почему вдруг она обязана превратиться в монолит? При соблюдении ряда базовых принципов этого не должно происходить.
Здравствуйте, SkyDance, Вы писали:
SD>Ха. То есть давайте самую сложную часть системы назовем "инфраструктурой"
Вот так, без каких то уточнений, это крайне спорное заявление. В текущем проекте, к примеру, инфраструктура отъедает процентов 10-15 общих ресурсов на разработку. И, что интересно, после релиза эта доля довольно активно начинает сокращаться.
SD> и заметем проблему туда, под коврик.
Никто ее не заметает. Еще раз — микросервисы это про разделение компетенций. В микросервисах инфраструктурой занимаются не авторы сервисов и даже не программисты, а специальные люди со специфической компетенцией — девопсы.
А вот если посадить заниматься инфрой программистов — тут да, легко можно потратить на нее больше половины разработки.
SD>Сам процесс поэтапного переезда и есть проект высочайшей сложности
Он может и высочайшей, но по этому пути уже многие прошли, и повторяемость решений там намного выше реюза в коде.
SD>Иногда еще эту инфраструктуру называют "платформой".
Никогда не слышал. Платформой обычно обзывают код и базовый слой библиотек и сервисов (что то типа SDK). А инфраструктура это оркестратор и сервисы, создаваемые вне собственных команд.
SD> И там нужны самые сильные кадры.
Нужны. Поэтому средняя зарплата девопса выше средней зарплаты программиста. Но девопсов нужно сильно меньше (при достаточном размере проекта, разумеется).
Здравствуйте, SkyDance, Вы писали:
SD>Нормальная такая пратика, нарезАть серверы за $400/мес по 32 пода, и каждый продавать поа по $60/мес (дешевые DigitalOcean) или ~$120/мес (AWS).
Тарифицируются обычно не поды, а ноды (в serverless некие попугаи CPU). Количество нод определяется не количеством подов, а нагрузкой. А сколько там подов ты на одну ноду взгромоздишь — неважно, главное лимиты правильно выставить.
SD>Теперь представь, что какой-то особо ретивый инженер заявил "а я свой микросервис хочу писать на расте, делайте мне развертывание, масштабирование, и прочие логгинги,
И при чем тут раст? От ретивого инженера требуется не раст, а готовый контейнер. А уж как он его соберет — его личные половые трудности.
Здравствуйте, Ночной Смотрящий, Вы писали:
SD>> А вместо виртуалок — bare metal? НС>С кубером это не особо совместимо
Всё вполне совместимо. Видел реализованную на K8s систему, где внутри контейнеров запускаются вложенные виртуалки. Работает поверх того самого bare metal.
Выглядит немного странно, но с задачей справляется.
Здравствуйте, Ночной Смотрящий, Вы писали:
SD>>То есть с помощью микросервисов можно "масштабировать компанию". Но не в плане возможностей. А всего лишь в количестве наемных работников, суть расходов на R&D. НС>Это ты, фактически, процитировал определение микросервисов. С этим кроме Sharov кто то тут не согласен?
С чем конкретно я не согласен и спорю помимо требований к квалификации к разработчикам микросервисов?
Здравствуйте, VladiCh, Вы писали:
VC>Ну это не обязательно, чтоб распределенный монолит получить это еще постараться надо. Это как — сервисы завязаны один на другой и не могут деплоиться независимо? VC>Разные сервисы работают с одной и тем же слоем хранения? Ну как бы сделать то такое конечно можно, но кто в здравом уме будет?
Ну все сервисы зависят от авторизации например, и без этого сервиса ничего работать не будет. Также и возможны некоторые бизнес
зависимости, т.е. доменные зависимости, которые и на уровне микросервисов сохраняются. Вот и распределенный монолит.
Здравствуйте, Sharov, Вы писали:
SD>>>То есть с помощью микросервисов можно "масштабировать компанию". Но не в плане возможностей. А всего лишь в количестве наемных работников, суть расходов на R&D. НС>>Это ты, фактически, процитировал определение микросервисов. С этим кроме Sharov кто то тут не согласен? S>С чем конкретно я не согласен и спорю
С определением.
Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа.
Здравствуйте, Cyberax, Вы писали:
НС>>С кубером это не особо совместимо C>Всё вполне совместимо. Видел реализованную на K8s систему, где внутри контейнеров запускаются вложенные виртуалки. Работает поверх того самого bare metal. C>Выглядит немного странно, но с задачей справляется.
Да понятно что напильником можно доточить. Но это, мягко говоря, не самое распространенное решение.
Здравствуйте, Sharov, Вы писали:
S>Ну все сервисы зависят от авторизации например, и без этого сервиса ничего работать не будет.
Совсем не обязательно. Иногда внутри кластера DMZ, так что аутентификация нужна только внешним сервисам. А внешние сервисы иногда в одном экземпляре, например используется API Gateway. Так что вся эта аутентификационная шняга касается только одного сервиса в системе.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>С определением. НС>
НС>Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа.
Это естественно, т.к. сначала появилась концепция, потом началось внедрение. Испытателей концепции было немного,
по сравнение с общим числом компаний и бизнесов. Это факт. А вообще спор начался из-за требований к квалификации.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну все сервисы зависят от авторизации например, и без этого сервиса ничего работать не будет. НС>Совсем не обязательно. Иногда внутри кластера DMZ, так что аутентификация нужна только внешним сервисам. А внешние сервисы иногда в одном экземпляре, например используется API Gateway. Так что вся эта аутентификационная шняга касается только одного сервиса в системе.
Это не опровергает тезис бизнес зависимостей. Т.е. сервис A зависит от сервиса B, который зависит от С.
Т.е. имеет смысл вообще было разбивать сервисы на A,B,C или лучше монолит ABC?
Т.е. крайне высокая связанность в самой предметной области.
НС>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?
Т.е. мс, работающий на одном сервере это ок?
S>>Еще вопрос -- вот у нас монолит, с кучей dll и отличнейший loose coupling, продуманный api, интерфейсы и т.п. S>>Т.е. один exe и много dll, чем это не микросервисная арх-ра? НС>Тем что связность модулей намного выше. Зачем задавать один и тот же вопрос несколько раз, если уже написан ответ?
А почему связанность модулей намного выше? Если взаимодействие через api, in-proc rest какой-нибудь?
Т.е. никакой связанности кроме единого адресного пр-ва я не вижу.
S>>По-разному: от ui desktop, до обработчиков в сервиcной арх-ре с rmq. Т.е. экземпляров много (процесса), но машина одна. НС>RMQ на одной машине? Необычная архитектура.
RMQ -- это отдельная машина в сети, а мн-во обработчиков на др. машине, которые прослушивают очередь rmq.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Серьезно, а специфика чего здесь есть? Монолитов? НС>Здесь специфика современных средств деплоймента. Просто в микросервисах оно критично, а с монолитами еще можно пытаться жить по старинке, с виртуалками. Но, в целом, для новых проектов однозначно следует предпочесть контейнеры, вне зависимости от архитектуры.
Как Вы себе представляете монолит на контейнерах? Т.е. вместо 10 маленьких 2 больших контейнера?
S>>>>Писать код, который корректно и грамотно работает с локальным состоянимем, НС>>>Здесь нет специфики микросервисов. S>>Как же нет, когда надо писать код так, чтобы можно было как минимум легко перезапустить сервис.
НС>Возможность перезапуска критична для любой архитектуры, включая монолиты.
Для монолитов этот код надо писать не всем разработчикам.
S>>Т.е. не только бизнес логика, а еще специфика окружения -- распределенная система. НС>Еще раз — распределенная система это не эквивалентное понятие микросервисам. Распределенность диктуется в первую очередь твоими задачами, и если требования по перфу выше того, что способна одна машина — у тебя просто других вариантов нет, при любой архитектуре. НС>А вот если тебе хватает с запасом одного сервера, и нет никаких требований HA и запрета на даунтайм даже при обновлении версии, то микросервисы точно не для этого кейса. И для маленькой команды на весь продукт микросервисы тоже негодный выбор.
То что они не эквивалентны согласен, но ведь микросервисная арх-ра осуществляется поверх распр. систем, т.е.
одна кодовая база разнесена по разным машинам. Т.е. говорим микросервисы на концептуальном уровне, понимаем
распр. систему как реализацию этой концепции. Т.е. на одной машине мс никто же не делает
S>>На этом форуме писали, что суть микросервисов это изоляция хранилища, НС>Не видел такого, чтобы именно суть. Но если писали, то это глупость. Суть микросервисов — выделение сравнительно небольшого функционала в сервис, связанный с остальным функционалом только через REST API (grpc, message bus etc). А изоляция хранилищ уже следствие, так как при расшаривании хранилища между несколькими сервисами между ними появляются плохо контролируемые паразитные связи.
У меня (было) ровно такое же понимание, но объяснили что суть именно в изоляции хранилища.
Если у нас нет никакого состояния, то разве это не serverless? Т.е. просто вызов отдельных ф-ий.
НС>При этом никакого абсолютного запрета нет. Если у тебя уже есть legacy БД с долгой историей разработки, толстым слоем изоляции средствами БД (хранимки и вьюхи) и целой кучей заинтегрированного через нее софта (совершенно типичная ситуация для крупных банков со своими отделами разработки, к примеру), то нужно быть безумцем чтобы пытаться нарезать ее на микрокусочки.
Хе-хе, именно этим сейчас все и занимаются. Как минимум на российском рынке, на хх, регулярно пишут про распил монолита на мс.
S>>>>Она предъявляет большие требования к квалификации чем монолит. НС>>>К кому то большие, к кому то меньше. В девопсам большие, к разработчикам меньшие. S>>К девопсам не то что больше, они появились благодаря этому подходу.
S>>Бизнес код остался таким же, но писать его надо с учетом совершенно другой, ненадежной, среды. НС>Монолит точно так же ненадежен, и даже еще менее (ты вот явно не заморачиваешься НА и хелсчеками). ИМХО ты опять путаешь распределенные решения и микросервисы. НС>Опять же, для совсем ленивых есть istio, который утаскивает все заморочки с ненадежностью типа ретраев на инфраструктурный уровень, оставляя код без этих заморочек.
Не уверен я, что это проходит мимо разработчиков мс. А если и мимо, то не бесплатно. В монолитах об этом явно не всем
разработчикам надо беспокоится.
S>>>>, но у всего есть цена, всяческих объвязок и прочей инфраструктуры стало больше. НС>>>И? Ты к чему ведешь? Что микросервисы не серебряная пуля? Да кто бы сомневался. S>>Я ни к чему не веду. Мы начали с полярного понимания к требованиям квалификации программистов микросервиса. S>>Таки требования в случае мс к ним больше. НС>Ты не смог пока этого доказать.
Почему я это должен доказывать? Заявление было что для мс требования к квалификации разработчиков ниже, а не выше.
Пока все что Вы написали в пользу своего довода сводится к тому, что требования к квалификации никак не меньше чем
для разработчиков монолитов. Т.е. защита довода строится на том, что к разработчикам монолитов такие же требования,
как и к мс, т.е. 1:1. А выигрыш тогда где?
НС>У тебя какое то очень странное понимание того, что требуется именно от программистов в случае микросервисов. В то время как на практике код типичного микросервиса кардинально проще аналогичного модуля монолита, сложность зачастую на уровне студенческого курсового и примерно такие же требования по качеству реализации. Сложность, она не в том чтобы прочитать какой нибудь простенький rest guidlines или прочий толмуд про основные шаблоны микросервисов. Сложность в том чтобы написать простой и качественный код, и вот тут монолиты однозначно в большом проигрыше, просто в силу объема и связности кодовой базы, а так же потенциальным эффектам от проблем в ней. И чем сложнее система в целом, тем больше микросервисы выигрывают в плане требований к квалификации над монолитом.
Все так, согласен. Но это простота бизнес кода приходит не бесплатно, а с учетом ненадежной (враждебной окружающей среды.
Т.е. сложность переехала в другое место. Ее не стало меньше, она стала другой. И вот это "другое" не факт что проще предыдущей сложности,
соотв. и квалификация должны быть выше.
Здравствуйте, Sharov, Вы писали:
S>Это естественно, т.к. сначала появилась концепция, потом началось внедрение.
Не в этом случае. Так было с SOA. А вот с микросервисами ситуация обратная — сперва были реальные системы, а потом уже действующие подходы оформили в концепцию.
Здравствуйте, Sharov, Вы писали:
S>>>Но почему сразу микросервисную? НС>>Кто сказал что сразу микросервисную? S>А о чем у нас тут спор?
Я тебе этот вопрос первый задал.
S>>>А как в мире разработки ПО что-либо контролируется? НС>>Ты это серьезно спрашиваешь? S>Что не так с вопросом ?
Странно слышать от разработчика вопрос как контролируются те или иные ограничения на архитектуру системы.
S>
НС>>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?
S>Т.е. мс, работающий на одном сервере это ок?
В проде? Нет.
НС>>Тем что связность модулей намного выше. Зачем задавать один и тот же вопрос несколько раз, если уже написан ответ? S>А почему связанность модулей намного выше?
Ты зачем мне задаешь вопросы, на которые уже получил ответ?
S> Если взаимодействие через api, in-proc rest какой-нибудь?
Если. И даже если так — остается связность по потребляемым ресурсам (CPU, mem), по проходу по памяти, по используемым технологиям (managed и unmanaged код объединять не самое удобное решение, к примеру), по скейлингу, и что самое важное — по процедуре деплоймента.
S>>>По-разному: от ui desktop, до обработчиков в сервиcной арх-ре с rmq. Т.е. экземпляров много (процесса), но машина одна. НС>>RMQ на одной машине? Необычная архитектура. S>RMQ -- это отдельная машина в сети, а мн-во обработчиков на др. машине, которые прослушивают очередь rmq.
Все обработчики на одной машине, при этом message broker выделен в отдельный сервис — тоже весьма странное решение. message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process.
Здравствуйте, Sharov, Вы писали:
S>Как Вы себе представляете монолит на контейнерах?
А в чем проблема?
S>Т.е. вместо 10 маленьких 2 больших контейнера?
1 контейнер на один под, при чем тут микросервисы? Да и сайдкары в монолите могут понадобиться, если решения сторонние, например minio или opa.
НС>>Возможность перезапуска критична для любой архитектуры, включая монолиты. S>Для монолитов этот код надо писать не всем разработчикам.
И в микросервисах тоже не всем. Пока у тебя нет необернутого в транзакции изменения персистентного стейта тебе не нужно париться по поводу рестарта, что в мололите, что в микросервисах. А если есть — надо и там и там.
В очередной раз убеждаюсь что у тебя какое то очень странное понимание микросервисов.
S>То что они не эквивалентны согласен, но ведь микросервисная арх-ра осуществляется поверх распр. систем, т.е.
Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов. Нет распределенности — не нужны никакие микросервисы. А потребность в распределенности определяется продуктовыми требованиями, а не архитектурой.
Ты с чего то себе вбил в голову, что монолит это непременно деплоймент на одну машину, отсюда твои странные заявления по поводу микросервисов.
S>Если у нас нет никакого состояния, то разве это не serverless?
Господи, какая каша у тебя в голове. Если у нас нет состояния, то это классический stateless сервис, каким он и должен быть, неважно микро или классический SOA монолит.
А serverless это про облака и способ выделения ресурсов, когда вместо виртуалок (серверов) с поштучной тарификацией под ноды ты получаешь некий абстрактный запускатель контейнеров с тарификацией по потребленным при работе попугаям CPU и/или памяти. AWS lambda и Azure function это просто один из вариантов serverless, самый примитивный. В контексте микросервисов serverless это что вроде AWS Fargate или ACI
S>Хе-хе, именно этим сейчас все и занимаются.
Кто все?
S>Как минимум на российском рынке, на хх, регулярно пишут про распил монолита на мс.
Распил монолита не означает распила БД с историей разработки в десятилетия. Из того что я от тех кто приходит на собеседования слышал пилят как правило веб-сервисы со своей собственной БД, причем эта БД зачастую что то простенькое типа MySQL с минимумом логики, а то и с code first подходом. А вот чтобы банк свой опердень на микросервисы пилил — про такое я не слышал.
НС>>Опять же, для совсем ленивых есть istio, который утаскивает все заморочки с ненадежностью типа ретраев на инфраструктурный уровень, оставляя код без этих заморочек. S>Не уверен я, что это проходит мимо разработчиков мс.
Учитывая твой нулевой опыт в микросервисах — не вижу смысла твою уверенность обсуждать. Аргументы есть, или одни ощущения?
S>>>Таки требования в случае мс к ним больше. НС>>Ты не смог пока этого доказать. S>Почему я это должен доказывать? Заявление было что для мс требования к квалификации разработчиков ниже, а не выше.
И было приведено обоснование, почему. А в ответ ничего путного ты возразить не можешь, одна "баба яга против". Есть что по делу возразить или одни ощущения?
S>Пока все что Вы написали в пользу своего довода сводится к тому, что требования к квалификации никак не меньше чем S>для разработчиков монолитов.
Ну что за бред?
S>как и к мс, т.е. 1:1. А выигрыш тогда где?
В изоляции узких доменов, как следствие в уменьшении размеров конкретных сервисов, снижении требований к суммарной компетенции команды, вынесение инфраструктурных компетенций за пределы сервиса и даже разрабатываемого программного кода, в возможности более тонкой настройки масштабируемости, в возможности независимого деплоймента небольших частей системы, в большей свободе по выбору инструментальных средств и подходов к разработке каждой конкретной командой, в снижении требований на коммуникации между командами. Статья в википедии содержит развернутый ответ.
Я последний раз отвечаю на этот вопрос. Если захочется еще раз спросить — предыдущие сообщения в твоем распоряжении.
S>Все так, согласен.
Не похоже.
S>Но это простота бизнес кода приходит не бесплатно, а с учетом ненадежной (враждебной окружающей среды.
Опять какие то ощущения или есть конкретика?
S>Т.е. сложность переехала в другое место. Ее не стало меньше, она стала другой.
Только часть этой сложности переехала в cloud native софт, который уже написан. Тебе не надо, как в монолите, самому писать свой собственный велосипедный кубер, к примеру.
Здравствуйте, Sharov, Вы писали:
S>Это не опровергает тезис бизнес зависимостей. Т.е. сервис A зависит от сервиса B, который зависит от С. S>Т.е. имеет смысл вообще было разбивать сервисы на A,B,C или лучше монолит ABC?
Если нет потребности в независимом скейлинге и в независимых релизах — можно и монолит. Только это не монолит в привычном понимании, просто домен довольно крупный. Так чтобы этот домен был размером с весь кластер — ну очень вряд ли.
S>Т.е. крайне высокая связанность в самой предметной области.
Нет такого в предметной области. Связность это не про предметную область, а про конкретную архитектуру.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Это естественно, т.к. сначала появилась концепция, потом началось внедрение. НС>Не в этом случае. Так было с SOA. А вот с микросервисами ситуация обратная — сперва были реальные системы, а потом уже действующие подходы оформили в концепцию.
А как много было реальных систем, чтобы можно было с уверенностью сказать, что это правильный путь развития?
Т.е. почему было понятно, что если это работает у Нетфликса или гугла, то заработает и в фирме на 20 программистов?
Как обычно, все упирается не в технологии, а в людей и масштабы.
окружающей среды.