Ранее писал о нашем процессе или фреймворке, которым подходим к проектированию ИТ-продуктов и социо-технических систем (https://xn--r1a.website/rsa_enc/359), ➕ и в прошлом посте про академию (⬆️) есть материалы по всем этапам процесса.

Так вот, приступая к проектированию архитектуры, мало основываться на результатах предшествующих архитектуре — архитектуру нужно уметь их не только "читать" и понимать, но и как минимум знать методы и процессы как артефакты для проектирования и реализации собирались и создавались.
А в идеале — архитектор должен присутствовать и участвовать на данных этапах анализа и проектирования бизнес-процессов, ещё даже предшествующих проектированию ИТ составляющей будущей системы.

Как архитектор, по возможности я участвую в таких активностях, и даже иногда их веду. А для этого нужно знать методы анализа досконально.

Идущие первым этапом нашего анализа выявление бизнес-целей и создание стратегии их достижения — мы прорабатываем с помощью метода "Карта гипотез". О нём я кратко расскажу на конференции в московской торгово-промышленной палате, где я состою в экспертной группе (как я попал и чем занимаюсь в экспертной группе при ТПП — истории для отдельных постов ☺️🏮).

Технология «Карта гипотез» для создания стратегий бизнеса и личностного роста. Метод позволяет связать цели бизнеса и конкретные задачи исполнителей через гипотезы-идеи.
Аспекты:
• как преодолеть разрыв между потребностью качественной стратегии и рамками возможностей руководителей создавать гениальные стратегии
• специфика и возможности технологии «карта гипотез»
• примеры разработки стратегий на реальных кейсах

Полную программу конференции прикреплю комментарием, также она доступна по ссылке:
Лучшие бизнес-практики для адаптации и устойчивости бизнеса в текущих реалиях

Участие бесплатное по предварительной регистрации.

Конференция совсем не про ИТ, но это и неудивительно.
В целом ИТ уже настолько неразрывно проникло во все сферы нашей деятельности и стало взрослой отраслью наравне с другими — что становится совсем неудивительным, что процессы или методологии, зародившиеся в одной сфере показывают свою эффективность и в ИТ-процессах.
Так ведь работает и наоборот! 😎 Методологии, которые изначально мы создали в рамках нашей ИТ-деятельности — показывают свою эффективность и в любых других сферах

👍

Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎

Теперь и в виде статьи на Хабре! Встречайте, выведенный и сформулированный мной Принцип каскадного снижения связанности: https://habr.com/ru/articles/894766/

Если понравится статья — буду рад вашим ➕⬆️ , это позволит увеличить охват читателей статьи ☺️

Весенний сезон оффлайн и онлайн выступлений выдаётся очень насыщенным 🍃

Сегодня я выступил в Торгово-промышленной палате. А уже завтра на next conf расскажу чуть адаптированный для системных аналитиков свой доклад про тестирование архитектуры as Code:
Переведём архитектуру в as code и проверим её качество тестами!

В апреле на конференции Systems Design сделаю по этой же теме уже более подробный мастер-класс с написанием кода тестов на архитектурные принципы:
Тестирование архитектуры программного обеспечения

И в Екатеринбурге на Dump расскажу об инструментах для измерения архитектурных метрик на примере проверки своего принципа проектирования:
Принцип каскадного снижения связанности и его проверка измерением архитектурных метрик

Буду рад всех видеть и со всеми пообщаться ❤️☺️

🥳 Сегодня нам исполнилось 13 лет!

Изначально мы собрались вместе на любви к инженерному делу. Прошли годы, нас уже 60 человек в трех городах, но суть компании осталась неизменна – практика и развитие инженерного дела.

Мы хотели успеть оформить результаты сделанного нами на странице Академии и успели https://byndyusoft.com/academy. Собрали в одном месте две книги и методы, которые выводят на новый уровень создание стратегии, анализ и проектирование социотехнических систем. Впереди еще много планов, например, вторая книга про Антихрупкость в IT, которая объединит знания трех основателей компании https://xn--r1a.website/byndyufeed/451.

Мы благодарны сообществу инженеров, аналитиков, управленцев за поддержку! И, конечно, благодарны нашим заказчикам за желание создавать сильные решения, что дает нам возможность делать великолепные инженерные конструкции в IT.

Всем спасибо и нас с праздником 🥳

Всем привет! За последний месяц я слетал в отпуск (на турнир по шахматам с кубиками 🎲) и выступил на четырёх конференциях 😅☺️

Как уже неоднократно писал и говорил — на это дело меня заряжают и драйвят ваши отзывы! Отзывы читателей и слушателей 💕. Всё чаще и чаще ко мне подходят незнакомые (а отходят уже знакомыми) люди, говорят что слушали/читали мои доклады/статьи, благодарят и рассказывают что у них удалось и не удалось внедрить у себя на проектах из моих материалов. Кто-то просто подходит пожать руку и сказать спасибо — это невероятно приятно 🤝🥰

Приведу пару отзывов с одной из конференций:

Это был самый отличный доклад. Сохранила все ссылки. Динамичный, интересный, полезный. Обаятельнецшмй автор. Актуальные задачи. Короткое время разраьотки. Не перегружено, в тоже время есть ссылки на гит и статьи. Респект! Используем и Кубернетес, и схемы в виде кода. Прямо очень понравилось. Спасибо вам, вы сделали мой день :)

