Выводы

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

Ниже в таблице сведены этапы процесса разработки, для каждого этапа указаны принципы согласно книге Сэма Ньюмена, «example feature» собраны на основе академической литературы.

Картинка ниже👇
(https://tttttt.me/microservices_arch/332)

Последние реализации микросервисов доводят идеи SOA до новых пределов, движимых целями быстрых, взаимозаменяемых, легко адаптируемых и легко масштабируемых компонентов. Как cloud-native архитектура, они хорошо сочетаются с основными функциональными особенностями облачных вычислений и их возможностями поставки (delivery).

Одним из следствий этой эволюции является разработка новых архитектурных паттернов и появление и применение новых стандартов. Авторы считают, что для достижения высокого уровня interoperability и compatibility важнейшим направлением является разработка и применение открытых стандартов (например – документирование RESTful APIs с помощью спецификаций Swagger/OpenAPI). Стандартизация описания сервиса и хореографический подход к взаимодействия могут обеспечить совместимость любых сервисов и улучшить их evolvability.

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

——————

Конечно, история микросервисов на этом не заканчивается, как не заканчивается и сама статья. Дальше в статье авторы анализируют разные репы на GitHub и приводят свои наблюдения. Я не увидел высокой ценности в переводе этой части (соотношение затраты/ценность), так что интересующимся предлагаю ознакомиться самостоятельно.

#msaevolutionwspub8 #msaevolutionwspub #перевод

Краткий пересказ статьи «Microservices: The Evolution and Extinction of Web Services?» за авторством Luciano Baresi и Martin Garriga 👌
Собрал все посты из телеги вместе, опубликовал.

http://agilemindset.ru/история-микросервисов/

Приятного чтения 🧠

#msaevolutionwspub9 #msaevolutionwspub #перевод

Огромный devops toolset
https://github.com/exajobs/devops-collection

Мне бы хотелось поднять острейшую тему, которую я наблюдаю в банковском секторе (пока только в нем).

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

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

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

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

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

UPD: Так суть сообщения в том, что эффективность падает при использовании распределенки и так, а без эффективных коллаборативных тулов еще сильнее и на это нельзя не обращать внимание при решении задач в complex domain

Что с этим делать?
У меня пока нет ответа. Предлагаю обсудить.

По-немногу начинаем выкладывать видео с #ArchDays’22

Как подготовиться и пройти System Design Interview
Александр Поломодов

https://youtu.be/jUbOm0B-eKQ

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

Пока не решил, буду ли менять название, какое-то время останется как есть.

Короткие вопросы и короткие ответы:

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

Q: Как формировать команду под разработку MSA?
A: Как и не под MSA. Через HeatMap например. Берем беклог, оцениваем потребность в компетенциях (не только по языкам и технологиям, но и по компонентам и системам) по каждому элементу по шкале от 0 (не нужна) до 10 (требуется фултайм), в команде должны быть компетенции для того, чтобы самостоятельно выполнить [в пределе] 100% элементов беклога.

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

Q: Возможно ли (и в каких случаях) выделать в отдельыне сервисы системные (не бизнесовые) компоненты?
A: Вполне, это такие же сервисы, как и любые другие, с точки зрения архитектуры отличий особых нет, но может отличаться подход к их развитию, – например, это может быть платформа, либо inner sourcing.

Q: Как определять контексты?
A: Границы поддоменов изначально определены самим бизнесом, а контексты мы задаем сами на этапе дизайна. Граница контекста – это граница согласованности единого языка, в рамках которой каждый термин имеет строго единственное значение за счет исключения тех деталей изначального домена, которые не имеют смысла (определения) в рамках границ заданного контекста.

Еще вопросы:
(это из разных чатов-переписок, чтоб добру не пропадать, может и еще кому-то будет полезно)

Q: В чем принципиальное отличие канарейки от А/Б тестирования?
A: Предприниматели вынуждены принимать множество решений, часто с неопределенной или неизвестной отдачей. Такими решениями могут быть: какую фичу реализовать, через какой канал вести продажи или какой тип клиентов обслуживать.

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

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

То есть A/B тестирование — это контролируемый эксперимент, в котором вы держите все переменные постоянными, кроме одной или двух для определения их влияния на целевой показатель.

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

Q: Было упоминание про нежелательность прямых запросов к БД - в чем их опасность? (речь о пользе DAO и отделении Domain от базы данных через Repository и DAO)
A: В архитектуре активно используется принцип Last Responsible Moment из Lean. Звучит он примерно так (применительно к архитектуре): принятие решения нужно откладывать до последнего момента, когда уже нельзя не принять решение. Например, тип базы данных или конкретную базу данных.
Суть здесь в том, что чем позднее в разработке мы примем важное решение, тем большим объемом информации мы будем обладать для принятия качественного решения (снижаем неопределенность).

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

Пример: вначале мы вообще можем использовать in memory базу или общепринятую в компании sql-базу. Но со временем мы поймем, что данные слабо структурированы и захотим перейти на mongo (или key-value, или graph based database). И вот тут, если весь наш код будет пропитан SQL-запросами, нам будет ООООЧЕНЬ тяжело) Надеюсь, пример понятен.

