Фантастическая статья о выборе 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), принципы и ограничения в поддержку этой бизнес-ценности. Они ограничивают целевое решение. Без ограничений мы быстро свалимся в хаос.

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

​​Если копнуть глубже и посмотреть очень схематично на визуализацию микросервисной архитектуры, то мы увидим, что вполне возможно выделить два уровня. Первый будет в себя включать модель предметной области и техническую макро-архитектуру. Например, именно здесь мы определяем чаще всего такие вещи, как: отвественности компонентов (сервисов), интеграция с UI, протоколы взаимодействия, форматы данных, избыточность данных (redundant data), логирование и мониторинг (и другие входящие в состав microservices chassis параметры). Это не обязательный список и он может варьироваться в зависимости от контекста конкретного решения.

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

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