Микросервисы / распределенные системы

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

Есть кто из nic.ru, можете мне написать, помочь решить проблему?

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

А первая линия общается так, будто вообще мой аккаунт не видит. Пишет про некий антивирус (который у меня не подключен), про каких-то внешних разработчиков CMS (хотя у меня не кастомизированный хостинг от nic.ru), как-будто даже не пытаются разобраться, да даже просто посмотреть на аккаунт, а просто рандомно инструкции в меня шлют.

Тут продолжение :)

https://t.me/ru_arc/445

Давайте опытом друг с другом поделимся.

20 августа 19:00 по мск “Learning Domain-Driven Design Часть III. Применение DDD на практике (Глава 10-13) / Сергей Баранов”

В самом начале обсудим историю перевода. После разберемся как быстро определять какой паттерн из DDD соответствующих сложности предметной области и ее потребностям. Рассмотрим практику EventStorming. И обсудим самый главный вопрос - как внедрить DDD в уже существующий проект, как его поддерживать и сопровождать.

В обсуждении нам поможет невероятный гость - Сергей Баранов 🔥 Занимается развитием направления DevOps и ИТ-архитектуры, партнер ScrumTrek с 2015 года. Он является основателем и идейным вдохновителем конференции ArchDays, председателем РОО «Объединение ИТ-Архитекторов», а также признанным экспертом в практике проведения сессий Event Storming.

Подключайтесь в вторник в 19:00 к обсуждению в Zoom или к YouTube трансляции

А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Сергею ⤵️

Продолжаем набор :)

5️⃣ Call for Papers: ArchDays’24

Открыт прием заявок на выступление на конференции ArchDays’24, которая состоится 1 ноября в Москве.

Наша цель — распространение имеющихся и создание новых знаний об архитектуре программных решений.
Мы обсудим следующие темы:
🟩 Процессы проектирования.
🟩 Инструменты проектирования.
🟩 Практики проектирования.
🟩 Обучение архитектуре.
🟩 Собственная разработка.

Если вам есть чем поделиться с сообществом, заполните заявку на сайте конференции.
Ждём ваших заявок! ⬅️

Поделитесь собственным опытом применения AsyncAPI, особенно с какими сложностями столкнулись на старте и при развитии API
https://www.asyncapi.com/

ArchDays

1 ноября пройдет конференция ArchDays. Мы продолжаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

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

Подавайте темы для выступлений, приглашайте выступить знакомых.

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Репост привествуется :)

Ловите 🙂
https://www.youtube.com/watch?v=rH3u9DvOlPk

Разом всем отвечу – я не имею отношения к Сберовскому Arch.Meetup и то, что стилистика и название совпадает, - ну вот такой организаторы Arch.Meetup выбрали, стилистика ArchDays не менялась ни разу за 6 лет :)

Новый стандарт UUID (rfc9562) вступил в силу
https://datatracker.ietf.org/doc/html/rfc9562

Тут кратко об изменениях: https://habr.com/ru/articles/795909/

UPD: еще статья о стандарте (объемнее): https://habr.com/ru/articles/813229/

Вдогонку

Small batches for the win / Continuous Delivery
https://www.eferro.net/2021/01/small-batches-for-win-continuous.html

Small batches -> faster feedback
Small batches -> Customer Value sooner
Small batches -> Reduce direct cost
Small batches -> Reduce deployment risk
Small batches -> Reduce errors
Small batches -> Reduce mean time to recover
Small batches -> Improve psychological safety

Небольшая, хорошая статья:

https://jessitron.com/2021/01/18/when-costs-are-nonlinear-keep-it-small/

Краткая выдержка:

When costs increase nonlinearly with delay or batch size, larger batches are not more efficient.
1. Batch when incremental cost decreases with batch size.
2. Don’t batch when time delay increases the risk.
3. Do not batch for efficiency when costs increase nonlinearly with size.

Тут такая идея пришла, сам не пробовал, но может кто-то пробовал или попробует 🙂

Есть хорошая практика - детализация типов работы. Вроде дефект, новая фича, инцидент.

Выглядит так, что если разделить новую функциональность на
- Новая функциональность
- Доработка существующей функциональность

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

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

Такая вот мысль 🙂

Полезное про k8s

Two reasons Kubernetes is so complex
https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/

Working with Kubernetes API
https://iximiuz.com/en/series/working-with-kubernetes-api/

Kubernetes Troubleshooting – The Complete Guide
https://komodor.com/learn/kubernetes-troubleshooting-the-complete-guide/

Automating quality checks for Kubernetes YAMLs
https://dev.to/wkrzywiec/automating-quality-checks-for-kubernetes-yamls-398

When to Use Kubernetes (And When Not to)
https://cult.honeypot.io/reads/when-to-use-kubernetes-and-when-not-to/

Learn How To Create Network Policies for Kubernetes : An online editor and visualisation tool, along with a built-in tutorial, for writing Kubernetes network policies.
https://editor.networkpolicy.io/?id=Dz5waQsJQOTwDm58

Writing your first kubectl plugin with Go
https://bmuschko.com/blog/writing-your-first-kubectl-plugin/

Продолжение

Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.

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

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

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

О масштабировании

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

Производительность и масштабируемость — это связанные, но различные концепции. Производительность — это оптимизация времени ответа. Масштабируемость — это оптимизация возможности держать возрастающую нагрузку.

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

Улучшение производительности сокращает время ответа, однако поддерживаемая нагрузка может не измениться. При этом улучшение масштабируемости увеличивает возможности держать возрастающую нагрузку. Производительность каждого запроса в отдельности может не измениться.

Что сдерживает машстабирование?

Будем считать систему согласованной, если все члены системы имеют единое представление о ее состоянии. Если мы выполним один и тот же запрос на всех инстансах одного сервиса и получим один и тот же ответ, то система согласована. Точно так же, если в команде или компании, — если мы всем зададим один и тот же вопрос и получим один и тот же ответ, то команда или компания согласованы. В противном случае — система не согласована.

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

Микросервисы — это распределенные системы. Распределенные системы разделены в пространстве. Физика накладывает ограничение на скорость передачи информации (скорость света). Когда две системы разделены в пространстве, всегда требуется время для достижения консенсуса. В то время, когда информация передается от источника к потребителю, состояние источника может измениться.

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

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

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

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

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

По мере увеличения нагрузки в конечном счете система выйдет за рамки приемлемого времени выполнения.

Забираем, кому нужны fundamentals

Вот такая презентация