Мне не нравится термин Multi-Runtime Microservices. Но мне нравится идея: выжать максимум из SideCar паттерна, получившего популярность вместе с решениями класса ServiceMesh. Идея, собственно, в том, чтоб реализовывать общий или повторно-используемый функционал в виде отдельных процессов внутри микросервиса. Эти процессы могут взаимодействовать между собой через сеть, реализуя, например, общие сервисы данных или еще что-либо. В общем, читайте очередное короткое интервью с Bilgin Ibryam, смотрите слайды, задавайте вопросы в группе по кнопке под этим каналом https://www.infoq.com/news/2020/03/multi-runtime-microservices/ Да, и вряд ли это следующая большая вещь, скорее всего только одна из них. Хотя для ИТ-архитектора, конечно, тема крайне занимательная

... и еще, картинка с возможным подзаголовком SOA и ESB возвращаются 🤔

Гради Буч примерил капитанскую фуражку:

All complex systems will fail, in one way or another. Between the small and the large, between the perfect and the flawed, there is some person or persons who had a vision for the shape of things to come; we call such people “architects”

https://twitter.com/Grady_Booch/status/1239742754067845121

Опрос группе архитекторов (на текущий момент 263 голоса) https://yangx.top/itarchitect/59104 показывает, что больше 40% работают из дома. Это хорошо. Если тема приживется, то может надо будет скоро и резюме обновлять :-D

Больше 400 голосов и 53% - из дома. После трех рабочих дней недели - наступил перевес дистанционщиков. Каким станет мир после этого кризиса даже сложно себе представить. Неужели кому-то еще хочется иметь свой датацентр?

Всё время забываю написать, что в bpmn.io можно делать не привычные конструкторские чертежи, а вполне человеческие скетчи https://github.com/bpmn-io/bpmn-js-sketchy Демо есть здесь: https://cdn.statically.io/gh/bpmn-io/bpmn-js-sketchy/v0.5.0/demo/index.html

18 карточек по книжке Digital Practitioner Body of Knowledge™ Standard https://publications.opengroup.org/n201 Внутри 12 компетенций, 2 странички про сам стандарт и еще 4 чего-то, что я не увидел (похоже, что коллеги спешили) Но карточки неплохие. Надо будет воспользоваться для некоммерческих целей, естественно

Не знаю, стоит ли разбираться в GitHub Classroom. Я как-то в гугловском освоился, но может кому пригодится https://github.blog/2020-03-18-set-up-your-digital-classroom-with-github-classroom/

офф-топик: Любой кризис оставляет за собой трущобы унаследованных приложений и обломки незавершенных проектов. ИТ-архитекторы называют это браунфилд. Это хотели переделать, да не успели. А это начали, но потом денег не стало, а потому бросили. В общем, всё как мы любим. Очень скоро заказчики захотят построить поверх этого новые воздушные замки силами сотрудников с удалёнки. Так что архитекторА будут востребованы. Вот только сначала HR-ы пройдутся дружными рядами туда-сюда и можно приступать.

Еще одна картинка о жизненном цикле архитектуры решений (solution architecture). От других её принципиально отличает попытка предоставить список возможных вариантов реализации (см. внизу секцию options) https://dalbanger.wordpress.com/2017/05/07/the-solution-architecture-life-cycle/

В своем учебном курсе про микросервисы https://itexpert.ru/msa/ (который переезжает в онлайн, ну разумеется) хочу перенести демо/лабы по docker и kubernetes с katakoda.com на какой-либо отечественный kubernetes-as-a-service. Если среди подписчиков кто-то такое предоставляет, напишите, плз. @mxsmirnov

Классификация микросервисов.
Совершенно разные вещи понимают под микросервисами те или иные эксперты. Для кого-то это компоненты без состояния (stateless), участвующие в обработке команд. В другом случае микросервис отвечает не только за обработку, но за хранение данных, причем не только в оперативной памяти, но и на внешних носителях. Часто микросервисом считают реплику данных, предназначенную только для чтения. Один и тот же набор данных может поступать в множество различных представлений, оптимизированных для определенного типа запросов. Все эти случаи разные. И характеристики компонент, называем ли мы их микросервисами или нет, так же различаются. Мы запутаемся если не признаем, что под общим термином мы понимает несколько непохожих вещей. Возможно, классификация микросервисов уже существует, но мне она не известна. В этом случае её придется создать

Похожая ситуация была с архитектурным стилем REST. Автор этого стиля Рой Филдинг (Roy Fielding) описал его в своей диссертации немного сложно https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Что не помешало разработчикам добавлять слово REST к любым API, реализованным поверх HTTP. И только одно нарушало их энтузиазм. Заметки Филдинга в его блоге о том, что очередной как бы REST API таковым не является

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Ситуацию разрядил Leonard Richardson, предложив модель зрелости API по степени их соответствия идеям REST http://restcookbook.com/Miscellaneous/richardsonmaturitymodel/