Чувствуется высокий уровень экспертизы докладчика. Очень понравилось

Бывает, конечно, и такое — куда без этого (иначе было бы подозрительно 😅):

Сильный выход за тему, очень нагруженно, несколько раз засыпал

Особенно хочу отметить Максима Цепкова — он выступает сам и публикует конспекты лучших докладов конференций. И уже не впервые мне приятно у Максима читать про свой доклад ☺️

На конференциях я рассказывал про наши продвижения в понимании принципа каскадного снижения связанности (КСС) (ссылка на статью) и обновлениях в репозитории AaCT.
Пока совсем кратко:
💡 выпустили первую версию анализатора архитектур, который строит отчёт и выдаёт архитектурные метрики (пока совсем базовые):
https://github.com/Byndyusoft/aact/blob/main/src/analyzer.ts
💡 пример его использования можно посмотреть в новом переработанном и более глубоком тесте на соблюдение принципа КСС: https://github.com/Byndyusoft/aact/blob/main/test/ccr.test.ts

Обязательно напишу отдельно про обновления подробнее и выложу видео с выступлений, когда они появятся. А пока можно полистать слайды — закину файл комментарием к посту (про метрики и тест — с 39го слайда).

И пару слов про дальнейшие планы:
🎤 24 мая выступлю в Челябинске на UWDC
🎤 6 июня — на МТС True Tech Day в Москве
А между этими датами буду как организатор на CodeFest, TechLeadConf и CTO Conf в Новосибирске и Москве.
Если доберётесь — буду очень рад всех увидеть 😘🥰!

Всем весны! 🍀

После одного из выступлений мне задали очень хороший вопрос — применим ли мой принцип каскадного снижения связанности только в софте (микросервисах и монолитах) или в целом и в других сферах жизни?

Скажу честно — к такому вопросу я готов не был 😅. Сходу на ум пришёл пример с организацией разделения компании на отделы. Представим, что в некоем офисе сотруднике разделены на отделы и у каждого отдела свой этаж (или комната). При этом предполагается, что коммуникаций между сотрудниками отдела будет больше, чем с коллегами из соседних отделов — что логично, проще спросить у Васи, который за соседним столом, чем идти в другой отдел по лестнице. Ничего не напоминает? 🙂 Те же связанность (coupling) и прочность (cohesion). Прочные и частые коммуникации внутри отдела, при более редких внешних.
При этом, если приходится постоянно бегать между этажами, а взаимодействий с соседом по кабинету почти нет — явно эффективность процессов страдает (связанность выше прочности), и это скорее всего сигнализирует о неправильном распределение сотрудников по отделам (и/или процессов и ответственности между отделами).

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

На мой взгляд, получился неплохой пример из жизни 😌

А сегодня хочу ещё порассуждать о химии, в которой я вообще ни разу не специалист 😅.
Как будто бы при объединении атомов в молекулы, а молекул в более сложные структуры — работает всё тот же принцип, что наверное логично 🙂
С массивными атомами всё вроде понятно — у них сильная внутренняя прочность (упрощая — большое количество протонов и электронов), поэтому они легко объединяются в сложные молекулы с множеством связей с другими атомами (связей с другими атомами всё равно меньше, чем связей частиц внутри).
Посмотрим на лёгкие атомы — водород (упрощая — 1 внутренняя связь) и бериллий (4 внутренние). Атом водорода в молекулах имеет всегда только одну внешнюю связь (в молекулы воды каждый из двух атомов водорода связан с единственной молекулой кислорода, в спирте — единожды с углеродом или кислородом). Т.е. внешних связей не больше чем внутренних.

Для атома бериллия я тоже не смог найти нарушения принципа — даже в органической молекуле оксид-гексаацетата бериллия у каждого атома тоже связей не больше четырёх (см. картинку 🙂).

В химии и физике нам намного проще — соблюдение законов контролирует сама природа (ну или движок матрицы 📺). Жаль, что в ИТ при проектировании сложных систем нам приходится делать это самостоятельно. Или не жаль 💚

Продолжим рассуждения предыдущего поста, в котором я перекладывал каскадное снижение связанности на организационную структуру компаний и даже на молекулярную химию 🤓

За полгода я уже достаточно много где рассказал про предлагаемый мой принцип — и много где после доклада мне говорили, что мои идеи являются следствием (или даже просто копией) постулатов всем известных (😉) теории систем и теории графов. Это обсуждали и в Алматы, и в Екатеринбурге, и в Новосибирске, и в Челябинске (чувак признался, что был на моём докладе в КЗ и пришёл на его продолжение в Че ☺️ ), и в Москве, и в интернете (в том числе по мотивам предыдущего поста).
Пользуясь случаем, выражаю огромную благодарность всем, кто задаёт вопросы, комментирует и подходит/пишет обсудить ❤️.

Сразу скажу честно — ранее, я весьма поверхностно был знаком именно с "теорией" теории систем. Хотя с переложением её на практику, как оказалось, сталкивался достаточно часто — и в материалах по системному подходу, и в различных статьях по Coupling & Cohesion в ИТ.

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

