Блог Сергея Баранова об ИТ-стратегии, архитектуре и организационном развитии

Признаки распределенного монолита

▪️Несколько сервисов почти всегда выпускаются одновременно
▪️Общая библиотека моделей (shared kernel) меняется вместе со всеми сервисами
▪️Сервисы читают или изменяют чужие таблицы
▪️Для теста одного сервиса требуется поднять другой сервис
▪️Один компонент невозможно запустить автономно
▪️Недоступность одного сервиса блокирует выполнение большинства операций
▪️Бизнес-операция требует согласованных изменений в нескольких БД
▪️Нельзя указать владельца данных и инвариантов
▪️Сервисы масштабируются только совместно

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

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

Распределенный монолит?

Даже удивительно, но значительно чаще, чем каждое второе решение, аудит которого проводим, – распределеный монолит. Сколько индустрия теряет, страшно представить. Это ж как нам не хватает архитектурной экспертизы (в широком смысле).

И иногда даже можно не смотреть на as-built, достаточно посмотреть на as-designed, это ведь так очевидно, на той же компонентной, по названиям даже (если исходить из смысла названий):
API Service -> Manager Service -> Data Service -> DB

Это типичный Layered Monolith:
Controller -> Manager -> Service -> Repository -> DB

То есть получили издержки на сетевые вызовы, сериализацию, ретраи, дискавери, трассировку, частичные отказы, если не считать координационных издержек, совместимости, распределенного внесения изменений, времени на деплой… и не получили главного преимущества микросервисов - автономности. Хотя называется оно в документах, конечно, «Микросервис UserService», «Микросервис Nginx».

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

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

• Независимое масштабирование
• Независимый жизненный цикл
• Отдельная команда
• Отдельный уровень безопасности
• Изоляция отказов
• Независимый темп изменения
• Отдельная модель данных
• Существенная внешняя интеграция

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

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

Аргумент железобетонный, если считать часы, а не прирост продукта.

Цифры Cockburn и Williams говорят другое: часов уходит на 15% больше, а не вдвое, дефектов на 15% меньше, кода на 20% меньше. А читаем мы код раз в десять дольше, чем пишем.

Сергей Баранов обновил статью про парное программирование, добавил раздел про AI.

Что внутри:
🧡пять стилей: штурман/водитель, строгий пейринг, пинг-понг под TDD, смешанный, mob;
🧡почему это навык, а не рассадка двух людей рядом, и три антипаттерна, которые убивают сессию;
🧡пара джун-сеньор: как не дать сеньору стать Keyboard Dominator;
🧡что делать, когда знаний не хватает одному партнёру, и что — когда обоим (иногда задача не решается вообще);
🧡AI в паре. Не «разработчик + AI», а «два разработчика + AI»: машина снимает механику и ровно поэтому поднимает цену ошибки штурмана.

17 минут чтения, в конце шесть шагов для старта.

🔗 Изучить полезное чтиво

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

«Набор ключевых решений в системе, которые избавляют разработчиков от ненужной креативности»

Да, было так, что архитектура защищала от «креативности» живых разработчиков, которые могли написать лишний/сложноподдерживаемый код.

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

Архитектурные ограничения (guardrails) теперь становятся жестким фильтром для AI-агентов. Архитектура должна явно задавать рамки, за которые AI не имеет права выходить при генерации кода. И это не так просто, как кажется на первый взгляд. Мы ведь формулируем guardrails на естественном языке, а какая проблема с естественным языком? Именно так, которую и подсвечивает DDD и которая в целом нередко проявляется в жизни – ограниченность любого языка. У нас огромный контекст в голове, мы пишем и даже не представляем, что то, что мы написали кто-то может трактовать иначе, а этот кто-то чистает и через призму наполнения своего мозга воспринимает именно иначе =)

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

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

Ну и конечно AI-агенты стали «цифровыми членами команд». Появилась новая социальная сложность гибридных команд (человек + AI).

Думаю, придется сделать несколько дополнительных веток практического обучения, в частности база по онтологиям, нейросимволичности и DDD конкретно в этом узком контексте, иначе… плывет оно и чтобы каждый раз собирать разъехавшееся решение в кучу, приходится прилагать экстра-усилия (тем, кто инженерию не практикует, разумеется) :)

ИИ уничтожит человечество?

Посмотрим через призму критического мышления на тезис в заголовке. Кто его озвучивает и неявно подпитывает? Те, кто несет колоссальные риски из-за отсутствия чистой прибыли и туманных сроков окупаемости. Нарратив об экзистенциальной угрозе – идеальныое прикрытие.

Образ сверхразума, якобы способного уничтожить человечество, превращается в удобный маркетинговый инструмент OpenAI и Anthropic для привлечения новых венчурных инвестици, а регулярные громкие инциденты и взломы (вроде HuggingFace) вполне могут оказаться спланированными инфоповодами для поддержания ажиотажа в условиях отсутствия иных инфоповодов.

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

