Здравствуйте, Sharov, Вы писали:
VC>>Не вижу где здесь зависимость при деплое. Сервис A деплоится отдельно, сервис B отдельно. S>Темпоральная зависимость же -- сначала приходиться деплоить В, затем А. Это ниразу не критично, S>но все же зависимость сохраняется хотя на уровне деплоя.
Это можно решить двумя путями (или даже обоими):
1. Сервис А может деплоиться и без сервиса B. Он просто ждёт когда станет доступным B и завершит свою инициализацию.
2. Сервис B сделать постоянно доступным. Запустить в нескольких экземплярах. Если один экземпляр упал/обновляется, обслуживанием сервиса А занимается другой экземпляр.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Явно не с этим. НС>Тогжа как понимать это? НС>
НС>Dockerfile писать надо? Надо. Т.е. надо изучать docker.
Ну, хорошо, используйте для монолитов docker. Я не против.
S>>Разработчику какого-нибудь компонента монолита зачем ломать об этом голову? НС>А кому ломать? Если компонент полагается на нетранзакционный персистентный стейт — кто должен бороться с последствиями сбоев? И чем, по твоему, нужно бороться авторам микросервисов?
Если. А если транзакционный?
НС>Вобщем, давай вместо общих фраз ты продемонстрируешь конкретную проблему, которую нужно решать в микросервисе и не нужно в монолите.
S>> Т.е. мы выяснили, что распределенная система может строится, например, на монолитах. НС>Не мы, а ты.
Я -- молодец!
S>>неверно. НС>Просто ты неверно понял что написано. Или сделал вид, когда аргументы кончились.
Просто у Вас в голове одно, а пишите другое. Бывает. На всякий случай, я все несостыковки процитировал.
S>>Или казуистикой, уводом темы в сторону, вопросом на вопрос или переходом на личности. НС>Переход на личности начался с того, что ты вместо аргументации начал применять обороты вроде "я не уверен". Ну и чего мне с твоей неуверенностью делать?
Я в пред. сообщение не мало написал в качестве аргументации, с ссылками. "Я не уверен" там не было. Речь про возросшие
требования к квалификции разработчиков мс.
НС>>>Да. Ты же зачем то пытаешься доказать что она другая. Да, другая. Но другая не значит больше. S>>Да, пытаюсь. От разработчиков мс требуется существенно больше компетенций в такой непростой среде как S>>распределенные системы.
НС>И существенно меньше в такой непростой среде как огромный монолитный проект. И? НС>При этом, как мы вроде бы разобрались, от компетенций в распределенности монолит нифига не спасает.
S>> Т.е. требуется больше экспертизы в распр. системах. НС>Или нет. Ты опять бросаешься бездоказательными утверждениями. Какой конкретно кейс будет проблемой, требующей особой экспертизы в микросервисах, и не будет в монолите?
S>>А можно подробнее, что требуется? НС>Огромное количество знаний и навыков, позволяющих создавать loosely coupled и high cohesion решения. Чем больше размер и сложность кода, тем больше ресурсов и умений надо вкладывать в архитектуру программного кода.
Телега впереди лошади, нет? Обычно когда у нас большой размер и сложность кода, архитектура давно выбрана.
При большом объеме кода и его сложности уже поздно, да и, наверное, проблематично выбирать арх-ру.
S>>Ничего окромя классических паттренов GoF и ООП в голову не приходит, но кто сказал что для S>>мс они не нужны? НС>Тебе точно надо объяснять, что важность и потребность в паттернах прямо зависит от объема кода? Что если у тебя кода десяток килобайт — тащить туда гору сложных паттернов не нужно?
Круть, т.е. паттерны надо применять после определенного кол-ва строчек кода? А он у всех паттернов разный, этот лимит?
MVC при каком кол-ве строчек кода разрешается использовать?
НС>>>и эта экспертиза куда дороже и реже, чем базовый стафф про микросервисы. S>>Возможно. Но, кмк, это экспертиза называется "умение читать и понимать код", НС>Нет, экспертиза называется умение писат легко читаемый и модифицируемый код.
Для мс этот навык не нужен? Мне кажется это навык нужен вообще для всего в мире разработки ПО.
НС>>>А кто то утверждал что у микросервисов нет недостатков? Даже я про некоторые писал тут. Ты опять ломишься в открытые двери. S>>Вы упорно отрицаете вот этот недостаток: S>>
S>> Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications
НС>Ложь. Я отрицаю что монолит позволяет обойтись без skilled.
Согласен полностью. С этим вообще никто не спорит ибо глупо.
Конкретно я спорю с этим
Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.
1)design goal Вы придумали сами, судя по всему, ибо вся наша дискуссия и мои аргументы к требованиям к квалификации говорят
об обратном.
2) Явно что-то путает не maxkar.
S>>Я тоже. НС>Да? А как тогда трактовать "я не уверен" в качестве аргумента?
Вы -- эксперт, я -- нет. Это было сразу заявлено. Что не так? Эксперты тоже могут ошибаться, они тоже люди.
S>> это же не я предложил кубер для монолитов использовать. Вот и думайте что еще. НС>Ну вот, к примеру, update rollout чтобы руками не фигачить. Или автоскейлинг. Cron jobs. Init containers. Да даже, блин, банально Lens использовать для управления кластером. Мало?
Здорово, кубер крутейшая вещь. Как-нибудь инвестирую свое время в эту технологию.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нужно умение хорошо структурировать код. И чем больше размер монолита, тем важнее это умение.
Монолит здесь ни при чем. Размер проекта имеет значение независимо от монолитности.
НС>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.
Микросервис страхует всего лишь от побочных эффектов в других компонентах. При этом никто не мешает иметь рядом мутную солянку common, utils, helpers куда валят вообще все подряд, буквально. А бывает таких "пакето-репозиториев" не один, а куча. Тогда получается, что бы разобраться хотя бы в одном микросервисе, надо разобраться в 90% кода проекта Если вдруг фиксануть чего — кроме как чудом трудно предложить годный вариант, что бы ничего не сломать.
Здравствуйте, Sharov, Вы писали:
S>>>Если у нас монолиты запущены на нескольких машинах -- через gateway или шину, то, наверное, можно говорить S>>>о распр. системе. НС>>Наверное? S>Цепляетесь к словам? Прекрасно.
Это не к словам, это к сути.
НС>>Ты утверждал что при разработке монолита знания о распределенных системах не нужны. S>1) Возможно, хотелось бы цитату целиком.
На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования. Требования к программисту микросервисов -- тоже самое + знание распределенных систем, ну хотя бы на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
S>Где у него могу возникнуть проблемы при работе над монолитом?
Там же, где и у микросервисов — при наличии расшариваемого между инстансами стейта. А если стейт не шарится, то и у микросервисов с распределенностью проблем особых нет.
S>Кроме бд я ничего такого больше не вижу,
Да действительно, такая мелочь — БД. Правда, если подумать, помимо БД есть еще редис, твой любимый кролик, прометей, эластик, сторадж облачный, балансер/ингресс. А опционально еще какой нибудь консул/волт или аналоги, opa. А есть ведь еще обычно какой то фронт, иногда не один, да?
S>все остальное находится в адресном пространстве процесса.
Это только если у тебя опять монолит это строго одна машина. А если несколько инстансов у нее?
S>может сделать? Ну выставит таймаут, ну стрельнет таймаут, попробует повторить операцию
Или воткнуть кролик, да?
S>делать больше не надо. Более того, а что он собственно, кроме повторов может сделать?
А что может сделать автор микросервиса?
S>О consistency думать ему не надо, за это движок бд отвечает или соседний модуль.
Так и микросервисы обычно stateless, а стейт, внезапно, где то в БД.
S>Ну, зависит от. Про рестарты в рамках монолита думать ему тоже не надо.
Надо. Пишешь ты на локальный диск в файл, и тут рестарт. На диске — мусор. Думать не надо, да? Отличный рецепт.
S>По сути кроме "The network is reliable",
Скажу тебе по секрету — если ты в микросервисах на внутрикластерную сеть забьешь и будешь считать что "The network is reliable", то, скорее всего, ничего совсем уж ужасного не случится, вероятность сбоя там крайне мала.
S>как-то через повторы можно обработать или прокинуть исключение наверх, больше особых знаний и не требуется.
Ты не поверишь, но в микросервисах все тоже самое.
S>На архитектурном уровне вместе с микросервисами приходит eventual consistency.
Или не приходит. А если приходит, то эта забота ложится на плечи готовых решений типа тех же nosql БД.
S> В монолите можно сделать большую транзакцию
В распределенном монолите — нельзя.
S>В общем, дело дрянь -- знать надо до фига и больше, а не только со стула не падать.
Ты реально игноришь все что я пишу. Надо знать специфику не означает надо знать больше. У монолитов своя специфика. Я уж не говорю о том, что ничего не знать про распределенные системы в монолите можно только в вырожденном случае, когда не нужно ни скейлинга ни НА.
Для примера — тебе, в силу перфоманса твоих хранилищ, понадобился шардинг. Ты правда думаешь, что в монолите при этом можно не обладать теми самыми специфичными знаниями про распределенные системы?
S>>>С трудом представляю такую арх-ру с RabbitMq. НС>>Я вроде нигде не писал что нужно именно rmq использовать. S>Зачем вообще mq какое-то использовать, если самодельного буффера за глаза хватит?
Именно это я и предложил. Опять ты ломишься в открытые двери.
Здравствуйте, Sharov, Вы писали:
S>Ну, хорошо, используйте для монолитов docker. Я не против.
Т.е. знание докера из уравнения убираем.
S>>>неверно. НС>>Просто ты неверно понял что написано. Или сделал вид, когда аргументы кончились. S>Просто у Вас в голове одно, а пишите другое.
Просто я не собираюсь раскрывать в каждой фразе весь контекст полностью, полагаюсь на сообразительность собеседника. Писать с постоянной оглядкой за возможность прицепиться к слову я не буду, мне такая беседа неинтересна.
S>>>А можно подробнее, что требуется? НС>>Огромное количество знаний и навыков, позволяющих создавать loosely coupled и high cohesion решения. Чем больше размер и сложность кода, тем больше ресурсов и умений надо вкладывать в архитектуру программного кода. S>Телега впереди лошади, нет?
Моя твоя непонимать.
S>Обычно когда у нас большой размер и сложность кода, архитектура давно выбрана.
Серьезно? Ты еще веришь что архитектуру можно заранее выбрать и больше к ней не возвращаться?
S>При большом объеме кода и его сложности уже поздно, да и, наверное, проблематично выбирать арх-ру.
Нет, не поздно. Рефакторинг, по твоему, для чего нужен?
НС>>Тебе точно надо объяснять, что важность и потребность в паттернах прямо зависит от объема кода? Что если у тебя кода десяток килобайт — тащить туда гору сложных паттернов не нужно? S>Круть, т.е. паттерны надо применять после определенного кол-ва строчек кода?
Открыл для себя новое?
S>А он у всех паттернов разный, этот лимит?
Конечно.
S>MVC при каком кол-ве строчек кода разрешается использовать?
Не надо все сводить до абсурда. Давай я тебе примером проиллюстрирую. Вот есть такой паттерн Посетитель. Если у тебя 2 реализации — точно нужно его использовать, вместо того чтобы написать просто свитч? А если реализаций 50 штук — разумно ли будет писать свитч на 50 кейсов?
Еще примеры — будешь ли ты в небольшой консольной утилитке использовать DI container? А в большом веб-сервисе? Нужно ли выделять DAL в отдельный слой, если в DAL всего пара примитивных методов? Нужно ли использовать CQRS если у тебя в публичном API методов штук 5? Нужно ли использовать chain of responsibility, если у тебя всего один аспект и вероятность что появится еще один низка?
И дело не только в паттернах. Нужно ли разбивать на сборки/dll проект из десятка кб исходников? А проект из сотни мб?
НС>>Нет, экспертиза называется умение писат легко читаемый и модифицируемый код. S>Для мс этот навык не нужен?
Менее важен.
S> Мне кажется это навык нужен вообще для всего в мире разработки ПО.
Это не битовый флаг, есть/нет.
S>Согласен полностью. С этим вообще никто не спорит ибо глупо.
Тогда тебе таки придется доказать, что для микросервисов скилов нужно больше.
Давай проиллюстрирую. Вот создание современного фронта на каком нибудь реакте требует определенных специфических знаний по сравнению с классическим каким нибудь фреймворком с серверным рендерингом — JS, сам реакт. Значит ли это, что создание фронта на реакте требует большей квалификации, чем создание фронта, скажем, на ASP.NET MVC с разором?
S>>>Я тоже. НС>>Да? А как тогда трактовать "я не уверен" в качестве аргумента? S>Вы -- эксперт, я -- нет. Это было сразу заявлено. Что не так?
То что ты, не являясь экспертом, при этом используешь свою неуверенность в качестве аргумента. Если ты не уверен, пиши "я не уверен потому что ...", а дальше подробно, что конкретно вызывает у тебя сомнения.
Здравствуйте, Ikemefula, Вы писали:
НС>>Нужно умение хорошо структурировать код. И чем больше размер монолита, тем важнее это умение. I>Монолит здесь ни при чем. Размер проекта имеет значение независимо от монолитности.
Монолит еще как причем, потому что порождает проекты с размером другого порядка по сравнению с микросервисом.
НС>>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API. I>Микросервис страхует всего лишь от побочных эффектов в других компонентах.
Всего лишь. Чувак, я тебе больше скажу — вся архитектура строится поверх ровно двух вещей, loosely coupling и high cohesion. Все остальные принципы и паттерны предназначены чтобы этого достигнуть. Так что да, микросервисы это "всего лишь" способ получить loosely coupling и high cohesion, сущая мелочь для больших систем.
I>При этом никто не мешает иметь рядом мутную солянку common, utils, helpers куда валят вообще все подряд, буквально.
Я тебе напомню — в микросервисах предполагается, что команды тоже поделены по микросервисам. И общаются микросервисы только через REST API, это гарантируется структурой деплоймента. Так что солянку в таких условиях надо специально и злонамеренно устраивать.
I>А бывает таких "пакето-репозиториев" не один, а куча. Тогда получается, что бы разобраться хотя бы в одном микросервисе, надо разобраться в 90% кода проекта
Это совсем плохие, негодные микросервисы, не имеющие права использовать гордое имя микросервисной архитектуры.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Монолит здесь ни при чем. Размер проекта имеет значение независимо от монолитности.
НС>Монолит еще как причем, потому что порождает проекты с размером другого порядка по сравнению с микросервисом.
Нужно сравнивать не монолит с микросервисом, а одну реализацию системы с другой. То есть монолитную реализацию с микросервисной.
I>>А бывает таких "пакето-репозиториев" не один, а куча. Тогда получается, что бы разобраться хотя бы в одном микросервисе, надо разобраться в 90% кода проекта
НС>Это совсем плохие, негодные микросервисы, не имеющие права использовать гордое имя микросервисной архитектуры.
Здравствуйте, Sharov, Вы писали:
VC>>Не вижу где здесь зависимость при деплое. Сервис A деплоится отдельно, сервис B отдельно. S>Темпоральная зависимость же -- сначала приходиться деплоить В, затем А. Это ниразу не критично, S>но все же зависимость сохраняется хотя на уровне деплоя.
Кстати, тут как раз интересная особенность есть. Сервисные приложения обычно работают 24/7, без перерывов. И API обычно эволюционирует так, что обратная совместимость никогда не ломается сразу.
Но есть исключение — развёртывание инфраструктуры с нуля. И иногда оказывается, что между сервисами в какой-то момент возникли циклические зависимости. Например, в AWS при развёртывании нового региона, в какой-то момент времени приходилось на начальном этапе использовать DynamoDB и S3 из другого региона. Впоследствии были написаны специальные мини-версии S3 и DDB, которые были достаточным для начального запуска.
Здравствуйте, Ikemefula, Вы писали:
НС>>Монолит еще как причем, потому что порождает проекты с размером другого порядка по сравнению с микросервисом. I>Нужно сравнивать не монолит с микросервисом, а одну реализацию системы с другой. То есть монолитную реализацию с микросервисной.
Зачем, если в микросервисах разработка микросервисов независима? Там, безусловно, есть и вопросы сложности системы в целом, но эти вопросы вынесены за пределы компетенции разработчиков сервиса.
НС>>Это совсем плохие, негодные микросервисы, не имеющие права использовать гордое имя микросервисной архитектуры. I>Ога. Это как бы вариант нормы.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Нужно сравнивать не монолит с микросервисом, а одну реализацию системы с другой. То есть монолитную реализацию с микросервисной.
НС>Зачем, если в микросервисах разработка микросервисов независима?
Совсем необязательно. Нормой является и подход, когда кучка микросервисов мейнтейнятся одной командой. Главное, что бы не было мейнтенанса одного микросервиса разными командами.
Здравствуйте, Ikemefula, Вы писали:
I>>>Нужно сравнивать не монолит с микросервисом, а одну реализацию системы с другой. То есть монолитную реализацию с микросервисной. НС>>Зачем, если в микросервисах разработка микросервисов независима? I>Совсем необязательно.
Обязательно. Иначе это не микросервисы.
I> Нормой является и подход, когда кучка микросервисов мейнтейнятся одной командой.
А другая кучка — другой. А если все микросервисы маинтейнятся одной командой, то в проект такого размера микросервисы втащили очень зря. Если команда только одна ты получаешь все минусы микросервисов и не получаешь почти никаких плюсов.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну, хорошо, используйте для монолитов docker. Я не против. НС>Т.е. знание докера из уравнения убираем.
Типа необходимо уметь им пользоваться и понимать для чего он нужен, так?
Ну т.е. у нас не только сложная кодовая база, при которой натурально в блокноте
приходится писать,
но теперь и докер впихнули. Фортануло, че!
S>>Просто у Вас в голове одно, а пишите другое. НС>Просто я не собираюсь раскрывать в каждой фразе весь контекст полностью, полагаюсь на сообразительность собеседника. Писать с постоянной оглядкой за возможность прицепиться к слову я не буду, мне такая беседа неинтересна.
Т.е., еще разок, вот это вот
НС>Ты перепутал причину и следствие. Не микросервисы требуют распределенной архитектуры, а распределенная архитектура микросервисов.
утверждение неверно, т.к., например, в работах Лесли Лэмпорта годах в 70-х про консенсус в расп. системах ни слова
про микросервисы. Вместо того, чтобы просто признать собственную неточность, использовались следующие отговорки:
1)выхолащенный контекст;
2)я не умею читать
3)(мы здесь)имеется некий скрытый подтекст, т.е. контекст раскрыт не полностью. Т.е. я что-то написал, догадайтесь что
я написал. С нетерпением жду 4-й вариант. Не разочаруйте.
S>>Обычно когда у нас большой размер и сложность кода, архитектура давно выбрана. НС>Серьезно? Ты еще веришь что архитектуру можно заранее выбрать и больше к ней не возвращаться?
Представляете! Такое может быть! Например сейчас в фаворе микросервисная арх-ра. Т.е. на начальных
стадиях это обычно обговаривается и далее идет разработка в соотв. с выбранной арх-ой. Арх-ра может и меняться,
конечно, перенос монолитной арх-ры на мс арх-ру. Но заранее выбрать таки можно.
S>>При большом объеме кода и его сложности уже поздно, да и, наверное, проблематично выбирать арх-ру. НС>Нет, не поздно. Рефакторинг, по твоему, для чего нужен?
Рефакторинг арх-ры? Можно, конечно, но чем это лучше чем переписать с нуля?
S>>Круть, т.е. паттерны надо применять после определенного кол-ва строчек кода? НС>Открыл для себя новое?
Да, буду пользоваться теперь.
S>>А он у всех паттернов разный, этот лимит? НС>Конечно.
S>>MVC при каком кол-ве строчек кода разрешается использовать?
НС>Не надо все сводить до абсурда. Давай я тебе примером проиллюстрирую. Вот есть такой паттерн Посетитель. Если у тебя 2 реализации — точно нужно его использовать, вместо того чтобы написать просто свитч? А если реализаций 50 штук — разумно ли будет писать свитч на 50 кейсов?
50 это хорошо, а почему не 49? Свитч на 49 разумно, а на 36 свитч разумно? Вы понимаете всю абсурдность Ваших аргументов?
НС>И дело не только в паттернах. Нужно ли разбивать на сборки/dll проект из десятка кб исходников? А проект из сотни мб?
Нет, дело именно в паттернах. Я первый раз услышал про количественные метрики применения паттернов, типа
49 свитчей еще рано, а вот 50 уже самое то.
НС>>>Нет, экспертиза называется умение писат легко читаемый и модифицируемый код. S>>Для мс этот навык не нужен? НС>Менее важен.
Докажите, ибо мне видится ровно наоборот -- в больших системах много кода писать не надо,
они написаны, работают, на код стараются не дышать. Да и затруднительно это, писать много
кода в блокноте (см. ссылку выше). Скорее важно уметь читать, т.е. для монолитов важен
навык чтения и понимания. А вот при переходе на мс арх-ру код приходится писать.
Т.е. не менее, а более.
S>> Мне кажется это навык нужен вообще для всего в мире разработки ПО. НС>Это не битовый флаг, есть/нет.
Тем более, к чему тогда был этот довод?
S>>Вы -- эксперт, я -- нет. Это было сразу заявлено. Что не так? НС>То что ты, не являясь экспертом, при этом используешь свою неуверенность в качестве аргумента. Если ты не уверен, пиши "я не уверен потому что ...", а дальше подробно, что конкретно вызывает у тебя сомнения.
Я с самого начала написал, что у меня нету опыта работы над мс арх-ой. Поэтому я стараюсь максимально цитировать более опытных
инженеров, либо внешние источники типа вики. Вот вся моя аргументация.
Кодом людям нужно помогать!
Re[21]: О микросервисах -- требования к квалификации.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тогда тебе таки придется доказать, что для микросервисов скилов нужно больше.
Ну давайте еще разок, попробую это как-то обосновать, ибо не знаю как это логически строго можно доказать.
Буду цитировать свой пред. ответ -- http://rsdn.org/forum/design/8190064.1:
Итак, мы начали с противоположенного мнения к требования квалификации разработчиков в проектах
с микросервисной арх-ой. Я утверждаю, что требования к квалификации разработчиков на подобных проектах выше, Вы -- что ниже.
У меня нету практического опыта над подобными проектами и я об этом сразу оговорился.
Поэтому в своих наблюдениях опираюсь на умозрительные и косвенные наблюдения.
1) Когда человек работает в мс арх-рах ему необходимо вот это все время держать в голове
-- https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Т.е. это не самая простая среда для программирования, требует определенной подготовки, т.е.
как минимум знать и понимать о чем пишут по ссылке. Для монолита, в силу высокой связанности,
многие вещи по приведенной выше ссылки не актуальны. Все натурально может быть в одном адр. пр-ве.
Но на мн-ве серверов, да.
2) Вакансии на хх стали изобиловать некоторым кол-вом новых баззвордов типа докер, k8, инструменты
мониторинга и т.п. Все это требует инвестиций на изучение, и вообще это новые требования к разработчикам,
которых лет 5 назад еще не было. Т.е. вроде обещали простоту, а по факту новые баззворды.
И да, речь идет именно об изучение, чтобы понимать, что под капотом, а не просто черный ящик.
3) За бугром, во фаанг и, следовательно, много где еще, появился новый этап в собеседованиях под
названием System design interview. Есть смутные подозрения, что едва ли людей дрючат на этом
этапе для работы над монолитными арх-ми. Стало быть дело в чем-то другом, в других арх-ых
подходах. Беру на себя смелость (без доказательств!) утверждать, что это необходимо для
разработчиков в микросервисных проектах. Подготовка, т.е. курсы, книги, ютюб, к подобным
интервью это некий прирост в экспертизе и навыках разработчиков. Т.е. помимо всего прочего --
знание языка, бд, dsl вроде sql, предметной области (желательно), добавляется целый пласт
необходимых знаний. С чего это вдруг, когда некоторые утверждают что мс арх-ра чудо как
хороша и разрабатывалась с учетом того, что над соотв. проектами могут работать программисты не самый высокой квалификации.
Натурально со стула не падают -- и хорошо! Дальше мс арх-ра + девопсы вывезут.
. И по косвенным признаками что-то такое говорит SkyDance,
дескать легко злоупотребить и улететь в распределенный монолит. Едва ли квалифицированные
разработчики такое смогут учудить.
Cognitive load
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.
Давайте поймем, что написано:
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.
Т.е. девопсы помогут. Остается понять, смогут ли они помочь настолько, чтобы сработало вот это:
НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой).
Вопрос, конечно, открытый. Далее:
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.
Да,тут, конечно, тяжко приходится. Но не все так плохо:
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.
В общем есть надежда, что жить станет лучше, жить станет веселей.(с)
НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
НС>[q]
НС>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.
НС>https://en.wikipedia.org/wiki/Microservices
[/q]
1) Что за design goal такой? Кто автор(ы)? Можно какие-то ссылки и конкретику кроме общих слов от себя?
2) Какая связь между
it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.
и квалификацией? Почему это как-то должно влиять на квалификацию, а особенно снижает требования к ней?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Где у него могу возникнуть проблемы при работе над монолитом? НС>Там же, где и у микросервисов — при наличии расшариваемого между инстансами стейта. А если стейт не шарится, то и у микросервисов с распределенностью проблем особых нет.
А если шарится, а что надо, чтобы не шарилось?
S>>Кроме бд я ничего такого больше не вижу, НС>Да действительно, такая мелочь — БД. Правда, если подумать, помимо БД есть еще редис, твой любимый кролик, прометей, эластик, сторадж облачный, балансер/ингресс. А опционально еще какой нибудь консул/волт или аналоги, opa. А есть ведь еще обычно какой то фронт, иногда не один, да?
Если подумать, то он не один программист на проекте. Есть специально обученные люди, которые в это умеют. У него
хватает сложностей в предметной области (расчеты какие-нибудь нетривиальные) + возможные проблемы при взаимодействии
с бд. Т.е. от него все это скрыто, и он получает как данное. (Наглый он, конечно, но ничего, при переходе на мс
арх-ру многие вещи из перечисленного его догонят, пускай не расслабляется!).
S>>все остальное находится в адресном пространстве процесса. НС>Это только если у тебя опять монолит это строго одна машина. А если несколько инстансов у нее?
И? Ну буду шарить бд или очередь, нашему программисту что с этого?
S>>может сделать? Ну выставит таймаут, ну стрельнет таймаут, попробует повторить операцию НС>Или воткнуть кролик, да?
Именно, у нас так -- если монолит упал, при рестарте попытается еще разок обработать сообщение.
Т.е. про рестарт думать особо не надо -- "все само".
S>>делать больше не надо. Более того, а что он собственно, кроме повторов может сделать? НС>А что может сделать автор микросервиса?
Если работает с другим модулем, как-то надо восстановить или сохранить консистентность. Для бд особой разницы не будет.
S>>О consistency думать ему не надо, за это движок бд отвечает или соседний модуль. НС>Так и микросервисы обычно stateless, а стейт, внезапно, где то в БД.
А если не stateless?
S>>Ну, зависит от. Про рестарты в рамках монолита думать ему тоже не надо. НС>Надо. Пишешь ты на локальный диск в файл, и тут рестарт. На диске — мусор. Думать не надо, да? Отличный рецепт.
Либо думать, либо все с нуля -- если с нуля дорого, то думать.
S>>По сути кроме "The network is reliable", НС>Скажу тебе по секрету — если ты в микросервисах на внутрикластерную сеть забьешь и будешь считать что "The network is reliable", то, скорее всего, ничего совсем уж ужасного не случится, вероятность сбоя там крайне мала.
Буду иметь в виду, благодарю.
S>>как-то через повторы можно обработать или прокинуть исключение наверх, больше особых знаний и не требуется. НС>Ты не поверишь, но в микросервисах все тоже самое.
Наверх в случае мс это куда, и что делать -- пытаться достучаться или падать?
S>>На архитектурном уровне вместе с микросервисами приходит eventual consistency. НС>Или не приходит. А если приходит, то эта забота ложится на плечи готовых решений типа тех же nosql БД.
Да, но это надо еще изучить. Это не входило в компетенции нашего монолитного разработчика.
S>>В общем, дело дрянь -- знать надо до фига и больше, а не только со стула не падать. НС>Ты реально игноришь все что я пишу. Надо знать специфику не означает надо знать больше. У монолитов своя специфика. Я уж не говорю о том, что ничего не знать про распределенные системы в монолите можно только в вырожденном случае, когда не нужно ни скейлинга ни НА.
Что нужно знать нашему разработчику для HA? Что-то кроме транзакций?
НС>Для примера — тебе, в силу перфоманса твоих хранилищ, понадобился шардинг. Ты правда думаешь, что в монолите при этом можно не обладать теми самыми специфичными знаниями про распределенные системы?
Для этого есть специально обученные люди.
S>>Зачем вообще mq какое-то использовать, если самодельного буффера за глаза хватит? НС>Именно это я и предложил. Опять ты ломишься в открытые двери.
Вы предложили брокер сделать in-proc:
НС>Все обработчики на одной машине, при этом message broker выделен в отдельный сервис — тоже весьма странное решение. message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process.
Здравствуйте, Sharov, Вы писали:
S>>>Где у него могу возникнуть проблемы при работе над монолитом? НС>>Там же, где и у микросервисов — при наличии расшариваемого между инстансами стейта. А если стейт не шарится, то и у микросервисов с распределенностью проблем особых нет. S>А если шарится, а что надо, чтобы не шарилось?
Непонятно.
S>Если подумать, то он не один программист на проекте.
Но в монолите все связано намного сильнее. У тебя программист на проекте напишет код, которых жрет CPU или память, и проблемы начнутся во всем сервисе.
НС>>Это только если у тебя опять монолит это строго одна машина. А если несколько инстансов у нее? S>И? Ну буду шарить бд или очередь
И чем это отличается от микросервисов?
S>>>может сделать? Ну выставит таймаут, ну стрельнет таймаут, попробует повторить операцию НС>>Или воткнуть кролик, да? S>Именно,
И получаем ровно ту же распределенную схему, что и у микросервисов.
S>Т.е. про рестарт думать особо не надо -- "все само".
А почему в микросервисах надо?
S>>>делать больше не надо. Более того, а что он собственно, кроме повторов может сделать? НС>>А что может сделать автор микросервиса? S>Если работает с другим модулем, как-то надо восстановить или сохранить консистентность.
Какую такую консистентность?
S>>>О consistency думать ему не надо, за это движок бд отвечает или соседний модуль. НС>>Так и микросервисы обычно stateless, а стейт, внезапно, где то в БД. S>А если не stateless?
То это фиговый микросервис.
S>>>Ну, зависит от. Про рестарты в рамках монолита думать ему тоже не надо. НС>>Надо. Пишешь ты на локальный диск в файл, и тут рестарт. На диске — мусор. Думать не надо, да? Отличный рецепт. S>Либо думать, либо все с нуля -- если с нуля дорого, то думать.
Т.е. думать таки надо и никакого отличия от микросервисов нет.
S>>>как-то через повторы можно обработать или прокинуть исключение наверх, больше особых знаний и не требуется. НС>>Ты не поверишь, но в микросервисах все тоже самое. S>Наверх в случае мс это куда, и что делать -- пытаться достучаться или падать?
У тебя есть еще какие то варианты?
S>>>На архитектурном уровне вместе с микросервисами приходит eventual consistency. НС>>Или не приходит. А если приходит, то эта забота ложится на плечи готовых решений типа тех же nosql БД. S>Да, но это надо еще изучить.
Как и в монолите.
S>Это не входило в компетенции нашего монолитного разработчика.
Чего вдруг? Монолит каким то волшебным образом избавлен от необходимости использовать БД или шардинг в ней?
S>Что нужно знать нашему разработчику для HA? Что-то кроме транзакций?
А что нужно знать разработчику микросервиса?
НС>>Для примера — тебе, в силу перфоманса твоих хранилищ, понадобился шардинг. Ты правда думаешь, что в монолите при этом можно не обладать теми самыми специфичными знаниями про распределенные системы? S>Для этого есть специально обученные люди.
А в микросервисах их почему то нет? И специальных людей недостаточно. В том же редисе при переходе на кластер надо править прикладной код чтобы правильно формировать ключи и избегать перекоса в сторону одной из нод из-за плохих значений.
S>>>Зачем вообще mq какое-то использовать, если самодельного буффера за глаза хватит? НС>>Именно это я и предложил. Опять ты ломишься в открытые двери.
S>Вы предложили брокер сделать in-proc:
S>
НС>>Все обработчики на одной машине, при этом message broker выделен в отдельный сервис — тоже весьма странное решение. message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process.
У тебя как то с пониманием текста не очень. Попробуй перечитать внимательно что ты процитировал и понять, что такое "второе" (нет, не message broker).
Здравствуйте, Sharov, Вы писали:
S>Типа необходимо уметь им пользоваться и понимать для чего он нужен, так? S>Ну т.е. у нас не только сложная кодовая база, при которой натурально в блокноте
приходится писать, S>но теперь и докер впихнули. Фортануло, че!
Опять ничего не понял. Ты точно понимаешь что такое докер и длоя чего он нужен.
S>>>Обычно когда у нас большой размер и сложность кода, архитектура давно выбрана. НС>>Серьезно? Ты еще веришь что архитектуру можно заранее выбрать и больше к ней не возвращаться? S>Представляете!
Представляю. На этом, пожалуй, разговор окончательно потерял смысл.
S>>>При большом объеме кода и его сложности уже поздно, да и, наверное, проблематично выбирать арх-ру. НС>>Нет, не поздно. Рефакторинг, по твоему, для чего нужен? S>Рефакторинг арх-ры? Можно, конечно, но чем это лучше чем переписать с нуля?
Ты точно понимаешь что такое рефакторинг?
НС>>Не надо все сводить до абсурда. Давай я тебе примером проиллюстрирую. Вот есть такой паттерн Посетитель. Если у тебя 2 реализации — точно нужно его использовать, вместо того чтобы написать просто свитч? А если реализаций 50 штук — разумно ли будет писать свитч на 50 кейсов? S>50 это хорошо, а почему не 49? Свитч на 49 разумно, а на 36 свитч разумно? Вы понимаете всю абсурдность Ваших аргументов?
На вопрос ответь.
НС>>И дело не только в паттернах. Нужно ли разбивать на сборки/dll проект из десятка кб исходников? А проект из сотни мб? S>Нет, дело именно в паттернах
Ты точно лучше меня знаешь что я имел в виду?
S>. Я первый раз услышал про количественные метрики применения паттернов
Количество, оно со временем переходит в качество, слышал про такое?
S>, типа 49 свитчей еще рано, а вот 50 уже самое то.
Сам придумал, сам посмеялся.
S>Докажите
Я тут вполне достаточно уже обосновал почему. Не в коня корм.
S>, ибо мне видится
О, опять началось.
S>Скорее важно уметь читать, т.е. для монолитов важен навык чтения и понимания. А вот при переходе на мс арх-ру код приходится писать.
Ты сам прочти что ты пишешь. В монолите писать код не надо?
S>>> Мне кажется это навык нужен вообще для всего в мире разработки ПО. НС>>Это не битовый флаг, есть/нет. S>Тем более, к чему тогда был этот довод?
К тому что чем выше требования к определенной экспертизе, тем выше нужна квалификация программиста. Маленький микросервис напишет обычный миддл, а ковыряться в огромном монолите не каждый сеньор потянет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
У меня другой опыт. При прочих равных (количество фич и их сложность) в монолит вносить изменения быстрее и дешевле.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Микросервисы это, во главе угла, прежде всего про процессы разработки. А архитектура это уже следствие. НС>Основное ради чего весь этот сыр-бор — максимальная изоляция компетенций по единицам деплоймента. Т.е. каждая конкретная команда решает свою узкую задачу независимо. Максимально независимо. И изменения деплоятся тоже независимо. А вот чтобы это обеспечить как раз и придумана та туча микросервисных технологий. НС>Монолит же, это когда у нас есть одна большая суперкоманда (пусть и состоящая внутри из нескольких команд), которая и обладает всеми необходимыми компетенциями. Характерный признак монолита — большие релизы, когда несколько разных сервисов, пусть и написанных разными командами, в итоге где то собираются в единое целое, и это целое сперва тестируется именно как целое, а затем и деплоится целиком. А сколько там физических сервисов и как расшарена БД — совершенно пофигу.
В целях микросервисов ты прав, но даешь свое определение монолита. Монолит это единица деплоймента (архитектура межмодульного взимодействия, организация кодовой базы и ее CI/CD цикла). Сколько команд разрабатывают и как — дело десятое.
Микросервисы это в первую очередь архитектура, призванная очень дорого решить проблемы границ команд, которые не вышло решить другими методами.
К примеру в монолите СПА-фронт и бэк могут составлять одну консистентную кодовую базу (и единицу деплоймента), но их разработка разными командами будет идти ничуть не хуже, а иногда и лучше чем если бы они жили и деплоились отдельно друг от друга.
Границы модулей можно провести и внутри монолита, какой-то общий код будет изредка правиться одновременно и все (проблема консистености контрактов и доки на них в микросервисах ничуть не проще). И в монолите могут быть команды, которые отвечают за какое-то направление в продукте и релизят фичи независимо от других. Проблемы коммуникации и незнания того, что делают другие команды в целом отличаются не сильно.
Давай на примерах, налоговая стала требовать в чеках новое поле, чем будут отличаться процессы в разных архитектурах?
Re[22]: О микросервисах -- требования к квалификации.
S>Итак, мы начали с противоположенного мнения к требования квалификации разработчиков в проектах S>с микросервисной арх-ой. Я утверждаю, что требования к квалификации разработчиков на подобных проектах выше, Вы -- что ниже.
Вы оба правы.
В "микросервисной" архитектуре всю сложность выгружают на "инфраструктуру", и там требования к квалификации выше.
Но в "продуктовых" командах (тех, что работают непосредственно над бизнес-логикой сервисов) требования ощутимо ниже. Можно и велосипедостроением заниматься, и перламутровые пуговицы пришивать. Все эти художества будут изолированы в одном конкретном сервисе, и если за API хорошо присматривают люди из "инфраструктуры", то все это может довольно долго копить все больше и больше тех. долга. Сродни "потолку господла США". Надо напечатать больше денег? Легко, поднимаем планку госдол... тьфу, добавляет еще один "микросервис", который уже с перламутром. И пуговицами.
Лишь бы инфра не лопнула. Но там квалификация требуется высокая. Порой настолько, что это просто отдают (за большие деньги) на откуп тем, у кого есть такая квалификация.
Здравствуйте, Ночной Смотрящий, Вы писали:
Z>>А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так).
НС>Включаешь трейсинг и смотришь в каком нибудь егере где мы утыкаемся. И 50 сервисов схлопываются до одного.
А где мы там утыкаемся? Обычно берешь ты трейс (хоть ягера, хоть профайлера) и видишь ровно столько, сколько у тебя знаний по каждому участку. Без этой экспертизы трейс малополезен.
Впрочем этим примером я иллюстрировал другую проблему. Когда мы нагружаем систему на тестовом стенде мы видим какие-то закономерности потребления ресурсов от нагрузки и как-то умозрительно пытаемся их экстраполировать на прод. Что в монолите, что в микросервисах это дело очень непростое, в микросервисах оно осложняется тем, что request/limit/hpa надо считать для каждого МС и точек отказа становится в разы больше (вероятность отказа растет еще быстрее).
НС>Значит снимаешь трейсинг для разных сценариев. Тебе продакты придут и скажут какой именно сценарий не удовлетворяет SLA. И микросервисы тут, опять же, совершенно не причем.
Я говорю о том, что матрица consumer — request/limit/hpa для каждого сценария обычно отличается. И совмещать их для разных сценариев при росте количества строк и сценариев становится все сложнее. Более того, после каждого релиза любой строки весь этот куб матриц может поменяться.
Трейсинг хорошо помогает, когда мы вырождаем сценарий до вызова одного эндопоинта. Если у нас сценарии на сотни/тысячи вызовов — трейсинги становятся менее информативны.
Если вдруг фиксануть чего — кроме как чудом трудно предложить годный вариант, что бы ничего не сломать.