Но сейчас хочу порассуждать не только об этом.
Постепенно (нет 🙃) подведу к теме концептуального будущего ИТ-архитектуры.

Общая теория систем, и тесно связанный с ней системный подход, опять же на мой взгляд, идеально и исчерпывающе подходят для проектирования, описания и изучения текущих имеющихся у нас ИТ-систем (на то они и системы 😉). Но что будет дальше?

Я вот всё время пишу и говорю, что мы как архитекторы должны бороться со сложностью, т.к. она убивает проекты и т.д. Но не ограничивают ли наши методы борьбы с ней прогресс развития ИТ?
Заметьте (❗️), не сама борьба тормозит прогресс, а несоответствующие текущему этапу развития методы борьбы со сложностью.

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

Что это вообще такое ❓

Мне очень нравится краткие формулировки описания этих терминов у С.Б. Переслегина, которые и процитирую:

В чём суть средового подхода — вы имеете дело с системой, в которой обязаны учитывать бесконечное количество элементов связи...
Базовое движение в средах — это волновые процессы. Если когда вы воздействуете на систему — она реагирует на вас принципом Ле Шателье (обратной связью — прим. моё), то когда вы воздействуете на среду — она рассеивает ваше воздействие через генерацию волн.

На ум сразу приходят возможные различные варианты реакций на резкий скачок нагрузки на распределенные системы — или же последствием будет падение (полное или частичное), или же последствия в различном виде волнами разойдутся по всей системе среде.

Среда — это система с бесконечным количеством степеней свободы.

Видео Сергея Борисовича про системный, средовой и сферный подходы: https://www.youtube.com/watch?v=Rn50DfXpATs

А вот до ИТ-сферы и соответствующего сферного подхода в ИТ, на мой взгляд, нам ещё далеко )

Интересно, как скоро придётся менять название канала на "Архитектура распределённых сред"? 🙃
Хотя думаю, что прилагательные "распределённые" неприменимо к средам. Скорее назову канал примерно так: "Архитектура по средам" 😀

Наверное один из самых задаваемых мне вопросов — с чего начать при проектировании архитектуры нового проекта, какие мне вводные нужны и как, и с помощью каких инструментов, я их собираю?

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

Я уже писал о том, что при старте нового проекта или проектировании следующего большого релиза существующего, мы в обязательном порядке используем наш фреймворк проектирования социотехнических систем, четвёртым шагом которого как раз и является создание ИТ-архитектуры. Архитектура — именно 4й шаг в последовательности анализа, и она всегда основывается на результатах и артефактах трёх предыдущих шагов — карт, выявляющих бизнес-цели и пути их достижения, собирающих целостное видение и описание смыслов будущего продукта.

В рамках своего курса в ИТМО я преподаю как проектировать и спроектировать архитектуру, почему именно так и что это даёт. Но в рамках курса мы не обсуждаем шаги, которые должны предшествовать проектированию архитектуры.

И наконец-то эта брешь будет закрыта! 🥳
Мои партнёры по Бындюсофт, авторы методов нашего фреймворка проектирования, Александр Бындю и Андрей Шапиро на базе ИТМО так же запускают курс «Анализ и проектирование социотехнических систем»!

В рамках курса как раз и разбираются три первых шага нашего фреймворка — три карты:
- гипотез,
- процесс-опыта,
- реализации историй.

Старт курса — уже в июле! Кликайте на ➡️ Подробности!

Таким образом мы начинаем преподавать все наши изобретения и новшества уже на уровне официального образования и с дипломами гос.образца 😎👨‍🎓

В своей стране продвигать и развивать отрасль, в которой работаешь и чувствуешь себя экспертом — лично для меня дорогого стоит 😄

А очередной запуск моего курса по проектированию ИТ-архитектуры я планирую на осень 🍁.
Не переключайтесь 📺

В выходные выступил на Pro IT FEST в секции Стендап с полушуточным докладом "Зодиакальные знаки микросервисной архитектуры" 😅🌛

О чем?
Вы слышали про 12-факторное приложение — но готовы ли вы к зодиакальной интерпретации этого манифеста? Руслан Сафин докажет, что микросервисы тоже рождены под звёздами: каждый из 12 факторов — это отражение астрологических архетипов. А значит, вы сможете заранее предсказать сильные и слабые стороны вашего приложения, просто зная дату его “рождения”.

Что вас ждет?
— Краткий, но ёмкий обзор 12 факторов
— Астрологическая метафора для каждого из них (да, это серьёзно, но и нет)
— Немного вовлечения зала и атмосфера лёгкой пятничной лекции под напитки
— Доля иронии и фана, за которой прячется неплохой инженерный смысл

Кто такой Руслан Сафин?
Инженер с бэкграундом архитектора, мыслитель с нестандартным углом обзора, и по совместительству — человек, который рискнул соединить DevOps и астрологию.
Иногда шутит, но всегда по делу.

Если бы я просто сказал, что буду рассказывать про отчасти уже очевидные, а местами чуть спорные 12 факторов cloud-ready приложения — уверен, публики было бы меньше 😏

Полную презентацию закину комментарием, а пока, не подсматривая туда, попробуйте угадать какому знаку зодиака соответствует описание фактора "Конфигурация" (сохранение конфигурации в среде выполнения (env)):

