Для вакансий ИТ-архитекторов стало характерно отсутствие больших идей. Даже хайпы стали упоминаться реже. Сохранились одни трансформации. Трансформации из априори плохого настоящего в сторону всё равно какого будущего. Почему так? Может с ИТ-директорами что-то случилось?

Не знаю, доберется ли до корпоративного мейнстрима идея поставки программного обеспечения в виде sidecars контейнеров, но контуры этой темы проступают всё более и более чётко: минимальные накладные расходы на межпроцессное взаимодействие в сочетании с независимостью от используемых технологий https://thenewstack.io/operators-and-sidecars-are-the-new-model-for-software-delivery/

Хотя может, я просто всегда любил sidecar-ы. В конце 1999 года даже короткую заметку в Компьютерре напечатал https://old.computerra.ru/196057/

Недавно случился подкаст, на который Gene Kim пригласил Michael Nygard, известного, в частности, знаменитой книжкой Release It! К аудиозаписи этого полуторачасового разговора добавили расшифровку(транскрипт).

В общем, слушайте и читайте здесь: https://itrevolution.com/idealcast-episode-8/
PS: картинка, как это часто уже случается в моём канале, неправильная :-)

20 августа, 20:00 MSK
Веб-ресурсы – новая интеграционная среда?

Нет никакого изъяна в очередях и брокерах сообщений. Нам по-прежнему нужны машины состояний и обработчики бизнес-правил. Почему же корпоративные сервисные шины ESB, ставшие столь популярными в нулевых годах, к концу второго десятилетия XXI века считаются явным анахронизмом. Что в них не так?
А может быть проблема не в сервисной шине, а некоторых других понятиях...

Приглашаю обсудить эту тему, в ближайший четверг, в zoom: https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09 Идентификатор конференции: 890 1916 0706 Код доступа: 513901

Можем ли мы простыми словами рассказать неайтишнику о том, что у нас происходит? Объяснить некоторые базовые концепции, приложив их к текущему состоянию дел. Раньше, очевидно, могли. И получаса хватит, чтоб растолковать практически кому-угодно что такое реляционные базы данных и даже порисовать с ним таблички, рассказать об устройстве хранилища данных или, например, корпоративной сервисной шины.

Сегодня, боюсь, что нет. Мы, конечно, можем попробовать, но вряд ли уложимся в полчаса и то, выйдет у нас слишком поверхностно (Расскажите про CQRS за пять минут). Впрочем, слушать нас скорее всего никто не станет. Обстоятельные истории об устройстве технологий уступили место бестолковым журнальным заголовкам. А в реальной работе понимание достигается за счет плотных регулярных коммуникаций. Показать мы можем намного больше чем объяснить. Потому и без agile никуда.

В общем, снова архитекторы виноваты, как ни крути! Ну, а кто еще должен простыми словами объяснять людям сложные вещи?

Доктор Курпатов рассказывает понятным для людей языком что такое архитектура предприятия и основные концепции ISO 42010 https://youtu.be/qOD3ceZxdYM?t=2278 :-D

Чем радует меня закат микросервисного хайпа, особенно в корпоративном контексте, так это предложением вернуться назад, типа к монолиту. Прям рисуется картина маслом, как мы берем ERP, CRM, системы дистанционного обслуживания и всё прочее и собираем в один большой процесс и развертываем его в сотнях экземпляров на всех серверах компании.

Не было у вас никакого монолита. Вернее, их было много с разными технологическими стеками, разными структурами данных и непосредственно данными, разными фрагментами функционала, перевязанного в сквозные бизнес-процессы интеграционными средами. В общем кусочно-лоскутная автоматизация во всей красе. Мы к ней возвращаться будем?
- Нет, не будем – отвечают ревизионисты микросервсиной архитектуры – мы новые системы станем писать не в виде набора сервисов, а как единый процесс.

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

Микросервис от приложения отличают два важных преимущества: у него есть API и у него нет GUI. Помните как раньше пользователи ходили и орали:
- Сделайте нам единое окно! Мы не хотим работать в десятках систем!... А еще мы хотим быстрый поиск по данным из всех систем и чтоб ничего никогда не тормозило!

Хайп твоего счастья заканчивается, дорогой пользователь!
Вспоминай старые навыки: запускаем в начале рабочего дня все нужные приложения и копи-пастим данные между ними через клипборд и ждем ...

Начав читать транскрипт этого выступления https://www.infoq.com/presentations/microservices-monolith-antipatterns/ я решил, что оно относится к разделу "сатира и юмор". Однако ни после истории с потребностью в webhooks, ни после злоключений с shared libraries в транскрипте не было отметок о смехе в зале. Пришлось включить запись. С изумлением я обнаружил, что по ходу выступления вообще никто не смеется... Может это считается неполиткорректным, не знаю. Почему-то мне кажется, что девушка собиралась сделать веселую презентацию, но вошла в другой образ и веселыми получились лишь смайлики на последнем слайде

Раз уж я переименовал этот канал в "Архитектура ИТ-решений", то позволю себе иногда публиковать некоторые определения. Сегодня термин solution (решение) из руководства бизнес-аналитиков BABOK Guide v3
Solution:

A specific way of satisfying one or more needs in a context.

A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity

Давайте продолжим с определениями:
Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT supports that operation.

Note: A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks
[ TOGAF 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_69 ]

А вот вам состав описания архитектуры решения из прошлогодней книжки
Alan McSweeney, Introduction to Solution Architecture

Собрал в один плейлист вебинары, проведенные на канале IT Expert https://www.youtube.com/playlist?list=PLDwZgqHLFBe5B4Dt3dFszxo-p3xMalN8e

#youtube

Я всё ждал, а не перерисует ли кто-нибудь знаменитую картинку Джона Захмана 1987 года в приемлемом разрешении

Вдогонку. Фрагмент видео https://youtu.be/oUhOPcHginY
#youtube

The OpenAPI Specification (OAS) - стандарт описания REST API в виде YAML-файла.

Но YAML можно использовать и для описания микросервисов в Microservice Design Canvas. Прототип такого решения см. https://solusoftsl.github.io/microservices-design-canvas-editor/

Нашел свой довольно старый текст https://mxsmirnov.com/2014/03/20/why-ea/ и подумал, что вместо него следовало бы создать для архитекторов предприятия страничку ответов на часто задаваемые руководителями и заказчиками вопросы. Может кто видел такую штуку именно для EA?

Очень простое объяснение одного из паттернов микросервисной архитектуры https://medium.com/@volodymyrfrolov/pluggable-microservices-734457c3a3b3 Я уже говорил, что микросервисы бывают разными и изложенная в статье архитектура - лишь одна из нескольких. Но, задумываясь о микросервисах, я бы в первую очередь думал о "распределенных плагинах"

Вау! Оказывается Cloud native computing foundation с июня 2020 делает тематические технологические радары, наподобие ThoughtWorks. Сегодня появился уже второй https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/

Подробнее: https://radar.cncf.io/