Архитектура распределённых систем

В архитектуре и в 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 растут как шевелящиеся графы — читать сложно, дебажить невозможно.❗️ Инциденты растут, команда не успевает, начинает винить себя, выгорает.❗️ Продукт р

На всех крупных ИТ-конференциях, где мне доводилось бывать, тема технологий двойного назначения фактически находилась под негласным запретом. До 2022 года эта тема, как правило, просто не поднималась, но теоретически подобные доклады как минимум могли быть рассмотрены.После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:🎞 https://t.me/rsa_enc/102И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.Например, 💬 Н. И. Касперская, президент группы компаний InfoWatch (бывший генеральный директор «Лаборатории Касперского»), на дискуссии «Архитектура цифровизации государственного управления»:Коллеги, давайте будем честны, мы идем к глобальной войне. У нас через некоторое время отключения интернета будут нормой.Отказ от бумаги к 2030 году — это диверсия по государственному управлению. На мой взгляд, это просто государственная измена.https://t.me/khazinml/12010💬 В. В. Шпак, заместитель министра промышленности и торговли РФ:Эпоха, когда мы делили технологии на гражданские и военные — она закончилась.https://t.me/nasledediye21/257💡 Посмотрите видео по ссылкам — интересн

📊 Статистические итоги года каналаГод получился спокойным, без гонки за частотой и хайпом — но, как мне кажется, достаточно насыщенным по смыслу.📈 ПодписчикиНа 1 января 2025 у канала был 1021 подписчик. Сейчас — 1469! СПАСИБО! Прирост +448 человек, примерно +44% за год.Без накруток, конкурсов и прочей... (активности) ради цифр — просто органический рост вокруг тем, которые мне самому кажутся важными.✏️ КонтентЗа год вышел 31 пост — в среднем 2–3 поста в месяц.Самый продуктивный месяц — март (6 постов).Самый непродуктивный — ноябрь (0 постов) — холодная осень в жизни и в канале — бывает 🙂📊 Средние показатели одного поста— 1676 просмотров— 26 реакций— 5,5 комментариевГоворят, для канала без развлекательного формата и без «кричащих» заголовков — метрики более чем живые. Особенно радуют комментарии: именно в обсуждениях обычно и рождаются новые идеи.________________________________🏆 Топ-посты года________________________________👁 Самый просматриваемый постЕсли отбросить выбросы в показателях, вызванные репостами пары постов, то наибольшее число просмотров будет у поста про.. внезапно химию! ⚗️Каскадное снижение связанности — от микросервисов к жизни, бизнесу и даже химииПост о том, что архитектурные принципы не заканчиваются на софте.Аналогии с оргструктурами, этажами офисов, атомами и молекулами — и попытка показать, что правильное соотношение связанности и прочности работает в любой сложной системе, независимо от её природы.👉 https://t.me/rsa_enc/375________________________________👍 Топ-3 по реакциям1️⃣. Языки программирования уходят в прошлоеПровокационный текст о том, что код — это интерфейс для человека, а не фундамент профессии.Про LLM, внутренние представления моделей, отказ от синтаксиса в пользу смысла — и почему это не смерть программирования, а его логичное развитие.👉 https://t.me/rsa_enc/3822️⃣. Парное программирование с ИИ и возвращение детского азартаЛичный опыт совместной разработки с ИИ: когда человеку остаются идеи и мышление, а рутину забирает

Сегодня (30 декабря) наконец закончился марафон экзаменационных защит у магистрантов по моему курсу микросервисной архитектуры — 6️⃣9️⃣ защитившихся на данный момент (часть уйдет на пересдачи уже в следующем году), и это абсолютный рекорд!Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!Что хочу сказать.. Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов 🌌И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло 😅, в голове каким-то образом сложились пазлики.. Пока сложно сформулировать, но как будто бы есть не такое большое количество типовых приёмов, из комбинации которых складываются почти все архитектуры.Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения! 🧠Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста 🙏 , давно не занимался вопросом и наверняка появилось много нового).Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи. Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализироват

