Пятничное чтиво

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

—————————————

GitHub’s Journey from Monolith to Microservices

Гитхаб появился в 2008 как рельсовый монолит, а за последние 1.5 года компания увеличила штат инженеров в 2 раза. Ситуация стала отправной точкой, что бы компания начина миграцию на сервисы. В итоге ребята получили архитектуру с Twirp, кафкой (если правильно понял), отдельным authN/authZ сервисами и self-service runtime platform для деплоя.

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

Также, подтвердился личный опыт, что scientist помогает переключать трафик на новую часть кода с меньшей тревогой (если логика не меняется). И было бы интересно подробнее почитать больше о AuthN сервисе и почему монолит ходит в этот сервис через Twirp.

—————————————

Architecting Modern Decentralized Applications

Под dApp подразумевают приложения, работающие в децентрализованной системе (например поверх смарт контрактов). Кажется, что dApp подойдут в аукционах, идентификации пользователя, играх и около биржах. К сожалению, проектирование таких систем достаточно болезненно в виду того, что надо учитывать security, usability и decentralization со своими ограничениями и особенностями. А также думать о имутабельности данных.

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

- Fully Decentralized (The Pure Dapp)
- Semi Decentralized (The common Dapp)
- Semi Decentralized (The other common Dapp)
- Semi Decentralized (Backend + Wallet)
- Centralized (Backend + Centralized Wallet)

—————————————

Building an Idempotent Event Consumer with Quarkus and Kafka

Возникающий вопрос при проектировании асинхронных систем - как сделать идемпотентность для событий. Т.е. как сделать так, чтобы отправка одного события 2+ раза, каждый раз, приводила только к одному вызову консьюмера для события. Это необходимо, чтобы избежать проблемы дублирования данных, особенно когда дело касается денег.

Текст начинается с описания ситуаций, в которых может возникнуть такая проблема, а причин три: ошибка консьюмера, ошибка message broker и ошибка сети. Дальше автор объясняет зачем нужна идемпотентность в асинхронных коммуникациях. А в качестве решения проблемы предлагает использовать логику, поверх уникального message id, таблицы со всеми message id и логики, которая проверяет сообщения на уникальность. Для большей наглядности - приводится пример основанный на Quarkus, MySQL и Kafka.

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

Федя позвал выступить на курсе о росте в следующую пятницу 13 числа и разбавить выступления СТО технической стороной развития.

В моей практике, под техническим развитием подразумевают “написал супер сложный драйвер или операционку” и с такая логика линейна. Делаешь проекты, находишь OSS, получаешь офер от компании, которой необходима компетенция или человек с доступом к OSS проекту. Мне же, хотелось уйти в проектирование систем и тут вскрылись проблемы:

1. “А что стратегически делать и куда развиваться?”. Гайдлайнов нет, карт развития тоже, приходится учиться на опыте + на разрозненных источниках информации (курсы либо о специфической теме, либо о микросервисах с одинаковым набором тем, которые ничего не говорят о стратегическом развитии);
2. Фидбэк луп длиннее, чем в коде. PoC (proof of concept) куска системы может делаться днями, а то и неделями или месяцами. Это похоже на то, что видел на НПО Салют, когда проходил там практику. Разбираешься, проектируешь, объясняешь что необходимо сделать, ждешь, получаешь фидбэк. Никакого REPL и тестов с мгновенной обратной связью;
3. Из второго пункта вытекает, что самому проектировать и реализовывать большее чем мелкий сервис - больно и долго. Поэтому появляются люди, которые реализуют спроектированное. Либо начинаешь сам и сгораешь из-за нагрузки.

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

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

PEPEGROW дает 10%, а курс начнется во вторник.

Пятничное чтиво

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

—————————————

Cell-Based Architecture and Federated Microservices
GitHub: wso2/reference-architecture

Короткая статья с рассуждениями о cell-based архитектуре, которая привлекла взгляд только потому, что последние пол года играю в факторио и в фоне думаю как концепцию сити блоков переложить на архитектуру приложений. Главное, что нашел в статье - ссылка на референс документ по теме, а также, рассуждения на тему схожести Federated Microservices и cell based подхода. Но самое интересное начинается, если открыть документ. В котором будет 5 секций: интро в абстракции, интро в юниты энтерпрайз архитектуры, обсуждение гибкости структуры, определение архитектуры и определение правил.

