Референсная микросервисная архитектура архитектура в контексте окружающей инфраструктуры (очередная итерация визуализации)

Вдогонку. Визуализировал 12factor app. Здесь все 12, тоже своего рода точка зрения (view point) на cloud-friendly, коими и микросервисы должны быть =)

Домен (предметная область) — область знаний/деятельности, для решения проблемы в которой разрабатывается приложение. Размеры домена зависят от того, как выбрать границу.

Как узнать домен?
Вовлекая специалистов, экспертов в домене. Они передают знания о том, почему принимаются те решения, которые принимаются и из каких ключевых элементов состоит домен.

Идея состоит в определении языка, делающего код понимаемым «извне».
Изучение кода новым разработчиком, таким образом, позволяет заодно изучить домен (предметную область).

Изменение в языке ведет к изменению модели и рефакторингу кода.

«If I say a word and I expect that you have the same definition, but you actually have a very different definition, we have false alignment. We think we’re talking about the same thing but we’re not.»

#DDD

Увидел тут еще один антипаттерн микросервисный, сходу не смог оформить в слова даже. Ну вот такое мне показали, сказав, что «вот такая у нас микросервисная архитектура» 🤷‍♂️
Картинку нарисовал, вместо тысячи слов.

Вчера высказал такое мнение, подразумевая в том числе понятия «микросервис», «devops»:

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

Ответ Церена Церенова мне показался полезным, помогающим проследить в том числе природу холиваров, так что решил опубликовать его и здесь:

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

Посмотрите, ведь это ровно оно: разные грани понятия в рамках ограниченных контекстов существования этих понятий (при, возможно, существовании строгого определения в домене).

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

Традиционно задам вопрос - кого из зарубежных спикеров вам хотелось бы видеть/слышать на конференции?

Пишите в коментариях, уже пора с ними связываться 💻

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

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

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

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

О чем всегда стоит помнить – это каскадные сбои при синхронных взаимодействиях. Какой-то процесс в глубине системы при блокирующих вызовах замедляется, поток на клиенте ждет и потребляет ресурсы/память, одновременно начинают происходить вертикальный (клиент клиента и так далее по цепочке ждут и потребляют ресурсы) и горизонтальный (если запросы повторяются и встают в ожидании, то соседние потоки ждут и потребляют ресурсы) отказы. Если это происходит в транзакции, то начинают тормозить базы данных и соответственно соседние потоки, все это распространяется по системе, cервера начинают перезагружаться, нарастает нагрузка на соседние ноды, они тоже падают. Всё останавливается. Все получают timeout error или нечто подобное. Экран гаснет.

Были в вашей практике каскадные сбои? =)

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

В завершение про каскадные сбои.

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

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

Применение парадигмы «быстрого сбоя» в микросервисах посредством таймаутов является антипаттерном

Небольшой список fail fast (выбросить ошибку как можно раньше) подходов:
- Лимит на объемы любых запрашиваемых клиентом данных
- Обязательный таймаут на все удаленные операции
- Для баз данных и на клиенте и на сервере, т.к прерванный запрос может продолжать выполнение
- Ограничение частоты обращений к серверу, а после превышения - 429 error code
- Ограничение количества открываемых входящих / исходящих соединений
- Ограничение размера задействованных пулов потоков под каждый тип операций
- Валидация аргументов запроса к сервису на стороне клиента (запрос все равно будет отвергнут, но мы сохраним время на удаленных вызов и пропускную способность сети)

Дополняйте в комментариях :)

Choreography vs Orchestration in serverless microservices
Mete Atamel & Guillaume Laforge

https://youtu.be/Z1_D0GJ7CB4

#video

Carving Microservices out of the Monolith with Domain Storytelling
Henning Schwentner

https://youtu.be/ggdBPW_DWbE

#video

Закон Конвея. Перевод статьи «How Do Committees Invent?»

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

http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/

Несколько цитат:

👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»

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

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

«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»

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

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

Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»

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

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

Крутая штука, да еще и свежак.