Наконец-то появилась запись моего доклада про будущее 🔮✨ а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fcРанее писал пару постов, и про идеи при подготовке доклада и про мысли по его следамВсех с наступающим.. будущим! Которое уже здесь ❄️🚀

2/2⬆️начало ⬆️🤖 Дальше интереснее: «оркестратор задач»Сергей поднял более глубокий уровень:«На входе у компании — тысячи задач.Каждая требует разные комбинации отделов.Как распределять приоритеты?Как система должна выбирать оптимальный набор задач для максимального эффекта?И кто должен быть этим „центром принятия решений“?»То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.И здесь аналогия с ИТ-архитектурой уже ближе:- есть оркестратор- есть «рои исполнителей» (отделы)- задачи приходят из разных источниковНо в отличие от классического оркестратора задач из идеального мира паттернов, такой оркестратор должен уметь:- переопределять приоритеты задач- отбрасывать протухшие задачи- перераспределять ресурсы- смотреть на общую ценность задачи для компанииЭто уже сложная модель.Тут нужна либо ИИ-система по центру,либо очень сложный алгоритм.Архитектура вокруг исполнителей — это уже вторично.И вот тут ровно то место, где микросервисная аналогия снова ломается:- как правило, в ИТ-системах все процессы обязаны выполниться;- а в компании — наоборот: главное выбрать, что НЕ делать.🧩 Выводы разговора1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.Люди не функции, отдел не является сервисом по определению.2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:- знает общие приоритеты,- видит загрузку всех отделов,- оптимизирует систему как целое.4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг 😢🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений

1/2🧩 Микросервисы в оргструктуре компании: работает ли эта аналогия?Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:а можно ли применить принципы микросервисной архитектуры ПО при проектировании оргструктуры компании?Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️🎯 Контекст: компания растёт, продуктов много, отделов ~20У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.Но вопрос непростой:как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?И не умереть под завалами задач.🧠 Кажется логичным: а давайте строить оргструктуру «как микросервисы»?Сергей сформулировал метафору:- каждый отдел — это по сути «микросервис»- на входе — задачи из разных частей компании- каждый «сервис» делает своё маленькое, но важное дело- хочется, чтобы система была масштабируемая, гибкая, без «архитектурного долга»(когда отделы созданы из локальной логики, а потом не складываются в общую систему)Идея выглядит привлекательно. Но…⚠️ Проблема №1: микросервис можно масштабировать, человека — нетМоя первая реакция была простая:Обратное применение микросервисного подхода почти никто не делал — и не случайно.Микросервис можно сделать любой гранулярности, а вот сотрудника ты не возьмёшь на 20 минут в день.Человек ≠ маленький сервис на одну функцию.Под обратным применением я подразумевал вывернутый наизнанку процесс — обычно ведь мы в ИТ-системах пытаемся построить упрощенную модель мира, и под неё подстраиваем ИТ-процессы и ограничения. Но вот наоборот — не факт, что сработает.В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.В компаниях и операционных процессах

