Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

What Is an Architecture Metamodel?

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

Начинается текст с объяснения термина метамодели (какие типы объектов входят в модель и как они связаны между собой). Далее автор переключается на инфраструктурные модели, так как в инфре проще определить метамодель. После говорится о логическом уровне, где application может значить что угодно. Рассказывается о фреймворках (TOGAF и c4, при этом, сложно с4 назвать фреймворком), где метамодель заранее продумана. Также описывается system-Level, тут придется учитывать SoI, подсистемы, элементы и сервисы. При этом, автор описывает возможные виды сервисов и элементов, что полезно. В конце описывается solution уровень, где придется думать о продукте, solution, application и сервисе. В самом конце описывается как связать все уровни и зачем запариваться о метамодели.

#architecture

—————————————

Building Service Topology at Scale

Еще одна статья от netflix, в которой рассказывается, как в компании строили динамическую «карту» системы. Это вторая часть, первая упоминалась в канале 19 июня. Проблема, которую решали — в компании хотели понимать связи между сервисами, чтобы считать blast radius, понять как структура системы выглядит и так далее. И если в прошлой статье объяснялось почему и зачем в компании заморочились, то во второй части описывается как именно делали «карту».

В начале описывается, почему забор информации раз в N времени не подошел, вместо чего решили выбрать streaming-based подход. Так как данные собирались из трех мест — возникла проблема с трафиком, который, в облаке, проходит не на прямую, а через компоненты (балансеры, гейтвеи, прокси). Эти компоненты не надо учитывать, поэтому пришлось фильтровать «шум» в три шага. Далее описываются дополнительные проблемы, которые вскрылись: лаг консьюмера кафки, проблемы с GC из-за роста трафика, увеличенное потребление памяти и сложность от reactive streams. Каждая из проблем подробно описывается с выбранным решением. В конце найдете общие уроки и выводы от всей затеи.

#how_it_works #observability #distributed_systems

—————————————

How Event Catalog contribute at the Event-Driven Governance

Если выбираете event-driven коммуникации — готовьтесь к тому, что придется заморочиться с наблюдаемостью системы, стандартизацией и обновлением схем. Связано это с тем, что добавить новое событие «в тихую» проще, чем в синхронных коммуникациях. Плюсом редко используют контрактное тестирование/генерацию диаграм. Автор статьи выше предлагает решение в виде Event Catalog (статья «продажная»).

Текст начинается с описания проблем от event-driven коммуникаций. После чего, автор сразу переходит к Event Catalog — централизованному хабу, для управления, discovery и поддержки событий. Для этого используется 6 видов объектов (domains, systems, services, events, flows, entities). Далее показывается пример с order service, где можно схему посмотреть, описание события и изменения событий.

В текстене хватило минусов и проблем с подхода, но если планируете заниматься ITAM-like вещами и инвентаризацией. И, при этом, не встречались с event catalog до этого — советую посмотреть текст и вдохновиться.

#event_driven