Микросервисы / распределенные системы
3.78K subscribers
105 photos
1 video
21 files
309 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Если есть вопросы или предложения, пишите @sergey486
Download Telegram
Forwarded from DDDevotion
Читал вчера статью Маттиаса Верраеса про Segregated Event Layers и внезапно узнал, что это серия статей о паттернах в контексте DDD и Messaging Architecture

https://verraes.net/2019/05/ddd-msg-arch/ Enjoy!
Forwarded from Code of Architecture
📖 Заканчиваем обсуждать Building Evolutionary Architectures

На последнем стриме по этой книге рассмотрим всю третью часть Impact. А именно разберем три главы, посвященные реализации эволюционной архитектуры. Среди тем, которые обсудим:

— рекомендации для построения эволюционной архитектуры;
— подводные камни и антипаттерны на пути к эволюционной архитектуре;
— влияние техники, бизнеса, орг.структуры и команд на возможность реализации эволюционной архитектуры.

Эфир проведем вмест с Сергеем Барановым, организатором и создателем конференции ArchDays, а еще автором Agile Mindset и телеграм-канала «Микросервисы — русскоязычное сообщество».

🔔 Последний стрим по Building Evolutionary Architectures проведем во вторник 13 июня в 18:00 по Москве.

Не забудьте подписаться на уведомления нашего ютуб-канала, чтобы не пропустить начало.
Please open Telegram to view this post
VIEW IN TELEGRAM
Приходите выступать 👌

ArchDays.ru

(И спасибо всем, кто уже прислал заявки, за июль планируем больше половины программы собрать)
«Ограниченный контекст — это граница модели, а модель применима только в своем ограниченном контексте. Ограниченные контексты реализуются в независимых проектах и решениях, что позволяет каждому ограниченному контексту иметь собственный жизненный цикл разработки. И наконец, ограниченный контекст должен быть реализован одной командой разработчиков, и, следовательно, он также является границей владения.»
Очень важный материал «How Complex Systems Fail»

https://how.complexsystems.fail/
Скончался Кевин Митник. Уходят легенды.

Его книгу «Искусство обмана» я прочел около 20 лет назад и она до сих пор стоит у меня на книжной полке.

Именно эта книга в то время проявила во мне интерес к взлому и безопасности и выступила катализатором к изучению всего, что касается сетей.

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

Это приятные воспоминания об увлекательных временах, а началось все с одной единственной книги Кевина Митника.

Покойся с миром.
У меня окончательно оформилось предложение по точечному аудиту/исследованию микросервисного архитектурного решения :)

Аудит затрагивает:
- степень соответствия выбранного стиля бизнес-модели и потребностям рынка
- степень соответствия орг. структуры микросервисному архитектурному стилю
- степень соответствия компетенций
- степень соответствия процессов горизонтального и вертикального взаимодействия
- степень соответствия процессов управления архитектурной целостности и развития архитектуры
- степень соответствия процессов управления тех долгом
- степень удовлетворения требованиям и атрибутам качества

А по итогу идет перечень дисфункций/ и стратегия их устранения.

«это была славная охота» :)

Скоро предложение будет опубликовано, пока все собирал и систематизировал получилось материала на книгу, более 200 страниц только текста :)

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

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

Версию лайт для самопроверки думаю выложить в паблик, но она еще не готова для публичного доступа.

Что побудило?
Некоторый застой в практиках архитектурного ассесмента. Если погуглить, то толком кроме ATAM ничего и не находится, причем статьи 15-летней давности. А индустрия не стоит на месте.

Еще планирую собрать рабочую группу из активистов для проработки деталей.

Все это будет, периодически буду публиковать новости на эту тему, всем хорошего дня :)
1 августа в 19:00 пройдет митап ArchDays: «Проектирование БД: От NF к денормализации данных»

Спикер: Антон Цитульский — Старший разработчик в Тинькофф.

На митапе Антон расскажет:
— о плюсах и минусах нормальных форм (NF);
— когда пора денормализовывать схему и как это сделать;
— как развивать схему БД с учетом роста данных и контекста бизнес-домена.

А в конце встречи обсудим тему вместе с участниками митапа.

💎 Регистрируйтесь: https://archconf.ru/meetup-010823
Тема следующего митапа - «Общий процесс проектирования микросервисов».

Дату и время анонсируем позже. А пока…
Напишите ваши вопросы или проблемы с проектированием заранее в комментариях к этому посту, мне это поможет лучше попасть в ожидания 🎯
Статья про надежный обмен данными между сервисами при использовании стриминговой базы данных.

(В посте есть ссылка на статью с описанием стриминговых баз данных и зачем они нужны).

https://www.iambobur.com/post/reliable-microservices-data-exchange-with-streaming-database

