Думаю 🤔, что таких простых и доступных статей как эта https://itnext.io/5-patterns-to-make-your-microservice-fault-tolerant-f3a1c73547b3 должно быть больше (не спрашивайте меня причем здесь микросервисы и не цепляйтесь к автору статьи по мелочам). Впрочем, как и ресурсов типа https://itnext.io/ Одним словом, рекомендую

Большое, чуть занудное, но полезное сравнение CDC и Event sourcing от Debezium https://debezium.io/blog/2020/02/10/event-sourcing-vs-cdc/

Краткий обзор https://medium.com/@dr.teck/10-secrets-for-developers-to-sabotage-a-micro-services-project-e73e1c55ad0a вот этого замечательного выступления https://youtu.be/X0tjziAQfNQ Слайды, текст, манера выступления - всё просто прекрасно! Не пропустите 😜

Читаю я наши архитектурные группы и всё больше склоняюсь к гипотезе, что главной проблемой карьерного роста ИТ-архитектора в современном нам enterprise является его повышенная серьёзность. В крупных организациях, так вообще к большей части происходящего стоит относиться как к некоторой игре, допуская, что люди делают все свои глупости понарошку, ну роль, например, такая у вашего заказчика - веселый недотёпа, вот он её и играет; кто-то стикеры развешивает, кто-то слайды рисует, так это всё они не всерьез, так просто у них в сценарии прописано...

Пятничный оффтоп, хотя сегодня  и понедельник: Наверняка все уже видели действующую модель windows - Windows93 https://www.windows93.net/ Ну, вдруг кто не видел

У меня много нового и интересного про визуализацию графов (естественно, для рисования архитектурных картинок), но пока я всё это внятно опишу пройдет неизвестно сколько времени. Потому, пока поделюсь этой старой ссылкой https://mxsmirnov.com/2018/06/25/concept-map/

Собрались как-то архитекторы, взяли кота и давай беседы беседовать в подкасте linkmeup_sysadmins.

Про что говорили:
- Кто такие архитекторы, и проблемы самоопределения
- Какие задачи решают, зачем вообще нужны
- Где считают деньги, где их посчитать забывают и зачем, если есть бухгалтерия
- Стоит ли стремиться к cloud native архитектурам и прочим хайповым словам?
- Путь профессионального развития
- Артефакты работы архитектора
- Даже девушка из QA, стала архитектором, а ты нет.

https://linkmeup.ru/blog/536.html

SystemsInnovation.io (есть такая сетевая организация) объявила о доступности своей главной книжки Systems Thinking Guide (под лицензией creative commons) Скачать или полистать можно здесь: https://systemsinnovation.io/systems-thinking-guide/ если кому интересно

В принципе, этот обзор сервисных сеток https://www.infoq.com/articles/service-mesh-ultimate-guide/ можно было бы пропустить если бы не несколько обстоятельств:
1. Автор Daniel Bryant
2. Полнота обзора и большое количество интересных ссылок внутри него
3. Актуальность (на 18.02.2020)

... и так ожидаемый мной неологизм, в отношении service mesh - короткий фрагмент с заголовком Enterprise Service Bus (ESB) 2.0 в разделе анти-паттернов. Задание начальникам отделов интеграции на 2020: забрать управление сервисными сетками вашей организации в зону своей ответственности. Не успеете сейчас, потом уже не отнимите

Послушаем, что SOER думает про ИТ-архитекторов https://youtu.be/bYd9FavRQfI а завтра и немного поспорим с тем, что он прочитал в своем смартфоне

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

По данному видео, я прицеплюсь к совсем невинному тезису про то, что плохой архитектор невнимательно относится к требованиям(5:47). Это точно подмечено,  вот только ругать его за это или хвалить? Архитектор от аналитика, действительно, отличается отношением к требованиям. Если аналитик считает что требования должны быть полными и непротиворечивыми, то архитектор знает, что так не бывает! Собственно одна из потребностей в архитектуре, т.е. придумывании внутренней структуры системы, выделении в ней разных элементов, и обусловлена противоречивостью требований. Совсем философски: мы выделяем части внутри целого для того, чтоб разнести противоречивые требования во времени и пространстве. Иначе нафига огород городить? Если всё хорошо, требования непротиворечивы, то закидали всё в один процесс и вот тебе приложение-калькулятор готово. По поводу полноты: так тоже не бывает. Вспоминаем великого мифического человеко-Брукса, который во второй своей книжке говорит: Самая сложная задача проектирования состоит в определении того, что должно быть спроектировано. Выявление потребности это инкрементальный процесс. Сначала заказчик очень смутно представляет чего он хочет. Чтоб конкретизировать потребность ему надо предлагать варианты, показывать прототипы и объяснять возможности. Процесс сопоставления потребностей с возможностями однажды сойдется (но это не точно) и только после этого есть смысл начинать что-то делать. В общем, я не стану в очередной раз пересказывать twin peaks model. Главное, что вне этих допущений потребность в архитекторе (и создаваемая им ценность) невелики

€30 - колода карт с паттернами cloud native трансформации https://www.cnpatterns.org/ картинки красивые, тексты понятные :-)

А не почитать ли нам мартовские книжки (см. Release Date: March 2020) https://learning.oreilly.com/library/view/the-software-architect/9781492077534/

Обратил внимание на то, что у Грефа в презентациях стало много внятных treemap-ов. Архитекторам предприятия, на мой взгляд, пора серьезно поизучать вёрстку или навсегда остаться в роли скромных архивариусов корпоративных справочников  (Взято из этого ролика: https://youtu.be/NOKJ96VgueI)

Это очень хорошо, что издательский дом «Питер» регулярно и довольно оперативно переводит книжки о паттернах распределенных систем. Но вот статью https://habr.com/ru/company/piter/blog/490180/ для анонса очередной книжки «Паттерны Kubernetes…» они выбрали не самую удачную. По сути, текст о том, что следует избегать приложений с сохранением состояния, мол все к этому стремятся и за этим будущее. Это можно сказать и без статьи, вопрос в том, насколько ответственной будет такая рекомендация на сегодняшний день. Ладно, скажем спасибо переводчикам текста за фразу Облачно-ориентированное проектирование приложений в качестве перевода Cloud-Native Application Design и пойдем читать новые книжки:

Ссылки:
[1] Бёрнс Б. Распределенные системы. Паттерны проектирования – первая книга "серии", переведена примерно год назад
[2] Ибрам Б., Хасс Р. Паттерны Kubernetes: Шаблоны разработки собственных облачных приложений
[3] Арундел Д., Домингус Д. Kubernetes для DevOps: развертывание, запуск и масштабирование в облаке

Я наконец понял природу негативного отношения Анатолия Левенчука к описанию архитектуры в виде картинок. Цитирую: В учебнике системного мышления есть несколько диаграмм с основными понятиями. Беда в том, что системное мышление после этого начинается применяться клочками — эти диаграммы не склеиваются в мозгах в одну большую схему https://t.me/ailev_blog/333https://t.me/ailev_blog/333

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

В связи с неуёмным флудом в группе Работа для ИТ-архитекторов продублирую ссылку на сообщение здесь: https://t.me/itarchitect_jobs/6394

Неожиданно для себя обнаружил, что часть сайта K8S переведена на русский язык https://kubernetes.io/ru/

Draw.ioDraw.io медленно переезжает на diagrams.netdiagrams.net Интересно, что станет с другими сайтами в домене io https://www.diagrams.net/blog/move-diagrams-net

Результаты ежегодного опроса Cloud Native Computing Foundation за 2019 год https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/ Краткий обзор и 16-страничный отчет (довольно познавательный)