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

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

Что делает в такой ситуации благовоспитанный сервис? Правильно, ждет немножко и пробует ткнуться ещё раз. Если не помогло, то и еще раз. Особо интеллигентные сервисы умеют даже варьировать время ожидания между попытками. Но все это хорошо, когда отказ внешних подсистем относительно кратковременный.

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

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

А как вы реализуете повторы при отказах?
#мысливслух

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

Обсуждение рабочего кейса.
Как надежно и отказоустойчиво реализовать массовые операции над большим количеством сущностей?
https://news.1rj.ru/str/archicases/2484/2485

Что важнее процесс архитектурной работы или артефакты, которые получаются в итоге?

Очень часто схемы, диаграммы и записи, на которые тратится уйма времени и сил в процессе архитектурной работы, оказываются невостребованными в дальнейшей работе. Значит ли это, что эти силы и время были потрачены зря?

Архитектурные инструменты сильно различаются по сложности использования. Популярные рисовалки вроде Visio, Draw.IO или Excalidraw не требуют почти никакой предварительной подготовки, бери и рисуй. Инструментарий класса "text 2 diagram" навроде PlantUML или специализированные моделеры вроде SparxEA или Archi существенно менее популярны, ведь их освоение требует немалых усилий - выучить "птичий язык" на котором описываются диаграммы PlantUML, освоить нотацию Archimate и осознать интерфейс и логику работы Sparx EA быстро не получится. Так нафига нужны эти сложные инструменты, если есть простые и понятные?

Когда-то, в эпоху расцвета автоматических пленочных камер, я учился фотографии у одного древнего и опытного фотографа. Он давал нам задание и раз в месяц мы приносили ему пачку фотографий, он показывал нам наши ошибки и давал рекомендации. Это все-таки была еще не цифра, пленка, печать и проявка стоили денег, но 2-4 пленки по 36 кадров за месяц уходили.
И вот в какой-то момент преподаватель говорит: "Слушайте, как вы умудряетесь столько снимать? Я вот за месяц отснял всего 12 кадров." Достает конвертик с фотографиями и показывает результат. Действительно, 12 кадров. Все разные, сюжетные, четкие, проработанные, лаконичные и понятные снимки. "Вы со своими автоматическими камерами" - говорит он - "щелкаете все подряд почти не глядя. А если с ручной камерой ходить, то пока посмотришь, пока наведешься, подумаешь... а надо ли вообще это снимать?"

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

Наткнулся на прикольный сервис для рисования BPMN диаграмм. https://bpmn.io/
Навскидку ничем особенно не лучше https://app.diagrams.net/, но выглядит симпатично.
Картинки получаются изящные, чистенькие и аккуратные.

Как-то довелось мне участвовать в укладке плитки в ванной. Дело с виду не очень сложное, но требует определенных навыков и сноровки. Так вот, правильной смеси для плитки нам не хватило, я метнулся в ближайший магазин и взял там мешок штукатурной смеси, предназначенной для финишной обработки стен. Эта смесь мелкодисперсная, эластичная, хорошо схватывается. В общем, область её применения шире чем только штукатурка, на такую смесь вполне можно класть плитку, если не обращать внимания на фактор цены.
Но и этот мешок мы быстро извели, пришлось опять бежать в магазин. Штукатурная смесь там к этому моменту кончилась, осталась только "универсальная". И вот с этой смесью я приобрел экзистенциальный опыт, сильно повлиявший на моё мировоззрение.

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

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

Вот пример отличной программы, которая делает одну функцию и делает её хорошо!

