​​Легким движением руки ноут с 8GB превращается в микро датацентр (с подробной инструкцией)

Немного красивой архитектуры

В микросервисах нередко I/O (например — работа с базой) операции рассматриваются как часть Unit’а в контексте Unit-тестирования. Таким образом, Unit-тесты начинают больше походить на интеграционные, интеграционные тесты — на тесты на живой системе в проде, а прод-тесты — на мониторинг и исследование. И в целом уже несколько раз приходилось переопределять состав юнита (минимальной, атомарной единицы). Ведь если сервис в 95% случаем обращается к базе и фактически это весь его код, то появлсяется смысл рассматривать вызов базы как часть юнита, даже несмотря на возможные side effect’ы с сетью и тем самым получить больший outcome от тестов за счет снижения стоимости поддержки (отсутствия заглушек и двух наборов тестов), фокусируясь на бизнес-функциях.

У многих разработчиков и архитекторов законно возникает множество вопросов к согласованности данных в микросервисах. Некоторые приходят к паттерну SAGA и вопросов становится еще больше 🙂 Saga из тех паттернов, к которым интуитивно подходит я бы не советовал по двум причинам:

1. Она все-таки сложна в реализации и
2. Нередко затрагивает достаточно важные бизнес-процессы в распределенной, событийной системе

То есть вероятность завалить всё высокая, а исправить быстро (и ладно бы исправить — банально понять в чем дело) получается далеко не всегда.

А ведь больше половины ответов на чаще всего возникающие вопросы содержатся прям вот в том самом документе, который её и породил: https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

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

Кто еще не читал — must read!

Статья «Размер микросервиса»

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

Идея простая — изоляция важнее размера.

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

По теме канала будет про тестирование приложений с потоковыми процессами (kafka) от Виктора Гамова (confluent) и об управлении зависимостями в CI/CD от Олега Ненашева(cloudbees).

Как Spotify мигрировал свои 1200 микросервисов в Google Cloud.

Просто грандиознейшее переселение микросервисов.

— Сформировали команду миграции
— Разделили миграцию на две части: миграция сервисов и миграция данных
— Визуализировали все сервисы, цветами помечая перенесённые (в статье написано зачем)
— Затем разделили стратегию миграции сервисов еще на две: миграция сервисов и миграция пользовательского трафика
— Мигрировали итерациями (1-2 недельными)
— Команда миграции втихую ломала смигрированное, чтобы посмотреть на реакцию разработчиков 😈

По ссылке статья и видео (англ)

Вспомним определение.

​​Внезапно прошла волна репостов статьи «Microservices considered harmful». Ссылка ниже.

Первая мысль из статьи
>>Если у вас спагетти в монолите, то при делении вы получите «spaghetti over HTTP».

Все правильно, только при чем тут микросервисы? Не устаю повторять две вещи:
1. «Выбирайте микросервисы за их преимущества, а не потому, что код монолита ужасен»
2. «Не нарезайте монолит AS IS, проведите моделирование с самого начала, постройте корректную модель предметной области, выделите независимые модули/пакеты внутри монолита и затем выносите микросервисы»

Вторая мысль из статьи
>>Производительность хуже, потому что пакеты бегают по сети.
Сравниваем время обработки сообщений и время на передачу данных. Потеряли на передаче 5 секунд, выиграли на параллельной обработке 10 минут. Так это работает.

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

А вот вывод отличный: «keep in mind that almost all technical challenges (code modularity, scalability, single point of failure…) will not be magically solved by using microservices». Все по делу.

———
Микросервисы — не панацея, они сложны, но у них есть существенные преимущества. Эти преимущества не нужны всем, выбор микросервисов должен быть очень прагматичным выбором. Монолит может быть качественно и модульно написан. Микросервисы нужны тогда, когда требуется независимая поставка/независимая замена/независимое развитие/независимое масштабирование/независимый выбор технологий и это действительно дает серьезное конкуретное преимущество. А не ради хайпа 🙂

Сегодня на TechLeadConf после моего выступления был вопрос — что делать, если приходится часто менять сервисы (примерно так). Вопрос касался Event Storming, — как часто корректировать модель, стратегический дизайн, как часто проводить периодические шторминги?

Короткий ответ — в зависимости от частоты изменений предметной области.
Высокая динамика изменений? Проводим чаще.
Предметная область относительно стабильна? Проводим реже.

Главное — делать это регулярно. Почему? Потому, что если будем назначать встречи по пересмотру модели, то такие встречи будут происходить после чего? Именно) После появления проблем. Регулярность даёт возможность обнаружить проблемы до того, как они стали реальными. Если же на регулярные встречи чаще приходим с уже случившимися проблемами дизайна — есть смысл начать проводить такие встречи чаще.

Скоро завершу оформление статьи по итогам выступления, а пока пример, когда пришлось склеить два микросервиса в один. Обычные дела)

