#оффтоп #холизм

Счёл важным привести пример системного подхода в одном из величайших трудов по стратегии «О войне», Клаузевица:

«В нашем предмете, более чем в каком-либо другом, вместе с частью должно мыслиться целое»

Что важно, автор задаёт эту установку (холизм) с самого начала, во вступительной части.

57-й выпуск дайджеста для ваших выходных!
 
Understanding and implementing micro-frontends
on AWS
Руководство от Amazon в части формирования понимания архитектуры микрофронтенда и создания решений микрофронтенда на Amazon Web Services (AWS).
 
Apache Kafka Cluster Type Deployment Strategies
Несколько кластеров Kafka являются нормой, а не исключением. Варианты использования включают гибридную интеграцию, агрегацию, миграцию и аварийное восстановление. В этой записи
блога рассматриваются реальные истории успеха и кластерные стратегии для различных развертываний Kafka в разных отраслях.
 
Building A Generative AI Platform
Интересная статья про концептуализацию знаний про приложения с генеративным ИИ. Автор изучил, как компании внедряют приложения генеративного ИИ, и выделил много сходств в их платформах.
В этой статье он описываются общие компоненты платформы генеративного ИИ, что они делают и как они реализуются.
 
Thinking Like an Architect
Не устаревающая со временем концепция о роли архитектора от Gregor Hohpe. Автор книги «The Software Architect Elevator» недавно делал доклад «Thinking Like an Architect» на конференции
QCon London 2024. Эта статья представляет собой доклад, который начинается с объяснения ролей архитектора и концепции соединения уровней.
 
Control Flow—The Other Half of Integration Patterns
Еще одна статья от Gregor Hohpe. Он рассматривает концепцию Control Flow (поток управления) в части механизма реализации асинхронных взаимодействий.
 
Остальные статьи этого выпуска можно найти на Confluence.
Читаем
 

#оффтоп #комментирую

Прокомментирую пост выше.

Про микрофронтенды

В статье про микрофронтенды сочетание BFF и API Gateway заставляет задуматься: https://docs.aws.amazon.com/prenoscriptive-guidance/latest/micro-frontends-aws/introduction.html

Важный момент - микрофронты, это прежде всего орг паттерн.

В представленном варианте вслед за BFF у команды может появиться, да почти точно появится, свой бэкенд. Если это конечно «чисто фронтовая» команда и бэкенда у неё до сих пор не было.

В иных случаях, от BFF могут «пойти» запросы в обход API Gateway к «своим микросервисам».

Почему так? Потому что появление BFF у отдельной команды может говорить о том, что развитие API (выставленного через API Gateway) и бизнес-логики под ним, не успевает за потребностями команды (на сами деле за потребностями клиентов/заказчиков)

Про Control Flow

Статью Грега Хоупа про Control Flow читать обязательно: https://www.enterpriseintegrationpatterns.com/ramblings/queues_control_flow.html

Грег Хоуп - выдающийся автор.

Напомню, Грег один из авторов книги, которая по сути заложила стандарт (паттерны + набор символов) в интеграции: https://www.enterpriseintegrationpatterns.com/
Кто не читал, читать обязательно!!!

Данная статья - дальнейшее развитие темы интеграции Грегом.

#оффтоп

Итоги подводятся с трудом

Пытаюсь переварить нестыковки в терминологии. Похоже никто этим всерьёз не занимался. Не складывается целостная онтология.

А пока, чтобы подать признаки жизни, поделюсь своими наблюдателями и выводами в работе с ChatGPT (AI)

Наблюдения:
1. AI хорошо переводит код с одного языка на другой, если код написан хорошо; похоже, если человеку легко читать код, то и AI воспринимает его без проблем, вероятно, благодаря качественным обучающим данным, на которых он обучен
2. AI прекрасно помогает траблшутить (выявлять и устранять проблемы), но для этого нужно уметь траблшутить и задавать правильные вопросы, что требует опыта
3. AI хорошо генерирует примеры, если запросы точно сформулированы, но это также требует навыков и опыта

Выводы:
1. Уже не мыслю свою деятельность без AI, как помощника
2. AI как помощник в решении сложных задач пока пригоден только для опытных специалистов, поскольку умение задавать правильные вопросы требует глубокого понимания предмета
3. В обозримом будущем AI вряд ли сможет помочь в решении задач, сложнее тех, которые человек способен решить без AI

#кейс

К посту выше

С помощью ChatGPT за пару вечеров:
- обернул в FastAPI код несложного, но полноценного (не прототипа) приложения на Python, вообще не зная FastAPI на тот момент
- задокументировал API в Swagger, снабдив работающим примером
- упаковал в Docker (это) приложение на FastAPI вместе с зависимостями на Go

При этом, я много лет программировал на Java, а Python использую только изредка в последние годы, в основном ради удовольствия

#кейс

