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

Время внесения изменений (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

​​Иначе мы можем сказать, что при корректно определенных границах микросервисов критически важна изоляция состояния. Это дает возможность внутреннего эволюционного развития микросервиса без негативного влияния на его внешнее окружение. Под негативным влиянием можно понимать, например, необходимость координации с другими командами/сервисами при внесении изменений или, более простым языком — наличие жестких зависимостей. На картинке — если два сервиса начинают использовать одну базу, то им придется договариваться о внесении изменений в эту базу. Зависимость detected.

Хорошая статья о тестировании микросервисов «Microservices test architecture. Can you sleep well without end-to-end tests?»
с примерами кода.

https://threedots.tech/post/microservices-test-architecture/

Завтра в clubhouse в 19:30 мск поговорим о проблемах микросервисной архитектуры.

https://www.joinclubhouse.com/event/xpA28noL

w/ Anna Pimkina, Sergey Baranov, Pavel Scherbinin, and Evgeniy Peshkov

Подборка ссылок про архитектуру Netflix, одну из самых часто цитируемых микросервисных архитектур:

Netflix: What Happens When You Press Play?
Dec 11, 2017
http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html

High Quality Video Encoding at Scale
Dec 9, 2015
https://netflixtechblog.com/high-quality-video-encoding-at-scale-d159db052746

Building and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency
Mar 25, 2019
https://netflixtechblog.com/building-and-scaling-data-lineage-at-netflix-to-improve-data-infrastructure-reliability-and-1a52526a7977

Ten years on: How Netflix completed a historic cloud migration with AWS
Sep 10, 2018
https://www.channelasia.tech/article/646530/ten-years-how-netflix-completed-historic-cloud-migration-aws/

The Netflix Simian Army
Jul 19, 2011
https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116

Globally Cloud Distributed Applications at Netflix
Oct 2012
https://www.slideshare.net/adrianco/netflix-global-cloud

Open Connect Overview
https://openconnect.netflix.com/Open-Connect-Overview.pdf

Open Connect Deployment Guide
http://openconnect.netflix.com/deploymentguide.pdf

Netflix and Fill
Aug 11, 2016
https://netflixtechblog.com/netflix-and-fill-c43a32b490c0

Automating Operations of a Global CDN
Sep 14, 2019
https://www.youtube.com/watch?v=Lwh6Yd_kfsQ

Mastering Chaos — A Netflix Guide to Microservices
Dec 07, 2016
https://www.infoq.com/presentations/netflix-chaos-microservices/

Netflix Revenue and Usage Statistics
March 6, 2020
https://www.businessofapps.com/data/netflix-statistics/

Netflix Play API — Why we build an Evolutionary Architecture
Dec 12, 2018
https://www.infoq.com/presentations/netflix-play-api/

Keystone Real-time Stream Processing Platform
Sep 10, 2018
https://netflixtechblog.com/keystone-real-time-stream-processing-platform-a3ee651812a

Netflix Releases Open Source Message Security Layer
Nov 24th, 2014
https://www.infoq.com/news/2014/11/netflix-msl/

Netflix Open Source
https://netflix.github.io/

Titus, the Netflix container management platform, is now open source
Apr 18, 2018
https://netflixtechblog.com/titus-the-netflix-container-management-platform-is-now-open-source-f868c9fb5436

Engineering Trade-Offs and The Netflix API Re-Architecture
Aug 23, 2016
https://netflixtechblog.com/engineering-trade-offs-and-the-netflix-api-re-architecture-64f122b277dd

Kafka Inside Keystone Pipeline
April 27, 2016
https://netflixtechblog.com/kafka-inside-keystone-pipeline-dd5aeabaf6bb

Open Sourcing Zuul 2
May 21, 2018
https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3

История становления AWS из первых уст (Dan Rose).

Небольшая цитата из рассказа по ссылке, относящаяся к теме канала: «Around this same time, Jeff was also interested in decoupling internal dependencies so teams could build without being gated by other teams. The architectural changes required to enable this loosely coupled model became the API primitives for AWS.»

https://twitter.com/danrose999/status/1347677573900242944?s=27

Четыре виде кеширования, используемые в микросервисной архитектуре Wix

1. Locally Persisted (or S3 backed) Configuration Data Cache
2. Kafka topic based 0-latency Cache
3. (Dynamo)DB+CDC based Cache
4. HTTP Reverse Proxy Caching (Varnish cache)

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

https://medium.com/wix-engineering/4-microservices-caching-patterns-at-wix-b4dfee1ae22f

Фейсбук сегодня напомнил, что в этот день в 2016-м году я написал такой текст о качестве:

Правильное и уместное использование инженерных процессов и практик в купе с отлаженным и осознанным применением процессных подходов позволяют получить на выходе качественный код и первоклассные системы.

Очень часто в понятие «качественный» вкладывают смысл «корректный с точки зрения функциональности». В действительности же «качественный» можно обозначить, как открытый к изменениям. И вот в игру вступают такие термины, как: «простота», «понятность», «гранулярность», «инкрементальность».

Суть в том, что если посмотреть на «качество» с этой точки зрения, то мы можем попытаться его измерить. Общей мерой качества становится то, как быстро и насколько безопасно мы можем вносить изменения в систему.

———

Микросервисная архитектура оказывает весьма положительное влияние как на скорость, так и на безопасность внесения изменений, особенно при необходимости масштабировании (at scale).

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

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

Немного подробнее и в цифрах. Здесь X - знак умножения.

Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента) —
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)

Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля

фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.

Вынесем стоимость разработки фичи за скобки, получим:

Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента) —
(фактор стоимости разработки самого повторно используемого компонента)
)

Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.

Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?

1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).

Итого, делаем вывод, что для микросервисов в их первоначальном определении повторное использование не применимо из прагматичных соображений. Каждый микросервис создается под свои границы в конкретной модели предметной области бизнеса. Повторное использование микросервиса приводит к появлению нового микросервиса в новом контексте, развивающегося автономно от изначального микросервиса.

Готов подискутировать в комментариях.

В подлодке планируется неделя распределенных систем. До понедельника - early birds. podlodka.io/becrew

“Don't build elaborate APIs that mimic the back-end system's design. Instead, build consumer-driven APIs that provide the service in a format that the front-ends prefer.” (с) Gregor Hohpe, Cloud Strategy

При проектировании API учитывайте контекст, в котором сущность используется.

Вместо всеобъемлющего
GET /product/123

Используйте хотя бы контексты
GET /catalog/product/123
GET /checkout/product/123
GET /someothercontext/product/123

С теми атрибутами, которые нужны в заданном контексте. Эту рекомендацию можно использовать и в монолите, в микросервисах же она жизненно-необходима.

Если пойти дальше, в DDD (например через event storming), то API изменятся еще сильнее и станут отражать поведение, а не сущности:
/GetAvailableProducts
/GetProductDeliveryOptions
/GetProductsAtSale

Такие API удобно развивать, они обеспечивать минимальную связанность и максимальное сцепление.

Проверим от противного
Три Use Cases:
- Отобразить доступные на складе продукты
- Отобразить варианты доставки продукта
- Получить список продуктов, участвующих в распродажах

В случае реализации трех сценариев с использованием метода /product/123 мы получаем зависимость всех трёх от одного API. Потребность в изменениях для одного приведет к необходимости координации изменений со всеми остальными. В случае API, определяемых от поведения таких зависимостей нет.

Рейтинг баз данных по популярности. Может пригодиться как одно из измерений в выборе БД под потребности конкретного сервиса.
https://db-engines.com/en/ranking