Видео с мастер-класса Кирилла Ветчинкина по 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 баз данных, которые могут быть использованы и команды вправе самостоятельно принимать решение о том, какая база у них будет, без лишних согласований.

​​Получается такая аккуратная картинка, которая достаточно неплохо встраивается в текущие процесссы любой организации от стартапа до very big enterprise.

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

Старенькая статья «Why Netflix Moved to a Microservices Architecture»

https://www.programmableweb.com/news/why-netflix-moved-to-microservices-architecture/elsewhere-web/2016/04/02

Продолжим тему истории компаний, на этот раз — SoundCloud. Объемная и достаточно детальная статья:
https://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html

Groupon тоже перешел на микросервисы и достаточно давно, их история:
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/

И про микросервисы в Gilt, так же достаточно интересная статья. Интересна, как и другие статьи, тем, что в них не теория, а что компании в действительности делали (может иногда и преукрашено и слишком асбрактно, но общее направление увидеть не сложно)
https://www.infoq.com/news/2015/04/scaling-microservices-gilt/

Всех с наступающим Новым Годом! 🎄🥂⛄️

Видео выступления Александра Поломодова «Архитектура в масштабе ... или как мы в Tinkoff принимаем архитектурные решения» с ArchDays 2020 теперь доступно в YouTube канале конференции, подписывайтесь на канал, чтобы не пропустить публикации остальных видео
https://youtu.be/-KMWmXTr2LE

Видео выступления Александра Бындю «Скрытые расходы при переходе на микросервисы» с ArchDays 2020!
Подписывайтесь на канал, чтобы не пропустить публикации остальных видео.
https://youtu.be/lSBYz8l2XUw

Видео выступления Сергея Лукина «Документирование микросервисов на примере LeanlX» с ArchDays 2020
https://youtu.be/wIJpumyG8qQ