Atomic Microservices Transactions with MongoDB Transactional Outbox

Диспетчер цепляется к change stream монги и слушает инсерты в outbox. Это позволяет слать в брокер события из outbox в режиме реального времени 😍

Правда, придется вендорлокнуться на монгу, так как change stream фича монги. Есть еще пара минусов, они в статье.

https://blog.insiderattack.net/atomic-microservices-transactions-with-mongodb-transactional-outbox-1c96e0522e7c

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

Если границы компонентов - технологические, то как вы определите, какие из компонентов являются бизнес-критическими?

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

Остановимся на уведомлениях.
Есть такой закон, 161-П, статья 9.3, банк обязан уведомлять клиента о движении денежных средств. В какой-то момент статья изменилась, теперь банк обязан уведомлять в соответствии с договором… но суть не в этом.

Технологичный, универсальный компонент отправки уведомлений. Если он отправляет 500 различных уведомлений (с днем рождения, с 8 марта, спасибо за покупку) по 5 каналам (смс, пуши, почта, звонок …) и среди этих уведомлений есть одно обязательное, критичное для бизнеса, то компонент автомагически становится бизнес-критическим, хотя бизнес-критичного в нем три копейки. Но вот у него уже совсем иной SLA, статус… ну вы поняли, он стал «золотым» в развитии, тестировании и поддержке.

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

Ну и самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:
1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/технологически/как пришлось
3. От критичного бизнес-компонента (логическая абстракция) в каждом техническом компоненте по 20% логики
4. Все 100% всех пяти компонентов становятся бизнес-критичными

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

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

Вдогонку реализация tx outbox для azure cosmos db

https://docs.microsoft.com/en-us/azure/architecture/best-practices/transactional-outbox-cosmos

За ссылку спасибо @dpr_dev

Software is also part of the team (c) 🧐

Наткнулся. Оффтопик, но пожалуй оно стоит того, чтобы запостить сюда :)