ChatGPT упешно решил задачу распределения ответственности (Responsibility Assignment ) и модульного синтеза

Я подавал описания бизнес-сценариев в ChatGPT и просил распределить их по модулям. ChatGPT успешно вывел структуру модулей и идеально (High Cohesion) распределил сценарии между ними. Примечательно, что шаг выведения функционала из сценариев (определение необходимого функционала для реализации сценариев) был пропущен. Сценарии были описаны на английском, что не стоит игнорировать.

Хотя пример был довольно простым, и я не затрагиваю вопрос «владения» сквозными сценариями, результаты всё же показались мне вдохновляющими.

Вполне может оказаться так, что качественно описанные сценарии (и требования в целом) могут принести дополнительный профит в проектировании, потому что они AI-Friendly

#оффтоп #комментирую

Начал читать «Implementing Data Mesh» Жана-Жоржа Перрина и Эрика Броды.

В главе 5, Driving Data Products with Data Contracts, авторы говорят о том, что создание доверия является основой для работы с дата-продуктами: «First, we try to nurture an honest and positive relationship with our customers.»

Они высказывают очень важную мысль: «When you think about a good product, probably one of the most important considerations is that you have trust in it.»

Перед этим они отмечают: «Trust is the foundation. Harvard Business Review (HBR) published a piece on how trust can be materialized.» и ссылаются на статью «The 3 Elements of Trust» Джека Ценгера и Джозефа Фолкмана (ссылка: https://hbr.org/2019/02/the-3-elements-of-trust).

Я тут же прочитал эту статью и был настолько взволнован, что решил не откладывать пост и сразу поделиться своими комментариями. В статье утверждается, что доверие базируется на трёх элементах: Positive Relationships, Good Judgement/Expertise и Consistency.

И у меня есть что сказать. В нашем с Алексеем Маркеловым стартапе (и моём первом стартапе) одним из элементов идеи была соцсеть, где связи планировалось взвешивать по уровню доверия. Мы исследовали тему доверия, опрашивая разных экспертов, до кого могли «дотянуться», и в итоге пришли к двум выводам:
- Оценка доверия не поддаётся алгоритмизации.
- Доверие — это результат совместного позитивного опыта.

Максимальное доверие рождается, когда люди вместе проходят "огонь и воду". При этом все три компонента доверия из статьи Harvard Business Review справедливы.

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

Ну а книгу однозначно рекомендую к ознакомлению: https://www.oreilly.com/library/view/implementing-data-mesh/9781098156213/

#забегаювперёд #важно

Понятие Data API неприменимо к дата-продуктам и вообще является довольно спорным.

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

Почему так?

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

С витринами данных то же самое: мы получаем данные таких дата-продуктов через интерфейсы СУБД.

В дата-продуктах можно наблюдать инверсию отношений между контрактом и интерфейсом.

Применительно к API, API реализует контракт в подходе Contract-First, да и в принципе — если контракт существует. Но момент создания контракта интерфейса ещё нет.

Применительно к дата-продуктам контракт описывает способ предоставления дата-продукта, способ получения данных, протокол (например, СУБД или объектного хранилища) и т. д. На момент создания контракта интерфейс существует и нужно его учесть в спецификации/дефиниции контракта

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

В потоковых (streaming) продуктах это интерфейсы брокеров/Pub-Sub систем, а не хранилищ, но сути это не меняет.

Хотя, конечно, дата-продукт может быть неотъемлемой частью какой-то системы.

Рассуждать о том, что является API, а что нет, очень удобно в контексте зависимостей. От чего возникает зависимость при взаимодействии с дата-продуктом?

Ещё одна мысль

Структуры данных в API - это часть интерфейса. Через разные методы интерфейса могут быть доступны разные данные.

Структура данных в дата-продукте - это часть продукта. Данные одного и того же дата-продукта могут быть доступны через разные интерфейсы, например, JDBC, ODBC, в топике Kafka (CDC)

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

Забегая вперёд, скажу, что стало понятно: под контрактами мы часто подразумеваем спецификации, в том числе машиночитаемые (WSDL, Swagger Definition, ProtoBuf), и не различаем контракты и оферты.

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

Напомню, что наличие машиночитаемых спецификаций — это основа для Automated Governance.

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

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

Для иллюстрации приведу цитату из статьи Джима Грея, который ввёл понятие транзакции. В своих трудах, например, он использует такие понятия, как сделка и контракт:

"The transaction concept derives from contract law. In making a contract, two or more parties negotiate for a while and then make a deal."
(“The Transaction Concept: Virtues and Limitations,” Jim Gray, June 1981)
Ссылка: https://www.cs.purdue.edu/homes/bb/cs542-06Spr-bb/TCVL-Gray-81.pdf

#предсказание

Побуду в роли оракула

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

Архитектура MASA от Gartner, на мой взгляд, лишь демонстрирует кризис идей. Акцент на гранулярности сервисов (macro, mimi, micro — multigrained) — это опасное заблуждение, которое ярко проявляется в MASA.
“MASA: Create Agile Application Architecture With Composable Apps, APIs and Services”, Gartner, Aug. 2024

При этом постоянно появляются направления архитектурной мысли, нацеленнные на продление жизни микросервисной архитектуры. На одно из них я хочу обратить внимание — это MACH Architecture: https://macharchitecture.com/

Gartner, комментируя MACH Architecture, говорит "правильные'' слова и как бы "притрагивается" к инженерии:
"The definitions used in MACH are not exactly aligned to some industry definitions — for example, the "microservices" in MACH refer to independent modular business services commonly provided as API-first SaaS services."
https://www.gartner.com/en/documents/5366163

Весьма вероятно, следующим архитектурным стилем станет SOA 2.0, где важными отличиями от (старой доброй) SOA будут:
- децентрализованное владение
- федеративный Governance
- платформизация

Я считаю, что концепция сервисной ориентированности является крайне удачной. Сервисная ориентированность подразумевает фокус на ценности (value) и удовлетворении потребностей. Этому вопросу я посвящу отдельный пост.

Думаю, стоит попытаться достичь цели «business and IT alignment» на новом витке развития IT.

Главное, что необходимо сделать на следующем этапе, — децентрализовать SOA, сблизить её с бизнес-архитектурой и внедрить инженерные практики, унаследовав при этом паттерны построения распределённых решений с независимой поставкой (ценности) компонентов, порождённые за годы «межвременья» микросервисов.

Технически новые архитектурные стили будут тяготеть к облачным технологиям, функциональному программированию и событийной ориентированности. В идеале, реализации SOA 2.0 будут облачно-нативными (cloud native) и реактивными, что мне особенно импонирует.

Важное уточнение

Любые инициативы, связанные с централизацией, включая создание федеративных структур, невозможны без устранения Agile-силосов и «дефеодализации» компаний. К сожалению, большинство компаний к этому не готовы, так как ещё не насытились сполна последствиями провалов крупных инициатив. Даже грома недостаточно, чтобы мужик перекрестился.

«Business and IT alignment» станет возможен, а SOA 2.0 приобретёт смысл лишь тогда, когда архитектурная функция будет поднята на стратегический уровень и наделена необходимыми полномочиями. Без выравнивания полномочий между бизнесом и IT достичь этой цели не получится.

А пока нужно запастись терпением и крепчать методологически, чтобы пережить безвременье в IT, с его бесшабашным Эджайлом и шальными микросервисами.

#datamesh #datafabric #dataproduct

Коллеги проделали значительную работу, проанализировав материалы по темам Data Products, Data Mesh и Data Fabric: https://link.springer.com/article/10.1007/s12599-024-00876-5

Эта статья оказалась очень своевременной и принесла моей душе умиротворение. Авторам удалось весьма удачно интегрировать эти концепты.

В конце статьи представлен полезный список источников. Рекомендую

Готовлюсь к интервью в канале друзей. Будут вопросы про монолитную архитектуру.

Планирую рассказать, почему само понятие монолитной архитектуры — это своего рода миф. В реальности не существует «монолитной архитектуры»; может быть монолитная конструкция и изделие, но не архитектура. И разработка не исключение.

Тем временем хочу поделиться презентацией с моего доклада на конференции «Подлодка». В этом докладе я анализирую разные определения термина «архитектура» и прихожу к выводу, что в самом широком смысле под этим термином следует понимать.

А вот пруф из дискуссии к каналу, что у любой системы есть архитектура.

Конец високосного года выдался особенно жарким. Поделюсь выводами, которые сделал за эту неделю.

Мне кажется, большая ошибка — внедрение практик, пререквизитом для которых является изменение культуры.

У нас красная страна, красная культура, и большинство наших компаний — красные. Это следствие нашей истории, наша объективная реальность. В этом наша сила и наша слабость.

Нужно внедрять практики, которые соотвествуют красной культуре. Розовые пони в нашей саванне долго не живут.

Применительно к архитектуре необходим сильный архитектурный комплаенс (Architecture Compliance). Причём вряд ли он должен строиться строго по TOGAF — комплаенс должен быть независимым от продуктовых команд.

Комплаенс должен быть максимально автоматизированным, а лучше полностью автоматическим.

Все уже привыкли к тому, что роботы "заворачивают" кредиты. Вот пусть роботы и некачественные релизы "заворачивают". На робота сложнее "надавить", чем на человека.

Продолжаю делиться наработками.

Автоматизировать архитектурный комплаенс лучше на основе цифрового двойника информационных систем.

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

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

Приведу цитату:

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

В данной концепции содержится неявный ответ на вопрос, входит ли архитектурный репозиторий в состав цифрового двойника.

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