Список Microservices Bad Smells. Смотрим в статью, смотрим на свое решение, думаем.

Миграция на микросервисы Mission Critical системы.

Анонс ArchDays MeetUp

12 сентября в 19:00 Илья Смирнов, руководитель практики ML/AI в ГК Юзтех расскажет об архитектуре системы моделирования на базе цифровых двойников производства.

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

Подробнее и регистрация тут:
https://meetup.archdays.ru/meetup-12092023

Ждем всех, будет интересно!

Первый публичный заход.

Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний.

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

После пикника подготовлю небольшую методичку, по плану к ArchDays будет готова.

И с первыми артефактами уже можно будет с желающими поучаствовать объединяться в группу :)

Презентация с выступления.

В компании три команды, все три проводят дискавери.
Все проверяют гипотезы, у кого-то срабатывает.
Означает ли это, что другие ошиблись? Нет. Это же гипотезы. Они на выходе имеют два легитимных состояния – подтверждена или опровергнута.

А вот те, чьи гипотезы не подтвердились, внесли точно такой же вклад, ведь если бы их не было, то эти гипотезы, скорее всего, все равно кто-то в итоге проверял. Если в описанном выше кейсе одна команда проверяла бы все гипотезы, то существует вероятность, что такая команда вообще дошла бы до подтвержденной гипотезы, остановившись где-то в середине пути.

Если какая-то гипотеза не подтвердилась, то нужно сделать формальные выводы, а результатом будет увеличение объема знаний об объекте исследования и сужение мощности множества доступных вариантов для последующей проверки.

Это касается как продуктовых гипотез, так и технических экспериментов.

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

Декомпозиция наглядно.

Domain-driven-design patterns for domain-driven microservice design, in UML notation

На тот случай, если кому-то в UML надо будет отобразить элементы DDD

source:https://ieeexplore.ieee.org/document/8354426

По этой картинке необходимо пояснение.

Что здесь изображено?

По пунктам:
1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов.
2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment.
3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.

Как с этим быть?
4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?

Есть два варианта, безопасный и менее безопасный.

Безопасный показан на изображении:
5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами.
6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура.
7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.

Теперь о неточностях в изображении.
Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.

Менее безопасный вариант:
Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.

/// продолжение

В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).


Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.

Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂

PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation

Схема, описывающая API Product Development Lifecycle для Major Version Change

Схема, описывающая API Product Development Lifecycle для Minor Version Change

Очень интересный ресурс, для общего развития «40 maps that explain the internet»
https://www.vox.com/a/internet-maps

Пошел удивительный тренд (впервые был замечен на хабре), что микросервисы – это не распределенная система (а земля, видимо, все-таки плоская). Достаточно взять определение Таненбаума: «Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой. В этом определении оговариваются два момента. Первый относится к аппара­туре: все машины автономны. Второй касается программного обеспечения: поль­зователи думают, что имеют дело с единой системой.»

Если так подумать, то у нас сейчас практически любая система – распределенная система :)

Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости –  изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов

Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.

Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)

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

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

В продолжение предыдущего поста. Вообще, в нашей индустрии, много проблем, связанных с поверхностным пониманием тех или иных технологий, подходов.

Оно и не мудрено, - индустрия молодая, даже в фундаментальных аспектах эксперты порой расходятся во мнениях.

Стандарты есть, конечно, но стандарты не сказать, чтобы были стандартами индустрии, - кто-то воспринимает и использует, кто-то даже не слышал. А вот интерпретаций без отсылок к первоисточникам сколько угодно.

Ну а работать как-то надо, вот и приходится раскапывать по крупицам хоть что-то.

Если взять ту же микросервисную архитектуру. Я уже упоминал, что мне здесь немного повезло, был проект почти 20 лет назад, в котором мы реализовали как раз то, что сейчас называется микросервисной архитектурой. В том же проекте был реализован Event Sourcing, хотя я в то время даже слова такого не слышал.

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

Термин получился может и не самый удачный для описания сути, но максимально хайповый, тут не отнять. Характеристики тоже попытались описать, получилось как получилось, попробуйте на досуге взять свое архитектурное решение и формализовать его характеристики для того, чтобы его можно было повторно использовать и развивать вокруг него теоретико-практическую базу. Этих характеристик будет практически бесконечное число, так что вам придется взять все существующие стили и выделить:
1. Те, что отличают от других
2. Те, что четко определяют ваш архитектурный стиль в своей совокупности

Я обобщаю и выделяю паттерны из конкретных сессий event storming и это максимально неблагодарное занятие.

Вернемся к описанию архитектурного стиля и вспомним фундаментальные труды по архитектуре. Как там описаны стили? Текстом в свободной форме. Какой-то формализм, конечно, присутствует, но в целом «что вижу - то описываю». Проблема здесь в том, что даже если трое видят одно и то же, описать они это могут совершенно по-разному. А те, кто прочитают, каждый кто прочитает, - могут и понять по-своему и написать по статье на хабре или медиуме со своим понимаем, и вот у нас уже 100500 интерпретаций.

Ситуация ухудшается, когда нечто на хайпе, - статей и интерпретаций становится настолько много, что с ума можно сойти.

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

Например, банальное «изоляция сбоев на уровне отдельных микросервисов». Мало того, что здесь смешаны и технические сбои и бизнес-ориентированные, так тут еще и что такое изоляция, а дальше, - как идентифицировать сбой, как его обработать, различные виды деградации, определение корректирующих действий, мониторинг…. В общем, не все так просто, как кажется на первый взгляд при прочтении нескольких слов, а стандартов описания нет, вот мы и живем каждый в своем контексте, но даже не смотря на это умудряемся строить надежные, эффективные, полезные, быстрые решения :)

Domain Driven Cloud

Естественное продолжение идей разграничения ответственностей на уровне моделей. Конечно, все сыренько пока, посмотрим, перейдет во что-то серьезное или нет.

https://www.infoq.com/articles/domain-driven-cloud/

В статье достаточно структурно изложены основные области знаний, которые имеет смысл подтянуть при движении от разработчика к Solution Architect.

From developer to (solutions) architect. A simple guide.

https://dev.to/this-is-learning/from-developer-to-solutions-architect-a-simple-guide-2b91