Продолжаю делиться своими мыслями насчет книги "Learning DDD". Вчера я дописал обзор на ту часть, где Влад Хононов рассказывал про связь DDD с микросервисами.
Эта часть мне особенно понравилась, так как я помню свои вопросы насчет того, как определять их границы. Особенно это было актуально после прочтения книги Сэма Ньюмана “Building Microservice”, после которой эти вопросы и остались. На часть вопросов Сэм ответил в книге “Monolith To Microservices”, но объяснения Влада мне понравились больше:)

Подробнее в обзоре https://bit.ly/learnDDD2

#SoftwareArchitecture #Microservices #Architecture #ExternalReview #DDD

Сегодня я решил вспомнить про очередную книжку по архитектуре программного обеспечения “Microservice Patterns and Best Practices” за авторством Vinicius Feitosa Pacheco.
Книжку я прочел несколько лет назад и она показалась мне интересной и с практическим уклоном, но это немного не мой профиль. Я люблю концепции и теории, а автор пошел от сохи:)
В итоге при чтении книги автор показывает построение микросервисной архитектуры для новостного портала и одновременно
- знакомит читателей как с архитектурными концепциями и паттернами
- так и дает им написать код на python и go
- сконфигурировать nginx
- написать docker файлы
- настроить docker compose и т.д.

А я люблю читать концепции, хотя ясно, что дьявол кроется в деталях, но явно не в настолько простых:)
Подробнее про концепции из этой книги можн прочитать в моем обзоре https://bit.ly/MPatternsBookRev

#Architecture #SoftwareArchitecture #Microservices #Patterns #DistributedSystems

AWS re:Invent 2022 - Keynote with Dr. Werner Vogels

Интересное выступление CTO Amazon.com, которое начинается с антуража матрицы и заканчивается призывом делать симуляции всего вокруг.
А внутри двухчасового выступления Верненр Фогель, в футболке с лямбда на груди, рассказывает об асинхронном мире вокруг и преимуществах создания асинхронных систем, которые учитывают это.
Он говорит про concurrency и parallelism и приводит примеры из дизайна распределенных систем, а точнее принципов, по которым было построено AWS S3 в свое время.
Рассказывает про эволюцию архитектуры самого Amazon через стадии Monolith -> SOA -> Microservices -> Shared Services
Вернер дает ссылку на документ 1998 года, который назывался Amazon Distributed Computing Manifesto и говорит, что уже почти 25 лет назад инженеры Amazon думали про наш распределенный мир. И если заглянуть в статью, то видно, что именно этот подход привел к тому, что в 2004 году он пообщавшись с ними стал их CTO на следующие 18 лет.
Дальше он рассказывает про работу workflow рассказывает про сервисы AWS Step Functions и AWS Event Bridge и их расширения.
И после этого он переходит к песне про Event Driven Architecture (EDA) про loosely coupled architecture, которое позволяет создавать системы, которые могут эволюционировать.
И дальше достаточно долго речь идет про то, как делать EDA на иструментах от AWS.
Интересно, что в процессе автор рассказывает про инструмент Amazon Builders Library, который является аналогом книги GoF про паттерны, но только от инженеров AWS и в контексте инструментов от AWS (надо будет почитать статьи оттуда).
Дальше автор анонсирует Amazon Code Catalyst для ускорения создания приложений для AWS, где объединен ваш код, CI/CD, issues и так далее.
Ну и заканчивается все переходом к 3D и моделированию окружающего мира, что закольцовывает выступление, которое начиналось с симуляции аля матрица.

#Architecture #SoftwareArchitecture #AWS #Patterns #EDA #Microservices #Technology #Conference

