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

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

​​Крис Ричардсон на DDD SoCal поделился десятью принципам рефакторинга при движении в сторону микросервисов. По ссылке и преза и видео. Классное выступление, я бы сказал — обобщающее.

https://chrisrichardson.net/post/refactoring/2020/08/21/ten-principles-for-refactoring-to-microservices.html

Фантастическая статья о выборе CI-платформы, куча полезных и интересных исследований для всех, кто сейчас оценивает CI и системы сборки: https://buoyant.io/2020/09/16/linkerds-ci-kubernetes-in-docker-github-actions/

​​На ArchDays все-таки будет выступление про LeanIX!

Сергей Лукин расскажет и покажет как документировать 150+ микросервисов в LeanIX. Я очень давно хотел посмотреть на этот инструмент вблизи, но всё как-то не было возможности, в России он не сильно распространен.

Ссылочка на описание выступления: https://archdays.ru/?speaker=430

К слову, у LeanIX очень крутые ресурсы по Enterprise-архитектуре, через ресурсы о них в свое время и узнал: https://www.leanix.net/en/resources/

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

Участникам этого канала скидка 30% по промокоду microservices_arch 👌

http://archdays.ru

Не супер-подробная, но достаточно интересная статья про полирепо vs монорепо в микросервисах. Автор статьи больше выступает за монорепо, судя по тону статьи — по собственному опыту, так что относитесь к мыслям в статье критически и перености в свой контекст.
https://caylent.com/the-shift-from-polyrepos-to-monorepos

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

Последние несколько лет изучаю вопрос применения теории графов к микросервисам используя различный инструментарий. Идея в том, чтобы формализовать часть свойств микросервисов через мат аппарат графов. Что это дает на практике? Как минимум: возможность автоматизации в выявлении паттернов (циклические зависимости, сильная связанность, рассчет нагрузки и таймаутов), автоматизации соблюдения архитектруных принципов, наглядный knowledge sharing, построение моделей угроз.

Достаточно обширная практическая (с jQAssistant и Neo4j) статья на эту тему:
https://dzone.com/articles/fixing-your-microservices-architecture-using-graph

Все готово 🙂
В 10:00 стартуем #archdays

Пока готовятся видео с архдейз можно посмотреть видео выступления Патрика Куа, соавтора книги Эволюционная архитектура на agiledays 2019 с переводом на русский язык :)

https://youtu.be/DwJE_nBw0Fk

Видео с ArchDays с мастерклассом взлома приложения в в докере от Дениса Якимова (@sec_devops и @cloud_sec) и Павла Канна
https://www.youtube.com/watch?v=0_Lb9OVxmbw

Еще одно видео с ArchDays, на этот раз с мастерклассом от Жени Пешкова (@dddevotion) по агрегатам
https://www.youtube.com/watch?v=SaTz4vS_CGE

Видео с мастер-класса Кирилла Ветчинкина по CDC тестам в микросервисной архитектуре
https://www.youtube.com/watch?v=dqPEeWJCshk

Видео обсуждения культурных и процессных особенностей, связанных с микросервисами
https://www.youtube.com/watch?v=GBrxFWamoak

Что такое распределенный монолит?

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

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

И в там и там в монолите вызовы - локальные.

Если «распилить» монолит, то получим распиленный монолит, то есть по сути то же, что было, только с удаленными вызовами.

В первом случае - неплохой набор потенциальных микросервисов (с поправкой на инфраструктуру).

Во втором случае - полный фарш проблем. И вот именно этот случай в народе принято называть распределенным монолитом.

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

Пути трех компаний к микросервисам

Для визуалов, выглядит это примерно так.

А Саймон Браун (если не ошибаюсь, это его цитата) ведь прав. Сперва бы в монолите навести порядок, скилы прокачать, а там уж можно и в MSA.

Родовое дерево GitOps.

Хочу рассказать об уровнях принятия решений в микросервисной архитектуре. То, что я использую в своей практике — это двойная петля обучения Криса Аргириса, адаптированная под архитектурный процесс. Привлекла она меня тем, что в ней выражены два уровне — «Что мы делаем?» и «Почему мы делаем то, что делаем?». Схематично роцесс показан на картинке, почитать подробнее можно, например, здесь: http://pds8.egloos.com/pds/200805/20/87/chris_argyris_learning.pdf

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

​​Адаптированный цикл выглядит так. Есть цель, а есть ASR, NFR(QA), принципы и ограничения в поддержку этой бизнес-ценности. Они ограничивают целевое решение. Без ограничений мы быстро свалимся в хаос.

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