Очень много материалов по кликхаусу: https://presentations.clickhouse.tech/talks_index.html

Немного необычные статьи про масштабирование по аналогии IKEA =)

https://codesensei.medium.com/http-request-and-response-and-how-web-applications-work-76780d4cb14c
https://codesensei.medium.com/how-to-scale-a-web-application-to-handle-infinite-amount-of-traffic-b3f3028bd923

Достаточно свежая, очень классная книга по теме Security Chaos Engineering.

По ссылке — видео выступления для SpbDotNet на тему «Event Storming: избавляемся от предположений в коде» от 14 апреля. Видео на два с половиной часа =)
http://agilemindset.ru/event-storming-избавляемся-от-предположений/

На фото происходит ровно то, что написано, без двусмысленных толкований 🙂

Фейсбук напомнил о написанном 5 лет назад :) Легаси Стрит :)

Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»

Есть идеальный код, а есть просто хорошо структурированный

Так вот, идеальный код — практически невозможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.

Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.

Статья от нетфликс о hexagonal architecture: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749

Рассуждения Саймона Брауна на тему организации кода: https://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html

Кому интересна история - первая статья о hexagonal architecture (Alistair Cockburn): https://archive.is/5j2NI
Для любителей видео: https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL

После двух лет использования автор статьи перешел с istio на linkerd. Статья полезна тем, кто выбирает какой использовать service mesh.

https://link.medium.com/00ksLCz9Fgb

Примерно в 3/4 продуктов, с которыми переходим на микросервисную архитектуру нет версионирования API, а внешние библиотеки и сервисы используются AS IS (не обернутые в интерфейсы), проникая, словно споры плесени в кодовую базу продукта и подменяя своими сущностями сущности предметной области самого продукта, создавая зависимости, образуя vendor lock. Вирусное поведение, только никакой касперский тут уже не спасет, только собственная голова =)

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

В микросервисной архитектуре команды могут самостоятельно выбирать наиболее подходящий инструментарий для достижения требуемого бизнес-эффекта, так что если не договориться о методах снятия таких зависимостей можно неплохо попасть на vendor lock.

Ищем спикеров на ArchDays.ru

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

По любым вопросам пишите в личку @sergey486 или в коментарии к этому сообщению.

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

Вышел результат исследования stackoverflow «developer insights» за этот год.

https://insights.stackoverflow.com/survey/2021

​​Первого сентября собираемся на архитектурное Ката 👊

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

Формат простой: 10-15 минут закрыть все вопросы по заданию, разбиваемся на малые группы на час (сессионные залы в zoom), возвращаемся в общий зал и презентуем результаты. Предварительно у каждого по 10 минут на презентацию результатов.

То есть это не «прийти и послушать», это «прийти и попроектировать».

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

Краткое описание тут: http://archtalks.ru/2021/08/28/архитектурное-ката-01-09-2021/
И тут (тут же обсуждение задания): https://miro.com/app/board/o9J_l0aYN3U=/

Нужна регистрация (простая, через стандартную форму зума).

Как думаете, есть ли смысл в COTS-микросервисах? Может уже есть такие?
Да, решения на микросервисах есть (АБС, кредитные конвейеры), а вот так, чтобы продавались отдельные микросервисы?

Понятное дело, что они строятся под конкретную модель предметной области, но в устоявшихся индустриях есть стандартные термины и определения (bian в банковской сфере, своя терминология в авиации, в телекоме уже свои референсы появились), так что… «Маркетплейс, продающий микросервисы, на которых сам же и построен» – в целом не такое уж и фентези…

Хорошая статья про кеширование от AWS Senior Principal Engineer.

И интересный термин metastable distributed system внутри.

https://brooker.co.za/blog/2021/08/27/caches.html

Через 10 минут стартанем, уже собираемся

Встреча прошла отлично, спасибо всем, кто пришел =)

Материалы

Доска в Miro со схемами и ссылками:
https://miro.com/app/board/o9J_l0aYN3U=/

Начальные вводные (по сути проговорил то, что на доске написано):
https://www.youtube.com/watch?v=u05iQ3wy7DQ

Презентации решений (в описании проставил временные метки):
https://www.youtube.com/watch?v=Qu3g_eiY4XA