Вообще, я не очень люблю интервью:
слишком часто их превращают в чек-листы —
«как стать архитектором»,
«что должен знать архитектор»,
«10 ошибок начинающего архитектора».
Но в этот раз разговор получился про суть — про то, что вообще происходит с IT и как сфера будет развиваться дальше.
Как и у многих, мой путь начался с кода.
13 лет писал, руководил командами, решал конкретные задачи.
Постепенно стало интересно не “что написать”, а “как и почему именно так”.
И вот тут начинается архитектура — когда перестаёшь думать строчками кода и начинаешь думать компонентами.
Но, если честно, как я ранее уже писал — сегодня и это разделение уже стирается.
ИИ скоро будет писать код лучше, чем большинство людей.
И если раньше архитектор мог сказать: «Это будет слишком долго и дорого реализовать», то теперь ИИ спокойно скажет: «вот моя стоимость месячного тарифа, хватит пары недель работы в паре».
И твоя роль смещается с реализации ещё больше в сторону понимания, что именно лучше подойдёт бизнесу и как это встроить в текущий ландшафт.
В интервью я повторил мысль, которая для меня сейчас ключевая:
ИИ не “заменит” программистов — он заменит процесс написания кода.
Пока мы заставляем его писать, например, на Python'е, он выглядит как человек.
Но у него нет нужды писать на Python'е или любом другом языке — это ведь наши инструменты, не его.
Он не мыслит синтаксисом, он мыслит математикой.
В какой-то момент ИИ перестанет «писать», он будет просто проектировать исполнение задачи.
И тогда архитектура снова поднимется на уровень выше — не над кодом, а над интеллектами, над экосистемами.
Но об этом тоже уже было в постах выше.
🧩 Про архитектуру как код
Я показал в интервью, как у нас построен подход:
вся архитектура описана как код — в Structurizr или PlantUML, всё хранится в git.
Архитектурные схемы проверяются автоматическими тестами на консистентность и соблюдение принципов.
Если продакшен и архитектура разошлись — тест падает.
Никаких “архитектура лежит в Confluence, но уже неактуальна”.
Это и есть архитектура XXI века — не документ, а часть проекта, часть кода.
Старый стереотип — архитектор это “человек, который всем мешает жить”.
Но на самом деле, одна из главных задач хорошего архитектора — это организация эффективной коммуникации между разработчиками, бизнесом и разработчиками, и даже бизнесом и бизнесом.
Он умеет укрощать сложность, построить простые модели сложных процессов, и объяснить это наглядными схемами так, чтобы у всех в головах сложилась единая общая картинка.
Архитектор не должен быть “самым умным”.
Он должен быть тем, кто видит всю систему целиком.
В этом смысле — это профессия про системность и понимание образов мышления, а не про технический менеджмент.
Когда игровая нейросеть AlphaZero перестала учиться шахматам на человеческом опыте и начала учиться и играть сама — произошёл революционный рывок в силе игры в шахматы.
То же самое сейчас происходит в инженерии:
ИИ перестаёт “копировать людей” и начинает искать свои закономерности.
А мы — остаёмся на уровне созидания, целеполагания и смысла.
Проектировать, интерпретировать и выстраивать баланс.
И вот это, по-моему, главная мысль интервью:
ИИ меняет то, как мы думаем об инженерии,
но не меняет того, зачем она нужна.
Если твоя ценность в том, что ты “знаешь фреймворки” — ИИ обгонит тебя.
Если твоя ценность в том, что ты понимаешь систему — он станет твоим инструментом.
Архитектура — это не про контроль, не про технический менеджмент, не про стандарты.
Это про развитие, стабильность и смысл.
Про умение видеть, как всё связано и насколько это применимо.
И именно это делает профессию архитектора по-настоящему вечной
P.S. Фото взял с другого недавнего интервью
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17💅4👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
1/2
🧩 Микросервисы в оргструктуре компании: работает ли эта аналогия?
Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:
Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.
⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️
🎯 Контекст: компания растёт, продуктов много, отделов ~20
У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.
Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.
Но вопрос непростой:
как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?
И не умереть под завалами задач.
🧠 Кажется логичным: а давайте строить оргструктуру «как микросервисы»?
Сергей сформулировал метафору:
- каждый отдел — это по сути «микросервис»
- на входе — задачи из разных частей компании
- каждый «сервис» делает своё маленькое, но важное дело
- хочется, чтобы система была масштабируемая, гибкая, без «архитектурного долга»
(когда отделы созданы из локальной логики, а потом не складываются в общую систему)
Идея выглядит привлекательно. Но…
⚠️ Проблема №1: микросервис можно масштабировать, человека — нет
Моя первая реакция была простая:
Под обратным применением я подразумевал вывернутый наизнанку процесс — обычно ведь мы в ИТ-системах пытаемся построить упрощенную модель мира, и под неё подстраиваем ИТ-процессы и ограничения. Но вот наоборот — не факт, что сработает.
В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.
В компаниях и операционных процессах так не работает.
Лирическое отступление: если что, я не являюсь последователем "1 микросервис — 1 разработчик (или даже 1 микросервис — 1 команда)", а даже являюсь противником такого подхода, вносящего дополнительные ненужные ограничения прежде всего на ту же гранулярность. К примеру, у меня был проект с 5 разработчиками на 60 микросервисов — и это нормально🙂
⚠️ Из первой проблемы логическим следствием вытекает вторая:
оргструктура и ИТ-архитектура должны быть независимы
Когда анализируешь энтерпрайз-архитектуру крупного предприятия — это важное правило почти всегда нарушается. Рано или поздно, в большем или меньшем объёме, но устройство человеческих отделов компании, их операционных процессов протекает и в архитектурные схемы, разделение ответственностей между системами и необоснованные барьеры и границы
Странно будет предполагать, что допустив обратное влияние: ИТ-архитектуры на оргструктуру компании, мы получим хороший результат — слишком разные процессы и правила игры в этих двух мирах.
Но речь всё же чуть о другом — в компании нет идеальной автоматизорованной айтишечки, которую надо "переложить" на людей. Скорее в целом стандартные методы управления перестают работать, и идёт логичный поиск новых парадигм во всех возможных смежных сферах.
⚡ И вот на таком высоком уровне аналогия, кажется, всё же работает!
И тут мы нашли точку пересечения: уровень теории систем, ну или графов, или связанности-связности (прочности).
Я недавно писал об этом при рассмотрении перекладывания моего принципа каскадного снижения связанности на реальную жизнь:
- внутри отдела — высокая прочность
- между отделами — минимальная связанность
- если постоянно «бегают между этажами» — структура неправильная
То есть принципы модульности, низкой связанности и высокой прочности действительно применимы к оргструктуре, но не 1-в-1 как в коде и архитектуре.
🤖 Дальше интереснее...
⬇️ продолжение⬇️
Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:
а можно ли применить принципы микросервисной архитектуры ПО при проектировании оргструктуры компании?
Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.
У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.
Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.
Но вопрос непростой:
как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?
И не умереть под завалами задач.
Сергей сформулировал метафору:
- каждый отдел — это по сути «микросервис»
- на входе — задачи из разных частей компании
- каждый «сервис» делает своё маленькое, но важное дело
- хочется, чтобы система была масштабируемая, гибкая, без «архитектурного долга»
(когда отделы созданы из локальной логики, а потом не складываются в общую систему)
Идея выглядит привлекательно. Но…
⚠️ Проблема №1: микросервис можно масштабировать, человека — нет
Моя первая реакция была простая:
Обратное применение микросервисного подхода почти никто не делал — и не случайно.
Микросервис можно сделать любой гранулярности, а вот сотрудника ты не возьмёшь на 20 минут в день.
Человек ≠ маленький сервис на одну функцию.
Под обратным применением я подразумевал вывернутый наизнанку процесс — обычно ведь мы в ИТ-системах пытаемся построить упрощенную модель мира, и под неё подстраиваем ИТ-процессы и ограничения. Но вот наоборот — не факт, что сработает.
В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.
В компаниях и операционных процессах так не работает.
Лирическое отступление: если что, я не являюсь последователем "1 микросервис — 1 разработчик (или даже 1 микросервис — 1 команда)", а даже являюсь противником такого подхода, вносящего дополнительные ненужные ограничения прежде всего на ту же гранулярность. К примеру, у меня был проект с 5 разработчиками на 60 микросервисов — и это нормально
⚠️ Из первой проблемы логическим следствием вытекает вторая:
оргструктура и ИТ-архитектура должны быть независимы
Когда анализируешь энтерпрайз-архитектуру крупного предприятия — это важное правило почти всегда нарушается. Рано или поздно, в большем или меньшем объёме, но устройство человеческих отделов компании, их операционных процессов протекает и в архитектурные схемы, разделение ответственностей между системами и необоснованные барьеры и границы
Странно будет предполагать, что допустив обратное влияние: ИТ-архитектуры на оргструктуру компании, мы получим хороший результат — слишком разные процессы и правила игры в этих двух мирах.
Но речь всё же чуть о другом — в компании нет идеальной автоматизорованной айтишечки, которую надо "переложить" на людей. Скорее в целом стандартные методы управления перестают работать, и идёт логичный поиск новых парадигм во всех возможных смежных сферах.
И тут мы нашли точку пересечения: уровень теории систем, ну или графов, или связанности-связности (прочности).
Я недавно писал об этом при рассмотрении перекладывания моего принципа каскадного снижения связанности на реальную жизнь:
если в компании люди сидят по отделам, и внутри отдела они общаются чаще, чем с соседним — это ровно те же coupling / cohesion.
- внутри отдела — высокая прочность
- между отделами — минимальная связанность
- если постоянно «бегают между этажами» — структура неправильная
То есть принципы модульности, низкой связанности и высокой прочности действительно применимы к оргструктуре, но не 1-в-1 как в коде и архитектуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3👍3🔥2 2🤔1💋1👻1👾1
2/2
⬆️ начало ⬆️
🤖 Дальше интереснее: «оркестратор задач»
Сергей поднял более глубокий уровень:
То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.
И здесь аналогия с ИТ-архитектурой уже ближе:
- есть оркестратор
- есть «рои исполнителей» (отделы)
- задачи приходят из разных источников
Но в отличие от классического оркестратора задач из идеального мира паттернов, такой оркестратор должен уметь:
- переопределять приоритеты задач
- отбрасывать протухшие задачи
- перераспределять ресурсы
- смотреть на общую ценность задачи для компании
Это уже сложная модель.
И вот тут ровно то место, где микросервисная аналогия снова ломается:
- как правило, в ИТ-системах все процессы обязаны выполниться;
- а в компании — наоборот: главное выбрать, что НЕ делать.
🧩 Выводы разговора
1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.
Люди не функции, отдел не является сервисом по определению.
2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.
3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:
- знает общие приоритеты,
- видит загрузку всех отделов,
- оптимизирует систему как целое.
4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.
5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.
И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг😢
🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений.
И пока кажется, идея аналогий действительно не так уж безумна.
Но начинать нужно не с микросервисов, как более такического приема на уровне solution-архитектуры, а чего-то более глобального 😉 Ведь по сути — везде нужно решить одну и ту же задачу — побороть и подчинить себе сложность👻
Сергей поднял более глубокий уровень:
«На входе у компании — тысячи задач.
Каждая требует разные комбинации отделов.
Как распределять приоритеты?
Как система должна выбирать оптимальный набор задач для максимального эффекта?
И кто должен быть этим „центром принятия решений“?»
То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.
И здесь аналогия с ИТ-архитектурой уже ближе:
- есть оркестратор
- есть «рои исполнителей» (отделы)
- задачи приходят из разных источников
Но в отличие от классического оркестратора задач из идеального мира паттернов, такой оркестратор должен уметь:
- переопределять приоритеты задач
- отбрасывать протухшие задачи
- перераспределять ресурсы
- смотреть на общую ценность задачи для компании
Это уже сложная модель.
Тут нужна либо ИИ-система по центру,
либо очень сложный алгоритм.
Архитектура вокруг исполнителей — это уже вторично.
И вот тут ровно то место, где микросервисная аналогия снова ломается:
- как правило, в ИТ-системах все процессы обязаны выполниться;
- а в компании — наоборот: главное выбрать, что НЕ делать.
1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.
Люди не функции, отдел не является сервисом по определению.
2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.
3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:
- знает общие приоритеты,
- видит загрузку всех отделов,
- оптимизирует систему как целое.
4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.
5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.
И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг
🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений.
И пока кажется, идея аналогий действительно не так уж безумна.
Но начинать нужно не с микросервисов, как более такического приема на уровне solution-архитектуры, а чего-то более глобального 😉 Ведь по сути — везде нужно решить одну и ту же задачу — побороть и подчинить себе сложность
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥8👍5❤3🤓3👾3🐳1
RUTUBE
Будущее ИТ-архитектуры
Как изменится ИТ-архитектура (а следовательно и сфера создания ПО в целом) на пике шестой технологической волны, когда ИИ станет как минимум обязательным инструментом во всех процессах?
Порассуждаем о роли архитектуры и архитектора в условиях, когда написать…
Порассуждаем о роли архитектуры и архитектора в условиях, когда написать…
Наконец-то появилась запись моего доклада про будущее 🔮✨
а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:
https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc
Ранее писал пару постов, и про идеи при подготовке доклада и про мысли по его следам
Всех с наступающим.. будущим! Которое уже здесь❄️ 🚀
а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:
https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc
Ранее писал пару постов, и про идеи при подготовке доклада и про мысли по его следам
Всех с наступающим.. будущим! Которое уже здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍3 3❤1🦄1
Сегодня (30 декабря) наконец закончился марафон экзаменационных защит у магистрантов по моему курсу микросервисной архитектуры —
6️⃣ 9️⃣ защитившихся на данный момент (часть уйдет на пересдачи уже в следующем году), и это абсолютный рекорд!
Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!
Что хочу сказать..
Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов🌌
И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло😅 , в голове каким-то образом сложились пазлики.. Пока сложно сформулировать, но как будто бы есть не такое большое количество типовых приёмов, из комбинации которых складываются почти все архитектуры.
Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).
Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения!🧠
Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста🙏 , давно не занимался вопросом и наверняка появилось много нового).
Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи.
Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализировать большое количество накопившихся архитектур.. а чтобы это количество пополнить и расширить выборку — обращусь к вам:
⚠️ пришлите, пожалуйста, мне свои микросервисные архитектуры в любом виде (если это нарушает NDA — можно каким-то образом анонимизировать и обфусцировать (например, убрав часть надписей)). Закидывать можно мне в личку (@razonrus)
По результатам, я надеюсь собрать и оформить архитектурные кубики (ну или сказать, что уже всё изобретено под🌛 ).
P.S. Есть ещё идея собрать ещё один публичный каталог архитектурных схем, если хотите чтобы ваша архитектура там была опубликована (на условиях анонимности) — явно в сообщении разрешите мне это сделать в сообщении. Без разрешения, естественно, никакие архитектуры никуда выкладывать не буду.
Буду только их анализировать и медитировать над ними
🧘♂️
Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!
Что хочу сказать..
Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов
И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло
Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).
Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения!
Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста
Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи.
Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализировать большое количество накопившихся архитектур.. а чтобы это количество пополнить и расширить выборку — обращусь к вам:
По результатам, я надеюсь собрать и оформить архитектурные кубики (ну или сказать, что уже всё изобретено под
P.S. Есть ещё идея собрать ещё один публичный каталог архитектурных схем, если хотите чтобы ваша архитектура там была опубликована (на условиях анонимности) — явно в сообщении разрешите мне это сделать в сообщении. Без разрешения, естественно, никакие архитектуры никуда выкладывать не буду.
Буду только их анализировать и медитировать над ними
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍10👏4🎉2
Год получился спокойным, без гонки за частотой и хайпом — но, как мне кажется, достаточно насыщенным по смыслу.
На 1 января 2025 у канала был 1021 подписчик. Сейчас — 1469! СПАСИБО!
Прирост +448 человек, примерно +44% за год.
Без накруток, конкурсов и прочей... (активности) ради цифр — просто органический рост вокруг тем, которые мне самому кажутся важными.
За год вышел 31 пост — в среднем 2–3 поста в месяц.
Самый продуктивный месяц — март (6 постов).
Самый непродуктивный — ноябрь (0 постов) — холодная осень в жизни и в канале — бывает 🙂
— 1676 просмотров
— 26 реакций
— 5,5 комментариев
Говорят, для канала без развлекательного формата и без «кричащих» заголовков — метрики более чем живые. Особенно радуют комментарии: именно в обсуждениях обычно и рождаются новые идеи.
________________________________
________________________________
Если отбросить выбросы в показателях, вызванные репостами пары постов, то наибольшее число просмотров будет у поста про.. внезапно химию! ⚗️
Каскадное снижение связанности — от микросервисов к жизни, бизнесу и даже химии
Пост о том, что архитектурные принципы не заканчиваются на софте.
Аналогии с оргструктурами, этажами офисов, атомами и молекулами — и попытка показать, что правильное соотношение связанности и прочности работает в любой сложной системе, независимо от её природы.
________________________________
Провокационный текст о том, что код — это интерфейс для человека, а не фундамент профессии.
Про LLM, внутренние представления моделей, отказ от синтаксиса в пользу смысла — и почему это не смерть программирования, а его логичное развитие.
Личный опыт совместной разработки с ИИ: когда человеку остаются идеи и мышление, а рутину забирает машина.
Про шахматные движки, pet-проекты и ощущение, что программирование снова стало игрой, а не конвейером.
Пятничный пост с бытовой аналогией: энергетик «на случай падения прода», у которого вышел срок годности, как индикатор реальной стабильности системы.
Иногда простые примеры объясняют сложные вещи лучше любых диаграмм.
________________________________
Большой разговор о применимости архитектурных принципов к управлению компаниями.
Почему нельзя копировать микросервисы 1-в-1 на людей, но почему принципы модульности, связанности и центра принятия решений всё равно универсальны.
По сути — про архитектуру управления сложностью.
Текст не вместился в ограничения телеграма и разделился аж на 2 поста, даю ссылку на первую часть:
Реакция на упоминание принципа в разборе антипаттернов микросервисов.
Про границы сервисов, потоки данных, динамическую связанность и архитектурный долг — в формате живой асинхронной дискуссии.
Жёсткий, но, как мне кажется, честный пост о разнице между инструментами и принципами.
Почему настоящие компетенции не стареют, при чём тут архитектура и шахматы, и почему умение «знать, куда кликать» — самый хрупкий навык в эпоху ИИ.
________________________________
Спасибо всем, кто читает, спорит, не соглашается и дополняет.
Копаем дальше
P.S. На картинке можно найти отсылки практически ко всем упомянутым постам
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍15❤🔥4🔥2❤1
На всех крупных ИТ-конференциях, где мне доводилось бывать, тема технологий двойного назначения фактически находилась под негласным запретом. До 2022 года эта тема, как правило, просто не поднималась, но теоретически подобные доклады как минимум могли быть рассмотрены.
После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).
Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
🎞 https://tg-me.sbs/rsa_enc/102
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
💬 Н. И. Касперская, президент группы компаний InfoWatch (бывший генеральный директор «Лаборатории Касперского»), на дискуссии «Архитектура цифровизации государственного управления»:
https://tg-me.sbs/khazinml/12010
💬 В. В. Шпак, заместитель министра промышленности и торговли РФ:
https://tg-me.sbs/nasledediye21/257
💡 Посмотрите видео по ссылкам — интересно, 14 минут в сумме.
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://tg-me.sbs/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.
После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).
Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
Коллеги, давайте будем честны, мы идем к глобальной войне. У нас через некоторое время отключения интернета будут нормой.
Отказ от бумаги к 2030 году — это диверсия по государственному управлению. На мой взгляд, это просто государственная измена.
https://tg-me.sbs/khazinml/12010
Эпоха, когда мы делили технологии на гражданские и военные — она закончилась.
https://tg-me.sbs/nasledediye21/257
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://tg-me.sbs/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Дискуссионный клуб «Наследие XXI»
Тихая революция: почему беспилотники — это новый фундамент экономики
Эту точку зрения в недавнем интервью подробно разъяснил сооснователь Клуба "Наследие XXI" Василий Шпак. Основные тезисы — ниже ⬇️
💬 Пока все говорят про хайп вокруг ИИ, в России тихо…
Эту точку зрения в недавнем интервью подробно разъяснил сооснователь Клуба "Наследие XXI" Василий Шпак. Основные тезисы — ниже ⬇️
💬 Пока все говорят про хайп вокруг ИИ, в России тихо…
11👍8🔥7👏3😢2🐳2
В архитектуре и в IT в целом всегда была одна закономерность: чем больше мы инструментов используем — тем больше у нас когнитивной нагрузки, связей и рисков. Но похоже, эта закономерность сейчас растёт не просто линейно — она уходит в экспоненту.
Каждая новая конференция, каждый свежий блог или твит — и вот уже в продакшене не только Kubernetes с Terraform, но и ArgoCD, Flux, Crossplane, Istio, Linkerd, Kafka, Prometheus, Grafana, Loki, Vector… и ещё десятки «must-have» штуковин, о которых пару лет назад никто и не слышал. И всё это с разными паттернами конфигурации, API, lifecycle-политиками, схемами RBAC и кучей плагинов.
С одной стороны — классно: инструменты становятся мощнее, автоматизация всё глубже, можно декларировать инфраструктуру как код, наблюдаемость как код, безопасность как код… и вообще делать всё быстрее. С другой — нам приходится управлять зоопарком взаимодействующих систем, каждая из которых умеет жить сама по себе, но в связке с другими — уже приносит новый класс сложностей.
Стаёт очевидно, что в девопсе сложность растёт быстрее, чем наша способность её осознать и контролировать.
И вот что меня особенно беспокоит:
➡️ Многие берут инструменты не подумав о контексте применения.
Инструмент X оказался крутым в десятке крупных команд с выделенными Platform и Infra командами. Там — куча девопсов, бюджеты, процессы, SLA. Там — есть кому его настроить, поддерживать и мигрировать через версии.
➡️ Потом инструмент становится «модным» — про него рассказывают на митапах, он попадает в блог-чарт, все на конференциях в нетворкинге довольные обсуждают, как они теперь используют «Y вместо Z». А дальше — этот же инструмент начинают внедрять в команды с парой девопсов, несколькими бэкендерами, и нулевым временем на поддержку.
И что происходит?
❗️ Команда тонет в конфигурациях CRD, webhooks, операторов, chart’ов.
❗️ Pipelines растут как шевелящиеся графы — читать сложно, дебажить невозможно.
❗️ Инциденты растут, команда не успевает, начинает винить себя, выгорает.
❗️ Продукт работает плохо.
Причина очень простая: инструмент сам по себе не плох — он сложен. А мы не всегда учитываем его назначение, контекст и границы применимости.
То есть:
➡️ инструмент A шикарно решает проблему в энтерпрайзе с 200 нодами и 10 командами — потому что там есть кто за ним следит;
➡️ но тот же A в команде с 2 девопсами — уже приводит к операционной долговой яме.
Иногда куда правильнее взять меньше инструментов, но более понятных и прогнозируемых, пусть и менее хайповых. Старые, зрелые, с простым поведением — и вы скорее добьётесь результата, который приносит бизнес-ценность и спокойствие команде.
Сложность не измеряется числом звезд на GitHub.
Сложность измеряется тем, сколько ты реально можешь понять, предсказать и поддерживать в ежедневной работе.
И если хочешь добавить новый инструмент в инфраструктуру — убедись, что есть ресурсы для его настройки и поддержки, и что он действительно нужен в продукте (а не только в твоём резюме или слайде очередной конференции).
Каждая новая конференция, каждый свежий блог или твит — и вот уже в продакшене не только Kubernetes с Terraform, но и ArgoCD, Flux, Crossplane, Istio, Linkerd, Kafka, Prometheus, Grafana, Loki, Vector… и ещё десятки «must-have» штуковин, о которых пару лет назад никто и не слышал. И всё это с разными паттернами конфигурации, API, lifecycle-политиками, схемами RBAC и кучей плагинов.
С одной стороны — классно: инструменты становятся мощнее, автоматизация всё глубже, можно декларировать инфраструктуру как код, наблюдаемость как код, безопасность как код… и вообще делать всё быстрее. С другой — нам приходится управлять зоопарком взаимодействующих систем, каждая из которых умеет жить сама по себе, но в связке с другими — уже приносит новый класс сложностей.
Стаёт очевидно, что в девопсе сложность растёт быстрее, чем наша способность её осознать и контролировать.
И вот что меня особенно беспокоит:
Инструмент X оказался крутым в десятке крупных команд с выделенными Platform и Infra командами. Там — куча девопсов, бюджеты, процессы, SLA. Там — есть кому его настроить, поддерживать и мигрировать через версии.
И что происходит?
Причина очень простая: инструмент сам по себе не плох — он сложен. А мы не всегда учитываем его назначение, контекст и границы применимости.
То есть:
Иногда куда правильнее взять меньше инструментов, но более понятных и прогнозируемых, пусть и менее хайповых. Старые, зрелые, с простым поведением — и вы скорее добьётесь результата, который приносит бизнес-ценность и спокойствие команде.
Сложность не измеряется числом звезд на GitHub.
Сложность измеряется тем, сколько ты реально можешь понять, предсказать и поддерживать в ежедневной работе.
И если хочешь добавить новый инструмент в инфраструктуру — убедись, что есть ресурсы для его настройки и поддержки, и что он действительно нужен в продукте (а не только в твоём резюме или слайде очередной конференции).
Please open Telegram to view this post
VIEW IN TELEGRAM
1💯18👍5❤3🐳1👻1
Давно я тут ничего не писал.. Ещё давнее — чего-то на самом деле архитектурного. Исправляюсь :)
Сегодня хочу поговорить о применении Common Reuse Principle (CRP) для микросервисной архитектуры. Вкратце я упоминал о применении данного принципа к микросервисам, например, в докладе по рефакторингу архитектуры. Давайте разберём подробнее и с примерами.
Вспомним, о чём говорит классическая формулировка CRP предложенная Робертом Мартиным:
Пример нарушения:
Я перенес этот принцип на микросервисную архитектуру, о его применение иногда вызывает споры. Давайте разбираться на примере контекстов микросервисов.
Итак, принцип будет звучать примерно так:
Если один контекст (1) использует микросервис из другого контекста (2), то использовать он должен и остальные "публичные" микросервисы.
Под "публичными" я подразумеваю микросервисы контекста, используемые извне, т.е. микросервисами других контекстов или систем.
Важен момент, что на практике у микросервисов часто вообще не проговаривают, какие из них публичные, а какие внутренние. Все сервисы вроде бы равны, все имеют API, а дальше кто куда смог дотянуться, тот туда и пошел. На короткой дистанции это кажется удобным. На длинной дистанции это начинает размывать границы контекстов.
💡 Я советую различать публичные и приватные микросервисы не только в головах и на схемах, но и на уровне инфраструктуры. То есть чтобы физический сетевой доступ извне контекста вообще был возможен только до тех сервисов, которые контекст действительно готов прокинуть наружу. Тогда архитектурное намерение закрепляется не только словами, но и ограничениями системы.
Наверное, проще проиллюстрировать соблюдение и нарушение принципа на примерах.
На схемах 1 и 2 нарушения принципа нет. В первом случае контекст 1 использует сервисы C и D контекста 2, и это допустимо — он зависит от всех "компонентов" контекста 2. Во втором случае контекст 1 использует только C, и тут тоже всё нормально, т.к. микросервис D — внутренний сервис контекста 2, который нужен только для внутреннего взаимодействия (например C -> D) и не используется извне никем.
Теперь перейдём к нарушениям принципа на схемах 3 и 4.
На этих схемах у контекста 2 оба микросервиса являются "публичными" — их использует кто-то извне. Согласно принципу: если мы зависим от одного из микросервисов контекста — мы должны зависеть от всех его публичных частей. На схеме 3 контекст 3 зависит только от одного микросервиса контекста 2, а на схеме 4 — такая же проблема у контекста 1. В этом и нарушение :) Т.е. контекст 2 перестает быть для внешнего мира цельным модулем, его начинают переиспользовать частями.
Если какой-то сервис другого контекста вам действительно нужен снаружи сам по себе, отдельно от остальных, то это уже хороший повод остановиться и подумать. Возможно, контекст собран неудачно. Возможно, микросервис слишком крупный или слишком мелкий. Возможно, микросервисы внутри контекста стоит перегруппировать. Возможно, сам bounded context проведен не там, где должен быть.
И вот тут CRP, как мне кажется, хорошо подсвечивает архитектурную проблему. Если что-то переиспользуется отдельно от остального, то, возможно, это "что-то" вообще должно жить в другой сборке/контекста/системе. А если мы продолжаем это игнорировать, то получаем не осознанную архитектуру, а исторически сложившуюся нарезку микросервисов с плохим соотношением связанности и прочности, которую уже давно пора рефакторить.
P.S. Спасибо Сергею — он оперативно добавил ADR с описанием принципа в каталог принципов проектирования, и планирует написать пример архитектурного теста на соблюдение данного принципа🔥
Сегодня хочу поговорить о применении Common Reuse Principle (CRP) для микросервисной архитектуры. Вкратце я упоминал о применении данного принципа к микросервисам, например, в докладе по рефакторингу архитектуры. Давайте разберём подробнее и с примерами.
Вспомним, о чём говорит классическая формулировка CRP предложенная Робертом Мартиным:
Классы и модули, которые переиспользуются вместе, должны находиться в одном компоненте; и наоборот, не стоит заставлять потребителя компонента зависеть от того, что ему не нужно.
Пример нарушения:
Представьте библиотеку GraphicsUtils, в которой лежат классы для работы с 2D-графикой и классы для сложной 3D-анимации. Если разработчику просто нужно нарисовать круг (2D), он вынужден подключить всю библиотеку, включая тяжелые 3D-алгоритмы. Согласно CRP, их следует разделить на два разных компонента
Я перенес этот принцип на микросервисную архитектуру, о его применение иногда вызывает споры. Давайте разбираться на примере контекстов микросервисов.
Итак, принцип будет звучать примерно так:
Если один контекст (1) использует микросервис из другого контекста (2), то использовать он должен и остальные "публичные" микросервисы.
Под "публичными" я подразумеваю микросервисы контекста, используемые извне, т.е. микросервисами других контекстов или систем.
Важен момент, что на практике у микросервисов часто вообще не проговаривают, какие из них публичные, а какие внутренние. Все сервисы вроде бы равны, все имеют API, а дальше кто куда смог дотянуться, тот туда и пошел. На короткой дистанции это кажется удобным. На длинной дистанции это начинает размывать границы контекстов.
Наверное, проще проиллюстрировать соблюдение и нарушение принципа на примерах.
На схемах 1 и 2 нарушения принципа нет. В первом случае контекст 1 использует сервисы C и D контекста 2, и это допустимо — он зависит от всех "компонентов" контекста 2. Во втором случае контекст 1 использует только C, и тут тоже всё нормально, т.к. микросервис D — внутренний сервис контекста 2, который нужен только для внутреннего взаимодействия (например C -> D) и не используется извне никем.
Теперь перейдём к нарушениям принципа на схемах 3 и 4.
На этих схемах у контекста 2 оба микросервиса являются "публичными" — их использует кто-то извне. Согласно принципу: если мы зависим от одного из микросервисов контекста — мы должны зависеть от всех его публичных частей. На схеме 3 контекст 3 зависит только от одного микросервиса контекста 2, а на схеме 4 — такая же проблема у контекста 1. В этом и нарушение :) Т.е. контекст 2 перестает быть для внешнего мира цельным модулем, его начинают переиспользовать частями.
Если какой-то сервис другого контекста вам действительно нужен снаружи сам по себе, отдельно от остальных, то это уже хороший повод остановиться и подумать. Возможно, контекст собран неудачно. Возможно, микросервис слишком крупный или слишком мелкий. Возможно, микросервисы внутри контекста стоит перегруппировать. Возможно, сам bounded context проведен не там, где должен быть.
И вот тут CRP, как мне кажется, хорошо подсвечивает архитектурную проблему. Если что-то переиспользуется отдельно от остального, то, возможно, это "что-то" вообще должно жить в другой сборке/контекста/системе. А если мы продолжаем это игнорировать, то получаем не осознанную архитектуру, а исторически сложившуюся нарезку микросервисов с плохим соотношением связанности и прочности, которую уже давно пора рефакторить.
P.S. Спасибо Сергею — он оперативно добавил ADR с описанием принципа в каталог принципов проектирования, и планирует написать пример архитектурного теста на соблюдение данного принципа
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6👏4🔥2❤🔥1🐳1
Эффективно выстроить работу с ИИ-агентами можно только хотя бы примерно понимая, как они устроены (досконально как работают современные LLM не понимает никто :)).
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученноес молоком матери знание, а контекст: временно подгруженная рабочая среда (контекст, скиллы и т.д.). И она хрупкая. Что-то попало в неё, что-то нет. Что-то модель посчитала важным, что-то второстепенным. Что-то при упаковке контекста сократилось или исчезло. Поэтому модель может знать огромный пласт общих вещей и при этом забыть, о чём вы договорились десять сообщений назад.
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученное
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
1🔥14👍9❤4😁2👾2☃1🐳1
В июне на конференции TechLeadConf в Питере я буду куратором и членом жюри архитектурной каты — соревнования по проектированию ИТ-архитектуры. И пока думаю, как это всё лучше организовать и по каким критериям потом оценивать решения, меня всё сильнее гложет одна неудобная мысль.
⚠️ Если попросить десять сильных архитекторов независимо друг от друга спроектировать одну и ту же систему, почти наверняка мы получим десять разных архитектур.
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в◀️ ваш любимый бигтех▶️ , так правильнее, гибче, надежнее. И вот это вот всё.
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить
Please open Telegram to view this post
VIEW IN TELEGRAM
10❤16👍6🔥5
Вышел пилотный выпуск подкаста про ИИ в разработке, в котором я принимал участие 🎙 Говорили не про ИИ в SDLC в целом, а конкретно про проектирование архитектуры — ровно нашу тему 😋 , которая иногда теряется пока все обсуждают генерацию кода.
Собрались вчетвером: ведущий Андрей Дмитриев (JUG Ru Group), Максим Смирнов (@it_arch), Андрей Бураков (@another_sa) и я.
Пара тем, которые хочется отдельно отметить👇
🚀 Архитектурные метрики.
Тема, про которую я писал и выступал уже много раз — и метрики через покрытие архитектуры тестами, и принцип каскадного снижения связанности, и наш опенсорс-инструмент для подсчета архитектурных метрик.. И вот прямо сейчас та самая ситуация, когда то, чем занимался годами, на глазах становится в разы актуальнее! Собирать метрики стало заметно проще, а их важность взлетела🤩
То, что раньше жило в голове архитектора на уровне «ну вроде паттерн нарушен, вроде нет», теперь без особых усилий проверяется тестами и ложится в цифры. Очень радует!
💾 ADR.
Последние годы архитектурные решения иногда воспринимались как бюрократия (особенно в некоторых процессах и компаниях😉 ). А сейчас их ценность только растёт. У агентов короткая память — они не помнят, что семь лет назад вы уже пробовали вот так и откатились по вполне конкретным причинам. ADR — это ровно то, что завтра вы будете скармливать агенту, работающему с вашим проектом. Даже если сегодня они вам не особо нужны — пишите. Через год скажете себе спасибо 🤩
🧪 SDD (Spec-Driven Development).
Идея классная, реализация пока сыровата. Я ставил эксперимент со Spec Kit — дал ТЗ и дальше почти не вмешивался. MVP получил за четыре дня 🙂 Последние два, правда, вычищал баги уже руками. Главный вывод для себя такой: спецификации, которые LLM генерит сама для себя, без человека в цикле начинают накапливать ошибку как снежный ком. Где-то это ломается раньше, где-то позже, но ломается.
А что по этим вопросам думают Максим, Андрей и Андрей — можно послушать в самом выпуске:
https://www.youtube.com/watch?v=IQ6zFeYDXd8
или на Rutube
Собрались вчетвером: ведущий Андрей Дмитриев (JUG Ru Group), Максим Смирнов (@it_arch), Андрей Бураков (@another_sa) и я.
Пара тем, которые хочется отдельно отметить
Тема, про которую я писал и выступал уже много раз — и метрики через покрытие архитектуры тестами, и принцип каскадного снижения связанности, и наш опенсорс-инструмент для подсчета архитектурных метрик.. И вот прямо сейчас та самая ситуация, когда то, чем занимался годами, на глазах становится в разы актуальнее! Собирать метрики стало заметно проще, а их важность взлетела
То, что раньше жило в голове архитектора на уровне «ну вроде паттерн нарушен, вроде нет», теперь без особых усилий проверяется тестами и ложится в цифры. Очень радует!
💾 ADR.
Последние годы архитектурные решения иногда воспринимались как бюрократия (особенно в некоторых процессах и компаниях
Идея классная, реализация пока сыровата. Я ставил эксперимент со Spec Kit — дал ТЗ и дальше почти не вмешивался. MVP получил за четыре дня 🙂 Последние два, правда, вычищал баги уже руками. Главный вывод для себя такой: спецификации, которые LLM генерит сама для себя, без человека в цикле начинают накапливать ошибку как снежный ком. Где-то это ломается раньше, где-то позже, но ломается.
А что по этим вопросам думают Максим, Андрей и Андрей — можно послушать в самом выпуске:
https://www.youtube.com/watch?v=IQ6zFeYDXd8
или на Rutube
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
AI Dev Podcast #1 / Проектирование систем в эпоху ИИ / Максим Смирнов, Руслан Сафин, Андрей Бураков
📢 [AI Dev подкаст #1] ИИ в проектировании архитектуры: хайп, метрики и «скиллы»
Спойлер: LLM уже справляется с проверкой техрадара, оценкой пул-реквестов и анализом архитектурного долга. Но есть нюансы.
Мы собрали трех практиков, чтобы ответить на вопросы:…
Спойлер: LLM уже справляется с проверкой техрадара, оценкой пул-реквестов и анализом архитектурного долга. Но есть нюансы.
Мы собрали трех практиков, чтобы ответить на вопросы:…
7❤9👍6🔥6❤🔥2🐳1🦄1👾1
🔮 Стратегия айтишника в эпоху ИИ: как остаться востребованным
Всем привет! Последние месяцы я активно думаю, пишу и выступаю о будущем ИТ — доклады про ИИ, посты про настоящие компетенции, на подходе — объёмная статья для Хабра..
И наконец-то я довёл все эти рассуждения до конкретного прикладного результата — и спешу им с вами поделиться!🚀
📌 SWOT-анализ + стратегия «Айтишник в шестой технологической волне»
➡️ https://app.sociotech.center/projects/public/133b2a7b-c7b0-4559-8fe6-1b734e5085b1
Это не очередные «10 советов, как не потерять работу из-за ИИ»😅 . Это полноценная стратегия — с целью до 2029 года, измеримыми метриками, тремя ключевыми гипотезами и конкретными задачами под каждую. Всё по букве методологий Карты гипотез и Связанного SWOT-анализа: сначала факторы, потом ставки, потом сами гипотезы и задачи.
❗️ И самое главное — там не только «анализ ради анализа». Там расписаны конкретные задачи и советы, которые можно начать делать уже на этой неделе ☺️ . Не абстрактное «развивайтесь», а «возьми одну реальную задачу и пройди её полностью через ИИ — от цели до верификации», «напиши один ADR для ИИ-агента, который возьмётся за твой код через год», «настрой один архитектурный автотест через AACT или ArchUnit».
🤩 🤩 🤩
🎯 Если вкратце — стратегия сводится к трём сдвигам:
1️⃣ Борьба со сложностью вместо производства кода
Код скоро станет таким же внутренним слоем, как ассемблер. Ценность сдвигается на уровень выше — в визуализацию систем, графовое мышление, архитектурные решения. Если сложность живёт только у тебя в голове — контроль над ней иллюзорен. Выплесни её на схему и начни с ней работать.
2️⃣ ИИ как новый режим мышления, а не как новый инструмент
В зависимости от того как ты работаешь с ИИ — разброс качества результата может быть огромным. Чат с ИИ ≠ работа с ИИ. Загрузи в агента полный контекст проекта и цель бизнеса — а не отдельный вопрос. Разбери свои типовые задачи на три корзины: рутина → агенту, решение → себе, проверка → обязательно себе. Напиши свой первый agent skill (сегодня это просто текстовый файл, а не поднятие векторных БД, как полгода назад).
3️⃣ Ответственность за результат, а не за код
До кода и до ИИ — запиши бизнес-цель, не-цели, ограничения, критерии «достигнуто». И проверь — а нужен ли вообще новый код? Это самый контринтуитивный пункт во всём списке. Перепиши резюме вокруг решений и результатов, а не стека. Проведи один пилот безопасного внедрения ИИ в команде — роль проводника ИИ в организации уже оплачивается, в отличие от роли «ещё один prompt-оператор» 🙂
🤩 🤩 🤩
🧩 И вот что ещё круто — стратегия не высечена в граните! Можно ведь совместно редактировать и дополнять карту гипотез и SWOT. И я очень хочу позвать вас поучаствовать! ❤️
Хочется, чтобы это стало не моим монологом, а живым коллективным документом, который мы вместе докручиваем, оспариваем, дополняем своими гипотезами, задачами и даже альтернативными ставками. Ведь именно в таких дискуссиях рождается настоящее понимание — сам я убеждался в этом уже не раз после каждого доклада и поста.
🙏 Поэтому приглашаю:
— просто посмотреть, покликать, повертеть карту и SWOT
— применить задачи к себе (реально, не отложив «на потом»)
— а главное — присоединиться к совместному редактированию и расширению стратегии и анализа: скидывайте мне свои аккаунты (@razonrus) — добавлю вас в пространство
Это тот случай, когда коллективный интеллект реально даст больше, чем любой индивидуальный анализ. Давайте вместе соберём самую толковую стратегиювыживания усиления айтишника в шестой технологической волне ✨
❤️ Буду рад любым комментариям, дополнениям, несогласиям, своим ставкам, гипотезам и задачам — всё это добавляет глубины и смысла общей работе.
А применённые задачки и инсайты по ходу дела — скидывайте в комментарии сюда или мне в личку (@razonrus). Самое интересное соберу в следующем посте 😌.
А ещё, если вдруг вы из Челябинска — приходите через месяц, в рамках доклада представлю данную стратегию в оффлайне🐰
Погнали! 🚀
Всем привет! Последние месяцы я активно думаю, пишу и выступаю о будущем ИТ — доклады про ИИ, посты про настоящие компетенции, на подходе — объёмная статья для Хабра..
И наконец-то я довёл все эти рассуждения до конкретного прикладного результата — и спешу им с вами поделиться!
Это не очередные «10 советов, как не потерять работу из-за ИИ»
🎯 Если вкратце — стратегия сводится к трём сдвигам:
Код скоро станет таким же внутренним слоем, как ассемблер. Ценность сдвигается на уровень выше — в визуализацию систем, графовое мышление, архитектурные решения. Если сложность живёт только у тебя в голове — контроль над ней иллюзорен. Выплесни её на схему и начни с ней работать.
В зависимости от того как ты работаешь с ИИ — разброс качества результата может быть огромным. Чат с ИИ ≠ работа с ИИ. Загрузи в агента полный контекст проекта и цель бизнеса — а не отдельный вопрос. Разбери свои типовые задачи на три корзины: рутина → агенту, решение → себе, проверка → обязательно себе. Напиши свой первый agent skill (сегодня это просто текстовый файл, а не поднятие векторных БД, как полгода назад).
До кода и до ИИ — запиши бизнес-цель, не-цели, ограничения, критерии «достигнуто». И проверь — а нужен ли вообще новый код? Это самый контринтуитивный пункт во всём списке. Перепиши резюме вокруг решений и результатов, а не стека. Проведи один пилот безопасного внедрения ИИ в команде — роль проводника ИИ в организации уже оплачивается, в отличие от роли «ещё один prompt-оператор» 🙂
Хочется, чтобы это стало не моим монологом, а живым коллективным документом, который мы вместе докручиваем, оспариваем, дополняем своими гипотезами, задачами и даже альтернативными ставками. Ведь именно в таких дискуссиях рождается настоящее понимание — сам я убеждался в этом уже не раз после каждого доклада и поста.
🙏 Поэтому приглашаю:
— просто посмотреть, покликать, повертеть карту и SWOT
— применить задачи к себе (реально, не отложив «на потом»)
— а главное — присоединиться к совместному редактированию и расширению стратегии и анализа: скидывайте мне свои аккаунты (@razonrus) — добавлю вас в пространство
Это тот случай, когда коллективный интеллект реально даст больше, чем любой индивидуальный анализ. Давайте вместе соберём самую толковую стратегию
А применённые задачки и инсайты по ходу дела — скидывайте в комментарии сюда или мне в личку (@razonrus). Самое интересное соберу в следующем посте 😌.
А ещё, если вдруг вы из Челябинска — приходите через месяц, в рамках доклада представлю данную стратегию в оффлайне
Погнали! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥15✍4👍3❤1🐳1👻1👾1
Неделя выдалась плодотворная ) очередной пост ))
Уже почти становится традицией — третью весну подряд у меня выходит статья на Хабре☀️
На этот раз я в текст облёк свой доклад про будущее ИТ, о котором уже писал здесь..
Повторюсь, что в этот раз я решил сознательно чуть отойти от привычного сугубо практического формата.
Если раньше я в основном писал про вполне прикладные вещи (гранулярность микросервисов, проектирование отказоустойчивости, покрытие архитектуры тестами, каскадное снижение связанности) — то здесь попробовал замахнуться на горизонт пошире:
- что вообще происходит с ИТ,
- что меняется из-за ИИ,
- зачем в новом мире по-прежнему нужна архитектура,
- и что со всем этим делать разработчику уже сейчас.
Ключевая мысль для меня такая: человеческая ценность всё меньше в самом написании кода и всё больше — в борьбе со сложностью, в проектировании, в постановке задач, в выборе ограничений и в проверке результата.
То есть не “меньше инженерии”, а скорее инженерия следующего уровня.
В общем, статья (как и доклад) местами провокационная :)
Там и про возможный уход языков программирования в роль промежуточного костыля, и про архитектуру как способ укрощения сложности, и про то, почему разработчик всё больше становится чем-то средним между архитектором, аналитиком и тимлидом ИИ-агентов.
https://habr.com/ru/articles/1027144/
Ставим огонёчки🔥 (или чо там на хабре?)),
зарабатываем плюсики в карму☯️
Уже почти становится традицией — третью весну подряд у меня выходит статья на Хабре
На этот раз я в текст облёк свой доклад про будущее ИТ, о котором уже писал здесь..
Повторюсь, что в этот раз я решил сознательно чуть отойти от привычного сугубо практического формата.
Если раньше я в основном писал про вполне прикладные вещи (гранулярность микросервисов, проектирование отказоустойчивости, покрытие архитектуры тестами, каскадное снижение связанности) — то здесь попробовал замахнуться на горизонт пошире:
- что вообще происходит с ИТ,
- что меняется из-за ИИ,
- зачем в новом мире по-прежнему нужна архитектура,
- и что со всем этим делать разработчику уже сейчас.
Ключевая мысль для меня такая: человеческая ценность всё меньше в самом написании кода и всё больше — в борьбе со сложностью, в проектировании, в постановке задач, в выборе ограничений и в проверке результата.
То есть не “меньше инженерии”, а скорее инженерия следующего уровня.
В общем, статья (как и доклад) местами провокационная :)
Там и про возможный уход языков программирования в роль промежуточного костыля, и про архитектуру как способ укрощения сложности, и про то, почему разработчик всё больше становится чем-то средним между архитектором, аналитиком и тимлидом ИИ-агентов.
https://habr.com/ru/articles/1027144/
Ставим огонёчки
зарабатываем плюсики в карму
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥14❤3👍2🐳1👻1
В этом году я снова в программном комитете Codefest — и помимо привычных дел с архитектурным/Future/бэкенд треками в этот раз мне выпало участвовать ещё и в самих дебатах в качестве одного из спикеров. Тема дебатов прямо в десятку моих недавних провокаций:
«Есть ли будущее у языков программирования в том виде, в котором мы их знаем и привыкли видеть?»
Формат для конференции свежий: прямо на сцене нас поделят на две команды — За и Против — и попросят аргументировать каждую позицию. Зал сможет подключаться вопросами, а в конце каждый спикер раскроет, на чьей стороне он на самом деле
Свою настоящую позицию я в канале уже размашисто проговаривал (https://tg-me.sbs/rsa_enc/382), коротко напомню
Код — это костыль. Языки придумали не потому, что они нужны машине, а потому что они нужны человеку. Python, Java, C#, SQL — это интерфейсы для нашего белкового мозга, чтобы хоть как-то упаковать сложность. Машине всё это не нужно. Ей не нужен Python. Ей не нужен C++. Ей вообще не нужен язык как таковой
Сейчас LLM получает задачу на человеческом языке, обрабатывает её в своей внутренней математике — векторах, коэффициентах, абстрактных представлениях — и только ради нас переводит результат обратно в «человеческий» Python:
смотри, узнаёшь?
Это вынужденный переходный этап — обучили её на наших же языках программирования и накопленной человечеством кодовой базе. Ключевое здесь — человечеством.
Тут полная аналогия с шахматами: пока AlphaGo училась на миллионах человеческих партий — была сильнейшей в своём классе. А когда AlphaZero освободили от всего человеческого опыта — она разнесла AlphaGo в пух и прах. Стереотипы, накопленные веками, начали мешать, а не помогать.
Так и с программированием: переход «задача → Python → машинный код» рано или поздно превратится в «задача → внутренний язык модели → машинный код». Без посредников и лишнего синтаксиса. И это отличная новость — потому что вместе с языками уходит и рутина, а человеку остаются по-настоящему человеческие задачи: постановка целей, поиск решений, творчество и ответственность
Чуть подробнее эти и смежные идеи — про сдвиг архитектора на уровень выше, про границы применимости ИИ, про средовой подход — в моей свежей статье на Хабре (постом выше).
Какую сторону мне выпадет защищать на сцене — За или Против — узнаем уже в Новосибирске
И пару слов про сам Codefest, раз уж всё равно пить клюковку
Конференция пройдёт 30—31 мая в Новосибирске уже в 16-й раз. Мы собрали 15 треков, заметно прибавили практики на мастер-классах, добавили новые форматы — те самые дебаты и разборошные, где можно не только слушать, но и участвовать. Ну и квартирники с неформальными дискуссиями на горячие темы — святое
Программа получилась такая, что сам бы пошёл слушать, но придётся спорить: https://16.codefest.ru/lecture/3558
Программа: https://16.codefest.ru/program
Регистрация: https://16.codefest.ru/reg
Прилетайте — будет жарко
Ну и приходите спорить со мной на дебатах: планирую разнести оппонентов в пух и прах, как AlphaZero — AlphaGo
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4❤🔥2🔥2❤1
Media is too big
VIEW IN TELEGRAM
Встречайте AACT 2.0 — большое обновление моего OpenSource-репозитория с инструментами для работы с архитектурой as Code!
Сегодня замержили большой PR #17: https://github.com/Byndyusoft/aact/pull/17🐱
Только зацените: +16871 | -6444 🟩🟩🟩⬜️⬜️
Когда я впервые выкладывал aact, это был код и примеры к идее: раз архитектура у нас «as Code», почему бы не покрыть её тестами? Потом появились автогенерация, roadmap, справочник принципов и паттернов...
А теперь репозиторий сделал следующий большой шаг: aact превращается из набора примеров в полноценный инструмент — CLI + npm-пакет для проверки, анализа, генерации и частичного автоисправления архитектуры.
Команды CLI:
Что умеет:
🔘 поддержка PlantUML и Structurizr
🔘 набор проверок на соответствие принципам и паттернам проектирования: ACL, acyclic dependencies, API Gateway, CRUD-сервисы, database per service, cohesion > coupling, stable dependencies, common reuse principle
🔘 запуск анализатора для подсчета архитектурных метрик и проверки принципа каскадного снижения связанности
Приятный бонус: часть нарушений теперь можно не только найти, но и автоматически поправить. Причём это не просто «заменить строку»: учитываются границы контекстов, соглашения по именованию (snake_case, camelCase, kebab-case), а правки пишутся обратно в PlantUML или Structurizr DSL.
Масштаб обновления: 77 коммитов, 139 файлов, 267 тестов. Огромное спасибо Сергею Волчкову @chs237 за такой вклад 🙌
Для меня это ещё один важный шаг к той самой идее: архитектурные договорённости должны жить не только вголовах, слайдах и Confluence контекстном окне 😆 , а проверяться в процессе разработки и ловиться ещё на этапе PR.
Как, я думаю, заметно — не удержался — и записал небольшое видео по использованию aact через консоль )📱 🤪
Репозиторий: https://github.com/Byndyusoft/aact
PR: https://github.com/Byndyusoft/aact/pull/17
Как и всегда — рад вашим⭐️ на 🐱 , вопросам, Issues и PullRequest'ам. И самое ценное — очень буду признателен за пожелания по дальнейшим фичам и развитию инструментов в целом — кому чего не хватает, и чего хочется? ✍️
Пишите!
Сегодня замержили большой PR #17: https://github.com/Byndyusoft/aact/pull/17
Только зацените: +16871 | -6444 🟩🟩🟩⬜️⬜️
Когда я впервые выкладывал aact, это был код и примеры к идее: раз архитектура у нас «as Code», почему бы не покрыть её тестами? Потом появились автогенерация, roadmap, справочник принципов и паттернов...
А теперь репозиторий сделал следующий большой шаг: aact превращается из набора примеров в полноценный инструмент — CLI + npm-пакет для проверки, анализа, генерации и частичного автоисправления архитектуры.
Команды CLI:
npx aact init
npx aact check
npx aact check --fix
npx aact analyze
npx aact generate
Что умеет:
Приятный бонус: часть нарушений теперь можно не только найти, но и автоматически поправить. Причём это не просто «заменить строку»: учитываются границы контекстов, соглашения по именованию (snake_case, camelCase, kebab-case), а правки пишутся обратно в PlantUML или Structurizr DSL.
Масштаб обновления: 77 коммитов, 139 файлов, 267 тестов. Огромное спасибо Сергею Волчкову @chs237 за такой вклад 🙌
Для меня это ещё один важный шаг к той самой идее: архитектурные договорённости должны жить не только в
Как, я думаю, заметно — не удержался — и записал небольшое видео по использованию aact через консоль )
Репозиторий: https://github.com/Byndyusoft/aact
PR: https://github.com/Byndyusoft/aact/pull/17
Как и всегда — рад вашим
Пишите!
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥21👍7❤3👏2😁1
Media is too big
VIEW IN TELEGRAM
На дне открытых дверей ИТМО кратко рассказал про свой курс по проектированию микросервисной архитектуры (https://microservices.itmo.ru/)
Кратко, конечно, получилось условно — потому что курс я веду уже который год, и каждый год он немного мутирует🙂
Начиналось всё с 7 теоретических лекций, из которых приходилось что-то выкидывать, чтобы заменять на новое, более полезное.. И сейчас их уже 10, и я всё чаще думаю, что нужна минимум 11-я. При этом убирать уже совсем нечего: всё случайное и устаревшее постепенно отвалилось, осталась база (которую, на мой взгляд, нельзя просто «загуглить и прочитать в паре статей») и уникальный мейнстрим, о котором стараюсь рассказывать и на конференциях.
Почему курс сейчас кажется мне ещё актуальнее, чем несколько лет назад?
Потому что с приходом ИИ код всё сильнее уходит в сторону генерации агентами. Простые решения всё чаще будут не писаться руками, а собираться, уточняться и проверяться. И тогда на первый план выходит не синтаксис, не фреймворк и даже не конкретная технология, а умение видеть систему целиком: связи, границы, потоки данных, ответственность компонентов, точки роста и будущих возможных проблем.
То есть ровно то, чем и должна заниматься ИТ-архитектура.
В курсе есть теория, воркшопы и практика.
На воркшопах я открываю чистый лист и мы вместе со слушателями проектируем систему с нуля. Я задаю вопросы, жду версии, предлагаю свою, бывает мы даже спорим.. и постепенно начинаю рисовать те самые абстрактные квадратики и стрелочки, которые потом почему-то определяют будущее продукта🙂
А практика устроена ещё интереснее: студенты курса делятся на группы по 2-4 человека, затем каждая группа выбирает один проект и ведёт его весь курс. На занятиях приносит очередную итерацию архитектуры, мы вместе её разбираем, обсуждаем, допроектируем, иногда критикуем, иногда находим удачные решения.
И главное — в разбор архитектуры конкретного проекта вникают все слушатели курса, а не только студенты группы.
На мой взгляд, одна из самых больших проблем в профессии архитектора — нехватка насмотренности. Когда ты несколько лет работаешь с одной большой системой, ты начинаешь очень хорошо понимать именно её. Но редко видишь десятки других доменных областей, решений, ошибок, компромиссов и способов думать.
А тут за один семестр слушатели курса могут посмотреть много разных архитектур, несколько раз пройти путь от идеи до схемы, а в конце — защитить своё решение и послушать защиты других. Услышать множество ответов на многочисленные «почему именно так?».
Для меня это тоже каждый раз мощная практика. За одно занятие приходится быстро вникать в разные проекты, переключать контекст, разбирать решения и объяснять, что в них работает, а где система начинает ехать не туда. Иногда немного страшно, что я не справлюсь, но когда получается — именно это меня и заряжает😅
В общем, курс полностью мой, авторский и очень практический. Всё, о чём я рассказываю, выросло из моего опыта, опыта Бындюсофт, реальных проектов, докладов, исследований и постоянных попыток понять: как проектировать сложные системы так, чтобы они не превращались в хаос.
И чем дальше развивается ИИ, тем сильнее я убеждаюсь: распределённые системы никуда не денутся.
Либо у вас микросервисы, либо много монолитов, но связанных друг с другом.
Но в любом случае — это система. И её надо уметь проектировать🧠
Полное видео дня открытых дверей:
🟥 СМОТРЕТЬ
🟦 CМОТРЕТЬ
Кратко, конечно, получилось условно — потому что курс я веду уже который год, и каждый год он немного мутирует
Начиналось всё с 7 теоретических лекций, из которых приходилось что-то выкидывать, чтобы заменять на новое, более полезное.. И сейчас их уже 10, и я всё чаще думаю, что нужна минимум 11-я. При этом убирать уже совсем нечего: всё случайное и устаревшее постепенно отвалилось, осталась база (которую, на мой взгляд, нельзя просто «загуглить и прочитать в паре статей») и уникальный мейнстрим, о котором стараюсь рассказывать и на конференциях.
Почему курс сейчас кажется мне ещё актуальнее, чем несколько лет назад?
Потому что с приходом ИИ код всё сильнее уходит в сторону генерации агентами. Простые решения всё чаще будут не писаться руками, а собираться, уточняться и проверяться. И тогда на первый план выходит не синтаксис, не фреймворк и даже не конкретная технология, а умение видеть систему целиком: связи, границы, потоки данных, ответственность компонентов, точки роста и будущих возможных проблем.
То есть ровно то, чем и должна заниматься ИТ-архитектура.
В курсе есть теория, воркшопы и практика.
На воркшопах я открываю чистый лист и мы вместе со слушателями проектируем систему с нуля. Я задаю вопросы, жду версии, предлагаю свою, бывает мы даже спорим.. и постепенно начинаю рисовать те самые абстрактные квадратики и стрелочки, которые потом почему-то определяют будущее продукта
А практика устроена ещё интереснее: студенты курса делятся на группы по 2-4 человека, затем каждая группа выбирает один проект и ведёт его весь курс. На занятиях приносит очередную итерацию архитектуры, мы вместе её разбираем, обсуждаем, допроектируем, иногда критикуем, иногда находим удачные решения.
И главное — в разбор архитектуры конкретного проекта вникают все слушатели курса, а не только студенты группы.
На мой взгляд, одна из самых больших проблем в профессии архитектора — нехватка насмотренности. Когда ты несколько лет работаешь с одной большой системой, ты начинаешь очень хорошо понимать именно её. Но редко видишь десятки других доменных областей, решений, ошибок, компромиссов и способов думать.
А тут за один семестр слушатели курса могут посмотреть много разных архитектур, несколько раз пройти путь от идеи до схемы, а в конце — защитить своё решение и послушать защиты других. Услышать множество ответов на многочисленные «почему именно так?».
Для меня это тоже каждый раз мощная практика. За одно занятие приходится быстро вникать в разные проекты, переключать контекст, разбирать решения и объяснять, что в них работает, а где система начинает ехать не туда. Иногда немного страшно, что я не справлюсь, но когда получается — именно это меня и заряжает
В общем, курс полностью мой, авторский и очень практический. Всё, о чём я рассказываю, выросло из моего опыта, опыта Бындюсофт, реальных проектов, докладов, исследований и постоянных попыток понять: как проектировать сложные системы так, чтобы они не превращались в хаос.
И чем дальше развивается ИИ, тем сильнее я убеждаюсь: распределённые системы никуда не денутся.
Либо у вас микросервисы, либо много монолитов, но связанных друг с другом.
Но в любом случае — это система. И её надо уметь проектировать
Полное видео дня открытых дверей:
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍6🥰3❤2🔥1👏1🏆1
Есть ли будущее у языков программирования в том виде, в котором мы их знаем?
(видео дебатов)
Самое забавное, что по жребию мне досталась защита позиции
«да, языки останутся примерно такими же»
Хотя моя настоящая позиция почти противоположная. Я уже писал об этом отдельный провокационный пост и статью
Но дебаты хороши тем, что заставляют честно сыграть иногда и за противоположную сторону. И аргументы пришлось приводить вполне себе настоящие:
Они обучены на нашем коде, библиотеках, паттернах, ошибках и костылях. Они пишут на Python, C# и JavaScript не потому, что это «правильные» языки, а потому что на них человечество накопило огромный слой опыта.
Текущие языки программирования — не только синтаксис. Это архив инженерной культуры. Пока LLM питается этим архивом, модель будет писать на том, на чём её учили.
Если нейронка написала код, который я не могу прочитать, то как я беру за него ответственность?
Одно дело — сгенерировать CRUD. Другое — автопилот, ракета, АЭС или любая система, где ошибка проявляется не красным логом в CI, а железом в реальном мире.
Тесты и симуляции — хорошо. Но если под капотом лежит нечитаемая лапша, которую никто не понимает, то в какой-то момент мы просто верим, что оно работает.. вера — так себе метод.
На дебатах я сформулировал это чуть грубее: будет серия катастроф, а потом мы вернёмся к Python :)
___________
В целом, я пытался высказаться, что спор не про Python, Java или очередной модный язык. Новые языки появлялись всегда и будут появляться дальше.
Вопрос, на мой взгляд, в другом: язык программирования будущего будет человеческим или нет?
Повторю свой давний тезис:
Языки программирования появились как инструмент для людей. Чтобы человек мог объяснить машине, что он хочет, и потом хотя бы примерно понять, что она делает.
Но если программировать начинает не человек, а ИИ-агент — то зачем этому агенту язык, оптимизированный под человека?
Зачем ему(ей) человекочитаемый синтаксис, красивые имена переменных и вся эта церемония, если основной потребитель слоя кодирования — уже не человек?
Вопрос из зала про XML и protobuf очень хорошо подсветил. Человекочитаемый формат удобен человеку, но не всегда эффективен для машины.
У AI тоже есть ресурс: токены, контекст, вычисления. И человекочитаемый код может оказаться таким же избыточным форматом, как XML там, где нужен компактный бинарный протокол.
Python будущего может быть не «любимым языком ИИ», а дорогой промежуточной упаковкой для нас. Чтобы мы видели знакомые слова и думали, что всё ещё контролируем процесс. Так зачем тратить лишние токены на написание кода на Python?
Хорошая аналогия — Google Translate. Когда перевод идёт через внутреннее представление модели, качество может резко вырасти. Внутренний язык не обязан быть красивым. Ему нужно быть эффективным.
Похожая история с AlphaZero: пока система училась на человеческих шахтматных партиях, она наследовала и человеческие ограничения. Когда её отпустили от этого слоя, произошёл скачок.
Сейчас у нас примерно так:
задача → человеческий язык → Python/Java/C# → машинный код
Но это может оказаться переходной стадией.
А может стать так:
цель → внутреннее представление модели → исполняемая система
А привычный код останется рядом. Как слой аудита, отладки и верификации. Как ассемблер, в который иногда всё ещё нужно уметь смотреть.
Это главное уточнение к старому тезису.
Я всё ещё думаю, что языки программирования в текущем виде будут уходить из центра разработки. Но дебаты хорошо подсветили, почему человекочитаемый слой ещё долго будет нужен именно нам, а не ИИ. Как слой ответственности, аудита и верификации.
Код перестаёт быть центром профессии.
А проверка, смысл, контекст и ответственность — наоборот, становятся ещё важнее.
Полное видео дебатов: https://rutube.ru/video/a857f6892d4c005ece54508387c2e396
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍9🔥1👏1
В одном из прошлых постов я писал о том, что архитектура часто строится на вере:
Предлагаю порассуждать, что в архитектуре можно считать доказательством.
Как только мы произносим слово "доказательство" применительно к архитектуре, появляется соблазн понять его слишком буквально.
В математике доказательство — это вывод из аксиом, который верен всегда и везде. В физике — воспроизводимый эксперимент. В медицине — иерархия исследований, на вершине которой двойные слепые рандомизированные испытания. И во всех трёх случаях за словом "доказано" стоит вполне определённый, формализованный процесс.
В ИТ-архитектуре такого процесса нет. И, скорее всего, не будет. Мы не можем провести рандомизированное контролируемое испытание на двух одинаковых компаниях, в одной из которых внедрили event-driven, а в другой — нет. Мы не можем повторить эксперимент с теми же командами, тем же легаси и тем же рынком. Каждая наша система — это эксперимент с выборкой из одного элемента, который к тому же нельзя перезапустить.
Из этого факта обычно делают два противоположных и одинаково вредных вывода.
1️⃣ . Раз строгое доказательство невозможно, то и говорить не о чем — архитектура была и останется делом опыта и вкуса, поэтому слушайте старших.
2️⃣ . Раз доказательство невозможно, давайте сделаем вид, что возможно, обложимся метриками на каждый чих, заведём архитектурный комитет с формальными скорингами и будем называть это data-driven architecture.
Оба вывода ошибочны, и оба по одной и той же причине: они требуют от доказательства абсолютности. А нам в инженерии нужна не абсолютность. Нам нужно нечто гораздо более скромное и гораздо более полезное: умение различать сильные и слабые аргументы, умение собирать сигналы из реальной системы и умение честно отвечать на вопрос, на чём именно держится наше решение.
Зависит от контекста
Начнём с главного свойства любого архитектурного аргумента: он контекстен (все же помнят коронную фразу архитекторов и анекдот про попугая💃 ?)
Контекстность встроена в саму ткань архитектуры — вплоть до того, что даже базовые понятия, которыми мы оцениваем "хорошесть" структуры, меняют знак даже от того. где мы проведем собственно границу нашего контекста.
Разберём на примере моего принципа каскадного снижения связанности:
Если даже фундаментальные свойства архитектуры не имеют оценки вне контекста, то конкретные архитектурные решения не имеют её тем более. "Микросервисы — это хорошо" — высказывание того же сорта, что "связи — это плохо". Оно не истинно и не ложно. Оно недоопределено́.
Поэтому когда я говорю о доказательстве в архитектуре, я всегда имею в виду конструкцию из трёх частей:
1️⃣ требования — описание назначения (целей), гипотез, поведения и свойств системы;
2️⃣ явный контекст, в котором сделаны требования;
3️⃣ способ их проверить в этом контексте.
Уберите любую из трёх частей — и доказательство развалится. Цель без контекста — это лозунг. Контекст без способа проверки — это сочинение на тему.. Способ проверки без целей и гипотез — это дашборд, на который никто не смотрит.
Из контекстности следует и ещё одна важная вещь: архитектурные доказательства устаревают. Решение, честно подтверждённое метриками три года назад, могло протухнуть вместе с контекстом: вырос масштаб, сменились команды, продукт повернул в другую сторону. В математике доказанная теорема остаётся доказанной навсегда. В архитектуре подтверждённая гипотеза остаётся подтверждённой до изменения условий. Это сама суть подхода — и именно поэтому в каждой архитектурной гипотезе мы должны прописывать явные условия пересмотра.
Я бы прям добавил такой пункт в формат ваших ADR — помимо обязательного описания контекста, в рамках которого принято решение; прописывать ещё и критерии и условия пересмотра (или устаревания) инженерного решения.
➡️ Продолжение следует.. в будущих постах продолжу тему доказательства и метрик в архитектуре
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
Предлагаю порассуждать, что в архитектуре можно считать доказательством.
Как только мы произносим слово "доказательство" применительно к архитектуре, появляется соблазн понять его слишком буквально.
В математике доказательство — это вывод из аксиом, который верен всегда и везде. В физике — воспроизводимый эксперимент. В медицине — иерархия исследований, на вершине которой двойные слепые рандомизированные испытания. И во всех трёх случаях за словом "доказано" стоит вполне определённый, формализованный процесс.
В ИТ-архитектуре такого процесса нет. И, скорее всего, не будет. Мы не можем провести рандомизированное контролируемое испытание на двух одинаковых компаниях, в одной из которых внедрили event-driven, а в другой — нет. Мы не можем повторить эксперимент с теми же командами, тем же легаси и тем же рынком. Каждая наша система — это эксперимент с выборкой из одного элемента, который к тому же нельзя перезапустить.
Из этого факта обычно делают два противоположных и одинаково вредных вывода.
Оба вывода ошибочны, и оба по одной и той же причине: они требуют от доказательства абсолютности. А нам в инженерии нужна не абсолютность. Нам нужно нечто гораздо более скромное и гораздо более полезное: умение различать сильные и слабые аргументы, умение собирать сигналы из реальной системы и умение честно отвечать на вопрос, на чём именно держится наше решение.
Зависит от контекста
Начнём с главного свойства любого архитектурного аргумента: он контекстен (все же помнят коронную фразу архитекторов и анекдот про попугая
Контекстность встроена в саму ткань архитектуры — вплоть до того, что даже базовые понятия, которыми мы оцениваем "хорошесть" структуры, меняют знак даже от того. где мы проведем собственно границу нашего контекста.
Разберём на примере моего принципа каскадного снижения связанности:
Возьмём классическую пару: связанность и прочность, coupling и cohesion. Полвека индустрия повторяет мантру: связанность — плохо, прочность — хорошо. Low coupling, high cohesion. Но ведь и то и другое — это просто связи между элементами. Почему одна связь хорошая, а другая плохая?
Ответ неожиданно прост и неожиданно неприятен для любителей абсолютных истин: связь становится связанностью или прочностью в зависимости от того, как проведены границы компонентов. Та самая связь, которая на одном уровне компонентизации была внешней связанностью (и считалась злом), после перерисовки границ оказывается внутренней прочностью (и считается добром). Сама связь при этом не изменилась ни на байт. Изменился контекст, в котором мы её оцениваем.
Если даже фундаментальные свойства архитектуры не имеют оценки вне контекста, то конкретные архитектурные решения не имеют её тем более. "Микросервисы — это хорошо" — высказывание того же сорта, что "связи — это плохо". Оно не истинно и не ложно. Оно недоопределено́.
Поэтому когда я говорю о доказательстве в архитектуре, я всегда имею в виду конструкцию из трёх частей:
Уберите любую из трёх частей — и доказательство развалится. Цель без контекста — это лозунг. Контекст без способа проверки — это сочинение на тему.. Способ проверки без целей и гипотез — это дашборд, на который никто не смотрит.
Из контекстности следует и ещё одна важная вещь: архитектурные доказательства устаревают. Решение, честно подтверждённое метриками три года назад, могло протухнуть вместе с контекстом: вырос масштаб, сменились команды, продукт повернул в другую сторону. В математике доказанная теорема остаётся доказанной навсегда. В архитектуре подтверждённая гипотеза остаётся подтверждённой до изменения условий. Это сама суть подхода — и именно поэтому в каждой архитектурной гипотезе мы должны прописывать явные условия пересмотра.
Я бы прям добавил такой пункт в формат ваших ADR — помимо обязательного описания контекста, в рамках которого принято решение; прописывать ещё и критерии и условия пересмотра (или устаревания) инженерного решения.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектура распределённых систем
В июне на конференции TechLeadConf в Питере я буду куратором и членом жюри архитектурной каты — соревнования по проектированию ИТ-архитектуры. И пока думаю, как это всё лучше организовать и по каким критериям потом оценивать решения, меня всё сильнее гложет…
1👍7🔥2❤1✍1