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/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
Сегодня (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://xn--r1a.website/rsa_enc/102
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
💬 Н. И. Касперская, президент группы компаний InfoWatch (бывший генеральный директор «Лаборатории Касперского»), на дискуссии «Архитектура цифровизации государственного управления»:
https://xn--r1a.website/khazinml/12010
💬 В. В. Шпак, заместитель министра промышленности и торговли РФ:
https://xn--r1a.website/nasledediye21/257
💡 Посмотрите видео по ссылкам — интересно, 14 минут в сумме.
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://xn--r1a.website/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.
После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).
Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
Коллеги, давайте будем честны, мы идем к глобальной войне. У нас через некоторое время отключения интернета будут нормой.
Отказ от бумаги к 2030 году — это диверсия по государственному управлению. На мой взгляд, это просто государственная измена.
https://xn--r1a.website/khazinml/12010
Эпоха, когда мы делили технологии на гражданские и военные — она закончилась.
https://xn--r1a.website/nasledediye21/257
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://xn--r1a.website/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
Давно я тут ничего не писал.. Ещё давнее — чего-то на самом деле архитектурного. Исправляюсь :)
Сегодня хочу поговорить о применении 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❤5👏4🔥2❤🔥1🐳1
Эффективно выстроить работу с ИИ-агентами можно только хотя бы примерно понимая, как они устроены (досконально как работают современные LLM не понимает никто :)).
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученноес молоком матери знание, а контекст: временно подгруженная рабочая среда (контекст, скиллы и т.д.). И она хрупкая. Что-то попало в неё, что-то нет. Что-то модель посчитала важным, что-то второстепенным. Что-то при упаковке контекста сократилось или исчезло. Поэтому модель может знать огромный пласт общих вещей и при этом забыть, о чём вы договорились десять сообщений назад.
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученное
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
1🔥13👍6❤4😁2
В июне на конференции 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
3❤8👍3🔥3