... Какая-то крупная компания создаёт интересный продукт, делает часть его функций открытой, но самую важную часть оставляет платной. Сообщество пользуется-пользуется, а потом кто-то махнёт рукой и сделает форк, реализовав в нём те самые платные фичи и открыв их для всех. Вот KeyDB — тот самый случай» https://habr.com/ru/company/flant/blog/478404/

А вообще, нормальный как-бы Redis - крайне актуальная тема

В тему инструментов отрисовки графов

Поделюсь еще одной странной картинкой о том, какими бывают ИТ-архитекторы 😜 (UPD: Картинка не моя, но названия строчек и столбцов заслуживают внимания)

Очередная громкая статья Monoliths are the future, активно обсуждаемая околомикросервисным сообществом, оказалась просто громким заголовком https://changelog.com/posts/monoliths-are-the-future. Микросервисам, как станет понятно из фрагмента и комментариев после него, ничего не грозит.

Вернее, речь идет даже не о статьей, а о выдержке из расшифровки подкаста Go Time https://changelog.com/gotime/114 Кстати, неплохой выпуск. Послушайте/почитайте

Думаю 🤔, что таких простых и доступных статей как эта 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 а завтра и немного поспорим с тем, что он прочитал в своем смартфоне

€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/333

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

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

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