А вот на что наткнулся в свете разговоров и результатов опроса по кафке
https://www.youtube.com/watch?v=DYayslszfz8

Презентация с выступления

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

Это было 8 лет назад. Их почти ни у кого не было. О них почти никто не слышал. И это было единственное выступление на той конфе, в котором упоминалось слово «микросервис». Можете себе такое представить сейчас? :)

UPD: пропустил, был еще один от Евгения Агафонова из ABBYY

Пример антихрупкого решения, если его вокруг обвязать практиками Chaos Engineering.

Было и такое выступление на первом ArchDays

Путь в хаос или как мы строили Chaos Engineering в банке
Дмитрий Якубовский и Максим Козлов

https://www.youtube.com/watch?v=PVufzlkhRcI

Доклад расскажет о том, как мы на реальном проекте погрузились в мир Chaos Engineering (CE), ощутили всю боль мониторинга, узнали о психологии инженеров и как вставляли "напильники в серверы". Мы поговорим о преимуществах Chaos Engineering и без чего он не получится, расскажем, почему он отличается от нагрузочного тестирования и поделимся опытом организации экспертизы в компании. Цель доклада — рассказать о том, с какими проблемами и их решениями мы столкнулись при проведении "атак" на реальном проекте, сравним инструменты и их автоматизацию для проведения этих "атак". Это живой опыт, который мы проходим до сих пор.

Привет!

Для канала microservices может быть интересен цикл статей про UI-композицию как last mile problem микросервисов.

https://www.jimmybogard.com/composite-uis-for-microservices-a-primer/

То же самое в форме доклада:
https://www.youtube.com/watch?v=gjtFGx0yX5M

Ностальгия по 2017-у году, когда еще все было очно :)

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

PS: А рисую я по-прежнему так себе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжение

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

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

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

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

Полезное про 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/

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

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

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

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

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

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