— Гендальф! – перекрикивая рев орков позвал Арагорн, – Остановись, планерка!
– Что? – удивился волшебник сбавляя темп бега.
– Планерка!
– Вы с ума сошли?! За нами гонятся орки! Давайте потом…
– Планерка проводится каждое утро! – менторским тоном перебил догнавший их мужчина.
Едва он успел договорить, как в него врезался Гимли, пачка хоббитов и Боромир. Только Леголас сумел затормозить перед неожиданно возникшим препятствием.
– Мы стоим на мосту посреди пропасти и за нами гонятся все орки Мории! Нет времени на планерку! – возмутился Гендальф.
– Я Энеджер, сын Менеджера, брат Инвестора, владыка Канбана! – стряхнув с себя хоббитов и приняв властную позу заявил мужчина, – Властью данной мне Эмбиеем объявляю планерку! И должен сразу отметить, Гендальф, что для планерки время есть всегда! Итак, первый вопрос для обсуждения. За нами гонятся орки, как мы пришли к такому, очевидно не устраивающему нас результату? Я не устану напоминать, что необходимо регулярно проводить мониторинг и корректировать наши действия соответственно полученным результатам.
Все молчали, нервно переглядываясь и прислушиваясь к реву, отражающемуся от сводов подземелья.
– Тук уронил ведро в колодец, нашумел, это услышали орки и подняли тревогу… – стал нетерпеливо объяснять Арагорн, но его прервал Энеджер.
– Не так токсично! Легко сваливать ответственность на другого! Лучше скажи как ты лично связан с этим результатом! Мы команда и каждый внес свой вклад в то, чтобы возникла такая ситуация. Ответственность и планирование!
– Я… Ну…
– Если мы будем тут стоять, то нас прибьют орки! – воззвал к голосу разума Гендальф.
– Самое простое – это лихорадочно бегать! – возразил Энеджер, – И я понимаю, почему инвесторы прислали меня чтобы усилить вашу команду. Очевидно раньше вы вообще не занимались планированием! Очевидно, что сейчас проект идет не совсем так, как было задумано.
– Да нет же!
– То есть забеги по подземельям с орками – это часть проекта? Можно посмотреть документацию?
– Нет, просто такое случается иногда! – заорал Арагорн.
– У меня нет. – возразил Энеджер, – Итак, очевидно нам надо немного подкорректировать проект в соответствии с нынешней ситуацией. Я изучил все данные, произвел расчеты и стало очевидно, что вы поставили перед собой слишком амбициозную задачу.
– И что? – хором спросили все.
– Нужно представить инвесторам новый план. Опять таки, я все посчитал. Мы уже потратили больше ресурсов чем планировали. А в график не укладываемся. Предлагаю отказаться от нереализуемых пунктов плана и сделать только то, что реально. Но четко к сроку.
Все непонимающе переглянулись. Леголас задумчиво пристрелил подбегающего к ним орка.
– И что конкретно мы должны сделать? – поинтересовался Гендальф.
– Я все посчитал. До Мордора мы не успеем добраться, а вот до Лориена вполне.
– Но нам же надо отнести его в Мордор! — возразил Арагорн.
– Слишком большие риски, да и все уже идет не по плану! Нужно смотреть на вещи реально! – возразил Энеджер.
– Но кольцо можно уничтожить только в Мордоре! У нас нет выбора!
– Не берите на себя слишком большую ответственность. – успокоил всех Энеджер, – Просто делайте свое дело. Решено, мы дойдем до Лориэна. И отчитаемся о проделанной работе. Как минимум 50% проекта мы реализуем. Это лучше, чем завалить все, не так ли? Управление рисками.
– И что дальше? – не понял Гендальф.
– Ну, нужно будет провести стратсессию, составить дорожную карту, привлечь консультантов и понять как отнести кольцо в Мордор. Да и нужно ли вообще нести.
– Что значит нужно ли? – нахмурился Гендальф.
– Вин-вин, всегда есть место сотрудничеству, понимаете?
Гендальф посмотрел на Арагорна. Тот кивнул.
– Ну что же, думаю можем продолжать двигаться. Объявляю планерку завершенной. Давайте побыстрее перейдем этот мост. А то как бы нас орки не догнали. Да и хлипковато выглядит эта конструкция, если честно.
Братство кольца с облегчением рвануло по мосту. Все кроме Гендальфа. Он придержал за локоть Энеджера, подождал пока все остальные удалятся и заглянув ему в глаза сказал.
– Ты не пройдешь.

В техническом компоненте у вас будет time2prod environment
В бизнес-компоненте к нему прибавится time2market (потому что дорога к рынку - это еще и маретологи, реклама, контент, позиционирование)

В бизнесе как таковом, явно или неявно, интересен time2value.
По сути это синоним LeadTime из Lean.

И как же сильно его не хотят замерять :)
Ну а что, вот у нас три команды, сервисы пилят, очень понятный у них output - написать код и в отправить в прод.

А как мы «требование» придумываем, анализируем, подтверждаем, выделяем, убеждаем - «вы не понимаете, это другое».

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

Был кейс с запросом на переход на микросервисы. Тайм2маркет сократить. Провел предварительный аудит-исследование. Баги пролетали от своего появления в джире до прода за пару дней, максимум 3-4 дня. А вот то, что действительно важно, что позволяет зарабатывать больше и у чего максимальный потенциал - от задумки до прода 2-3 месяца. Из них разработка - около 2-х недель (спринт). Разработка - около 15% времени. Решать проблему хотели переходом на микросервисы, оставим мотивацию за скобками.

Правда, тут один нюанс. Посмотрите внимательно на описанный кейс. Без изменения процесса (от идеи до получения клиентом ценности) с переходом на микросервисную(или любую другую) архитектуру, изменится ли time2value?

Технические зависимости (на уровне данных и интерфейсов) сложно разорвать в том числе из-за отсутствия бизнес-семантики. На основе технической зависимости мы может только сделать вывод о ее наличии, но не можем определить, должна она присутствовать по бизнес-контексту или нет.