Меня эта тема заинтересовала, потому что как минимум в одном текущем проекте увидел явную потребность. Кто использует/использовал, напишите в комментарии или в личку какую базу используете и в каком контексте, можно устроить митап на тему стриминговых баз данных и их применения.
Название: "Код Зла"

Сценарий:

Начало
Туманный городской пейзаж. Мы видим старое здание с табличкой "Software Corp". Главный герой - Алекс, молодой архитектор ПО, приезжает на новое место работы, где ему поручают создание новой банковской системы.

Сюжет 1: Таинственное наследие
Алекс знакомится с командой и узнает, что последний архитектор, работавший над этим проектом, исчез без следа. Оставив лишь заметку: "Разберитесь с доменами... или они разберутся с вами".

Сюжет 2: Пробуждение домена
Алекс начинает анализировать предметную область. Каждый раз, когда он ошибается в понимании домена, странные вещи начинают происходить: свет мерцает, программное обеспечение ведет себя непредсказуемо, а коллеги слышат шепот неведомой сущности в коридорах.

Сюжет 3: Встреча с предыдущим архитектором
Алекс случайно обнаруживает потайную дверь в офисе. За ней - старый серверный кластер и дневник прошлого архитектора. Дневник рассказывает о том, как домены, неправильно оформленные и понятые, стали живыми сущностями, стремящимися воплотить свои правила и инварианты в реальном мире.

Сюжет 4: Борьба и понимание
Алекс решает воспользоваться DDD, чтобы "укротить" домены. Его команда, преодолевая страх, ведет глубокие интервью с экспертами домена, определяя ограниченные контексты и настоящие потребности пользователей. С каждым новым открытием, мистическая активность в офисе уменьшается.

Сюжет 5: Конечная битва
Алекс создает идеальную модель, где каждый агрегат и сущность на своем месте. Однако, последний домен, самый сложный и неясный, начинает активно сопротивляться. Свет гаснет, здание начинает трястись. Алекс, вдохновленный духом прошлого архитектора, проводит мастер-класс по DDD, и в результате выявляется последний недостающий элемент. Сущность, терроризировавшая их, успокаивается и становится частью их системы.

Конец

Солнце вновь светит над "Software Corp". Алекс и его команда понимают, что настоящая магия DDD - в понимании и сотрудничестве. Вдали, туманный силуэт предыдущего архитектора благодарно кивает им и исчезает.

Титры.

(с) ChatGPT
Опрос, касается только статей, не книг и только архитектуры/дизайна.

Когда у вас возникает вопрос прикладного характера и вы начинаете гуглить и искать ответы в статьях или на условных stackoverflow, (в результатах поисковой выдачи), вы:
Anonymous Poll
24%
Быстро находите ответ
36%
Долго и упорно ищите и в итоге находите ответ
22%
Чаще не находите ответ
2%
Ни разу не смогли найти ответ
16%
Посмотреть результаты
Микросервисы / распределенные системы
Опрос, касается только статей, не книг и только архитектуры/дизайна.

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

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

1. Максимально вкладываться в образование (в широком смысле). Часто из-за высокой загрзуки на это остается мало времени, а именно это дает возможность сократить множество нерешаемых задач
2. Формировать внутренние и внешние сообщества, где вбросил вопрос и кто-то может знать конкретный вектор поиска ответа или ответ
3. Развивать практические навыки на различных хакатонах и за счет прототипирования, – теория без практики быстро выветривается из головы
4. Расширять кругозор на митапах и конференциях, – здесь как раз идеи того, что можно попробовать сделать на практике; важно то, что вы знаете с кем можно обсудить проблему детальнее, этот человек буквально перед вами
5. Отдавать предпочтение книгам, – все-таки долгое погружение в один контекст дает лучший эффект, чем сотня разрозненных статей. Статьи пишут те, кто читает книги 🙂 Это я, конечно, упростил, но, скорее всего, именно книги помогут чаще находить ответы самостоятельно, потому что они развивают мысль, а статьи все ж чаще дают конкретный ответ, без более широго контекста, подводки, рассуждений, выводов с примерами и так далее

Поделитесь своими идеями в комментариях, какие еще видите подходы?

Может быть у нас вместе получится собрать несложный фреймворк/экосистему с конкретными материалами, но сначала нужно определить базис, а это как раз и есть различные подходы.
Традиционно для подписчиков канала скидка на archdays.ru 20% и на онлайн и на оффлайн по промокоду microservices_arch

В этом году большой конкурс и чтобы никого не расстраивать, с теми, кто согласился, мы провели и проведем еще митапы (два уже запланировано, скоро анонсы), а спикеров митапов ArchDays Meetup мы приглашаем бесплатно на конференцию, так что их можно будет найти пообщаться 🙂