Запись вебинара #PlatformEngineering

Обещал выложить слайды

Ну, и еще немного про платформы. Почитать на выходных документ от CNCF: https://tag-app-delivery.cncf.io/whitepapers/platforms/

Давайте поделюсь еще одним отчетом по #PlatformEngineering
State of DevOps Report: Platform Engineering Edition https://www.puppet.com/resources/state-of-platform-engineering

Каждая версия технологического радара приносит какие-то новые термины или переосмысляет прежние. Вышедшая на днях 28-ая версия не исключение. И в длинных списках платформ, инструментов и языков программирования может легко затеряться раздел про системы управления знаниями. Так что обратите внимание на то, что Thoughtworks включил в кольцо assess раздела инструментов Obsidian и Logseq

На AWS re:Invent 2022 знаменитый Gregor Hohpe в своем выступлении Are you integrating or building
distributed applications? порадовал нас вот таким вот слайдом про RPC

[1] Ссылка на выступление https://youtu.be/Zrj7RD7G24Q?t=3141
[2] Слайды в PDF

Можно было бы сделать отдельный курс по Solution Architecture по материалам от Alan McSweeney. Но пока этого не случилось, в дополнение к слайду о составе ИТ-решения, я поделюсь его слайдом об отображении компонент решения и зависимостей между ними

Авторы курсов по Solution Architecture (не только я :) любят делиться своими материалами. Вот, например, из Web Age Solution Architect

Мало кто сомневался, что рано или поздно холст(canvas) описания архитектуры появится. Вероятно, не первый и не последний вариант Software Architecture Canvas представил пару недель назад Patrick Roos. Описание шаблона и параллели с arc42 и c4model см. по ссылке выше и в других текстах этого автора на workingsoftware.dev

У Olaf Zimmermann (ZIO) в блоге вчера появился гостевой пост How to Build and Run a Decision-Making Architecture Board По удивительному стечению обстоятельств именно о работе с решениями в формате ADR и вынесение их на архитектурный комитет мы обсуждаем на курсе Практики архитектуры предприятия очередной поток которого закончился тоже вчера

Наверняка вы однажды задумывались - откуда взялось разделение моделей на концептуальные, логические и физические. Не знаю, кто первым придумал такое разделение, но у Zachman оно уже есть. Появилось оно еще в первых вариантами матрицы, а некоторое самодостаточное описание можно почитать здесь Conceptual, Logical, Physical: It is Simple

Многие книги, а тем более статьи, появляющиеся в наше время, пытаются свести ИТ-архитектуру к набору практичных рекомендаций. В меру простых, чтоб их несложно было растолковать широкому кругу читателей, как правило не архитекторов. В меру полезных, ну или выглядящих такими. Ну, и конечно, охватывающим достаточно широкую область общих и актуальных для самых разных организаций проблем. Таковы, например, книжки Марка Ричардса. Хотя каждая последующая из этой условной трилогии глубже и интересней чем предыдущая, все их объединяет простая идея от SEI: давайте возьмем нефункциональные требования и выберем из «списка архитектур» ту, что подходит нашему сочетанию требований наилучшим образом.

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

Проанонсирую его в ближайшее время!

Выложил запись https://youtu.be/fC-0SHqfFq4

Несколько нетрадиционный взгляд на микросервисную архитектуру озвучил сегодня Марк Ричардс в своем архитектурном понедельнике https://youtu.be/UZQMUiVqpFs В давней статье Льюиса и Фвулера говорилось о владения микросервисом всеми своими процессами. Марк делает акцент на изолированности данных микросервиса. Речь идет даже о владении таблицами данных в некоторой (дисковой, как я понимаю) БД. И во второй части ролика это позволяет ему предостеречь от использования микросервисной архитектуры в ситуациях, когда мы не можем выделить в наших данных ограниченные контексты. Другой причиной отказаться от микросервисов он называет сильную семантическую связанность функций (Что это?). В сочетании с картинкой зацикленных вызовов и упоминанием о большом комке грязи это уже напоминает хэллоуиновкую открытку

Транскрипт разговора с Ребекой Парсон на InfoQ https://www.infoq.com/podcasts/evolutionary-architecture-evolution/

Нет, ну я так не играю...

В Scaled Agile Framework оказывается есть своя табличка со сравнением архитектурных ролей. Где они были лет десять назад?

Хочу поделиться ссылкой на очень короткую(9 страниц) и очень простую статью о методе Enterprise Architecture Planning (он же – wedding cake) https://gc.scalahed.com/recursos/files/r161r/w24851w/updating.pdf Мне кажется, что этот текст отличная иллюстрация того, что архитектура предприятия была когда-то вещью практичной и не сильно запутанной. По сути, весь текст - пояснение этой одной картинки

От создателя Ruby on Rails, Basecamp и автора Rework [правильный]текст c кликбейтным заголовком How to recover from microservices https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc

1. Прекратите копать (проснувшись в яме)
2. Соберите свои flow
3. Сохраните обособленными сегменты систем, критичные к производительности
4. Откажитесь от наиболее эзотерических реализаций
5. Научитесь декомпозировать большие системы на модули, а не разделять их сетями

Читайте книжки Эрика Эванса, Кента Бека и Мартина Фаулера

The mass adoption of microservices...
... массовое цитирование 8 заблуждений относительно распределенных вычислений потребовало их визуализации. И вот, пожалуйста, вам картинка https://architecturenotes.co/fallacies-of-distributed-systems/ Сопровождающий эти иллюстрации текст не столь хорош, но хоть более развернутый нежели в Википедии