С моей подачи 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, отвалите!

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

Тезис о том, что приложения – это проблема совсем не метафора. Кому-то это покажется странным, но дискуссия о том, что важнее: разработать софт или сочинить протокол возникала в ИТ-отрасли неоднократно. В 90-ые по организациям ходило множество уродов, которые впаривали proprietary реализацию электронной почты. Стоило больших сил убедить руководство в том, что почту надо отправлять по SMTP, а читать по POP3/IMAP4. Пользователи орали, что им нужен функционал, а не правильная архитектура. Про сайт ietf.org вообще мало кто что понимал. На тот момент электронная почта по интернет-протоколам победила (Собственно интернет и существует исключительно благодаря протоколам).

Когда сегодня тот или иной локальный облачный почтовый сервис отключает у себя IMAP, предлагая читать почту через собственное мобильное приложение или сайт, я чувствую, что мракобесие возвращается. (Эти компании - алчные идиоты, а никакие не технологические лидеры)

Такая же ситуация с разного рода госуслугами. Если вы не можете получить услугу используя curl, то с вами, скорее всего, просто играют в наперстки. Протокол начинает работать, а сервис развиваться, только когда появляются 3-4 независимые реализации. Вспомните, хотя бы войны браузеров.
В общем: #APIFirst

Никак не найду время написать что-то внятное после прочтения этой книги https://www.alpinabook.ru/catalog/book-604931/ потому главное впечатление.

Авторы поставили себе цель не просто регулярно проводить опросов вокруг DevOps (с 2014 года), но и найти статистические зависимости между довольно разными вещами в организациях (помните, наверное, критерий хи-квадрат и всё такое... )
Ряд таких зависимостей (и их отсутствий) авторам обнаружить удалось. Ну а за подробностями переадресую к первоисточнику

Расширю словами самого же Gene Kim из интервью https://www.infoq.com/articles/unicorn-project/
--
When I contributed to Accelerate and to The State of DevOps Reports with Dr. Nicole Forsgren and Jez Humble, we established that architecture is a top predictor of performance
Architecture enables teams to independently develop, test, and deploy value to customers without being coupled to 20 30 40 other teams. This finding really got me interested in exploring how important it is for developers to write code that can be decoupled from everybody else.
--
Ну, а вообще, это интервью про книжку The Unicorn Project и раскрытых в ней Five Ideals:
- Locality and Simplicity
- Focus, Flow, and Joy
- Improvement of Daily Work
- Psychological Safety
- Customer Focus

Новое слово в архитектуре пишется AIP, что означает API Improvement Proposals
AIP - это сочетание руководства по проектированию и системы, которую мы используем для управления и отслеживания этого руководства
https://aip.dev/
Изобретатель архитектурного стиля REST Рой Филдинг пишет у себя в твиттере (см. рисунок). В общем, наблюдаем

Не хотел делиться этой ссылкой в канале, но в выходные в группах по ИТ-архитектуре как-то совсем тоскливо. Редкий спам от ботов, а иногда и людей. Так что расшарю: https://mxsmirnov.com/2020/04/02/digital-shadow/

ИТ-ПЛАТФОРМА как много в этом звуке, для ... начинающего предпринимателя, чиновника от ИТ, бюрократа. Если у вас есть бюджет, но нет понимания какой нужен продукт - создавайте платформу. Если у вас есть потенциальный заказчик, но нет решения - продавайте платформу. Когда вам нравится считать себя обладателем некоторого набора технологий, ноу-хау, но не очень ясно куда и как это применить назовите их в платформой и предлагайте при всяком удобном случае.

Теперь чуть более серьезно. Последнее время термин платформа часто комбинируется с о словом микросервисная. Однако внятной концепции, ответа на вопрос зачем она нужна, практически не услышишь.
У меня есть свой вариант ответа (надеюсь неплохой). Позже, я обязательно его озвучу. Есть и еще несколько гипотез. Но уверен, что мой список неполный. Потому прошу подписчиков поделиться своим вариантом ответа на вопрос: кому и зачем нужна микросервисная платформа; какие боли нашего и кого именно она вылечит и почему? Чем такое лекарство отличается от других таблеток?

У каждого типа платформ, технологических или бизнес- , есть свой вариант ответа на вопрос ЗАЧЕМ? (Кстати, есть и своя цена, которую мы платим за выбор такого варианта ответа) Библиотеки не только упрощают разработку, но и обеспечивают концептуальную целостность. Сервера приложений отвечают за совместное использование ресурса. СУБД обеспечивают нескольким параллельным процессам работу с общим набором данных, обещая поддержание консистентности этого набора. Бизнес-платформа защищает нашу позицию внутри экосистемы. API избавляет от необходимости интеграции с каждым новым клиентом, вынуждая их интегрироваться в режиме самообслуживания. Но зачем нужна микросервисная платформа?