Кто чувствительный как продакшн-сервис в пятницу? Кому важна душа и персональность, безопасность и обособленность (каждому окружению свой env)?

Переменные окружения, отделённые от кода, — это как надёжный дом для личных данных. Кому свойственно интуитивно понимать важность конфиденциальности и защищённости?

Какой же это знак? ⭐️🙂

На моё удивление — публика легко угадала все знаки зодиака всех 12ти факторов ) Можете попробовать разгадать и остальные знаки листая презентацию и не подсматривая следующие слайды: сначала идёт 2 слайда описания фактора, а на третьем — правильный ответ со знаком зодиака.

Вращайте барабан! 🥁🙂

Всегда приятно, когда твои материалы упоминают в профильных статьях и постах. Александр Межов в своём канале в ходе рассуждений над одной из тем рекомендует мой принцип каскадного снижения связанности: https://xn--r1a.website/arch_and_dev/83 😊

Позволю себе несколько комментариев к контексту рекомендации и к исходному посту в целом. Сам исходный пост является комментарием к статье "Microservices antipatterns and pitfalls" Марка Ричардса, то есть у меня будут комментарии на комментарий 😂

Речь идёт о холиварной теме границ микросервиса и его размера. В неблагодарном деле определения этих параметров Александр и упоминает мою статью:

При этом важно принимать во внимание то, насколько прочны логические связи между перечисленными функциями сервиса, насколько они логически согласованы и сочетаются друг с другом. Если изъянов нет, то процесс декомпозиции выполнен успешно и нет причин для беспокойства. (По этой теме рекомендую обратить внимание на "Принцип каскадного снижения связанности", сформулированный Русланом Сафиным.)

💡 Интересная мысль! Конкретно в разрезе определения правильности оптимальности декомпозиции микросервисов, о принципе снижения связанности я ещё не думал 🙂 Но в целом — да, в конечном счёте именно внешние проявления существования микросервиса (его использование другими и его собственные зависимости от других) определяют и характеризуют все его смыслы и качества, в том числе и эффективность его границ. Без внешних проявлений микросервис бессмыслен (микросервис не монолит — как вещь в себе, он невозможен).

В целом, у меня есть отдельная статья и доклад про гранулярность микросервисов. В них я тоже упоминаю связанность и связность, но до идей отслеживания динамической связанности я тогда ещё не дошел :)

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

И вновь отличный комментарий! Появление "микросервисных монолитов" зачастую оправдывают транзакционностью обработки данных, которую никто не хочет делать распределённой. При этом, зачастую не видят проблем в самом способе получения, хранения и обработки данных — говоря об архитектуре микросервисов, иногда забывают об архитектуре принадлежности данных, их потоков и их разделения.
На эту тему могу так же посоветовать статью: Управление мастер-данными в микросервисной архитектуре

3️⃣Степень общительности сервисов
Насколько много внешних сервисов задействованы при выполнении операций целевого? Это в какой-то степени допустимо для API-шлюзов и workflow-оркестраторов, но в иных случаях это "черная метка". Каждое обращение к внешнему сервису снижает пропускную способность и надёжность.

Вот здесь как раз принцип каскадного снижения связанности должен помочь в полной мере! :) Можно даже поэкспериментировать с различного рода архитектурами на бумаге в PlantUML и посчитать их метрики автоматом.

4️⃣Соответствие целям бизнеса
Для чего делается сервис? Какую проблему бизнеса он решает? Ответы на эти вопросы могут существенным образом повлиять на итоговое решение. 👔 Например, если в основе требований бизнеса — уменьшение TTM (Time-To-Market), то будет стремление к множеству мелких сервисов; если повышение надёжности, то будет стремление к укрупнению сервисов.

А вот с последним доводом я скорее не соглашусь. Всё же чем крупнее сервис, тем больше шансов, что он упадёт, будет тормозить или в нём будут баги. Про проектирование отказоустойчивости у меня естественно тоже есть статья 😅

Получился не совсем самостоятельный пост, а больше обсуждение или даже кусочек асинхронной беседы, вынесенный на публике. Но, имхо, как раз в беседах и рождаются новые идеи и развиваются старые! И кажется будет не лишним в лишний раз (🙂) собрать ссылочки на статьи по теме.

☀️

Несколько ночей я провёл в вайбе за совместным с ИИ программированием (в платной IDE — то есть в нормальном режиме парного программирования, а не копи‑паста в чатбот).

В целом, я уже лет 5 как не пишу код (кроме изредка опенсорса).. И вот что хочу сказать — такого азарта я не ощущал уже лет 20! Помню, как после универа садишься «на пару часов» за комп... и обнаруживаешь себя в 5 утра не отходившим от тогда ещё совсем неплоского монитора 🤓

Конечно, всё зависит от задачи. Азарт быстро садится, когда первый этап pet‑проекта пройден, и начинается рутина: загрузки, парсеры, сериализация, кэширование, инфраструктура… всё нужное, но скучное. Уже не пишешь самую мякотку — алгоритм, визуал или физику идеи. А лепишь обвязку.

