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

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

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

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

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

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

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

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

На конференциях я рассказывал про наши продвижения в понимании принципа каскадного снижения связанности (КСС) (ссылка на статью) и обновлениях в репозитории 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. Фото взял с другого недавнего интервью 😅

1/2

🧩 Микросервисы в оргструктуре компании: работает ли эта аналогия?

Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:

а можно ли применить принципы микросервисной архитектуры ПО при проектировании оргструктуры компании?

Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.

⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️

🎯 Контекст: компания растёт, продуктов много, отделов ~20

У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.

Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.

Но вопрос непростой:
как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?
И не умереть под завалами задач.

🧠 Кажется логичным: а давайте строить оргструктуру «как микросервисы»?

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

Идея выглядит привлекательно. Но…

⚠️ Проблема №1: микросервис можно масштабировать, человека — нет

Моя первая реакция была простая:

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

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

В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.
В компаниях и операционных процессах так не работает.

Лирическое отступление: если что, я не являюсь последователем "1 микросервис — 1 разработчик (или даже 1 микросервис — 1 команда)", а даже являюсь противником такого подхода, вносящего дополнительные ненужные ограничения прежде всего на ту же гранулярность. К примеру, у меня был проект с 5 разработчиками на 60 микросервисов — и это нормально 🙂

⚠️ Из первой проблемы логическим следствием вытекает вторая:
оргструктура и ИТ-архитектура должны быть независимы

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

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

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

⚡ И вот на таком высоком уровне аналогия, кажется, всё же работает!

И тут мы нашли точку пересечения: уровень теории систем, ну или графов, или связанности-связности (прочности).

Я недавно писал об этом при рассмотрении перекладывания моего принципа каскадного снижения связанности на реальную жизнь:

если в компании люди сидят по отделам, и внутри отдела они общаются чаще, чем с соседним — это ровно те же coupling / cohesion.

- внутри отдела — высокая прочность
- между отделами — минимальная связанность
- если постоянно «бегают между этажами» — структура неправильная

То есть принципы модульности, низкой связанности и высокой прочности действительно применимы к оргструктуре, но не 1-в-1 как в коде и архитектуре.

🤖 Дальше интереснее...

⬇️продолжение⬇️

2/2

⬆️начало ⬆️

🤖 Дальше интереснее: «оркестратор задач»

Сергей поднял более глубокий уровень:

«На входе у компании — тысячи задач.
Каждая требует разные комбинации отделов.
Как распределять приоритеты?
Как система должна выбирать оптимальный набор задач для максимального эффекта?
И кто должен быть этим „центром принятия решений“?»

То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.

И здесь аналогия с ИТ-архитектурой уже ближе:

- есть оркестратор
- есть «рои исполнителей» (отделы)
- задачи приходят из разных источников

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

Это уже сложная модель.

Тут нужна либо ИИ-система по центру,
либо очень сложный алгоритм.
Архитектура вокруг исполнителей — это уже вторично.

И вот тут ровно то место, где микросервисная аналогия снова ломается:
- как правило, в ИТ-системах все процессы обязаны выполниться;
- а в компании — наоборот: главное выбрать, что НЕ делать.

🧩 Выводы разговора

1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.
Люди не функции, отдел не является сервисом по определению.
2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.
3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:
- знает общие приоритеты,
- видит загрузку всех отделов,
- оптимизирует систему как целое.
4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.
5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.
И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг 😢

🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений.
И пока кажется, идея аналогий действительно не так уж безумна.
Но начинать нужно не с микросервисов, как более такического приема на уровне solution-архитектуры, а чего-то более глобального 😉 Ведь по сути — везде нужно решить одну и ту же задачу — побороть и подчинить себе сложность 👻

Наконец-то появилась запись моего доклада про будущее 🔮✨
а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:

https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc

Ранее писал пару постов, и про идеи при подготовке доклада и про мысли по его следам

Всех с наступающим.. будущим! Которое уже здесь ❄️🚀

Сегодня (30 декабря) наконец закончился марафон экзаменационных защит у магистрантов по моему курсу микросервисной архитектуры —
6️⃣9️⃣ защитившихся на данный момент (часть уйдет на пересдачи уже в следующем году), и это абсолютный рекорд!
Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!

Что хочу сказать..

Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов 🌌