Сама архитектура состоит из клеток (cells), которые содержат в себе 1+ компонент и каждая клетка изолирована, как по смыслу, так и по деплойменту. При этом компоненты общаются между собой по своему протоколу, а коммуникации между клетками тоже разрешены. Т.е., как я понял, это следующая абстракция над SoA, которая группирует сервисы по бизнес признаку. Кажется, что подобный подход может работать только в больших компаниях, где отделы работают над кусками приложений. Также, хочется оставить цитатой мысль, которая понравилась: “Cell-based architecture aims to create business focused architectural constructs that can be reused at a higher level, so naturally organizing the teams and cells around business functions is essential.”. А больше информации о том, как это работает и примере системы построенной на «клеточной» архитектуре найдете в документе.

—————————————

The Lakehouse Architecture

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

Для этого, стараюсь обращать внимание на современные подходы вокруг data engineering. И сегодняшний текст о подходе, который называется The Lakehouse Architecture и смысл которого сводится к попытке взять лучшее из data lakes и data warehouses подходов. В статье найдете исторический контекст подхода, как работает и зачем нужен. И что приятно, какие у архитектуры ограничения и рассуждения о будущем.

—————————————

Building a Reactive Architecture Around Redis

В моей практике редис используют для кэширования и бэкграунд процессинга. Поэтому каждый новый способ использования базы - автоматически становится текстом для ознакомления. Сегодняшняя статья о том, как с помощью редиса можно построить reactive architecture, что в понимании автора - способ создания системы в основе которой идеи observer pattern-а.

Для этого, предлагается воспользоваться тремя особенностями редиса: pub/sub, streams и keyspace notifications (до этого не слышал о нотификациях, будет что изучить). А дальше рассказывается, как, на примере микросервисов, можно создать message broker из редиса, описывая какую из особенностей стоит использовать в каждом конкретном случае. Понравилось, что объясняется как сделать триггеры по времени (пример - отправь событие, если через N времени ничего не произошло). Спойлер - через keyspace notifications.

Пятничное чтиво

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

—————————————

Bartosz Ciechanowski

В подборке ссылок редко появляются темы не связанные с IT, но сегодня исключение, которое захватило меня на три дня. Речь идет о блоге, где автор разбирает как работают механизмы или системы. Например, по ссылке найдете объяснение работы шестеренок, камер и линз, чисел с плавающей точкой, двигателя внутреннего сгорания и других вещей. Каждая статья - лонгрид, который подробно и в деталях объясняет природу явлений. Кроме того, автор добавляет динамическое взаимодействие с вещами, о которых говорит. Так, например, для двигателя внутреннего сгорания, крутится модель двигателя и каждой из ее частей, а для шестеренок, поиграть с размерами и видами шестерен. Кратко характеризовать блог можно фразой - "vas3k блог о механизмах с динамическими примерами".

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

—————————————

Архитектура распределенной очереди в Mail.ru Cloud Solutions

Mail ru продолжает экспериментировать с  Tarantool и в сегодняшней статье описывается, как с помощью собственной базы данных инженеры сделали распределенную очередь, которая используется в cloud платформе от mail. Компания вдохновилась Simple Queue Service, а реализация амазона описывается в статье. Из интересного - архитектура сервиса, особенно часть, в которой говорится о том, как сообщения хранятся. Не хватило графиков и бенчмарков. Но если хотите сделать собственную SQS - статья поможет вдохновиться и начать.

—————————————

Give me /events, not webhooks

Относительно короткая статья, смысл которой сводится к тому, что кроме пуш стратегии в вебхуках, есть еще вариант с пуллингом. Этот вариант реализуется через эндпоинт /events, который предоставляет список событий, произошедших для пользователя. А курсор (отметка прочитанных сообщений) выбирает каждый сервис локально. Плюс такого подхода: если сервис будет в дауне, вебхуки не пропадут, а также, не приходится думать как ускорить получение события на стороне консьюмера. В качестве примера используется HTTP API от stripe.

Из интересного - в конце статьи приводится идея, что кроме пуллинга со стороны консьюмера можно использовать long-polling. Это значит, что после стандартного запроса на /events не дропаем коннекшн, а ждем новые данные в реалтайме и обновляем курсор. Если конекшен прервался (даун или редеплой) - делаем еще один запрос и продолжаем обрабатывать события с последнего прочитанного.

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

Пятничное чтиво

Сегодня только две статьи, так как ничего интересного найти не смог за неделю.

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

—————————————

Disasters I’ve seen in a microservices world