Так вот! С ИИ, как я уже много раз говорил, человеку остаются только человечные задачи — задачи, требующие искры идеи, мысли, озарения! А всю остальную обвязку на себя возьмёт ИИ. Скорость разработки взлетает, азарт возвращается с новой силой, ведь теперь ты воплощаешь более смелые и сложные идеи , проверяешь гипотезы и получаешь фидбек, можешь быстро в одного реализовать гораздо более масштабный проект! Переходить к следующим белковым человеческим задачам своей мега идеи!

Наверное, без примера меня понять сложно. Я — старый шахматист и азартный игрок. Так вот, по ночам я пишу ради интереса компьютерный движок (алгоритмический, не нейросеть) для вероятностной версии шахмат.

Ещё с универа я мечтал создать разные версии шахматных движков (с разными алгоритмами мышления и конфигурациями оценки позиций) и заставить их играть между собой, тем самым выявляя сильнейшего и развивая его дальше. Но всё разбивалось об нехватку времени и лень — слишком много скучного, но нужного кода надо было бы писать.

Так вот. С помощником в виде ИИ я могу лишь генерировать идеи, направлять, думать и смотреть результаты! Больше не нужно самому писать движок доски, I/O, тесты.. и даже больше — я лишь формулирую идеи алгоритмов, прошу добавить кэш уже оценённых позиций, просчитать ходы вперёд! И даже более сложные вещи — например, я пишу: "добавь альфа-бета отсечение для ускорения оценки позиции", и ИИ меня понимает и правильно реализует этот алгоритм применительно ко всему остальному имеющемуся коду!

Азарт только нарастает, двигаться удаётся семимильными шагами, и вчера ночью я впервые проиграл своему детищу! 🤩

При этом я вовсе не хочу сказать, что ИИ заменит программистов (по крайней мере не всех😂) если бы я не умел программировать — ничего бы не получилось. Естественно ИИ ошибается. Иногда нужно смотреть его код, поправлять и направлять, подсказывать, просить отрефакторить.. Плюс даже в такой известной игре как шахматы — он далеко не эксперт.

На мой взгляд, для эффективной реализации проекта с ИИ в виде программиста нужны две вещи — глубокое понимание предметной области (идеи) проекта и хорошие навыки программирования и использования инструментов . В такой связке ИИ на порядок увеличивает производительность и возвращает детский азарт от программирования реализации своих идей и концепций.

P.S. Один умный мужик в твиттере еще до мейнстрима (года два назад) сказал, что "лучший язык программирования — английский!" (читай — человечий). Всё именно так — я общаюсь с ИИ на русском, редко что-то дописываю сам на C#. Но есть ощущение, что понимая структуры данных, мне уже сложно на русском формулировать чего хочу. В уме абстрактно я понимаю как оптимизировать сложную структуру нескольких вложенных массивов и хэшсетов и примерно написать это на LINQ.. я уверен, что ИИ меня бы понял с его уровнем владения и русским, и C#.. Но вот выразить это в виде промпта на русском иногда бывает достаточно сложно.
Думаю, в ближайшее время я точно перейду на некую смесь русского с LINQ ))

P.P.S. Все эксперименты и рассуждения проводились на основе не очень большого pet-проекта (~8K строк кода), для которого нестрашно, что код будет отправляться на забугорные сервера

ИИ не убивает программирование, он делает его великим и интересным снова, возвращает его ностальгический вайб! 😃
Делает его снова нашим!

Чем ближе сентябрь — тем больше подписчиков меня спрашивают..
И вот наконец спешу сообщить, что уже совсем скоро стартует очередной, как и каждый год обновленный, мой авторский курс по проектированию микросервисной архитектуры!

Как и последние несколько лет курс будет запущен в рамках магистратуры ИТМО, но будет открытым и выборным для магистрантов партнёрских программ, ВУЗов и компаний.

И что особенно может быть актуально читателям канала — как и в прошлом году, обучение на курсе можно будет приобрести отдельно, не поступая в магистратуры и т.д.
В прошлом году это стоило 75 тыс. руб, в этом году цена и подробности будут чуть позже, пока просто напишите мне в личку (@razonrus), что этим заинтересовались.

🔜 Старт — уже 15 сентября!

