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

Видео выступления Филиппа Уварова «Краткая история 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-и команд, пытаясь выяснить, что делает команды более или менее эффективными. Исследование показало, что психологическая безопасность — одна из пяти базовых основ высокоэффективных команд. При этом — самая важная. В такой культуре люди фидбечат свободно, принимают фидбек, меняют что-то и у них просто не остается поводов для конфликтов (гипотетически) и остается куча энергии и времени на решение крутых задач.

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