Для тех, кто любит сестру таланта, основная мысль:
«When adding new functionality we should question whether our architecture still justifies itself. In this case, at the beginning it seemed that a ride and a prebook have a right to live as separate entities, and therefore have separate services and databases. As more requirements and features arrived, it became clear that the separation of services caused cumbersomeness.»

​​Рассуждения о том, где лучше расположить Event Handler.

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

Расположение Event Handler рассматривается через призму следующих характеристик:
- Выделение ресурсов на разработку и поддержку
- Наличие экспертизы в предметной области
- Потребность в изменении существующих сервисов
- Выбор технологий

Рекомендую прочесть всем, кто принял решение переходить с синхронного на асинхронный стиль взаимодействия.

​​Открыт прием докладов на конференцию ArchDays!

Детально проработав обратную связь с прошлой конференции мы расширили спектр тем:

Организационные вопросы в архитектуре
Архитектурная методология на базе теории сложности, подходов из области социо-техники, работ в области Agile Architecture от Open Group и прочих.

Моделирование в архитектуре
Практика Domain Driven Design, Event Storming, C4 model, Architecture as Code

Качество и надежность
Подходы к работе с качеством, например Chaos Engineering, тестирование микросервисов, самовосстанавливающиеся системы.

Технические аспекты архитектурных решений
Общая рубрика — кейсы применения микросервисов в организациях.

Безопасность в распределенных системах
Все, что касается безопасности в распределенных системах. Стандарты PCI DSS, PSD2 и прочие. Модели угроз в микросервисных архитектурах.

Облачные решения
Использования как российских облачных платформ, так и AWS/Google Cloud; serverless

Будет 🔥

COBOL в Кубере запустили...
По задумке - должно стать катализатором развития микросервисов на COBOL.
Что-но новенькое :)

https://containerjournal.com/topics/container-ecosystems/ibm-shows-instances-of-cobol-running-natively-on-kubernetes/

Кто должен разрабатывать админку?

Частый вопрос. Обсуждение на примерно эту тему сейчас идет в @microservices_ru

Суммирую в этом посте свои мысли.

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

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

Когда мы говорим о домене Продукта, то он находится НАД технической реализацией. А значит фронт, бэк, инфраструктура, — все, что относится к Продукту — это граница ответственности команды или нескольких команд (как в LeSS) в рамках одного домена.

Никаких отдельных команд для админки, оказывается, не требуется (если только админка не является реально существующим отдельным бизнес-доменом), а границы ответственности команды Продукта аккуратно соблюдены в рамках границ модели предметной области.

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

Подоспело видео моего выступления на TechLeadConf «Моделирование микросервисов с помощью Event Storming»

Приятно, что средний балл — 4,41 из 5.

Описание: «При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.»

https://www.youtube.com/watch?v=cG9DVbcPc9M

Ну теперь «познать кубер» стало действительно просто, смотрите что нашел: «Путеводитель по Kubernates для детей в картинках» :)

Убер написал статью о том, что они пришли к «Domain-Oriented Microservice Architecture» (и как они к этому пришли). Интересно, что я даже не думал, что можно как-то иначе получить слабосвязанное микросервисное решение. По крайней мере на текущем уровне нашего понимания процесса проектирования через модели предметной области.
Спойлер тем, кто был у меня на курсах «Проектирование микросервисов» — это примерно то, что мы делали с вами в течение почти всего первого дня (через все эти Event Storming’и, выделение контекстов, anti-corruption слои и прочие важные элементы) и затем наполняли техническими деталями.

Статья хорошая, советую.

Похоже, что статью удалили, но в гуглокэше она еще жива: https://webcache.googleusercontent.com/search?q=cache%3Af7N-baQWhTgJ%3Ahttps%3A%2F%2Feng.uber.com%2Fmicroservice-architecture%2F%20&cd=2&hl=ru&ct=clnk&gl=ru&lr=lang_en%7Clang_ru&client=safari&fbclid=IwAR1utfoUsdIDGAXi8DvG_yyJOE5D9yel-d_tU-vYGw6SkvNhXipd8NgPF2U

​​Перенес перевод модели оценки навыков и компетенций DevOps от DASA в Miro!

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

Кто хочет скопировать себе модель, пишите в личку, отправлю ссылку с правами редактирования (не выкладываю такую ссылку в паблик, потому как не проживет эта доска без вандализма и пары часов 😈

Достойное собрание материалов по RBAC для k8s.
Тема хоть и узкая, но одна из наиболее проблемных когда дело доходит до практики.

https://rbac.dev

Исследование состояния DevOps в России.

Полезное и важное дело от Экспресс 42 и Онтико. Давайте поддержим инициативу, а то на другие страны (DORA, Puppet,..) смотрим, а про себя не знаем.

Ссылочка на опрос:
https://ru.surveymonkey.com/r/VQZRLN6?fbclid=IwAR17rIikgnQvBdsheEj4mvbDocjcdI3tFO2a30qPtbtIF-QA-SX6hJK_jJE