В 19:00 Иван Волынкин (OneCell) расскажет как предоставить команде возможность работать на разных dev окружениях с разными ветками и всегда знать, где что задеплоено.

Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t-M?feature=shared

Ваня пилит достаточно классный и удобный open source инструмент: https://github.com/jonasasx/envrouter 🙂

В видео Ваня показал envrouter в действии, демка пока даже доступна публично https://demo.envrouter.ru (как я понял 1-2 дня будет доступна)

Кому интересно попробовать или поконтрибьютить, чат проекта:
https://tttttt.me/envrouter_ru

♻️ Виды потерь, через призму которых можно посмотреть и на процессы, относящиеся к работе с архитектурой

Неэффективная верификация
Неэффективное тестирование, прототипирование, подтверждение; например — поддержка тестов стоит дороже, чем тем риски, которые они митигируют

Плохая координация
Плохое планирование, некачественное расписание, приоритизация, не синхронизированный процесс; например: работа выполняется последовательно в то время как может выполняться параллельно

Переключение между задачами
Прерывания, требующие изменения направления движения /мышления; например: встречу могут прерывать выполнение других задач

Ограничение возможностей и выгорание
Прерывание выполнения работы из-за недоступности ресурсов или превышения возможностей; например: слишком большое количество одновременно выполняемых проектов может привести к выгоранию сотрудников

Недостаток в требуемых компетенциях
Недостаток навыков или знаний, требуемых для выполнения задачи; например: неэффективное использование IT-инструментов из-за недостаточных навыков

Нечеткие цели, видение
Разобщенные цели и видение в отношении друг с другом, например, в требованиях; например: сотрудники двигаются в разном направлении, что снижает эффективность

Перегрузка информацией
Большие размеры партий работы (batch size), распространение и хранение ненужной информации; например: слишком большое количество информации усложняет процесс поиска релевантной информации

Нечеткие ответственности
Нечеткие ожидания в отношении производительности и организационных ролей; например: наложение компетенций и ролей

Недостаточные коммуникации
Коммуникации требуют значительного времени и усилий, при этом не добавляя ценности; например: недостаточная коммуникация ведет к исправлению неверной выполненной работы (rework)

Множественная интерпретация информации
Форма представления информации ведет к возможности множественной интерпретации; пример: отсутствие стандарта документирования

Доступность информации
Невозможность получить доступ к информации в тот момент, когда она требуется;

Недоутилизация
Использование навыков и компетенций не самым эффективным способом

Оверинжинирнг
Добавление фич, которые не добавляют ценности клиенту; пример: возросшая стоимость разработки и поддержки как результат избыточных требований

Ненужное преобразование данных
Перевод данных из одного формата в другой из-за использования неподходящих инструментов и недостатка в стандартизации; пример: переформатирование или повторный ввод данных

Недостаток в распространении знаний
Отсутствие обмена информацией, экспертизой и навыками; пример: старт новых проект не использует опыт, полученный при старте прошлых проектов

Обработка ошибочной информации
Обработка информации, основанной на правильных потребностях, но потребности не полностью удовлетворены; пример: при обработке информации не выявлена ее дефектность, что влияет на другие процессы

Изменение требований
Внутреннее или внешнее изменение требований; пример: изменения могут привести к rework, особенно если они произошли в конце процесса

Барьеры в кооперации
Нежелания взаимодействия; пример: недостаточное владение ведет к снижению мотивации

🧩 Виды прототипов в связке с архитектурой

Макет/демо
Цель – получить представление о том, как продукт должен выглядеть. Можно сделать на основе одной или нескольких историй, учитывая, что вы строите продукт основываясь на воображении, а не на действительной обратной свзязи. Люди не оценивают макет так же, как они оценивают продукт. Отсюда можно получить первые очертания NFR.

Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.

MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.

Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.

Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.

Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная:

Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?

Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.

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

В такой ситуации стоит рассмотреть вариант хранения имени и фамилии в сервисе документов, так как в описанной ситуации они относятся к модели работы с документами. При необходимости можно обновлять данные об имени и фамилии на основе события-уведомления из сервиса авторизации.

С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.

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

Ссылка на оригинальное обсуждение: https://tttttt.me/microservices_ru/26794

Нашел в архиве требования безопасности, уж не помню к какому точно проекту формулировал, еще в 2012-м году, может кому-то будет полезно.

Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)