Микросервисы - сложно и больно. При этом, сервисная архитектура заставляет решать проблемы, которых нет в монолитах. И сегодняшняя статья как раз об этом. В тексте описывается шесть проблем, с которыми столкнулась компания Adevinta, когда перешла на сервисную архитектуру. Среди проблем найдете: какой размер сервисов оптимален, к чему приводят общие базы данных, стоимость, тестирование, согласованность, таймауты, ретраи и так далее. Закралось подозрение, что часть описанных проблем связана с проблемами вокруг декомпозиции сервисов.

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

Русский перевод

—————————————

Стратегии обработки ошибок: Circuit Breaker pattern

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

В тексте, упоминается четыре способа:

- параллельная отправка запросов, при которой данные, даже если один из инстансов сервиса упадет, будут полученны сервисом;
- Idempotency Key, который выполняет одну команду один раз, вне зависимости от количества вызовов;
- Retry pattern, который ретраит до победного запрос;
- Circuit Breaker pattern, который не только обрывает соединение при каком-то условии (например 50% запросов с таймаутом), но и сразу же отдает клиенту ошибку, в обход таймаутам;

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

Пятничное чтиво

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

—————————————

Letter from the editor – Increment: Mobile

Вышел новый выпуск журнала Increment. В канале упоминался журнал до этого, а выпуск апреля 2021 года - мобильная разработка и мобильные приложения. Из статей выбрал фаворитов, которыми хочу поделиться:

An Introduction to the Microapps Architecture

Подход с микросервисами вдохновил фронтенд на создание microfronted, теперь на очереди мобильная разработка. Microapps подход собирает приложение из модульных частей, часть которых можно независимо протестировать локально, запустив только необходимые модули. Из плюсов, также, отмечают скорость сборки.

Сами приложения состоят из user-facing application (координационный слой), feature модулей (что-то в духе доменов и бизнес логики в них), UI модуля, foundation/utility модулей (low-level функционал) и тувинка. Подробнее о видах модулей, челенджах и компромиссах, прочтете в конце статьи.

Feature Flags for Mobile Development

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

—————————————

Observability with RabbitMQ and microservices

Статья с описанием реализации observability для событий в rabbitMQ. Уделяется внимание четырем аспектам: events history, events reply, topology visibility и трассировки. Понравилось, как ребята сделали трассировку (спойлер: хранят id продюсера как родителя, консьюмера и trace_id одинаковый для всех событий), после чего Google Trace показывает трейс каждого из событий. Для visibility используется хак с описанием конфета транспорта, с последующей визуализацией конфигов. А для истории - редирект каждого события в системе в отдельную очередь.

—————————————

Protecting Sensitive Data in Event-Sourced Systems with Crypto Shredding

Один из популярных вопросов, которые я слышу касаемо event sourcing - как работать с sensitive данными, которые надо удалять или маркировать удаленными. Такие вопросы возникают, потому что каждое событие иммутабельно, что значит - удалить или мутировать события возможности нет. Один из способов решить такую проблему - Crypto Shredding, т.е. шифрование необходимых данных. А при требовании удалить информацию - ключ шифрования “теряется”.

Об этом статья, в которой описывается реализация Crypto Shredding в 11 шагов. Сама реализация подробно описана на C#, думаю и в других языках реализация будет похожей.

Пятничное чтиво

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

Старые записи стримов можно найти на ютубе. Хочу в ближайшее время сделать стрим с реализацией биллинга на событиях + ES. Хочется показать, как проектирую и делаю биллинги у клиентов. Если интересно или есть вопросы которые можно будет покрыть - пишите в комментарии. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

—————————————

Техники обработки отказов сервиса в микросервисных архитектурах, или Альтернативы Circuit Breaker

Две недели назад публиковал ссылку о реализации Circuit Breaker паттерна. К сожалению, это не серебряная пуля и у паттерна присутствуют ограничения и проблемы (не возможность повторно отправить сообщение, например, если тарифный план сервиса изменился в худшую сторону, уменьшение скорости работы при отказах и не возможность параллельной обработки). В случае системы, описанной автором статьи, изначальное решение с fire-and-forget заменилось на Circuit Breaker. Но в скоре Circuit Breaker тоже оказалось не достаточно. Поэтому инженеры решили переехать на очереди, что в итоге привело к симбиозу reschedule подхода с очередями и Circuit Breaker.

—————————————

Zero Trust Security Architecture Overview

