​​Хронология развития технологий микросервисов

Результаты опроса более 1000 человек по логированию, мониторингу и observability.

​​Вчера выступил на митапе сообщества DDDevotion в Райфайзен Банке с докладом про Event Storming и по итогам написал статью с кратким изложением. Кому интересна тема — welcome.

​​Всем привет! 12-го мы собираемся порешать реальный архитектурный кейс.

Продублирую саму идею.

Собираемся и вместе ищем решение сложных, рабочих архитектурных задач.

Цели:
1. Помочь друг другу получить более стабильные, интересные, надежные и эффективные архитектурные решения быстрее.
2. Учиться друг у друга, расти профессионально, развиваться, заводить новые знакомства, приятно провести время в кругу единомышленников и друзей.

Встреча для всех желающих.

​​Отчет о прошедшей вчера встрече «Совместное решение архитектурного кейса»

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

Недавно статейку написал, а сюда не отправил, на что пара человек обратили внимание. Исправляюсь :)

Статья о том, нужен ли в принципе API Gateway исходя из желаемой командной динамики в компании.
Иногда на курсе по микросервисам (зависит от запроса участников) разбираем через желаемую динамику коммуникационных связей (aka Закон Конвея) и уровень энтропии в организации необходимость в таких вещах, как API GE, ESB, всякие отдельные платформы и так далее. Следуя логике статьи можно легко выйти за пределы API GW.

PS: в курсе по DevOps тема топологий команд так вообще обязательная, а то появляются потом автономные и независимые команды... devops- инженеров :)

​​Микросервисы 20 лет назад

​​DDD одним слайдом

​​Интересный набор примеров и упражнений по безопасности с использованием встроенных возможностей Kubernetes от Connor Gilbert (StackRox).

https://securek8s.dev/exercise/

​​Четыре ​​поколения микросервисной архитектуры
a) оркестрация контейнеров
b) Service Discovery и Fault Tolerance
c) Sidecar и Service Mesh
d) Serverless

Перевел курс по микросервисам в онлайн!

Спасибо всем, кто помогал своей обратной связью и критикой.
Пока самая актуальная информация здесь: http://agilemindset.ru/разработка-микросервисов-онлайн-кур/

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

Вопрос к сообществу: какие темы о микросервисной архитектуре, разбор каких конкретных ситуаций, на ваш взгляд, принесут максимальную пользу и ценность? Цель — принести ценности намного больше стоимости курса, а ценность можно определить только общаясь с людьми :)

​​Какие метрик собирают сервисы Microsoft

​​Conftest
Инструмент для тестирования конфигураций Кубера, Терраформ и т.д.

Можно строить в delivery pipeline (особенно при использовании GitOps) и повысить надежность поставки инфраструктуры (не обязательно микросервисов, хотя для них подходит идеально).

Хорошая документация, много примеров, есть возможность расширения функциональности с помощью плагинов.

​​Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs

Практическая статья от Uber. Очень интересные и местами смелые мысли о масштабировании инженерных команд.

Тезисно
1. Спланировать прежде, чем что-то делать. А именно — достигнуть кристально-чистого общего понимания решения всеми членами команды
2. Собрать план в небольшой документ (aka RFC)
3. Получить апрув от нескольких релевантных решаемой задаче коллег
4. Отправить план всем инженерам в компании, любой может оставить свои комментарии
5. Все в компании должны следовать этим шагам для любых не тривиальных задач

В Uber итеративно пришли к таким шаблонам документов:

Backend
- List of approvers
- Abstract (what is the project about?)
- Architecture changes
- Service SLAs
- Service dependencies
- Load & performance testing
- Multi data-center concerns
- Security considerations
- Testing & rollout
- Metrics & monitoring
- Customer support considerations

Mobile/Web
- List of approvers
- Abstract (what is the project about?)
- UI & UX
- Architecture changes
- Network interactions detailed
- Library dependencies
- Security concerns
- Testing & rollout
- Analytics
- Customer support considerations
- Accessiblity

