Микросервисы / распределенные системы
3.64K subscribers
105 photos
1 video
21 files
306 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Если есть вопросы или предложения, пишите @sergey486
Download Telegram
Микросервисы / распределенные системы
Вышел очередной, 27-й technology radar от thoughtworks Изучаем: https://www.thoughtworks.com/radar
Threat Modelling наконец дождался и попал в категорию Adopt. Считаю, что давно пора, а помещение Team Cognitive Load в категории Adopt говорит о том, что даже в рамках одной команды сопуствующая когнитивная нагрузка помимо основного домена команды стала столь сложной, что ее необходимо учитывать при дизайне команд и архитектутрных решений

Path-to-production mapping - вот тут для менять удивительно немного. Вроде как всегда так делали 🤷‍♂️ У меня даж курс есть, который с 2016 года и который весь целиком построен вокруг практики path-to-prod-mapping

Обнадеживает попадение в список observability for CI/CD pipelines. Структура ci/cd pipeline может по своей сложности превышать сложность инфраструктуры самого приложения в проде, а в ci/cd эти пайплайны используются постоянно, так что, чтобы вовремя реагировать на проблемы поставки, нужно за этим самым процессом наблюдать, а вообще-то еще и обвесить его тестами (например, если автотесты в ci стали выполнятся дольше 15 минут – тест падает).
Микросервисы / распределенные системы
Сложности Эволюционный взгляд позволяет увидеть, что нового привнесли микросервисы и какие принципы и концепции SOA все еще применимы. Сложности дизайна Несмотря на лавинообразное распространение микросервисов (microservitization), авторы указывают на недостаток…
Сложности разработки

Большинство микросервисов сегодня взаимодействуют посредством RESTful HTTP (заявление актуально на 2015 год). Взаимодействие посредством сообщение выглядит многообещающим, но имеет слабую распространенность (а это актуально и сегодня, почти 8 лет спустя). API становится своего рода контрактом, увеличивающим связанность (coupling) и нарушение которого ведет к невозможности взаимодействия сервисов друг с другом.

Таким образом можно выделить две сложности со взаимодействием сервисов:

– Одновременная поддержка нескольких версий API в процессе разработки
– Обратная совместимость и/или поддержка старых версий API в проде

В статье рекомендуется посмотреть на OpenAPI (весьма ценная рекомендация 🙂 ).

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

На 2022 год у обеих сложностей есть подходящие решения. Мы проектируем решение таким образом, чтобы в нем не было необходимости в распределенной транзакции. Обычно такая транзакция – это следствие нарушения cohesion на уровне всей системы, то есть когда неделимое целое с точки зрения целостности данных разделили на несколько «независимых» частей. Для решения сложности запроса данных можно использовать паттерны Backend For Frontend и/или CQRS.

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

[1] V. Heorhiadi, S. Rajagopalan, H. Jamjoom, M.K. Reiter, V. Sekar, Gremlin: systematic resilience testing of microservices, in 2016 IEEE 36th International Conference on Distributed
[2] M. Rahman, J. Gao, A reusable automated acceptance testing architecture for microservicesin behavior-driven development, in 2015 IEEE Symposium on Service-Oriented System

#msaevolutionwspub6 #msaevolutionwspub #перевод
Микросервисы / распределенные системы
Раз уж косвенно затронули безопасность, то здесь best practice по secure api design. Даже тезисное описание не нужно, статья без воды. https://dev.to/vaultree/designing-a-secure-api-4059
Пачка ссылок по процессной части безопасности

Роль Security Champion
https://github.com/c0rdis/security-champions-playbook/
https://docs.google.com/presentation/d/19k9NafiDJjl81sN9Ufp8NENS1-TttPyVIgilavgbzFg/edit

Проактивность в безопасности
https://cheatsheetseries.owasp.org/IndexProactiveControls.html

Приложение с уязвимостями
https://owasp.org/www-project-juice-shop/

Моделирование угроз
https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/
https://github.com/Toreon/threat-model-playbook/
https://github.com/threatspec/threatspec
https://github.com/izar/pytm
https://threagile.io
https://owaspsamm.org/model/design/threat-assessment/stream-b/

Ну и под сотню ссылок в одном месте по API Security
https://github.com/arainho/awesome-api-security

Дополнеие от @ddiozavr
https://42crunch.com/api-security-audit/
в том числе в виде плагина VSCode
Делает аудит OpenAPI спеки на предмет безопасности.
Но у них строгие правила и с первого раза можете увидеть сотню ошибок/замечаний
Микросервисы / распределенные системы
Сложности разработки Большинство микросервисов сегодня взаимодействуют посредством RESTful HTTP (заявление актуально на 2015 год). Взаимодействие посредством сообщение выглядит многообещающим, но имеет слабую распространенность (а это актуально и сегодня…
Сложности эксплуатации

Сложности эксплуатации в основном связаны с потреблением вычислительных и сетевых ресурсов.

Больше сервисов:
- Больше сред одновременно в рантайме
- Больше удаленных вызовов

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

Операционная сложность напрямую следует из распределенной и динамичной природы решения на микросервисах:
- Гибкое масштабирование в обе стороны (scale in / scale out)
- Миграция с одного хоста на другой

Можно дополнить этот список:
- Одновременное выполнение нескольких версий одного сервиса при постепенном развертывании
- Независимое друг от друга развертывание сервисов
- Внезапное падение или замедление любого сервиса в любой момент

#msaevolutionwspub7 #msaevolutionwspub #перевод
Микросервисы / распределенные системы
Сложности эксплуатации Сложности эксплуатации в основном связаны с потреблением вычислительных и сетевых ресурсов. Больше сервисов: - Больше сред одновременно в рантайме - Больше удаленных вызовов Облачные провайдеры снимают все больше и больше боли в управлении…
Выводы

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

Ниже в таблице сведены этапы процесса разработки, для каждого этапа указаны принципы согласно книге Сэма Ньюмена, «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-культура (культура сотрудничества) и так далее.

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

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

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

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
Forwarded from Event Storming (Sergey Baranov)
Нотация Event Storming без элементов модели Software Design.