Печаль 😢, но в Windows до сих пор не добавили встроенную возможность закреплять окно поверх других окон!
Есть всякие менеджеры окон, типа AquaSnap, которые умеют делать много всего и в том числе закрепление поверх. Но бесплатная редакция AquaSnap отказалась работать на двух мониторах, а вот бесплатная OpenSource программка DeskPins (https://efotinis.neocities.org/deskpins/) делает только закрепление окон поверх и прекрасно делает свою работу.

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

Уже во вторник, 1 августа, стоимость участия в ARCHDAYS вырастет. Успейте приобрести билеты по сниженной цене ✅

Тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре
5. Собственная разработка

Зарегистрироваться: https://archconf.ru/the-price-is-rising

Один из самых болезненных недостатков Archi - отсутствие возможности изменить тип существующего элемента или связи. Ну ошибся я, вставил component там, где уместнее было бы сервис. Почему нельзя сменить тип квадратика с одного на другой с сохранением всех связей? зачем заставлять меня заново переносить все связи и вводить свойства?
#archi #боль

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

Открыл для себя формат yaml как отличный способ моделирования сущностей в текстовом представлении.

Раньше, когда мне нужно было сделать набросок объектной модели, прикинуть, какие сущности возникают в системе, какие у них могут быть атрибуты и т.п., то я либо писал какой-то псевдокод на c#/java/kotlin или чертил UML подобные диаграммки в draw.io или plantuml, А тут попробовал делать наброски в yaml и мне неожиданно понравилось. Удобный редактор VSCode добавляет интерактивности - перестановка строк, автоформатирование, сворачивание/разворачивание по уровням, подсветка комментариев и т.п. делают работу с наброском/моделькой простой и приятной. Минимум служебной информации (читай - информационного шума), концентрация полезной информации на пиксел экрана прямо запредельная.

Короче, если не пробовали - рекомендую.
#yaml #vscode #моделирование

Вот все вокруг говорят - DDD, ограниченные контексты... распиливают монолиты на микросервисы, изолируют и разделяют код по микросервисам...
А я вот все думаю: а к чему, к какому контексту (= сервису) относятся контракты по взаимодействию между сервисами? Кто "владелец" API, модели событий или graphQL схемы при взаимодействии сервисов между собой?
Вот, к примеру, есть два сервиса, один вызывает другой по ресту. И вроде бы отсюда следует, что тот, кто предоставляет API, является владельцем, поставщиком контракта, а вызывающая сторона - это клиент, он подстраивается под API. Но вдруг оказывается, что клиент - это большая система, к которой можно подключать плагины/расширители поведения и для этого они должны реализовывать определенный интерфейс. И сразу оказывается, что владельцем контракта является вызывающая сторона, именно она определяет "правила игры", а на реализующий сервер накладываются обязательства следовать контракту...
Такая же история может возникать и с событиями. Кто, какой сервис владелец схемы события - отправитель или получатель? Неправильный вопрос. Владелец схемы - это тот сервис, который определяет логику, смысл, содержание события. Когда-то это может быть сервис-источник события, который генерирует события и ему все равно кто их обработает, потребители подстраиваются под контракт. А может быть наоборот, источник события заинтересован, чтобы его события были обработаны конкретным получателем, и он "подстраивается" под возможности/контракты получателя, посылает события в определенном получателем формате, т.е. владельцем контракта становится получатель, обработчик события.

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

Новая версия Archi заявляет новую фичу - возможность изменять типы элементов и отношений! Пошел ставить и проверять.

И правда работает! Это очень сильно упрощает жизнь.

Уже неоднократно сталкивался с тем, как тяжело дается управление процессом создания сложных систем, на которыми работает множество команд.

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

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

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

В первом случае в архитектуре отдельных подсистем, которые во власти своих команд, поначалу все хорошо. Но если связи меняются редко, то, как правило, нет простых и доступных организационных механизмов изменения отношений между подсистемами. Чтобы что-то добавить или изменить нужно пройти 7 кругов ада и 18 раундов согласований. Итог - изнутри (каждой!) команды остальное окружение воспринимается уже как что-то далекое, чужое и неподвластное. Как следствие, проблемы, которые можно было бы решить уточнением и точечными изменениями контрактов или ответственностей на границах подсистем, решаются сложными компенсациями внутри каждой подсистемы. Сложность растет на ровном месте.

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

Интересно, с чем связаны эти эффекты? Это чьи-то недоработки или закон природы? Есть ли рецепты борьбы с ними или нужно признать, что это следствие особенностей человеческой психологии и смириться?

#накипело #мысливслух