​​Написал об аргументации технических решений

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

Применительно к теме, вопрос иногда звучит так: «Мы хотим микросервисы, как обосновать/продать это бизнесу?». Как раз ответ на этот вопрос, а именно — что первично, в статье.

Для микросервисов/непрерывной поставки первичная аргументация может быть, например, такой:
- Повышение лояльности клиентов и ускорение ROI за счет непрерывной поставки готовой бизнес-функциональности
- Повышение удовлетворенности клиентов за счет снижения количества ошибок минимум в 2 раза
- Повышение конкурентоспособности и клиентоориентированности за счет проведения безопасных экспериментов для проверки продуктовых гипотез
- Отсутствие потребности в остановке системы при ее обновлении

А какой бизнес-кейс для перехода на микросервисы у вас в компании?

​​1500 микросервисов в Monzo

Мне много приходилось не только проектировать с нуля и переводить монолиты на микросервисы, но и отговаривать.

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

Только с помощью тестов можно проверить и подтвердить, что постепенно меняющаяся архитектура остается пригодной. Почему еще это так важно на ранних этапах перехода?

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

Второй момент, — все мы знаем подход shift left (например - выполнять часть тестов производительности и безопасности еще на этапе разработки), когда практики качества серьезно сдвигаются влево. В микросервисах, помимо shift left появляется shift right - тестирование на продакшене (тот же chaos engineering, нагрузка и scalability на проде). Только на проде можно получить самые точные результаты тестов, так это именно то окружение, со своими достоинствами и недостатками, которым пользуется клиент.

Постепенно расскажу о других препятствиях.

Какие виды тестов и в каком количество вы используете?

Вдогонку к микросервисам в Monzo, статья о том, как они поддерживают свои полторы тысячи:

https://www.theregister.co.uk/2020/03/09/monzo_microservices/

Ничего нового, проверенные истины, вроде:
«Well-known software development principles count for more than technology choices»

Но читается интересно.

Продолжая тему тестирования, сегодня речь о юнит-тестах.

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

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

Юнит-тесты можно условно поделить на те, что тестируют состояние объекта и те, что тестируют поведение/взаимодействие, используя тест-дублеры.

Первые находятся в центре дизайна, слое доменной логики. Его особенность в том, что если удалось провести качественное проектирование на уровне предметной области, то изменения в него будут вносится все реже и реже(и, скорее всего, точечно), — это стабильная область (в отличие, например, от UI). Следствие из этого — код и нюансы его работы будут забываться, тесты станут стабильнее и выступать в том числе актуальной документацией, а их запуск в рамках CI является формальным подтверждением того, что в сборку не попал регрес.

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

Если планируется переход от монолита к микросервисам, то юнит-тесты с использованием дублеров могут разделиться на две части. Чтобы лучше это понять, следует обратиться к шаблону «Микросервисное шасси/Фреймворк микросервиса» (Microservices Chassis - https://microservices.io/patterns/microservice-chassis.html) — от вынесение общей инфраструктурной функциональности в отдельный фреймворк. Тесты общего назначения могут уйти в кодовую базу фреймворка и поддерживаться отдельно, что снижает общую сложность управления тестами и сокращает время их выполнения (в CI сервиса выполняются юнит-тесты сервиса, а юнит тесты фреймворка выполняются в своем CI).

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

Иногда код настолько плох, что юнит-тест не пишется, с какой стороны к нему не подойди. Был случай, когда команде буквально приказали начать писать юнит-тесты, которых никто никогда не писал, а системе (это была java) больше 10 лет. За два месяца не было написано ни одного теста. Это тот случай, когда типовая стратегия тестирования для greefield не подходит и следует рассмотреть альтернативы. О них напишу после еще нескольких постов о видах тестирования в применимости к микросервисам (хотя, это актуально вне зависимости от архитектурного стиля).

​​FailoverConf, 21 апреля, онлайн, участие бесплатное.

Бомбический список участников и докладов, регистрируемся!