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

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

Руслан ответил на эти и другие вопросы в ходе доклада. А также рассмотрел тревожные сигналы о необходимости рефакторинга, поговорил о принципах рефакторинга в переложении на архитектуру микросервисов, наметил конкретные шаги и этапы безопасного и итерационного рефакторинга архитектуры на практике.

Смотреть: https://youtu.be/foKH9KJjgRI

Mike Beedle (died at March 23, 2018)

Agile Manifesto co-creator
proposed the term “agile” to manifesto co-creators introduced “Enterprise Scrum” and “Business Agility”

Source: https://twitter.com/mikebeedle/status/976500772438409216

A Definition of Done for Architectural Decisions

https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9

В целом хороший перечень пунктов с конкретикой, касающихся:
- Доказательной базы
- Критериев оценки и наличия альтернатив
- Непосредственно процесса принятия решения
- Документации
- Реализации и плана пересмотра решения

Пример
Are we confident enough that this design will work?
Have we decided between at least two options, and compared them (semi-)systematically?
Have we discussed among each other and with peers just enough and come to a common view?
Have we captured the decision outcome and shared the decision record?
Do we know when to realize, review and possibly revise this decision?

Всем привет)

Какие ресурсы/блоги/рассылки по архитектуре читаете?)

Часто в разные чаты прилетают запросы на разбор реальных архитектурных кейсов.

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

Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌

В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса

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

Большой-большой материал по «Data Engineering: ETL, ELT, Data Pipeline, Data Warehouse, Data Lakes, Data Marts»

https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/

Девушки, с праздником! 🌷🥂

Cейчас в чате обсуждаетя (примерно здесь старт https://tttttt.me/microservices_ru/17178), сокращенно:

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

🙂

Ссылки по DevSecOps

- Awesome Threat Modeling
- Awesome Policy-as-Code
- Cloud & DevSecOps Learning Resources
- DevSecOps Roadmap
- DevSecOps Reference Architecture
- OWASP DevSecOps Guideline
- DevSecOps Maturity Model
- OWASP SAMM

#DevSecOps

Всем привет, есть новости 🙂

14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.

А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.

Наблюдения Jim Hurne, technical lead for a "services" team within IBM Watson касательно структуры команд под микросервисы:

Many of the organizations that have successfully applied the microservices style (e.g. Amazon, Netflix) have had a similar internal team structure:
- Teams are responsible for one or more services
- No service is owned by more than one team
- Teams are relatively autonomous and are free to make independent implementation choices, so long as they adhere to the agreed-upon APIs and service contracts.
- Teams contain the complete skill set necessary to support a service from inception to deployment (product management, development, operations, database administration, production support, etc).
- While teams are loosely coupled from internal implementation details, they are tightly aligned on overall organizational goals.

А я как-то пропустил, что многоликий DDD и на DotNext выложили, доклад похожий, но рассказан немного иначе и все-таки на конференции, а не на митапе 🙂
https://www.youtube.com/watch?v=2WHarUW0PjI

В Архитектурных Этюдах новый кейс.

…Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку…

Кто успел поиграться, как впечатления?

We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices.

https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html

Нетленная классика, принципы и практики управления рисками от Barry Boehm

Заметки по распределенным системам.

Категории заметок

- Concepts
- Failure Detection
- Leader Election
- Replication Consistency
- Dissemination
- Anti-Entropy
- Gossip
- Distributed Transactions
- Consensus
- Paxos
- Message Queues
- Distributed Locks
- Clustering
- Cache
- Rate Limit

https://tangentyh.github.io/notes-of-tan/backend/distributed.html

Latency Comparison Numbers

Source: https://gist.github.com/jboner/2841832?permalink_comment_id=412306

A Metrics Suite for Microservices, EventStorming and DDD 👍
Measuring Coupling and Cohesion of Bounded Contexts on an EventStorming Domain Model

https://phillipjohnson.co.uk/a-metrics-suite-for-microservices-eventstorming-and-ddd

Много ссылок по Solution Architecture
https://github.com/unlight/solution-architecture