На мой взгляд, наиболее адекватный сегодняшним технологиям способ классификации взаимодействий между сервисами представлен на рисунке. Любое взаимодействие — это либо команда (command), запрос(query) или событие(event). Команды устремлены в будущее. Они несут намерение клиента изменить состояние ресурса на сервере. Это может произойти при успешной обработке команды, как правило осуществляемой асинхронно, либо не произойти. Запросы не собираются ничего менять. Они хотят предоставить клиенту информацию о текущем состоянии ресурса (это тоже может не всегда получиться). Команды – про настоящее. Вернее, про очень недавнее прошлое. И события – это уведомления сервера о том, что где-то за его границами что-то случилось с одним из ресурсов и сервису может быть интересно об этом узнать. События – следы прошлого. Они не могут закончится неудачей, т.к. уже произошли, хотя сервис, конечно, может их проигнорировать

The Open Group начал выкладывать этот документ в твиттер https://twitter.com/DPBoK_TM/status/1243150725263302656 по страничкам

Иногда краткий обзор книжки бывает не так уж плох. Нашел такой для знаменитой "Дилеммы инноватора" Клейтона Кристенсена. Всё перечисленное там полностью применимо к ИТ-продуктам

Немного странный опрос: https://tsh.io/state-of-microservices/ Ну, какой есть

С моей подачи https://yangx.top/itarchitect_jobs/6691 третий день в группе "Работа для ИТ-архитекторов" идет крайне интересное обсуждение темы Почему люди становятся ИТ-архитекторами, посмотрите. Язык не поворачивается назвать это офф-топиком. Вряд ли кто-то сейчас занят подбором архитекторов, ведь так? Думаю, что контекст, в котором мы все сейчас оказались, располагает к размышлениям о более фундаментальных вещах, чем обычно

... да, но на собеседованиях лучше рассказывать другие истории. Если бы меня спросили почему ты решил стать ИТ-архитектором, то я бы ответил, что всю жизнь мечтал стать менеджером. Хорошим менеджером, как в книжках Питера Друкера про эффективного управляющего. Менеджером, принимающим правильные решения, учитывающим объективные возможности, способным придумать несколько альтернативных вариантов, а ещё лучше – угадать неожиданное, но офигенно эффективное решение.

Наивность таких фантазий я осознал, став еще совсем маленьким начальником. И вот почему. Во-первых, даже у самого маленького начальника времени о чём-то подумать просто нет. Какие альтернативные варианты и неожиданные решения? Дела надо раскидывать, причем шустренько, а иначе ими тебя просто закидает. Во-вторых, если о чем-то и удается подумать, то исключительно о политике. Всё многообразие мира ограничивается для начальничка его организационно-социальным окружением; такими же как он бюрократами, с которыми и дружить надо, но палец в рот не клади. И в-третьих, работа норовит превратить всю твою потенциальную энергию в свою кинетическую. Сил разобраться с той или иной технологией, понять и посмотреть что-то новое, пусть даже очень простое, банально не остается.

Даже доработав до должности руководителя департамента, по-настоящему хорошим менеджером я так не стал. Зато понял, чего ИТ-руководителю больше всего не хватает и как ему помочь почувствовать себя эффективным управляющим из книжек Питера Друкера. Я научился готовить хорошие решения. Когда меня просят проработать для руководства компании какой-либо технический вопрос я делаю это будто бы для себя. Вернее, для того вымышленного хорошего менеджера из собственных фантазий.

В общем, вот так я и стал ИТ-архитектором. Нет, ну еще много UML-диаграмм рисовал, конечно, в нотации Archimate и TOGAF-ом перед сном зачитывался
PS: история вымышленная [почти], но вдруг кому пригодится

На злобу дня (Март 31, 2020) https://www.infoq.com/articles/teams-teamwork-trends-2020/

Ну что, айтишнички криворукие, есть ли у вас план Б? Я не знаю, живо обсуждаемое в telegram-каналах приложение https://yangx.top/itsorm/1576, действительно, от оперативного штаба Москвы или нет, но есть ряд детских глупостей, от которых отлично помогает ИТ-архитектура. Надо её просто иногда применять. Попробую перечислить пару вещей:

1) Никогда не пишите приложения. Особенно клиентские, особенно мобильные (да и фронтальные, те что на js в браузере, тоже не пишите), особенно если нет времени, тем более если вам масштабироваться до нескольких миллионов за несколько дней. Начинайте с протокола взаимодействия: Alice->Bob…, ну сами знаете

В нашем случае, вот сгенерите человеку, которому надо выйти из дома, цифру и пусть она будет валидна в течении получаса, а потом сгорает. Можно к району привязать, а можно и не париться. А программу для проверки можно сделать так, чтоб она и в офф-лайне работала, без проблем (да даже на бумажке посчитать)

2 ) Нет приложения, нет проблемы омниканальности. Сегодня локально проверяем, а вечером логи на сервер грузим для поиска злоупотреблений, завтра в браузере, послезавтра по mail-у шлём и ответ полчаса ждём, через полгода приложение напишем, ну если ещё захочется, разумеется

3) Фичи никому не нужны. Всегда надо делать только базовый функционал. Кстати, реальное назначение MVP не гипотезы тестировать, а отгонять от продукта идиотов с дополнительными требованиями (это шутка, почти). Типа:
- А почему ты не хочешь биометрию встроить?
- Я?! Не хочу? Да я всё что угодно встрою! Хоть блокчейн с машинлёрнингом, хоть ГОСТовские алгоритмы, реализованные только под виндоуз, но потом, в целевой архитектуре, так сказать. А пока у меня MVP, отвалите!

Ну, а для тех кому всё это сложно даётся простой совет: архитектора позовите, будет хоть на кого потом всё свалить