Интересный всплыл вопрос - как отличить качественную инженерную работу от удачного промта?

Это в тему собеседований.

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

То есть как ведет себя человек с очень быстрым, но ненадежным коллегой.

Так быстро и так фундаментально, конечно, отрасль еще не перестраивалась.

Как только кто-то начинает читать вашу схему БД напрямую, ваша схема становится публичным API.

Переписывать ли канал взаимодействия?

Например, мобильное приложение, админку, личный кабинет. Это частый вопрос. Начнем с технических особенностей.

Единственная техническая причина переписывать с нуля, - это если канал - стороннее решение, кода у вас физически нет возможности провести рефакторинг.

Остальные причины - экономические, когда развивать дороже, чем переписать, и тут все намного сложнее, потому что - «а насколько дороже?», «а как посчитать?» и так далее. Ответить на эти и другие вопросы можно, тем более, что оценить можно в относительных единицах.

Экономические (внезапно) причины:
▪️Умер стек, на котором разработана текущая имплементация канала. Сложно или дорого найти компетенции под стек.
▪️Архитектура фундаментально несовместима с направлением бизнеса. Вроде, - проектировали под single tenant, а теперь работаем с multitenant, сюда же если изначально не закладывался highload и так далее. При архитектурной несовместимости постепенная замена модулей может оказаться дороже, чем полная замена с разработкой с нуля
▪️Банкротство. Это когда годовая стоимость поддержки старой системы (проценты) доходит до 40% от реалистичной оценки переписывания. Речь только о процентах, а есть еще тело долга.
▪️ Бизнес-модель поменялась настолько, что старая система решает не ту задачу, - нужен другой продукт

Это были рациональные причины. Чтобы их обсчитать и принять рациональные решения, нередко придется потрудиться, это затратно, поэтому иногда решения принимаются иррационально, например:

▪️В целом выглядит привлекательно начать с чистого листа, чтобы скинуть балласт. Часто решение принимается при смене команды или руководства, - «нам проще переписать, чем разбираться и поддерживать, что они там написали». Это скорее организационная причина.
▪️Переписать - это понятный проект с границами, который можно защитить (формально) в отличие от нередко непонятного (что печально) менеджменту постепенного рефакторинга. Это, скорее политическая причина, понятный проект выглядит просто привлекательнее по форме.

Вспомните этот пост, когда в следующий раз будете обсуждать вопрос «переписывать или нет» и задайте себе вопрос - есть ли рациональные причины писать с нуля? Если строго нет, рассмотрите альтернативы. И если альтернативы дороже, чем переписать - ну тогда погнали :)

Новый кейс в «Архитектурных этюдах»

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

https://t.me/archicases/10055/10056

Шедевр

Архитектурные конференции

Несмотря на то, что ArchDays проходит аж с 2019-го года, я все равно постоянно размышляю о том, что конференция может дать участникам.

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

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

Тимлиду или техлиду уже сложнее – сами действия сильнее растянуты во времени и отдача дольше и уже так просто не попрыгаешь между командами.

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

У CEO/CTO обычно с этим еще сложнее, поэтому они нередко и нанимают консультантов и советников с нужными компетенциями и насмотренностью, закрывая свои пробелы. И да, я считаю что то, в России не сильно развит спрос на архитектурный консалтинг - это большая проблема, огромная, особенно когда фактически не осталось аутсорсерсов вроде Люксофта, где можно было бы разносторонний опыт получить.

Возвращаемся к конференциям.

Это идеальный способ расширить горизонты восприятия, расширить кругозор. Сами выступления – это буквально концентрированный другой опыт да еще и с доступом к человеку с этим опытом, можно расспросить, обменяться контактами, наладить связь. Это как раз компенсация сужения насмотренности из-за особенностей профессии, своего рода T-shape’инг. И это нельзя заменить чатами или просто вебинаром. На конференции – ты уже физически в этом месте, твое внимание направлено и сфокусировано, вокруг тебя коллеги и опыт каждого не похож на твой опыт, это буквально 300-400-500 человек, которые совместно обладают колоссальными знаниями, колоссальными возможностями. Это как книги, которые еще не прочел и которые напоминают о том, как много еще не знаешь.

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

Увидимся на http://archdays.ru

Презентация с вебинара

Запись вебинара «Определение объектов и границ объектов NFR»

Youtube: https://www.youtube.com/watch?v=7sLMNBNCMi8
VK: https://vkvideo.ru/video-184472537_456239215

Лайк, шэр, репост :)

Напомню, сегодня в 17:00 диафильм на тему артефактов (объектов) в сценариях атрибутов качества.

База с прикладными примерами.

«Связь между экономикой и архитектурой»:
https://scrumtrek.ru/blog/technical-excellence/17194/svyaz-mezhdu-ekonomikoj-i-arhitekturoj/

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

Случайный Выготский

