#вопросыиответы
Вопрос. Есть вариант взаимодействия двух ИС по api, а есть через брокер (кролик, кафка и т.д). В чем принципиальные отличия? Как я понимаю, в первом случае в одной ИС (например на бэкенде МП) нужно написать какой-то контроллер, отвечающий за определенный сервис. А в случае с брокером как? По идее должно быть примерно тоже самое. А если так, то в чем смысл вообще от брокера?

Ответ
основное отличие - синхронное или асинхронное взаимодействие. Когда по API - ты метод вызвал и сидишь, ждешь ответа. А через брокер - ты сообщение отправил и пошел дальше. Разница примерно как общение по телефону или через мессенджер :)
смысл брокера в том, что, например, если связь прервана, то ты до собеседника не доорешься, твой вызов потерян и ты должен сам думать о том, а не надо ли перезвонить/вызвать еще раз, когда это делать и т.п. А с брокером - ты сообщение туда закинул - и свободен. Брокер берет на себя задачу доставки сообщения до адресата, когда он снова будет "в сети"

К вопросу о моделировании баз данных в Archimate
#archimate #database

Что такое нагрузочное тестирование и зачем оно проводится?
Столкнулся с тем, что у многих есть сложности с ответом на простой вопрос - "в чем цель нагрузочного тестирования?".
Когда в ответ на этот вопрос я слышу: "Вот у нас тут есть запланированные профили, а цель тестирования - прогнать эти профили и написать отчет", то у меня начинают ныть зубы. Кроме того, часто путают и смешивают нагрузочное, стресс-тестированию и тестирование производительности.
Для чего же проводят такого рода тестирования?
Мне видится, что цели бывают, как минимум, такие:

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

2. Измерить предельно допустимую нагрузку на систему. Применяется для планирования нагрузки и, например, обоснования увеличения КТС. При таком тестировании используют профили нагрузки, аналогичные первому случаю, но нагрузку устанавливают не целевую, а плавно поднимают от минимальной до тех пор, пока показатели работы системы остаются в приемлемом диапазоне. В результате не только выявляется допустимая нагрузка, но и выявляются ограничения, которые её определяют - объем памяти, производительность системы хранения или количество процессорных ядер.

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

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

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

#performance #load #testing

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

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

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

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

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

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

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

Обсуждение рабочего кейса.
Как надежно и отказоустойчиво реализовать массовые операции над большим количеством сущностей?
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. Но вдруг оказывается, что клиент - это большая система, к которой можно подключать плагины/расширители поведения и для этого они должны реализовывать определенный интерфейс. И сразу оказывается, что владельцем контракта является вызывающая сторона, именно она определяет "правила игры", а на реализующий сервер накладываются обязательства следовать контракту...
Такая же история может возникать и с событиями. Кто, какой сервис владелец схемы события - отправитель или получатель? Неправильный вопрос. Владелец схемы - это тот сервис, который определяет логику, смысл, содержание события. Когда-то это может быть сервис-источник события, который генерирует события и ему все равно кто их обработает, потребители подстраиваются под контракт. А может быть наоборот, источник события заинтересован, чтобы его события были обработаны конкретным получателем, и он "подстраивается" под возможности/контракты получателя, посылает события в определенном получателем формате, т.е. владельцем контракта становится получатель, обработчик события.

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