И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло 😅, в голове каким-то образом сложились пазлики.. Пока сложно сформулировать, но как будто бы есть не такое большое количество типовых приёмов, из комбинации которых складываются почти все архитектуры.
Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).
Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения! 🧠

Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста 🙏 , давно не занимался вопросом и наверняка появилось много нового).
Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи.
Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализировать большое количество накопившихся архитектур.. а чтобы это количество пополнить и расширить выборку — обращусь к вам:

⚠️ пришлите, пожалуйста, мне свои микросервисные архитектуры в любом виде (если это нарушает NDA — можно каким-то образом анонимизировать и обфусцировать (например, убрав часть надписей)). Закидывать можно мне в личку (@razonrus)

По результатам, я надеюсь собрать и оформить архитектурные кубики (ну или сказать, что уже всё изобретено под 🌛).

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

🧘‍♂️

📊 Статистические итоги года канала

Год получился спокойным, без гонки за частотой и хайпом — но, как мне кажется, достаточно насыщенным по смыслу.

📈 Подписчики
На 1 января 2025 у канала был 1021 подписчик. Сейчас — 1469! СПАСИБО!
Прирост +448 человек, примерно +44% за год.

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

✏️ Контент
За год вышел 31 пост — в среднем 2–3 поста в месяц.
Самый продуктивный месяц — март (6 постов).
Самый непродуктивный — ноябрь (0 постов) — холодная осень в жизни и в канале — бывает 🙂

📊 Средние показатели одного поста
— 1676 просмотров
— 26 реакций
— 5,5 комментариев

Говорят, для канала без развлекательного формата и без «кричащих» заголовков — метрики более чем живые. Особенно радуют комментарии: именно в обсуждениях обычно и рождаются новые идеи.
________________________________

🏆 Топ-посты года
________________________________

👁 Самый просматриваемый пост

Если отбросить выбросы в показателях, вызванные репостами пары постов, то наибольшее число просмотров будет у поста про.. внезапно химию! ⚗️

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

👉 https://xn--r1a.website/rsa_enc/375
________________________________

👍 Топ-3 по реакциям

1️⃣. Языки программирования уходят в прошлое

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

👉 https://xn--r1a.website/rsa_enc/382

2️⃣. Парное программирование с ИИ и возвращение детского азарта

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

👉 https://xn--r1a.website/rsa_enc/380

3️⃣. Метрика стабильности систем из холодильника

Пятничный пост с бытовой аналогией: энергетик «на случай падения прода», у которого вышел срок годности, как индикатор реальной стабильности системы.
Иногда простые примеры объясняют сложные вещи лучше любых диаграмм.

👉 https://xn--r1a.website/rsa_enc/363
________________________________

💬 Топ-3 по комментариям

1️⃣. Микросервисы в оргструктуре компании: где аналогия работает, а где ломается

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

Текст не вместился в ограничения телеграма и разделился аж на 2 поста, даю ссылку на первую часть:
👉 https://xn--r1a.website/rsa_enc/390

2️⃣. Обсуждение принципа каскадного снижения связанности в профессиональной среде

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

👉 https://xn--r1a.website/rsa_enc/379

3️⃣. Если твои компетенции устаревают — ты не дошёл до сути

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

👉 https://xn--r1a.website/rsa_enc/387
________________________________

😵 Я по-прежнему не гонюсь за регулярностью ради регулярности и не планирую превращать канал в новостную ленту. Хочется писать тогда, когда появляется мысль, которую действительно стоит сформулировать и проверить об аудиторию.

Спасибо всем, кто читает, спорит, не соглашается и дополняет.
Копаем дальше👩‍🎓

P.S. На картинке можно найти отсылки практически ко всем упомянутым постам 🐰🥚

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

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

Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
🎞 https://xn--r1a.website/rsa_enc/102

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

Например,
💬 Н. И. Касперская, президент группы компаний InfoWatch (бывший генеральный директор «Лаборатории Касперского»), на дискуссии «Архитектура цифровизации государственного управления»:

Коллеги, давайте будем честны, мы идем к глобальной войне. У нас через некоторое время отключения интернета будут нормой.

Отказ от бумаги к 2030 году — это диверсия по государственному управлению. На мой взгляд, это просто государственная измена.

https://xn--r1a.website/khazinml/12010

💬 В. В. Шпак, заместитель министра промышленности и торговли РФ:

Эпоха, когда мы делили технологии на гражданские и военные — она закончилась.

https://xn--r1a.website/nasledediye21/257

💡 Посмотрите видео по ссылкам — интересно, 14 минут в сумме.

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

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

При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.

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

Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://xn--r1a.website/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.