Сегодня играли с дочкой 5 лет в логическую игру-головоломку на ноуте. Чтобы выиграть нужно сделать несколько действий в определенной последовательности, нужно понять какие это действия. Сначала она тыкала случайно, затем я начал ее наводить - посмотри, что ты видишь? ага, а что нужно сделать? а что мешает это сделать? тогда какие действия можно совершить? а вот если такое действие сделать, что будет дальше? и я просто обалдел, когда на примерно на 10-й головоломке она уже начала сама решать рассуждая, планируя на 3-4 хода вперед. Моя маленькая гордость 🙂

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

А теперь посмотите на структуру ADR, то что мы там увидим?
• Контекст: что ты видишь?
• ASR: что нужно сделать?
• Компромиссы: что мешает?
• Рассмотренные альтернативы: какие действия возможны?
• Последствия: что будет дальше?

Это ведь по сути те же вопросы. Вот так-то. Повод задуматься.

«Цитадель»
Антуан де Сент-Экзюпери

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

Я уверен почти на 100%, что после ее прочтения никто не сможет смотреть на мир вокруг себя как раньше, что-то глубинное точно откроется.

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

Сложно подобрать слова для описания этой книги, столь она многогранна. Вот взять притчу о корабле. Суть в том, что правитель строил свое царство как корабль, – крепил, оснащал и «теперь он плывет в потоке времени, ставшем ему попытным ветром». Но тут же предостерегает от опасной иллюзии. Люди, обжившись на корабле, перестают замечать все вокруг. Они начинают думать, что «море создано для корабля»… а дальше тема раскрывается еще глубже, – что враг (сопротивление, ограничение) – это то же самое, что море для корабля. Море грозит поглотить судно, и корабль вечно сопротивляется ему, но именно это сопротивление веками формирует его корпус, делая обтекаемым и изящным. Это же буквально диалектика в чистом виде.

Спустя годы на многое в книге смотришь с позиции логики, но сама книга ровно от этого пытается предостеречь. Например, рассуждение о том, что дом невозможно осознать логикой:

«Дом для людей! Рассудку ли тебя строить? И способен ли кто-нибудь выстроить тебя как цепочку логических заключений? Ты – реальность, но ты – нереальность тоже. Ты есть, и тебя нет. Сущность твоя – разнородность, и для того, чтобы ты появился, нужно тебя сотворить. Тот, кто, желая понять сущность дома, разбирает его, видит кирпичи, черепицу, но не находит ни тишины, ни уюта, ни прохлады, которым служили кирпичные стены и черепичная крыша. Кирпичи, черепица – чему способны они научить, если распался замысел зодчего, который объединил их воедино? Камень нуждается в сердце и душе человека.»

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

#Книги

Рубрика #Книги

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

У меня с самого детства была большая библиотека и, хотя в детсве мы жили не сказать, что богато, единственное, наверное, в чем мне никогда не отказывали – это покупка книг. У меня была (и сейчас на месте) вся коллекция энциклопедий от Аванты, все книги Черепашек Ниндзя и детского детектива Черный Котенок, огромное количество произведений о мифах Древней Греции, много книг по математике и бесконечное количество художественной литературы.

Затем, когда появился первый ПК, 386, появились книги по использованию ПК и… ассемблеру =) Потому что на 386 писать на чем-то еще было весьма затруднительно. Затем появился Intel Pentium 166 и появились книги по VC 6.0, Java (Java Cookbook и подобные), Perl, параллельным вычислениям и появился Танненбаум =), это был кажется 10-11 класс.

В универе было много книг со всех концов света, – и фантастика (те же принцы Амбера, Гиперион), какие-то совсем трэш-романы, прикладные книги по теории игр (я занимался разработкой игр), по геометрии (в том числе трехмерных, помню свой первый 3dfx) и по экономике (мы тогда столько всего разрабатывали, открывали и закрывали, писали бизнес-планы, чем только не торговали через фидошку, чинили материнки и видеокарты).

А затем был период новых книг и повторного чтения старых книг, вроде Достоевского. Книг стало очень много, а выбрать все сложнее, появились сервисы с кратким содержанием вроде SmartReading, которые до сих пор выручает, если хочется именно ознакомиться и понять, стоит ли игра свеч. Сейчас уже собралась новая библиотека и она процентов на 80 - профессиональная, однако все самые значимые для себя книги я стараюсь покупать в бумаге, чтобы у них было свое место и чтобы они напоминали о себе и о идеях в них заложенных. А какие-то напоминают, сколько еще того, «что и не снилось нашим мудрецам».

Тот самый слон из притчи и твое архитектурное решение

NFR – это требование к чему именно?

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

Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию?

К каким проблемам это может привести?
▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства
▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему
▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR

Что разберем на вебинаре?
Одна из обязательных частей сценария атрибуты качества – объект, к которому относится требование.

На вебинаре обсудим два вопроса:
▪️Какими бывают объекты NFR?
▪️Как определить границы этих объектов?

Вебинар проведет Сергей Баранов.

🗓 8 сентября, 17:00 МСК
🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt

Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