Курс состоит из лекций, воркшопов и практики. В этом году курс пополнится последними изысканиями по предлагаемому мной принципу каскадного снижения связанности (лендинг скоро актуализируем: https://microservices.itmo.ru/).

Основная программа курса:
1. Шаблоны интеграции приложений
2. Зачем бизнесу микросервисы.
Распил монолита на микросервисы
3. Управление мастер-данными в микросервисной архитектуре
4. Воркшоп по проектированию архитектуры с нуля
5. Распределенные транзакции. Оркестратор бизнес-процессов. BPMN
6. Гранулярность микросервисов
7. Рефакторинг микросервисной архитектуры
8. Отказоустойчивость / Fault tolerance
9. Архитектура as Code. Автоматизация и покрытие архитектуры тестами

Оставляйте заявку мне, и вам чуть позже напишут из ИТМО ✏️

Всех с осенью! 🍁

🌀 Языки программирования уходят в прошлое 😎

Код — это костыль. Языки придумали не потому, что они нужны машине, а потому что они нужны человеку. Человек не способен оперировать нулями и единицами, не может держать в голове гигантские структуры. Поэтому и появились Python, Java, C#, SQL... Это интерфейсы для нашего мозга, чтобы было хоть как-то удобно. 🧠

Но у этого «синтаксического сахара» есть цена — рамки и ограничения. Язык заставляет подстраиваться под синтаксис, бороться с багами и уязвимостями. Машине всё это не нужно. Ей не нужен Python. Ей не нужен C++. Ей вообще не нужен язык как таковой. 🎞

Что происходит прямо сейчас? LLM получает задачу на человеческом языке, обрабатывает её в своей внутренней математике — вектора, коэффициенты, абстрактные представления — и только ради нас переводит результат в «человеческий» код: «смотри, вот тебе Python, узнаёшь?». Но это лишь переходный этап.
Ну и это вынужденный переходный этап, т.к. пока LLM-ки обучились как раз на языках программирования — "промежуточных" инструментах, на котором человеком создан и накоплен большой опыт кодовой базы. Ключевое здесь — человеком! К примеру, когда в шахматах AlphaZero освободили от всего человеческого опыта — он(-о, -а) разгромил в пух и прах AlphaGo, обученную на миллионах человеческих шахматных партий и являющейся на тот момент сильнейшей шахматной нейросетью.

Как когда-то машинный перевод перескочил от «русский→английский» к «русский→внутренний язык модели→английский», так и программирование перейдёт от «задача→Python» к «задача→внутренний язык модели→машинный код». Без посредников. Без лишнего синтаксиса.

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

Так уже было много раз: калькулятор снял с нас ручной счёт, экскаватор заменил лопату, интернет — библиотеки. Каждый раз казалось, что «всё пропало», а на деле освобождалось место для большего.

То, что мы называем «будущим», на самом деле уже наступило.
И это будущее — гораздо более человеческое. 🤩

🎙 Готовлю свой доклад на тему «Будущее ИТ-архитектуры и работы ИТ-архитекторов»..

И вот о чём думаю.

Да, мы все видим, что ИИ уже умеет писать код. Иногда даже такой, что работает 😅 Но говорить, что это новый калькулятор, где на входе «1+1», а на выходе «2» — явно рановато. Пока что на выходе часто получается не «2», а «ну тут чуть подкрутить и вроде сойдёт» 🤖

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

Думаю, что архитектура наконец-то уже окончательно поднимется на уровень выше и уйдёт от непосредственно кода (его паттернов и принципов), что уже сейчас происходит. А если говорить про горизонт 5-10 лет — может быть, даже выше уровня систем. Кто знает, возможно, реально придётся переходить от «системного» подхода к «средовому», а там и до «сферного» рукой подать (писал об этом выше: https://xn--r1a.website/rsa_enc/376).

Так что мой доклад — это не про то, как «ИИ всех уволит» или «роботы всё сделают за нас». А скорее про то, как мы, архитекторы, в будущем будем меньше спорить о размере микросервиса и больше думать об уникальной структуре продукта, законах по которым он растёт, развивается и встраивается в различные ИТ-экосистемы.

Но чтобы попробовать смоделировать будущее — не обойтись без попытки вычленить базовые смыслы в настоящем. Применительно к нашей теме — я начну с попытки выделения истинной роли ИТ-архитектуры сейчас, которая перетечёт но несильно изменится и в дальнейшем.

Давайте порассуждаем, чуть подробнее 🧠
Если сейчас архитектура в том числе нужна для борьбы со сложностью:
- чтобы большая система была доступна для понимания и "умещалась" в голове архитектора,
- и чтобы разработчик мог разобраться в коде и внести изменения, не сломав себе мозг и всё предыдущее проекту..
то в эру написания кода ИИ всё это станет уже не столь актуальным.
К примеру, возможно станет уже необязательно соблюдать принципы и паттерны, любой запутанный код будет всё равно понятен ИИ, лёгок для тестирования и модификации им.
А ещё, такой запутанный с человеческой точки зрения код (или последовательность вызовов) может быть быстрее оптимальнее и "ближе" для ИИ; и кто сказал, что он должен быть написан на высокоуровневом языке программирования, которые создавались больше для людей, нежели чем для компьютеров (см. мой прошлый провокационный пост https://xn--r1a.website/rsa_enc/382 😂 ).

Ещё раз. Я хочу сказать о том, что функция борьбы со сложностью, как одна из основных задач ИТ-архитектуры, никуда не денется — но она скорее всего перейдёт на новый уровень, поднимется сильно выше уровня кода и простых атомарных взаимодействий между сервисами, что позволит нам делать ещё более крутое и всеобъемлющее ПО. Как выше и писал —  возможно, выйти с уровня программных систем и экосистем, на уровень сфер (перейти от системного подхода в ПО к следующему — сферному).

Одна из мыслей доклада — ИТ перестаёт развиваться отдельно, и встаёт на одни рельсы с развитием всех технологий. Для ИТ наконец-то начинают работать парадигмы и законы, по которым развивался и развивается прогресс в других более древних сферах человеческой деятельности.

В итоге архитектор станет программистом снова (точнее все программисты станут архитекторами — смотря с какой стороны смотреть), т.к. создавать ПО становится снова весело кайфово быстро и азартно ✨
А азарт — это главный предвестник будущего 💥

Ну и чтобы пост не выглядел слишком пафосным, добавлю прозаичности (но истинной):
Буду рад всех увидеть 17 октября на своём докладе на балтийских берегах в прекрасном Янтарь-холле в Светлогорске ✈️
https://baltic2025.mergeconf.ru/speakers/development/backend/safin
Промокод на скидку 20% для подписчиков канала: SAFIN 🙂


⚡ И всех причастных с праздником! ⚡

Перезалил на Rutube одно из первых своих выступлений на больших конференциях — почти ровно 4 года назад на Highload'е рассказал как проектировать и строить распределенную архитектуру без боли и оглядки на количество микросервисов.

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

Я говорил о следующем:
1️⃣ Шаблоны репозиториев
2️⃣ Визуализация архитектуры
3️⃣ Автообнаружение
4️⃣ CI/CD Pipeline
5️⃣ Окружения по требованию
6️⃣ Процесс проектирования и разработки
7️⃣ Observability

Вдвойне приятно, что спустя годы я понимаю, что не ошибся — всё о чём говорил, действительно сработало и нашло подтверждение в отрасли 🚀

https://rutube.ru/video/68da03b2f8cb3e104e9f6d219fd91fc7/

Всем привет!

Давно не писал про обновления (а они есть!) репозитория с инструментарием для работы с Архитектурой "as Code" — обещаю исправиться в ближайшее время ☺️

А пока хочу рассказать, что репозиторий прошёл отбор в финальное голосование OpenSource трибуны на HighLoad++ ❗️
Победителям голосования будет представлена возможность представить свои решения на широкую публику на крупнейшей ИТ-конференции в России 🤩

Если вам интересен мой OpenSource проект — находите его в списке:

«Инструменты для работы с AaC (архитектурой «as code»)
AACT (Architecture As Code Tools)»

и поддержите голосом, чтобы у ещё большего числа людей был шанс с ним познакомиться:
https://opensource.highload.ru/vote 😊

Для голосования нужно авторизоваться через емаил или ВК 🗳

upd: а для тех, кто ещё вдруг с проектом не знаком — скопирую сюда краткое описание:

AACT (Architecture As Code Tools) — набор инструментов и практик для работы с архитектурой,
представленной в формате «as Code». Основная фишка — это автоматическое тестирование
архитектурной схемы реальному положению вещей на проде (или любом другом окружении),
а также покрытие тестами проверки соответствия архитектуры принятым принципам и паттернам.

Основные цели проекта:
• устранить неактуальность архитектурных схем, которые быстро устаревают относительно
кода и конфигураций IaC;
• повысить декларативность архитектур — не просто зафиксировать «что», но и кодом тестов
формализовать «почему»;
• ввести контроль над соблюдением архитектурных принципов (паттернов, договорённостей)
непосредственно в процессе разработки;
• обеспечить обратную связь об архитектурных проблемах уже на этапе PR (сборки ветки в CI/CD),
чтобы архитектурные нарушения ловились до слияния веток.

Возможности проекта и примеры использования:
• микросервисные архитектуры (REST, gRPC, kafka, Rabbit, ...);
• модульные монолиты.

Ваша архитектура может быть описана при помощи:
• PlantUML,
• Structurizr.

Информация об архитектурных зависимостях может браться из:
• IaC (yaml-файлы для kubernetes),
• исходный код.

AACT делает архитектуру живой, актуальной и контролируемой, устраняя разрыв между
диаграммами и кодом.

Выступил на конференции в Светлогорске с совсем нетипичным для себя мене практическим, но более прогностическим и даже философским докладом:

Будущее ИТ-архитектуры и работы ИТ-архитекторов

Ранее при подготовке к выступление писал о том, что хочу рассказать, и вот наконец "релиз" состоялся 😎
Всё прошло отлично — переполненный зал, много вопросов и в зале, и потом в коридорах.. Народ подходил и просто пожать руку, поблагодарить за доклад 😇

Записи к сожалению не было — поэтому придётся теперь писать статью по теме выступления 😅
Выложу комментарием пока хотя бы слайды

💡 По следам моего доклада про будущее и про истинную суть ИТ-архитектуры, родилась одна весьма спорная и провокационная мысль.. попробую её сформулировать в виде поста

Если все твои компетенции в ИТ (да и на самом деле в любой другой профессии) устаревают — это не значит, что «мир слишком быстро меняется».
Это значит, что ты не докопался до сути, корневых постулатов и методологий в своей деятельности.

Значит, что скорее всего ты понимаешь профессию на уровне инструментов, а не на уровне принципов.
К примеру, ты освоил конкретный свойственный лишь настоящему времени фреймворки, а не основания, не меняющиеся десятилетиями.
Когда человек опирается только на инструменты — он неизбежно устаревает. Фреймворки меняются, языки обновляются, аббревиатуры становятся неактуальными быстрее, чем ты успеваешь обновить резюме.

Ты учишься пользоваться кистью — вместо того чтобы учиться рисовать.. Понимаешь как, но не почему..

Если твои знания обесцениваются каждый год — это не профессионализм, а временный навык специалиста.
Тогда в программировании тебя можно будет заменить новой библиотечкой, моделью, агентом или плагином — потому что, грубо говоря, ты и сам в таком случае всего лишь плагин к некой системе деятельности, которую не понимаешь.

Да, звучит жёстко. Но это не упрёк — настоящие компетенции не стареют!

Меняются оболочки, протоколы, синтаксис — но не логика.
Архитектор, который понимает принципы системного (а ещё лучше средового или даже сферного 🙂) мышления, будет актуален и через 100 лет, даже если всё программирование уйдёт в ИИ квантовое исчисление.
Педагог, который понимает, как учится мозг, будет нужен и в метавселенной.
Истинная архитектура, инженерия, логика построения систем (любых) не зависят от того, какой сегодня год — 1975 или 2025.
А человек, который просто знает, куда кликать — исчезнет с апдейтом ИИ 6.2.7 🙂

Когда говорят «всё так быстро устаревает» — спорно.
Нет, не всё.
Устаревает то, что было поверхностным.
То, что ты изучал как инструкцию, а не как структуру и принципы её работы; то, что ты сам не прожил как идею, не пропустил через себя 🧘
То, что ты выучил из туториала, а не из собственного опыта осмысления.

Любая профессия — это как шахматы ♟.
Можно учить дебюты, можно учить комбинации — но пока ты не поймёшь принцип позиций — ты не игрок, ты репликатор заученных ходов.

И вот главный парадокс:
чем быстрее вокруг меняется всё, тем больше понимаешь, что смена инструментов перестаёт пугать.

И если ты, условно, "на правильном пути" — твоё понимание меняется вместе с миром, а не пытается судорожно его догнать.
И тогда устаревают не твои компетенции — а всё вокруг, что уже не нужно. ☯️

Что думаете? 🙃

🎙 Недавно записали большое интервью — про путь в ИТ-архитекторы, про то, как меняется профессия, и почему «архитектор» сегодня — это очень разная в разных компаниях должность.

Вообще, я не очень люблю интервью:
слишком часто их превращают в чек-листы —
«как стать архитектором»,
«что должен знать архитектор»,
«10 ошибок начинающего архитектора».
Но в этот раз разговор получился про суть — про то, что вообще происходит с IT и как сфера будет развиваться дальше.

🧱 О пути
Как и у многих, мой путь начался с кода.
13 лет писал, руководил командами, решал конкретные задачи.
Постепенно стало интересно не “что написать”, а “как и почему именно так”.
И вот тут начинается архитектура — когда перестаёшь думать строчками кода и начинаешь думать компонентами.

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

💡 Про будущее кода
В интервью я повторил мысль, которая для меня сейчас ключевая:
ИИ не “заменит” программистов — он заменит процесс написания кода.

Пока мы заставляем его писать, например, на Python'е, он выглядит как человек.
Но у него нет нужды писать на Python'е или любом другом языке — это ведь наши инструменты, не его.
Он не мыслит синтаксисом, он мыслит математикой.
В какой-то момент ИИ перестанет «писать», он будет просто проектировать исполнение задачи.

И тогда архитектура снова поднимется на уровень выше — не над кодом, а над интеллектами, над экосистемами.

Но об этом тоже уже было в постах выше.

🧩 Про архитектуру как код
Я показал в интервью, как у нас построен подход:
вся архитектура описана как код — в Structurizr или PlantUML, всё хранится в git.
Архитектурные схемы проверяются автоматическими тестами на консистентность и соблюдение принципов.
Если продакшен и архитектура разошлись — тест падает.
Никаких “архитектура лежит в Confluence, но уже неактуальна”.

Это и есть архитектура XXI века — не документ, а часть проекта, часть кода. 🌌

📊 Про роль архитектора
Старый стереотип — архитектор это “человек, который всем мешает жить”.
Но на самом деле, одна из главных задач хорошего архитектора — это организация эффективной коммуникации между разработчиками, бизнесом и разработчиками, и даже бизнесом и бизнесом.
Он умеет укрощать сложность, построить простые модели сложных процессов, и объяснить это наглядными схемами так, чтобы у всех в головах сложилась единая общая картинка.

Архитектор не должен быть “самым умным”.
Он должен быть тем, кто видит всю систему целиком.
В этом смысле — это профессия про системность и понимание образов мышления, а не про технический менеджмент.

🔭 Про ИИ и мышление
Когда игровая нейросеть AlphaZero перестала учиться шахматам на человеческом опыте и начала учиться и играть сама — произошёл революционный рывок в силе игры в шахматы.

То же самое сейчас происходит в инженерии:
ИИ перестаёт “копировать людей” и начинает искать свои закономерности.
А мы — остаёмся на уровне созидания, целеполагания и смысла.
Проектировать, интерпретировать и выстраивать баланс.

И вот это, по-моему, главная мысль интервью:
ИИ меняет то, как мы думаем об инженерии,
но не меняет того, зачем она нужна.

🧭 Главный вывод
Если твоя ценность в том, что ты “знаешь фреймворки” — ИИ обгонит тебя.
Если твоя ценность в том, что ты понимаешь систему — он станет твоим инструментом.

Архитектура — это не про контроль, не про технический менеджмент, не про стандарты.
Это про развитие, стабильность и смысл.
Про умение видеть, как всё связано и насколько это применимо.

И именно это делает профессию архитектора по-настоящему вечной 😇

P.S. Фото взял с другого недавнего интервью 😅