🎙 Недавно записали большое интервью — про путь в ИТ-архитекторы, про то, как меняется профессия, и почему «архитектор» сегодня — это очень разная в разных компаниях должность.Вообще, я не очень люблю интервью:слишком часто их превращают в чек-листы —«как стать архитектором»,«что должен знать архитектор»,«10 ошибок начинающего архитектора».Но в этот раз разговор получился про суть — про то, что вообще происходит с IT и как сфера будет развиваться дальше.🧱 О путиКак и у многих, мой путь начался с кода.13 лет писал, руководил командами, решал конкретные задачи.Постепенно стало интересно не “что написать”, а “как и почему именно так”.И вот тут начинается архитектура — когда перестаёшь думать строчками кода и начинаешь думать компонентами.Но, если честно, как я ранее уже писал — сегодня и это разделение уже стирается.ИИ скоро будет писать код лучше, чем большинство людей.И если раньше архитектор мог сказать: «Это будет слишком долго и дорого реализовать», то теперь ИИ спокойно скажет: «вот моя стоимость месячного тарифа, хватит пары недель работы в паре».И твоя роль смещается с реализации ещё больше в сторону понимания, что именно лучше подойдёт бизнесу и как это встроить в текущий ландшафт. 💡 Про будущее кодаВ интервью я повторил мысль, которая для меня сейчас ключевая:ИИ не “заменит” программистов — он заменит процесс написания кода. Пока мы заставляем его писать, например, на Python'е, он выглядит как человек.Но у него нет нужды писать на Python'е или любом другом языке — это ведь наши инструменты, не его.Он не мыслит синтаксисом, он мыслит математикой.В какой-то момент ИИ перестанет «писать», он будет просто проектировать исполнение задачи.И тогда архитектура снова поднимется на уровень выше — не над кодом, а над интеллектами, над экосистемами.Но об этом тоже уже было в постах выше.🧩 Про архитектуру как кодЯ показал в интервью, как у нас построен подход:вся архитектура описана как код — в Structurizr или PlantUML, всё хранится в git.Архитектурные схемы проверяютс

💡 По следам моего доклада про будущее и про истинную суть ИТ-архитектуры, родилась одна весьма спорная и провокационная мысль.. попробую её сформулировать в виде постаЕсли все твои компетенции в ИТ (да и на самом деле в любой другой профессии) устаревают — это не значит, что «мир слишком быстро меняется».Это значит, что ты не докопался до сути, корневых постулатов и методологий в своей деятельности.Значит, что скорее всего ты понимаешь профессию на уровне инструментов, а не на уровне принципов.К примеру, ты освоил конкретный свойственный лишь настоящему времени фреймворки, а не основания, не меняющиеся десятилетиями.Когда человек опирается только на инструменты — он неизбежно устаревает. Фреймворки меняются, языки обновляются, аббревиатуры становятся неактуальными быстрее, чем ты успеваешь обновить резюме.Ты учишься пользоваться кистью — вместо того чтобы учиться рисовать.. Понимаешь как, но не почему..Если твои знания обесцениваются каждый год — это не профессионализм, а временный навык специалиста.Тогда в программировании тебя можно будет заменить новой библиотечкой, моделью, агентом или плагином — потому что, грубо говоря, ты и сам в таком случае всего лишь плагин к некой системе деятельности, которую не понимаешь.Да, звучит жёстко. Но это не упрёк — настоящие компетенции не стареют!Меняются оболочки, протоколы, синтаксис — но не логика.Архитектор, который понимает принципы системного (а ещё лучше средового или даже сферного 🙂) мышления, будет актуален и через 100 лет, даже если всё программирование уйдёт в ИИ квантовое исчисление.Педагог, который понимает, как учится мозг, будет нужен и в метавселенной.Истинная архитектура, инженерия, логика построения систем (любых) не зависят от того, какой сегодня год — 1975 или 2025.А человек, который просто знает, куда кликать — исчезнет с апдейтом ИИ 6.2.7 🙂Когда говорят «всё так быстро устаревает» — спорно.Нет, не всё.Устаревает то, что было поверхностным.То, что ты изучал как инструкцию, а не как структуру и принципы

Выступил на конференции в Светлогорске с совсем нетипичным для себя мене практическим, но более прогностическим и даже философским докладом:Будущее ИТ-архитектуры и работы ИТ-архитекторовРанее при подготовке к выступление писал о том, что хочу рассказать, и вот наконец "релиз" состоялся 😎Всё прошло отлично — переполненный зал, много вопросов и в зале, и потом в коридорах.. Народ подходил и просто пожать руку, поблагодарить за доклад 😇Записи к сожалению не было — поэтому придётся теперь писать статью по теме выступления 😅Выложу комментарием пока хотя бы слайды