В микросервисах мы получаем выгоду от такого подхода, так как в рамках микросервиса мы и только мы полностью владеем данными и моделью данных этого микросервиса, то есть если мы перейдем на mongo, никто об этом даже не узнает, а нам стане лучше)

Здесь часто приводят контр-аргумент: DAO-слой — лишняя прослойка, генерит кучу ненужного кода, запросы не эффективные, в общем — одна беда с ними. Это действительно так, когда используется единая база данных, а моделирование начиналось с модели данных, а не модели предметной области. Тут вам и нормальные формы и связь всех со всеми через foreign keys. Разумеется, условному hibernate или NHibernate снесет голову. Но вспоминаем про CQRS, что модель записи (та самая нормализация или ES, то есть последовательность событий) и модель чтения (удобная и практичная организация данных для чтения) — это разные модели. И модель чтения в общем случае будет очень похожа на модель предметной области. То есть таблицы для чтения вполне могут быть максимально денормализованными, а значит ORM-системы будут создавать простые, быстрые и эффективные запросы.

Q: По блоку 12 пунктов. Не совсем понятно словосочетание "Одна кодовая база".
Какие аффекты получим, если скрипты, конфиг и код будут в разных репозиториях?
(речь о 12-factor)
A: Не сможем простым способом отследить последовательность изменений и удобно настроить тригггеры на сборку. В мире непрерывной поставки изменения настроек приложения или настроек среды так же являются триггером к сборке и тестированию. По итогу может быть обнаружен дефект. Удобно, посмотрев diff, увидеть, что менялась только среда или только какие-то настройки.
Плюс к этому версия сервиса - это не только версия кода, но и. версия его конфига и версия среды. То ест должна быть возможность в любой момент собрать и запустить версию, являющую комбинацией (код сервиса+настройка сервиса+настройка среды), это открывает возможности для:
X. Паритет разработки/работы приложения
Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими
VIII. Параллелизм
Масштабируйте приложение с помощью процессов
V. Сборка, релиз, выполнение
Строго разделяйте стадии сборки и выполнения

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

Вообще не про микросервисы 🤷

Q: Подскажите, как боретесь в своих командах с тем, что многие не готовятся к груммингам, не читают требования или читают их спустя рукава, не задают вопросов?
Не надо заставлять читать 🙂
Надо собираться на груминг и там в режиме диалога добиваться взаимного понимания задачи, ее особенностей и ограничений.
Аналитик или архитектор может для себя или для команды подгтовить какие-то диаграммы и описания, но лишь в том объеме, которые нужны чтобы пояснить объяснение голосом, на встрече. Это единственный эффективный способ коммуникации.

Q: В таком случае число груммингов по одной фиче растёт. Команда с первого раза не может предусмотреть негативные сценарии, декомпозировать и оценить задачи.
A: Пусть растет. Цель не в том, чтобы сократить время, а в том, чтобы понять что делать и как делать. Расти оно будет пока люди погружаются в домен, затем начнет сокращаться, а качество продолжит расти.

Q: У нас именно так и было. Потом мы решили командой от этой практики отойти и заставить всех готовиться к груммингам, чтобы у всех уже на первый итерации было понимание, что будем делать. Кто-то начал читать и задавать вопросы в комментариях к статье, но большинство забивает
A: Потому что читать требования – скучно.
Ревьюить их - и скучно и когнитивно очень напряжно.
Если хочешь, чтобы люди подготовились к грумингу – сделай презу из 2-3 слайдов и запиши видео 5-15 минут, вероятность того, что посмотрят и соответственно подготовятся вырастет кратно, возможно до 100%.

