Структура классов для поддержки двух версий API одновременно.

Материалы с Service-Oriented Computing 19th International Conference, ICSOC 2021 🧐

https://link.springer.com/content/pdf/10.1007%2F978-3-030-91431-8.pdf

Всех девушек поздравляю с 8 марта! 🌹

Счастья, добра, любви, мира, крепких связей и надежных людей рядом! 🌟🌻☀️

Пару лет назад составил себе шпаргалку по VUCA и BANI.

VUCA - модель описания происходящего для принятия решений (sense-making framework), появившаяся в 1987.

Несколько лет назад была предложена новая модель описания – BANI. Она описывает ситуации, в которых условия не просто нестабильны, – они хаотичны. В которых результаты не просто трудно предвидеть, они совершенно непредсказуемы. Или, если использовать язык этих фреймворков, ситуации, когда то, что происходит, не просто двусмысленно (не определено; ambiguous), оно непостижимо.

Делюсь заметками. Считаю, что VUCA актуальна, а BANI рассматриваю как гипотезу.

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

Вообще, Крис Ричардсон назвал VUCA одним из трендов, которые привели к появлению микросервисов: https://chrisrichardson.net/post/microservices/2020/02/18/why-microservices-part-1.html

Компании сегодня должны быть гораздо более гибкими и внедрять инновации гораздо быстрее. А поскольку инновационные продукты и услуги основаны на программном обеспечении, IT должны выпускать ПО гораздо быстрее, чаще и надежнее.

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

Микросервисы+DevOps нам все это дают.

Подробно про дебаг ошибок, связанныз с SSL-сертификатами.

https://www.netmeister.org/blog/debugging-certificate-errors.html

В open source решениях находят все больше политической малвари. По ссылке – пополняемый список.
Рекомендуется отключить обновления apt, rpm, brew, npm и так далее для latest версий.

https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview

ECommerce Microservices is a fictional eCommerce, based on different software architecture and technologies like Microservices Architecture, Vertical Slice Architecture, CQRS pattern, Domain Driven Design, Event Driven Architecture, Inbox and Outbox Pattern and using Postgres for write side and MongoDb for read side and etc.

https://github.com/mehdihadeli/e-commerce-microservices

Гипотезу Данбара про 150 контактов опровергли.

https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158

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

Почему это важно?

В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.

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

В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.

Про метрики

«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»

Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.

ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.

Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:

— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.

И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!

Свеженький гайд по безе подъехал

Казалось бы, причем тут микросервисы. Но если прочитать внимательно определение, сформулированное Мартином Фаулером в 2014-м году (https://tttttt.me/microservices_arch/87) удивительным образом, практически один-в-один повторяет принципы построения архитектуры Amazon, изложенные Безосом в 2002-м. И неспроста в каждой третьей статье про микросервисы в пример приводят именно Amazon.

Давно не писал в канал, не мог найти времени, а все от того, что параллельно работаем над такими вещами, как:
- референс-архитектуры, в том числе микросервисные, в том числе ддд-compliant (детали тут: https://tttttt.me/emacsway_log/888)
- возрождение архитектурных ката, попробуем перезапустить с @Kirill_vet
- российская сертификация/база знаний в области разработки и проектирования (от сообщества для сообщества). Понятно, что нет такого понятия, как «российская специфика», но есть определенный базис, который нужен и хорошо, если мы сможем его давать внутри страны 👍получится - хорошо, не получится - чему-то научимся :)
- ddd проникает во все большее число компаний, растет интерес к применению ddd для отображения в орг структуру. Чему я несказанно рад, потому что при проектировании микросервисов так или иначе всегда строили модель предметной области, а вот предложение перенести эту модель в орг структуру и бизнес-архитектуру принималось через раз (где принималось, те понимают о чем я 😉). Готовлю выступление «оргдизайн через ddd». Кстати, это буквально воплощение закона Конвея.
- со дня на день стартует подготовка к archdays. Оффлайн🤞, наверное все же с онлайном, ибо странно не использовать этот канал совсем. Уже есть заявки, ждем еще 👀

Пошла жара вокруг ДДД. Имхо когда мы говорим о какой-то практике, нужно четко разделять:
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение

Поясню на примере ДДД.

Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).

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

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

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

Буду рад обсудить в коментах.

А вы когда собеседуете разработчиков или архитекторов на продукты/проекты, построенные по принципу распределенной системы/микросервисного решения, вы какие вопросы на собеседовании задаете?

Или какие вопросы задавали вам, тем, кто проходил собеседования?

Думаю это многим может помочь составить траекторию обучения с учетом реальной (не гипотетической) потребности реальных проектов и продуктов.

Ольга пишет диссер на тему самоактуализации в сфере IT, попросила помочь, если кому интересно можете пройти тест.
👇

Приглашаю пройти участие в исследовании в сфере самореализации у IT-специалистов.

✅ по его результатам вы сможете узнать о том, насколько в вас развиты: гибкость, креативность, синергия и другие важные качества для реализации себя в IT сфере.

Опрос анонимный, состоит из небольшой анкеты и 2 тестов.
Займёт примерно 20 минут.

https://docs.google.com/forms/d/e/1FAIpQLSdWL8HklTaEr02iWzl_YclfexJjiEmvpuGEz5tz9KzLAmFVSw/viewform?usp=sf_link

Если будут вопросы по ходу тестирования - задай их мне, я подскажу, отвечу (@OlgaEgelskaya)
Благодарю за уделенное время!

Мы решили объединить усилия в новом коллективном телеграм-канале, посвященном вопросам ИТ-архитектуры и управления процессами разработки.

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

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

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

Канал самоуправляется консенсусом коллегии из четырех человек: @sergey486 , @GKruglov , @elukianov и @emacsway . Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).

Для обсуждений создан чат: https://tttttt.me/ru_arc_chat

Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.

27-го выступаю на DotNext (очно), кто идет?)

https://dotnext.ru/talks/1d81350f83a040519d454f92a5164ad8/