Just-in-time Architecture • Macklin Hartley • YOW! 2022 (Рубрика #Architecture)

Хорошее выступление про архитектуру, где автор рассказывает простую мысль о том, что нет универсальной архитектуры, которая подойдет всем. Выступление строится на примере системы для покупки пользователями картинок-аватаров, а в качестве наглядной метафоры используется работа кофейни. В этой метафоре кофейна постепенно растет и ей треубется эволюционировать, а в ходе этой эволюции автор успевает пройти по темам
1) Старта с монолита, а дальше переход на microservices, что становится скорее distributed monolith с availability coumpling
2) Потом распределенный монолит автор чинит с использованием event-driven architecture, где рассматривается два типа событий: event notification и event carried state transfer и 3 варианта генерации событий: transaction logs, transaction outbox pattern, event sourcing
3) И под конец автор доходит до communication patterns, где рассмотрели хореографию и оркестрацию. В хореографии события используются для общения сервисов между собой, децентрализованно и элегантно, но сложно для понимания что именно происходит, а в оркестрации у нас централизованный workflow

#Conference #Architecture #SoftwareArchitecture #SystemDesign #Software #DistributedSystems

Architecture Modernization: Aligning Software, Strategy, and Structure - Nick Tune

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

Architecture Modernization is about converting architecture from a competitive disadvantage to a competitive advantage.

И дальше его подход содержит три пункта
1) Architecting for flow - проектирование для улучшения потока создания ценности и взаимосвязи изменений
2) 5 Essential tools for architecture modernization - инструменты для модернизации архитектуры
3) Kickstarting and enabling architecture modernization - как начать модернизацию

В первой части автор говорит про stream-aligned команды из team topologies, которые формируют вокруг value-stream. Отдельно надо отметить, что иногда между системами команд бывают зависимости, которые влияют на flow. Поэтому все и мечтают создавать автономные команды (про это было много в докладе, о котором я рассказывал вчера):)

Дальше спикер говорит про fullstack модернизацию по всем уровням

- User interface - modernize the UI to enable a better UX improving user happiness and productivity
- Software - modernize tech and alignment to domain model for code that is easier to understand and evolve.
- Domain model (conceptual) - modernize the conceptual domain model, creating a better shared understanding and language improving collaboration & innovation
- Domain - modernize the domain by adding new and better capabilities which create new business and customer value.

Дальше речь идет про инструменты:
1) Активное слушание - оно помогает понять бизнес-цели и проблемы заинтересованных сторон
2) Impact mapping - в этом подходе создается связка: strategic business objectives - actor - impact - deliverables. Подробнее можно почитать в книге "Impact mapping", про которую я писал раньше
3) Wardley mapping - здесь компоненты архитектуры связаны с цепочкой создания ценности, а также стадиями жизненного цикла продукта. Интересная концепция, про которую я узнал впервые и которую можно использовать для определения текущего состояния и эволюции компонентов архитектуры.
4) Event storming - это интересный подход lkz проведения воркшопов для коллаборативного изучения сложного бизнес домена ... Подробнее можно прочитать в моем посте
5) Modernization strategy selector - график для обсуждения вариантов модернизации через раскладывание по осям platform modernization и product, domain, software modernization
В конце перечисления автор еще вспоминает CodeScene - инструмент для поведенческого анализа кода.

Дальше автор рассказывает, а с чего стоит начать модернизацию и показывает матрицу 2x2 (риски - эффект). В итоге, у нас есть
1) "низковисящие фрукты" (риск небольшой, а эффект значительный)
2) проекты, для тех, кто уклоняется от риска (риск и эффекты незначительные)
3) проекты, для тех, кто готов к большим ставкам (риски и эффекты большие)
4) "последняя паста в тюбике" (рисковые проекты с низким эффектом) - такими часто вообще не занимаются никогда:)

В итоге, надо сорвать низковисящие фрукты и выдать результаты в первые 3 месяца - полгода, но продолжать работу над крупными изменениями параллельно. Во время модернизации стоит сделать команду поддержки для процесса модернизации, но потом ее надо вовремя распустить. Отдельно стоит отметить, что у успешной компании есть свои плюсы и минусы, такие как сложность и унаследованные процессы, но это цена успеха. Зато у стартапов таких проблем нет и они могут внедрять инновации быстрее. Также модернизация должна быть больше, чем просто техническое усовершенствование, и что технология сама по себе не решит все проблемы. Ну и финально спикер выступает капитаном очевидность и говорит о том, что важно не переоценивать инвестиции в неправильные области и не недооценивать их в нужных областях.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment