Видео выступления Филиппа Уварова «Краткая история Event Delivery в Spotify»
https://youtu.be/e0TC5Qef78E

​​Краткое сравнение SOA и микросервисов от infopulse

Видео выступления Ильи Волынкина «Как сделать SaaS для анализа переписки, который не страшно использовать?»
https://youtu.be/FPmCLxkc2AM

Видео выступления Максима Цепкова «Модели приложения для разных парадигм программирования»
Тот самый доклад про гномиков 🙂
https://youtu.be/AkUMSyapP6E

Сделал редирект на канал ArchDays в youtube c http://archdays.ru/youtube/
Теперь делится ссылкой на канал станет проще.

А странно в этой истории то, что все условия для того, чтобы сделать человеческий урл, вроде /archdays на самом youtube все условия уже год как выполнены, но google по неизвестной причине не дает возможность этого сделать, поддержка молчит. Если кто-то знает, как решить проблему (обложка есть, лого есть, подписчиков > 600) – напишите в комментариях, буду признателен за помощь.

Терминология istio

Архитектура istio

istio: data plane и control plane

Статейка вышла по итогам моего выступления на TechLeadConf про Event Storming и микросервисы: https://m.habr.com/ru/company/oleg-bunin/blog/537862/

Само видео тут: https://www.youtube.com/watch?v=cG9DVbcPc9M

Для микросервисной архитектуры жизненно-важным является наличие DevOps-культуры. При этом эту культуру пытаются как-то измерить, но чаще пытаются измерить производительность команд, нередко, чтобы сравнивать между собой (facepalm).
По мне так это странный способ и сами три пути DevOps и принципы CALMS дают ответ на то, что следует измерять, а в книге Accelerate так вообще все раскладывается по полочкам.
Посмотрим на измерение важных вещей в трех измерениях:
1. Outcomes на уровне компании
2. Здоровье команд
3. Компетенции

Почему именно эти срезы? В чем-то это моя любимая фрактальная структура. Outcome (так я не нашел достойного перевода этому термину для отделения от output и result, можете предложить вариант в коментариях), так вот, outcome на уровне компании — это результат работы команд, состоящих из людей, обладающий нужными компетенциями на необходимом уровне.

Далее по-порядку:

Метрики уровне компании, мой перевод из отчета State of DevOps 2019

Подробнее про эти метрики

Время внесения изменений (Lead Time)
Сколько времени требуется для поставки фичи, от начала и до конца. С этим могут быть сложности, иногда упрощают от pull request’а до клиента.

Частота развертываний (Deployment Frequency)
Количество поставок на прод в единицу времени. Для повышения частоты развертываний нередко все начинается с декомпозиции большой задачи на более мелкий, автономные, отвечающие критериям INVEST (https://www.agilealliance.org/glossary/invest/)

Процент отказов при изменениях (change-fail rate)
Процент поставок, приведших к падению сервиса от общего числа поставок.

Среднее время восстановления (Mean time to restore, MTTR)
За какое время в среднем восстанавливаем упавший сервис. Обычно выясняем в рамках post-mortem. Это интересная метрика, потому что монолитных системах нередко акцент идет на метрику MTBF (Mean time between failure - среднее время между сбоями). Это по-прежнему важная метрика, а для ряда классов систем прям вот сильна важная, но в распределенных системах, микросервисных, мы принимаем, что падать будет и будет падать часто, поэтому на MTBF смотреть можем, но важнее стремиться к сокращению MTTR. Быстро поднятое не считается упавшим 🙂

Лучшая метрика здоровья команды — это обратная связь от её членов и между её членами. Все в том же отчете State of DevOps 2019 приведены основные факторы, влияющие на производительность поставки и на продуктивность. И там и там есть такой фактор, как психологическая защищенность. Это убеждение, что никто не будет наказан или унижен за высказывание идей, вопросов, опасений или ошибок. В 2015-м году Google провел внутреннее исследование 180-и команд, пытаясь выяснить, что делает команды более или менее эффективными. Исследование показало, что психологическая безопасность — одна из пяти базовых основ высокоэффективных команд. При этом — самая важная. В такой культуре люди фидбечат свободно, принимают фидбек, меняют что-то и у них просто не остается поводов для конфликтов (гипотетически) и остается куча энергии и времени на решение крутых задач.

Например, вот что влияет на производительность поставки. Жирным выделены статистически самые важные аспекты.

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

@microservices_ru

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

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

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

Что получаем: обоснование в необходимости развития тех или иных компетенций и текущий уровень несоответствия. Последним заполняем столбец «Действия» — как будем экпертизу получать.

Важно, чтобы по итогам заполнения «Действий» появились реальные Action Items — зарегистрироваться на курс, написать коллеге письмо, сходить в соседний проект в понедельник и так далее. И самое важное — завести регулярную встречу, на которое отслеживать прогресс (5-10 минут в неделю бывает достаточно).

Микросервисная среда — весьма динамична. Поэтому так важно выбрать полезные метрики и непрерывно разивать свои скилы, скилы команды, тем самым усиливая её. Это компас нашей производственной системы.

Матрица компетенций в CircleCI: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0

Микросервисы - это не только технологии, это еще и люди и команды их разрабатывающие. Завтра будет бесплатный митапчик по дизайну команд. Да, там не будет про технологии, но технологии у нас в сердцах и головах, а ведь немаловажно с кем мы плечом к плечу микросервисы пилим :)

Кому интересно, ссылочка: https://agilerussia.timepad.ru/event/1539341/

​​Не так давно выкладывал ссылку на работу о сагах (https://tttttt.me/microservices_arch/82), пришло время работы о модульности. Еще в 71-м году Девид Парнас описал подход к модульности через сокрытие информации как более предпочтительный, чем подход, в котором модули являются шагами процесса. Физическое воплощение модульности через сокрытие информации мы и видим в том числе в микросервисах, когда скрываем детали реализации сервиса, включая его данные («difficult design decisions or design decisions which are likely to change»), за API.

…it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since,in most cases,design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.

Читать статью полностью: https://prl.ccs.neu.edu/img/p-tr-1971.pdf