Я не слышал о подходе Zero Trust Architecture. Как оказалось, философия Zero Trust - никогда не доверять и каждый раз просить подтверждать личность. В случае Zero Trust Architecture - придется использовать строгие условия повторной авторизации для каждого запроса из сети. Для большего погружения в тему - обзорная статья, из которой узнаете о плюсах подхода для бизнеса (хотелось бы еще узнать о минусах), о примерах использования Zero Trust (говорится о трех гигантах, google, microsoft, aws и IBM), а также шаги, с помощью которых можно внедрить Zero Trust.

—————————————

Navigating the 8 fallacies of distributed computing | Ably Blog: Data in Motion

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

- The network is reliable. Сеть падает и в целом, она не предсказуема.
- Latency is zero. Когда локально работаешь с сервером кажется, что система работает быстро, в продакшене оказывается, что данным нужно время чтобы дойти. С этим и прошлым пунктом встречался в реальности, когда запрос в кластере k8s “магическим” образом раз в N времени длился 2 секунды (при среднем в 100 мс) и отваливаться по тайм-ауту. Причину так и не нашли.
- Bandwidth is infinite. Пропускная способность частей системы может оказаться меньше, чем рассчитывал. С этим столкнулся, когда сервис не успевал продьюсить 4к сообщений поштучно (вместо матча) в кафку за достаточное количество времени.
- The network is secure.
- Topology doesn’t change. Это о том, что сегодня сеть может быть реализована как звезда, а завтра стать mesh. Такие переходы могут повлиять на работу системы.
- There is one administrator.
- Transport cost is zero. Это о том, что иногда забываются низкоуровневые абстракции, которые нужны для отправки данных из точки в точку. Что может влиять на финансовую стоимость.
- The network is homogeneous. Тут о том, что в распределенных системах могут быть разные устройства с разной конфигурацией, что приводит к мысли: “it’s critical to focus on interoperability, thus ensuring that all these components can “talk” to each other, despite being different”

Пятничное чтиво

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

—————————————

Reactive in practice, Unit 1: Event storming the stock trader domain

В канале уже упоминалась статья о декомпозиции монолита с помощью event storming. Event storming - способ обнаружения компонентов системы (на ряду с actor/action и workflow approaches). Пришла из ДДД и специфика подхода - упор на команды и события, как способ вызова одной команды из другой.

Пока готовлюсь ко второму потоку курса нашел сегодняшнюю ссылку. Это первый урок из серии статей о создании event-driven системы, в котором рассказывается как использовать ES в определении доменов системы, а также команд и событий. Подробно описывается сам подход, части из которых состоит и на примере stock trader системы, состоящей из трех доменов, раскладываются команды и события.

—————————————

5 Database technologies used by 2000 Wix microservices

Как можно понять из названия - в wix используется 2к сервисов, написанных на разных языках и использующие пять баз данных: MySQL, MongoDB, DynamoDB, ElasticSearch и S3. Каждая из БД решает определенную проблему, например монга используется для блога, а динамо - для чатов. В статье найдете, когда использовать базу, плюсы и минусы, а также юзкейсы компании, в которых используется каждая из баз данных.

Понравилось, что в статье описали юзкейсы компании и концовка текста, в которой описываются критерии выбора БД, а также диаграмма для принятия решения. Кажется, что если в компании больше пары баз - подход поможет выбрать нужную бд под задачу каждой команды/сервиса.

—————————————

Версионирование API или единая кодовая база для всех версий

Один из способов соблюдения эволюции API при изменении требований - придерживаться выбранного уровня совместимости для response/request схем. Если случаются ситуации, когда совместимость нельзя соблюсти, приходится вводить версионирование. Что работает не только в синхронных коммуникациях, но и в асинхронных (я рассказываю об этом у себя в курсе).

В статье рассказывается о трех способах версионирования API:
- Feature-версионирование, когда клиент запрашивает доступ к определенным фичам;
- Версионирование средствами VCS, когда версия зашивается в код и в инстанс приложения, что дорого и костыльно для web-api;
- Версионирование средствами языка, когда код приложения реализует каждую версию в отдельном контроллере (как пример);
- Версионирование Blueprints, не путать с API Blueprint. Это способ, придуманный в SuperJob, при котором конфиг с описанием версий и сущностях, по которому вызывается нужная бизнес логика.

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

Пятничное чтиво

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

—————————————

Distributed transaction patterns for microservices compared

Лонгрид о пяти способах создания транзакций в распределенных системах. Перечисленные способы:

- Modular monolith
- Two-phase commit
- Orchestration
- Choreography (два вида)
- Parallel pipelines / Listen to yourself