Почти совсем оффтопик.

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

Кто не видел – не пожалейте времени, всего 6 минут. Это шедевр 🙂

Михаил Жванецкий - Паровоз для машиниста (1986)
https://www.youtube.com/watch?v=srfeL88Oov8

Почитать под вечерний кофе

https://www.infoq.com/news/2023/10/uber-up-cloud-microservices/

И вдогонку еще статья, McAfee перешел на микросервисы и в статье есть интересные моменты об их опыте.

Оставлю один тут, как опорный, чтобы потом можно было вспомнить и найти :)

If I'm a McAfee user, what are the five things that a user can do? It shouldn't overreach. It should be complete. And you should provide all of that functionality. It's almost like taking these little, itsy, bitsy pieces of things that you can stitch together. And then you think ‘that’s a noun, what does it provide in terms of verbs that can be done to it? 
Or what can it do to other nouns in the system? So that's the domain decomposition, which is the first exercise. 

https://diginomica.com/mcafee-adopts-microservices-using-confluent-cloud-scale-its-architecture-and-services?amp

ArchDays занял столько времени, что подготовить не оказалось времени, а на пикнике не велась запись.

Так что, – надо повторить :)

К концу месяца доработаю выступление, добавив в него деталей и сделаю онлайн выступление.

Скоро анонс, а пока можете написать в комментарии к этому сообщению свои вопросы или идеи (может кто из канала был на выступлении, какие темы были не раскрыты или раскрыты не полностью).

А кто хочет погрузиться глубже, – начинайте с гугления ATAM и CBAM, проверенные годами подходы, а позже я напишу какие с ними проблемы (точнее, – не с ними, с аудируемыми решениями, но сути это не изменит).

Кто использует https://raml.org для API?
Поделитесь впечатлениями.

Собрали ролик 🙂
https://www.youtube.com/watch?v=qTjHSA_5Et0

О важности знания предметной области и однозначном определении терминов

На прошлой неделе я вошел в высший совет профсоюза ИТ-специалистов «ПРО-ИТ».

Профсоюз ПРО-ИТ - это сообщество, которое защищает интересы IT-специалистов.

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

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

Будут и совместные проекты ассоциации и профсоюза.

Официальный сайт профсоюза: https://proito.org
Если захотите вступить, укажите в форме вступления код приглашения ARCH

На видео Алексей Мариза на открытии ArchDays рассказывает о профсоюзе и том, что он может дать.

За дело :)

Поговорим немного об атрибутах качества применительно к микросервисам.

Reusability (возможность повторного использования)

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

Ключевая мысль: это не повторное использование того же микросервиса, это возможность минимальными затратами адаптировать микросервис для самостоятельного использования в другом домене. То есть reusability в микросервисах тесно связана с возможностями кастомизации.

Для обоснования достаточно посмотреть на это через призму наличия/отсутствия [блокирующих] зависимостей и координационную нагрузку при согласовании вносимых изменений.

Разумеется, необходимо различать прикладные сервисы, вроде «Уведомлений», «Идентификации» и доменно-специфичные микросервисы.

Например, сервис «Уведомлений» может использоваться множеством других сервисов, но при этом ничего не будет знать о доменной специфике сервисов, использующих его. Но представим, что наш сервис уведомлений изначально был разработан в домене «Кредитования» под собственные задачи. Он знает, что такое «Уведомление о просроченном платеже», что такое «Уведомение о следующем платеже». И вот мы решили его заиспользовать еще и для домена страхования, дополнив событиями «Уведомение о страховом случае», «Уведомлении о необходимости продлить страховой контракт». Тем самым была создана сильная зависимость между доменами Страхования и Кредитования и теперь изменения, вносимые одним из доменов в сервис «Уведомлений» потребуют координаци с другим доменом. Этот сервис более не является микросервисом, так как его граница не проходит по границе бизнес-домена, он совмещает в себе ответственности двух различных доменов. Вариантов здесь может быть два:
1. Выделить наравне с доменами «Кредитование» и «Страхование» домен «Уведомления», в домен «Уведомления» войдет только специфичная для этого домена функциональность и никаких знаний о кредитовании или страховании.
2. Развернуть в домене «Страхование» собственный сервис «Уведомлений», который будет знать только об специфичных для страхования уведомлениях.

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

А вот здесь было еще про повторное использование:
https://tttttt.me/microservices_arch/171

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