Гугл выпустил поисковик по 25 миллионам открытых датасетов!

PS: для микросервисов нашлось 47 :)
https://datasetsearch.research.google.com/search?query=Microservices

Итоги встречи «BDD в разработке, архитектуре и инфраструктуре»

Внутри краткие выводы, презентации и пополнительные ссылки.
Помимо прочего — обсудили пользу от BDD для микросервисов.

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

Результаты опроса более 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»

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