Предлагаю в комментариях к этому сообщению поделиться друг с другом полезными и интересными Telegram-каналами, которые читаете :)

Всех с наступающим Новым Годом! 🎄
Пусть системы будут надежными, а их пользователи - довольными :)

Видео всех выступлений с гидры:
https://www.youtube.com/playlist?list=PLC5OGTO4dWxbxpZWsvWWeBxUQWVqGXeBB

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

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


«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/

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

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

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

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

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

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

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

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

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

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