Два года я пытался связаться с гуглом. При выполнении всех условий у меня не было возможности указать собственное название для канала archdays в youtube.

Гугл так ни одно обращение не ответил, но они ввели понятие handles и вот, наконец, короткое имя:

https://www.youtube.com/@archdays

🤩

Мы скоро будем выкладывать видео с крайней ArchDays, зашел посмотреть как дела на канале, url поменять опять же и вспомнил/увидел, что записывал (в качестве эксперимента) видео про инженерную культуру и даже залил его на youtube. По большей части видео по мотивам Accelerate и DevOps Handbook, так как имхо это самая актуалочка на текущий момент 🙂

https://www.youtube.com/playlist?list=PLrVFXqPAjZsrt3T_nEn0D5JrhPLfi4dXC

Building a Distributed Job Scheduler for Microservices

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

https://medium.com/@mesutpiskin/building-a-distributed-job-scheduler-for-microservices-8b7ab2ce5f91

#design

Нотация Event Storming без элементов модели Software Design.

Это настолько жизненно, что решил репостнуть :)

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

Выбрал я значит несложную таску. Там даже оценка от разрабов «3 часа» стояла. Отличная, понятная, полезная задача. Тогда ещё подумал, что управлюсь минут за 30. Как же сильно я ошибался...

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

Начал разбираться с кодом. Тот ещё треш. Посмотрел по истории, выяснил, что сервис написал Егор, которого мы 2 года назад уволили за то, что он выдавал себя за программиста. Задача оказалась плёвая, всего три строки кода написать пришлось. Только ушло у меня на эти три строки полторы грёбаных недели по 5 часов в день.

Выкатил изменения на прод. Барабанная дробь... и ничего. Проверяю на проде — нет изменений. Лезу на сервер, в коде нужные строчки есть, а открываю в браузере — их словно нет. Ещё неделю разбираюсь с хитрым кешем. Дописываю ещё пару строк в код. Заработало! Но через час прибежали саппорты с жалобами от клиентов, что сервис сломался. Смотрю в метрики и в логи — там тишина, никаких ошибок. Позже выяснили, что логирование ошибок там никто не настраивал.

Сегодня я откатил все изменения, вернул задачу в Unstarted и купил бутылку вискаря.

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

Задеплоил на хероку и забыл.
Работает и работает, развивать не нужно.

И черт дернул хероку обновить у себя стек 😂 Сервис отвалился, а чтобы заработал мне его нужно пересобрать и передеплоить.

И сначала я еле исходники нашел (этот сервис написать было моей личной инициативой, облегчающей жизнь коллегам,- написал и забыл).
А теперь оказалось, что оно чета собираться перестало, а у хероку за это время обновилась немного админка и надо разобраться и интеграционные точки; логины/пароли/ключи локальные протухли…

В общем - сервис еще немного полежит 😴

Самого недавно предупредили, думал фигня, а нет, все больше знакомых попадается, за сегодня уже три таких сообщения пришло (на скриншоте то, что прилетело мне, я уж думал с новым годом поздравить решили 😂)
В общем - просто предупреждение.

❗️НОВЫЙ ВИД СКАМА!

Вам приходит сообщение от друга (его взломали и запустили рассылку среди всех чатов), якобы, друг, переходи по ссылке и получи БЕСПЛАТНЫЙ телеграм премиум.

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

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

КАК ОБЕЗОПАСИТЬ СЕБЯ? 👇

1. ЕСЛИ УЖЕ ПОПАЛИСЬ, ТО ПЕРЕХОДИМ В НАСТРОЙКИ —> УСТРОЙСТВА —> И ОТКЛЮЧАЕМ ВСЕ НЕИЗВЕСТНЫЕ АКТИВНЫЕ СЕАНСЫ
2. БУДЬТЕ БДИТЕЛЬНЫ И НЕ ПЕРЕХОДИТЕ НИ ПО КАКИМ ССЫЛКАМ!

👤Аутентификация клиентов и ее место в современной архитектуре

На ARCHDAYS’22 Алексей Хмельницкий, CEO
RooX,
рассказал о новом для России классе систем управления доступом — CIAM (Customer Identity and Access Management):

▪️Как цифровизация повлияла на управление доступом;
▪️Чем клиенты компании отличаются от ее сотрудников с точки зрения аутентификации;
▪️Как учесть эти отличия в архитектуре.

Смотрите запись доклада и подписывайтесь на канал👈