Для каждого из подходов дается описание, плюсы/минусы, а так же примеры использования. Для некоторых способов присутствуют вариации, что также описывается в статье. Порадовала таблица в самом конце, которая сравнивает подходы между собой не только по плюсам и минусам, но и по другим характеристикам, таким как: service runtime, datasource, point of control, execution flow, properties и implementation.

—————————————

Under Deconstruction: The State of Shopify’s Monolith

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

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

- Как и зачем выращивать Architecture Guild;
- Как создать целостную архитектуру;
- Инструменты которые помогли во время рефакторинга;
- Какие два способа инженеры нашли во время работы над декомпозицией монолита;

—————————————

Ballerina Swan Lake: 10 Compelling Language Characteristics for Cloud Native Programming

Язык создали для упрощения написания сервисов в соа, поэтому в стандартной библиотеке можно найти auth, gql, grpc и sql модули. Кажется, что основной конкурент языка - го и хотелось бы больше видеть подобных инструментов для разработчиков. Также хочется верить верить, что сегодняшняя статья поможет с мотивацией для изучения балерины.

Я слежу за языком уже года 4 и статья выше - попытка «продать» язык в хорошем смысле. В тексте N характеристик языка, которые могут заинтересовать разработчиков. Фавориты - data ориентированность языка и dsl для работы с данными, 1 в 1 похожий на sql, в частности. А также визуализация sequence диаграммы того, как работает код и transaction first подход в коде.

——— одной строкой ———

- Релиз Kafka 3.0, в которой продолжают работу над KRaft, механизмом консенсуса, который должен заменить zookeeper. Для тех, кто не любит читать - ссылка на YouTube

Запустился второй поток курса по асинхронным системам

В марте этого года решил, что будет хорошей идеей попробовать сделать курс с нуля. Поэтому, поговорив с Федей, мы сделали курс по проектированию и созданию асинхронных систем. За основы курса были взяты идеи и подходы, которые помогают мне в работе последние 4.5 года, которые были собранны в одном месте и дополнены доп материалом и примерами. За 4 недели я успел показать, как спроектировать систему (и почему проектировать надо начинать от бизнеса), а также реализовать эту систему, учтя проблемы эволюции данных в событиях. Уже к концу курса, кроме практики и теории асинхронных систем и коммуникаций, одной из главных ценностей курса оказалось обучение мышлению и как разбирать систему на части (чего сам не ожидал).

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

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

В этот раз затрону такие темы как:
- coupling и cohesion. Решил больше о coupling рассказать, так как считаю это важным в контексте курса и коммуникаций;
- transaction outbox / transaction log tailing паттерны;
- личный опыт, в этот раз оказалось еще больше примеров из практики, выделил урок для примеров;
- попсовые паттерны в виде CQRS, ES, SAGA и как паттерны могут в EDA использоваться (и почему они не являются обязательными);
- больше внимания постарался уделить мышлению и обоснованию решений;
- отшлифовал то, что было связано с проектированием, чтобы сложилась картинка и было понимание зачем нужен каждый из шагов;
- захотелось сделать дз из которого получится "начальный" уровень, который в конце можно будет сравнить с конечным результатом. Кажется, что это поможет не только закончить курс, но и сравнить себя до и после;

Курс стартует 21 октября, записаться можно тут, а если хотите спасти попугов - PARROT10 даст скидку в 10%.

Пятничное чтиво

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

—————————————

How percentile approximation works (and why it’s more useful than averages)

Перцентиль говорит, что все значения до определенного % меньше или равны какой-то величине. Например “80-й перцентиль читателей прочтут текст за 10 минут” будет означать, что 80% читателей прочтут текст за 10 или меньше минут, а 20% прочтут за 11+ минут. Эта концепция помогает анализировать “основную” массу данных, выкинув отклонения. 

Примером может служить HTTP response time: банковское приложение хочет чтобы average response time был не больше 0.5 секунд, в противном случае - отправляется алерт. Все хорошо, но придет клиент, который захочет загрузить все транзакции в банке за 10 лет, что потребует 10+ секунд. Из-за этого average response time подскакивает до секунды. Вроде ничего страшного не случилось, но инженеры бегут чинить “проблему”. Вместо этого, можно указать максимальное значение времени ответа ответа для N% запросов и таким образом дергать людей, только когда 90+% пользователей системы столкнулись с увеличением ответа.

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

—————————————

Partitioning GitHub’s relational databases to handle scale

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