Прояснение замыслов (концепций) один из основных видов деятельности архитектора. Нам не избежать ответов на подобные вопросы, ведь так?

Cloud Native Computing Foundation решил рассортировать свои многочисленные видео. Здесь: https://videos.cncf.io/

Я за такой вариант ответа: безопасное(safety) расширение функционала. Главная цель микросервисной платформы дать возможность добавлять новый функционал без риска обвалить остальную систему.

Микросервисная архитектура для функционала - это как в свое время wiki для контента. Две главные концепции wiki: 1)простое и 2)безопасное(обратимое) внесение изменений в веб-страницы. Вы можете спокойно править страницу в wiki. Если что не так, модератор её откатит(или не пропустит). Но главное, что ничего не испортится. Таким образом, микросервисная платформа - ответ на вопрос : как изменить существующий функционал решения, добавив в него новый сервис , который использует произвольные технологии хранения данных, любые инструменты разработки и любую среду выполнения. Причем сделать это с минимальным риском для работающей системы и без помощи программистов, сисадминов этой системы или кого-либо ещё.

Почти всегда речь должна идти об inversion of control, т.е. не мы вызываем сервисы платформы, а они нас. Скорее всего, реализуемый микросервисом функционал - это обработчик определенного события или набора событий (даже для команд и запросов). Вполне вероятно, что микросервисная платформа выстраивается вокруг того или иного инструмента непрерывного развертывания

#оффтопик, но не совсем. Несколько дней назад Вова Ломов из теплицы социальных технологий сделал короткое видео про Google Classroom https://youtu.be/49mB73vJtf8 Я уже пару лет пользуюсь этой штукой и всё жду, когда же она испортится. Когда же в неё напихают кучу ненужного функционала. Так, чтоб использовать инструмент стало бы решительно невозможно. Но классрум остаётся простым и рабочим. Может гугл знает какой-то секрет сохранения свежести программных продуктов, а?

О! Спасибо, Алексей Лосев, за картинку на русском: https://logrocon.ru/wichthe_architector

Новости такие. Mos.ru ожидаемо лежит и не встаёт.

Проанонсирую вебинар: https://www.itexpert.ru/rus/webinars/AWS-WEB/

Архитектор решений (solution architect), пожалуй, самый атипичный представитель семейства ИТ-архитекторов. Вальяжный архитектор предприятия (enterprise architect) стремится выстроить правильный ИТ-ландшафт. Технологически подкованный архитектор ПО (software architect) настаивает на грамотном использовании технологий. Они всегда голосуют за правильное. Solution architect из другой когорты. Он взламывает (to hack) унаследованную корпоративную систему для получения нового качества, не реализуемого в текущих процессах взаимодействия и технологиях. Он нарушает социальные и технологические правила, чтоб продукт или сервис состоялся. Архитектор решений – это больше про авантюризм и про совсем другую степень ответственности. Вся компания будет ждать, когда же он, нарушитель сложившихся устоев и негласных правил, ошибется. Будут ждать, чтоб потом злорадно отметить: ага, мы же говорили, что так нельзя!

Длинный текст с плохими картинками, но разумными мыслями https://medium.com/@kylegenebrown/whats-the-right-size-for-a-microservice-bf1740370d47

Draw.io Вернее, теперь и в будущем Diagrams.net создает картинки из псевдокода (причем здесь русалки?) https://www.diagrams.net/blog/mermaid-diagrams Лучше бы он создавали диаграммы, а не изображения. Но это посложнее будет

Ещё несколько отличий солюшена от других архитекторов:
- наличие нескольких вариантов реализации, а не одного, безоговорочно «правильного»
- выбор варианта реализации в большей степени на заказчике, а не на ИТ. Ну или коллегиальное решение всех заинтересованных лиц
- решение выбрано в тот момент, когда все заинтересованные лица договорились.Пока не договорились – рано что-либо делать
- фокус на интеграции приложений, а не на обсуждении того, что там внутри. Главное, чтоб внутри приложения сидел человек, который пообещает сделать всё, что от него требуется
- причем интеграция— это не взаимодействие точка-точка, а длинное путешествие сквозь множество систем
- требования – субстанция относительная, сегодня их больше, завтра меньше. Решение – это русло реки в котором течет функционал. Лишь бы река полностью не пересохла, но и не вышла бы из берегов

... можно продолжать еще долго