Вангую - ошиблись в определении границ и получили тот самый распределенный монолит во всем его великолепии :)

Ну или синхронное взаимодействие без заглушек 💁‍♂️


«Hey guys, I've recently switched jobs and at the current company it's really tedious to launch all the required microservices locally every day. Depending on the task, I might need to have running 3-7 microservices. My teammates suffer from the same issue and each spends about 20 minutes in the morning to launch all the environment. It's even harder than u return from the vacation or get back to microservices you didn't work with for a while - you need to recall or refresh your knowledge by reading documentation so you can launch all the required microservices in the right order with the proper keys, configs, etc.»


https://www.reddit.com/r/microservices/comments/sa3ma4/the_complexity_of_launching_local_environment/

Есть разбитие видео на эпизоды👍

https://youtu.be/gfh-VCTwMw8

Годнота. Проектирование мессенджеров вроде WhatsApp

http://highscalability.com/blog/2022/1/3/designing-whatsapp.html

The Major Software Industry Trends from 2021 and What to Watch in 2022

Такие дела.
По теме канала:

There may be a COVID corollary to Conway's law; companies that have been effective at developing loosely coupled systems (often with a microservices architecture) were better set up to work remotely and using a distributed approach. It's the independent and highly aligned teams and the people that make microservices work.

https://www.infoq.com/articles/summary-podcast-2021-review/

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

Вдогонку. Визуализировал 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