Для этого инженеры начали партиционировать базу данных в 2019 году и как первый шаг - virtual partitions, и для определения партишенов использовалось два инструмента: Schema domains + SQL linters (Query linter и Transaction linter). Первый помог найти границы в данных, второй - обеспечил соблюдение границ. Ну а в конце описывается, как происходил перенос данных в другой физический кластер (использовалось два подхода: Vitess и Write-cutover process). Ну а так же результаты, выводы и немного о шардировании.

—————————————

Identification of quality requirements with Quality Storming

Event storming уже упоминался в канале, сегодня пример того, как идеи могут эволюционировать.

Технические решения принимаются исходя из специфического контекста задачи, требований связанных с продуктом, а также из требований связанных с качеством software product (quality requirements). Это как раз тот случай, когда возникает “it depends on” как ответ на любой вопрос о выборе технического решения. 

При этом, сами требования качества - состоят из расплывчатых формулировок ("the system must be scalable"), а каждая группа заинтересованных в продукте лиц (разработчики, овнеры, доменные эксперты и так далее), хочет видеть свои требования. В таком случае могут возникнуть ситуации, когда требования качества поставленные доменными экспертами не могут быть соблюдены технически. Из-за этого гэпа в коммуникации возникают ситуации, когда quality requirements поверхностны и используются только для fulfill internal governance чек листов. Поэтому технические решения, принимаемые разработчиками и архитекторами, могут не отражать реальной специфики продукта.

Тут на помощь приходит Quality Storming, который придуман как решение коммуникации стейкхолдеров вокруг вопроса quality requirements. А подходы которые используются в Quality Storming, вдохновлены event storming-ом. Из статьи узнаете правила и процедуры проведения Quality Storming.

Пятничное чтиво

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

—————————————

Консистентно о Консенсусе

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

—————————————

Scalable logging for microservices

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

Реализация состоит из: кастомного лог агента (сайдкар к контейнеру с приложением), лог сервиса, который консьюмит логи от агентов и кидает в кафку, части которая консьюмит логи из кафки, применяет фильтры и отправляет данные в Google Cloud Logging. В тексте найдете подробное описание компонентов, какие проблемы обнаружились у решения и идеи улучшения.

—————————————

Microservices Patterns: Sidecar

Короткая заметка о Sidecar pattern. Паттерн позволяет создать второй контейнер, который не может существовать без основного. При этом, сайдкар контейнер может переиспользоваться для других сервисов. Дефолтный пример использования - перевести сеть в кластере на https с помощью сайдкар контейнеров, которые в контейнер приложения уже гонят http.

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

O’Reilly дают плюшку в честь выхода моей книги: бесплатный доступ в O’Reilly Online Learning на месяц.
За месяц можно почитать мою книгу, и еще кучу всего что они там выкладыют (все свои книги, addisson-wesley, manning, курсы, онлайн-треннинги, и т.д.) Промокод: LDDD21
Регистрация: https://learning.oreilly.com/get-learning/?code=LDDD21

Пятничное чтиво

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

—————————————

Real-Time Exactly-Once Ad Event Processing with Apache Flink, Kafka, and Pinot

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

Для реализации системы использовалось четыре инструмента: Apache Flink (stream processing framework), Apache Kafka, Apache Pinot (OLAP datastore), Apache Hive (data warehouse). В статье найдете хайлевел архитектуру, а также описание как система была сделана.

—————————————

RPC chains. Learn how RPC chains solve the problem…

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

Сегодняшний текст является кратким пересказом идей из 12ти летнего пейпера от microsoft (RPC Chains: Efficient Client-Server Communication in Geodistributed Systems). Основная идея лежащая в RPC chains - ускорение стандартных rpc вызовов которые проходят через сервисы (больше одного). Вместо того, чтобы вызывать каждый сервис, получать ответ и джойнить данные, авторы предлагают сделать цепочку вызовов, которая одним потоком пройдет по нужным сервисам. Для этого предлагается описывать chaining function.

А если знаете где можно найти практическую реализацию в любой экосистеме - буду рад ссылкам.

—————————————

The impossibility of exactly-once delivery

Exactly-once delivery гарантирует, что каждый консьюмер получает сообщение строго один раз. Автор текста рассуждает, что подобный вид отправки сообщений не возможен и для этого приводит два примера: эксперимент с двумя генералами, которые не знают нападать или нет, а также прямое доказательство.

В конце статьи приводится три примера, что делать в реальном мире, когда exactly-once невозможен:

- at-most-once - сообщение отправляется один раз и либо успешно обрабатывается, либо теряется;
- at-least-once - сообщение отправляется до тех пор, пока отправитель не подтвердит доставку (тут либо одно сообщение придет, либо несколько одинаковых);
- no guarantees;

Ну и как завершение, обсуждается обработка сообщений exactly-once, это либо идемпотентная обработка, либо хранить каждое обработанное сообщения и ничего не делать на повторах.

Курс начнется послезавтра (в четверг), промокод на 10% - ptichka10

Пятничное чтиво

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

—————————————

Migrating Monolithic Application to Microservices

Еще одна статья-пример миграции на сервисную архитектуру из монолита. Авторы предлагают выносить новые сервисы из монолита в пять шагов:
1. Разделение на уровне кода на изолированные компоненты с общей базой;
2. Разделение данных на 2+ базы данных (для каждого из компонентов своя бд). А также добавление “integration glue” в виде стратегии миграции данных со старой базы данных на новую;
3. Определение функционала нового сервиса, который будет использоваться вместо части кода из вынесенного модуля;
4. Добавление нового сервиса, который будет реализовывать функционал вынесенного модуля + ходить в базу из второго шага + перевод юзеров на этот сервис. Для этого предлагается использовать APIs gateway;
5. Удаление функционала, который вынесли в новый сервис, из монолита;

—————————————

An Introduction to Semantic Monitoring for Microservices

Как утверждает автор статьи, semantic monitoring - подход, сочетающий автоматическое тестирование и мониторинг, для выявления “какие бизнес требования не выполняются в системе”. Если проще - это процесс последовательного выполнения автоматических тестов на продакшен системе. А результат тестов уже отправляется в мониторинг, который отправляет нотификации, если что-то пошло не так. Подход напомнил chaos engineering но только не для инфраструктуры, а для бизнес требований.

В статье найдете подробное описание semantic monitoring, какие виды мониторинга бывают (спойлер: Availability, Performance, Transaction), а также плюсы подхода и что не стоит от него ждать. Если у вас используется что-то подобное или работали в проектах с подобными подходами - поделитесь опытом, было бы интересно послушать.

—————————————

Modelling Reactive Systems with Event Storming and Domain-Driven Design

Я уверен, что основная ценность event storming в “интеграции” с EDA из-за определения  бизнесовых событий, команд и связанности команд между собой, в отличии от использования Actor/Action или Workflow подходов.  На этот раз статья как раз о подобном симбиозе реактивных систем и event storming для определения команд, событий и доменов в системе.

В статье найдете описание event storming. Радует, что автор уделил внимание подробному описанию policy в контексте event flow + event reaction. Понравилось, что упоминаются внешние системы (розовые стикеры), упоминание которых я видел только в книге и статьи с хабра.

Пятничное чтиво

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

—————————————

Strategies for the Success of Microservices

Список из 11 стратегий, которые могут помочь справиться с переходом на сервисную архитектуру. В списке найдете “банальные” стратегии: наличие процессов CD (Continuous Delivery) для постоянного деплоймента, тестирования для выявления ошибок до продакшена, мониторинга для понимания того, что происходит с системой, описанных способов и технологий для интеграции, подходов для обеспечения безопасности сервисов. Также упоминается не такие очевидные стратегии: версионирование сервисов, быстрый провижн новых сервисов, изменение архитектурных возможностей и определение стратегий по обеспечению устойчивости системы.

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

—————————————

Monolith -> Services: Theory & Practice

Иногда возникает ситуация, когда бизнес хочет перейти на сервисы быстро. И для того, что бы заранее огорчить бизнес - предлагаю ознакомиться с рассуждениями Kent Beck-а связанные с вопросом “перейти от монолита к сервисам быстро?”.

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

—————————————

Service Architecture at SoundCloud — Part 3: Domain Gateways

Первая статья из серии “Service Architecture в SoundCloud”, в которой уделяется внимание BFF. Во второй о Value-Added Services (VAS, близкий аналог entity service, только бизнесовый сервис, который возвращает агрегат и применяет business authorization rules), а в третьей части развиваются идеи VAS.

В SoundCloud используется для каждого из десятка API клиентов свой BFF сервис. В компании, BFF реализует логику API gateway, rate limiting, authN, проверку заголовков и контроль кеша. При этом, сервисы используются как для мобильных и браузерных клиентов, так и для публичного и партнерского API. Понравилось, что в статье описывается не только положительный опыт, но и плохой. Например: проблемы с функционалом, который затрагивает больше одного сервиса, из-за чего оркестрация происходит на стороне BFF, что приводит к дублированию логики между сервисами для разных клиентов.

Пятничное чтиво

После прочтения Fundamentals of Software Architecture решил сделать “спецвыпуск”  связанный с ролью солюшен архитектора. Поэтому сегодня 3 ссылки о том, что это за роль, как помогает компании и разработчикам и как стать архитектором. Если хотите больше таких статей или хотите обсудить идеи для других спец выпусков - пишите в комментарии, буду рад.

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

—————————————

What is a Solution Architect? (Roles & Responsibilities)
Solution Architect — Who Am I?. For almost a year, one of my job…

Две статьи о том, чем занимается человек на роли архитектора. Из первой узнаете, что роль солюшен архитектора в преобразовании требований в архитектуру и дизайн, которые станут планом для решения. А так же, при чем тут тестирование технологий, функциональный анализ, паттерны, мотивация и guidance of the development leads. При этом, уделяется внимание тому факту, что приходится изучать “поверхностно” кучу технологий, вместо закапывания себя в одну область.

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

—————————————

Курс Essential Architecture #Intro

Публичная версия вводных лекций тинькова по архитектуре. Александр разбил курс на пять частей:
- Что такое архитектура и чем занимается архитектор
- Код (подходы, практики, модульность и так далее)
- Данные. Способы хранения, обмен данными, как работать с аналитическими данными
- Архитектурные стили, архитектурный квантум
- Виды архитекторов, как обсуждать архитектуру, различия между архитектурой и проектированием

Пока из курса доступны только две части: о коде и данных. Из которых узнаете о разнице между coupling и cohesion, модулях, 12 factor apps, видах файловых хранилищ и вариантах интеграции.

Советую следить за выходом новых лекций.

—————————————

Software Architecture Monday

В ссылках редко появляются подобного вида списки, но сегодня особый случай. Один из авторов Fundamentals of SA, по понедельникам, выкладывает короткие записи, где затрагивает архитектурные темы. Список уже состоит из 125 уроков и включает как темы из книги, так и темы, которые не упоминались (например последняя, Managing Broad Bounded Contexts). Уроки разделены на 6 тем: микросервисы, основные архитектурные темы, EDA, софт скилы, интеграция, энтерпрайз архитектура.

Пятничное чтиво

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

—————————————

From developer to (solutions) architect.  A simple guide. - DEV Community

Еще одна статья, которая описывает возможные шаги, которые помогут стать архитектором. Из интересного - описываются навыки, желательные для роли: больше слушать, валидировать предположения с клиентами, не предлагать решений, пока не будет максимально полной картины системы, быть объективным и так далее. Кроме того, статья описывает темы, которые стоит знать (согласен не со всеми) и поднимается вопрос “продажи”, когда архитекторы помогают продать решения или проконсультировать клиентов с технической стороны.

—————————————

Build Your Own Technology Radar

Существует такая штука как technology radar. Радар был придуман в компании The ThoughtWorks, так как, в компании, лиды собирались два раза в год и выбирали technology direction & strategies для компании. Через какое-то время участники встреч назвали артефакт полученный в ходе работы тех радаром. Neal Ford (один из авторов Fundamentals of Software Architecture), в 2013 году, написал статью, в которой предлагает использовать тех радар не только в компании, но и в личном обучении (архитекторов, но и разработчикам подойдет), для отслеживания изменений в профессии. А тех радар, может помочь в отслеживании технологий, которые изучаете и в диверсификации “портфеля” знаний инженера.

—————————————

Implementing a workflow for your Architecture Decisions Records | by Asier Marqués | Medium

В канале публиковалась статья об ADR (architecture decision records), в которой говорилось, зачем нужен документ и из чего документ должен состоять. К сожалению, статей о том как строить воркфлоу работы с описанием архитектурных решений крайне мало. Сегодняшний текст - исключение, так как говорит о том, что делать с ADR. А именно:

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

Если планируете начать работу с ADR в компании - однозначный мастхэв.

Пятничное чтиво

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

—————————————

Deleting Data in a Microservices Architecture

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

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

—————————————

When to use shared libraries in Microservices architecture

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

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

—————————————

Simplifying Dealing with Legacy Systems

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

- трата времени каждой команды, так как команда по новой изучает легаси систему;
- дублированию бизнес логики в каждом из сервисов;
- при этом, каждый сервис реализует бизнес логику в “уникальном” виде;

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

——— одной строкой ———

- Вышел свежий номер журнала Increment, в этот раз о планировании.