Попутал ссылку к последнему посту. Вот правильная:

https://medium.com/geekculture/architecting-a-scalable-permissions-service-for-saas-web-applications-a4bc7dcb1cb3

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

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

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

Comparision of all modern database models

Название статьи говорит о контенте. Модели которые сравниваются:

- key-value (redis)
- Wide-column store (Cassandra)
- Column-oriented (InfluxDB, ClickHouse)
- Document-oriented (mongo)
- Relational (sql)
- Graph (neo4j, запись стрима с примером использования бд)
- Inverted index (Elasticsearch)

Для каждой модели дается краткое описание, плюсы/минусы, основные юзкейсы и примеры продуктов.

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

Reporting models and Event Sourcing

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

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

Moving from Salesforce Commerce Cloud to Microservices-Based Commerce

Статья с историей перехода с Salesforce Commerce (SaaS для магазинов) на собственную микросервисную архитектуру. У компании было три причины для переезда (типичные переезды с SaaS решения на самом деле):

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

В оставшейся части статьи найдете описание переезда. Сначала компания определила место переезда (в статье дается 4 примера начальных сервисов в зависимости от контекста). Потом создала Middle Layer для подмены старого магазина на новые части системы и  мигрировала данные из старой части системы в новую. А потом уже релиз, тесты и повтор цикла с новой частью системы.

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

- Crystal 1.0 - What to expect - The Crystal Programming Language

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

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

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

Keeping CALM: when distributed consistency is easy | the morning paper

CALM (consistency as logical monotonicity) теорема представлена в 2010 году и системы основанные на этой теореме обходятся без координатора, так как координатор является боттлнеком в high performing scalable distributed systems. Статья - вводная в теорему (за подробностями - в пейпер), в которой описывается основные принципы. А также, в конце дается пример использования такой теоремы в виде языка bloom, который существует только как Bloom DSL поверх ruby.

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

От монолита к модулям: как отстроены бизнес-процессы склада Lamoda

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

Также дается три причины почему не перешли на сервисы:
- Сильная связанность процессов и агрегатов между частями системы
- Нужна транзакционность для бизнес процессов
- Общие процессы между бизнес процессами

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

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

The limits of the saga pattern

Саша паттерн решает проблему распределённых транзакций с помощью событий и компенсаторный событий при ошибках. С бизнес ошибками такой подход работает без вопросов, проблемы начинаются с техническими ошибками. Автор статьи разбирается с тем что есть бизнес и технические ошибки, развивает идею «сага только для бизнес ошибок» и в конце даёт пару примеров “smells”, которые помогут сориентироваться, если используете сагу для технических ошибок.

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

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

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

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

Для тех, кто захочет попробовать - PEPELEAD, 10%, а записаться можно по ссылке: http://education.borshev.com/teamlead

#реклама

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

После перерыва выпустили очередную серию подкаста, в которой подкаст скатился. Говорим, как нас накрыл синдром самозванца во время подготовки курса об асинхронной архитектуре, по-детски материмся (как всегда) и рассказываем, куда пропал сосед.

Слушайте везде (18+):  SoundCloud ,  Apple ,  Яндекс.Музыка ,  Google Podcasts ,  Castbox ,  Spotify ,  RSS

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

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

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

5 things I learned while developing a billing system

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

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

Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят

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

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

Top 5 Things Every Apache Kafka Developer Should Know

Статьи о “N вещей которые надо знать” и статьи от confluent в почете, поэтому было сложно пропустить данный текст. В тексте описываются следующие темы:

- durability guarantees и отправка сообщений;
- sticky partitioner в продюсерах;
- ребалансировка групп консьюмеров;
- CLI
- хедеры записей (добавляет метаданные, например версию в сообщение);

Я не знал о sticky partitioner и плавал в durability guarantees, поэтому статья оказалась отличным стартом в разборе тем.

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

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

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

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

Как использовать ClickHouse не по его прямому назначению

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

- Использование clickhouse-local для локального выполнения файлов, что позволяет использовать SQL подобный диалект для работы с файлами;
- Работа с полуструктурированными данными, т.е. использование материализованных столбцов для json в котором может быть поле, а может и не быть;
- Реализация graph processing (осторожно, китайский);


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

Building Multi-Tenant SaaS App for an Unknown Scale

В последний месяц часто сталкиваюсь с Multi-Tenant приложениями, при этом, я не фанат такого подхода. Так как избежать Multi-Tenant приложений не реально, то сегодня статья с примерами реализации таких приложений. В тексте найдете описание пяти подходов:

- Multi-Tenancy using Virtualization
- Multi-Tenancy using Containerization
- Database-per-tenant
- Single multi-tenant database
- Sharded Multi-tenant databases

Для каждого из подходов найдете краткое описание, как использовать и где подойдет.

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

My Mental Model on Choosing a Database for a Particular Problem

Выбирать базу сложно, не только из-за количества технологий, но и из-за того, что сложно помнить все области по которым стоит рассматривать решения. В тексте, автор, описывает основные области, по которым выбирает базы данных. Всего вышло восемь пунктов: Access and Write Patterns, Consistency, Fault Tolerance, Scalability с разными вариантами, Maintenance and Observability, Self-healing, Regulations and Compliance и цена. Понравилось, что в конце еще упоминается поддержка экосистемы языка и лицензирование.

Кажется что статья поможет в двух случаях:
- хотите разобраться с базами данных и на что смотреть, когда данные и нагрузка достаточно большие;
- хотите подготовиться к system design interview;

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

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

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

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

Emergencies in Distributed Systems

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

- Создание протокола, который должен отвечать на вопросы “кто”, “что” и "как”;
- Таймфрейм в котором работает протокол;
- Решения. В статье указываются три основных вида: блокирование доступа к stateless протоколам, блокирование доступа к message-based systems и роллбэк транзакций;
- Различие централизованных и децентрализованных распределений. Тут работе emergency orchestrator/choreography и emergency message pipeline;
- Как применять принятое решение;

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

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

Simulating CloudEvents With AsyncAPI and Microcks

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

Из статьи узнаете о существовании спецификации для event data - CloudEvents, а также о том, как комбинируя две спецификации получить полное описание асинхронного вызова в системе.

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

Chaos Engineering — Part 3. Tools and Methods

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

В третьей части разбираются 4 категории неисправностей (пятая связана с людьми):
- resource level;
- network and dependencies level;
- application, process, and service level;
- infrastructure level;

Для каждой из категорий приводится описание что это, как и почему может возникнуть. А также, дается список “обычных” инструментов, которые делают тест каждой из частей системы. Все инструменты - дефолтные утилиты или вообще запросы в базу с измененным конфигом, например манипуляции с /etc/hosts и шатание серверлесс функций.

Чтобы в будущем не делать тесты руками - дается список toolkit-ов, которые одной библиотекой реализуют набор неисправностей.


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

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

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

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

Event-driven APIs — Understanding the Principles

В тексте рассказывается о трёх способах создания event driven api: webhooks, websockets и SSE (Server-Sent Events). Подобное апи подойдет для пушинга информации на клиенты, например для нотификаций или обновлении асинхронного состояния. А состоит из двух концепций: возможности подписки консьюмером на определенные события и непосредственно отправкой событий.

Для каждого из подходов дается краткое описание, как работает подписка и как работает отправка событий. Важно учесть, что в статье говорится не только о клиент-сервер коммуникациях, но и о сервер-сервер (webhook). А в качестве бонуса - в конце приводится еще один пример использования asyncAPI для документации асинхронных коммуникаций в системе.

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

An Event-Driven REST Coffee Machine API with Clojure

Статья о том, как реализовать коммуникацию между частями системы используя event driven подход. Для этого автор использует собственную реализацию Embedded Event Processing библиотеки. В качестве реализации делается приложение по доступу к кофе машины используя HTTP API, которое состоит из трёх компонентов: сервера, event emitter и бизнес логики кофемашины. При этом сервер вызывает бизнес логику через event emitter.

Работа с событиями состоит из handler и observer. А сервер диспатчит нужное событие во время вызова экшена, возвращая результат работы хендлера.

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

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

Is Your Microservice a Distributed Monolith?

Статьи о распределенных монолитах уже упоминались в канале, но сегодня маркетинговая статья от технического писателя Gremlin (платформа для Chaos Engineering). Хоть статья “продажная”, мне понравилась идея, что Chaos Engineering позволяет явно определить, является система распределенным монолитом или нет используя набор экспериментов. Такое чувство, что данную идею можно автоматизировать, автоматически “тестируя” релиз и определяя значение распределенности монолита. А потом встроить еще один шаг в CI

Помимо определения распределенного монолита и описания почему он плох упоминаются три характеристики:

- Services are tightly coupled
- Services don’t scale easily
- Services are overly chatty

А для каждой характеристики дается подробное описание с примерами и вариациями. А также, предлагается набор тестов, которые могут показать насколько все плохо (с примерами использования Gremlin).

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

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

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

Антипаттерн Entity Service. Иногда микросервисы хуже монолита-Architecture Cleaning

Я являюсь сторонником разделения монолита на сервисы по поведению бизнеса, поэтому entity service паттерн выглядит для меня как сумасшествие. Что также  подтверждается личным опытом и историями других разработчиков. Идея паттерна - делать CRUD only сервисы под сущности, т.е. сервис с заказами, сервис с постами, пользователями и так далее.

Вроде как, разделение по данным поможет с CRUD системами, но приносит проблемы связанные с отказоустойчивостью и накладным расходам по производительности. В статье, кроме описания паттерна, найдете рассуждения о том, как избавляться от entity service в системе (спойлер - перейти на разделение по поведению или по subdomains).

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

Message Expiration Pattern Explained

Для одного клиента потребовалось реализовать систему, в которой у данных в событии есть собственный expiration time. Т.е. данные из события могут быть использованы до определенного времени. Решили проблему с помощью общей очереди и таблицы, так как данных в событии было не так много (если интересно - могу написать подробную статью).

Поэтому вторая статья - о том, как работать с expiration time в событиях. Кроме двух способов установки TTL (на уровне события и на уровне топика/очереди), рассказывается о Dead Letter Queue паттерне. Также, порадовало, что в статье упоминается ситуация с истекшим временем жизни события во время лока этого события на стороне получателя.

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

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

—————————————
Himeji: a scalable centralized system for authorization at Airbnb

Проблема сервисной архитектуры - авторизация. С такой проблемой столкнулся airbnb, когда переезжал с рельсы на SOA. Так как у них каждый ресурс со своим эндпоинтом, который было легко проверить на авторизацию в монолите, но в сервисах это оказалось не так просто, так как начали дублироваться проверки, появилось больше вызовов между сервисами.  Решением стал отдельный сервис авторизации, основанный на Zanzibar (Google’s Consistent, Global Authorization System). А как сервис работает (включая архитектурную диаграмму), из чего состоит и какой тулинг представляет - найдете в статье

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

Изучаем YELP с помощью Neo4j, python

Базовая статья о том, как использовать neo4j с реальными данными, на примере дампа yelp. А так, как я фанат графовых баз данных (даже стрим делал) то статья оказалась в рассылке. В статье найдете как загрузить дамп yelp в базу, а после - разобраться что там есть (судя по статье - там 7 типов нод, с которыми и будет разбираться автор). Ну а дальше - показывается, как используя питон сделать выборки (например, найти топ 10 отелей Ванкувера с наибольшим количеством отзывов).

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

What’s Your Decomposition Strategy?

Кроме DDD существуют другие способы декомпозиции систем на части. В статье приводится еще четыре способа разделения систем: Value Streams, Failure Domains, Anti-Corruption Layers, Single Responsibility Principle. Понравилась идея разделения по Failure Domains, так как это напоминает как корабли и подводные лодки разделены на изолированные отсеки, чтобы при пробоине все судно не затонуло. К сожалению, подробной информации по такому разделению найти не смог. Поэтому, если знаете где можно посмотреть на примеры - буду рад комментарию.

Также, в догонку, статья о трех видах декомпозирования систем основываясь на подходах DDD (bounded context, business subdomain, business entities). Главное, ребята добавили важное замечание, что стоит начинать разделение с bounded context, а дальше, по надобности, опускаться на следующие слои.

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

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

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

Why hexagonal architecture doesn’t suit me. My DDD implementation is a layered block architecture

Hexagonal architecture тема, о которой говорят, но говорят по разному. Из подобных тем могу выделить event sourcing, saga, микросервисы и cqrs (предлагайте другие варианты в комментариях).

Мне нравится смотреть на статьи вокруг таких тем, так как это позволяет изучить отличия и найти общие части, поэтому сегодня текст, который начинается странно. Удивила фраза “Hexagonal architecture is one approach to implement DDD” (в оригинальной статье 2005 года упоминались только адаптеры и application). Сбивает с толку, утверждение что все знают о “Hexagonal architecture” (я сам так и не разобрался на 100% в теме, но походу это хорошая тема для статьи/выступления).

Автор предлагает решение, основанное на 5 слоях: ports, core (тут реализуются бизнес процессы), domain, adapters, data objects. А также на 6 правилах: однозначность возвращаемого значения, запрета кросс коммуникаций между доменами, отсутствия бизнес логики в доменах (тут возникли вопросы), чистые функции в доменах, DTO и юнит тестирование только одного слоя за раз.

В конце приводится пример на js и список бенефитов, которые появляются с такой архитектурой.

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

Software System Design #002. Collating  Business Requirements | by Joseph Casey | May, 2021 | Medium

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

В статье разбираются функциональные требования, которые состоят из:
- списков юзер ролей;
- скоупа или ограничений в которых должна работать система;
- определения функциональности приложения;
- информации об отказоустойчивости, которая говорит о том, как быстро/надежно/etc система должна работать;

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

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

Microservices Architecture: Breaking the Monolith

Ещё одна статья о разбиения монолита на сервисы. Понравилось что автор даёт описание трех шагов декомпозиции: определение сервисов/доменов, решения вокруг коммуникации/стриминга данных и странного шага с выносом сервисов в облака. Так же понравилось, что указывается две стратегии экстракции: Strangler Pattern и параллельная разработка.

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

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

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

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

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

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

5 Prerequisites To Know Before Adopting Microservices

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

- Как будете обрабатывать failures. Тут больше о синхронных коммуникациях, но добавлю, что об failures в асинхронных коммуникациях подумать тоже стоит.
- Логирование и трассировка должна появиться до первого сервиса. Мотивируется упрощением дебага.
- Build, deploy, run, and monitor. Кажется, что это пункт, который выполнялся в каждой из компаний где довелось поработать.
- Developer Experience. Тут хотелось бы больше информации о микросервисном шасси, да и пункт самый недооценённый в языковых экосистемах, как мне кажется.
- Microservice Architecture Assessment Platform. Это проект от автора microservices.io, который помогает оценить сервисы по заданным признакам. Крайне рекомендую попробовать.

Если у вас есть еще примеры похожих статей - пишите в комментарии, буду очень рад.

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

How Technology Architects make decisions

Статья - краткая выжимка пейпера “An Approach for Decision Making Analysis in Enterprise Architecture” от 2014 года. Сам пейпер описывает четыре стратегии принятия решений в Enterprise Architecture, которые разделяются на две группы:

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

Ну и список самих решений:

- Compensatory Equal Weight
- Compensatory Weighted Additive (WADD)
- Non-Compensatory Conjunctive
- Non-Compensatory Disjunctive

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

Статья поверхностна, но текст вдохновил на осмысленное прочтение пейпера.

Привет!

Хочу попробовать ввести новую рубрику в канал: ответы на вопросы. Я не знаю что из этого получиться и как много будет вопросов, но считаю, что попробовать стоит.

Поэтому, каждый понедельник, буду отвечать на один чётко сформулированный #вопрос по около тематике канала.

Форма для вопросов: https://forms.gle/cWGeLg6cYN1gQvTT6

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

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

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

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

The Outbox Pattern in Event-Driven ASP.NET Core Microservice Architectures

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

Кроме реализации, в тексте найдете информацию, как тестировать паттерн, а также углубленные темы, например: Publisher Notify, Acknowledgments и Resilient Message Handling.

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

Ten Signs You Don’t Understand This “Microservices” Thing

Переход на сервисы дорогое мероприятие, так как накладывает доп расходы на инфраструктуру и на экспертизу инженеров/архитекторов (и консультантов). К счастью, переход на сервисы может быть обусловлен только желанием отдельных людей и(или) “мы видели это у других и нам тоже поможет”. Чтобы избежать бессмысленной траты ресурсов - стоит также знать, когда останавливать переезд.

Автор собрал список из 10 пунктов, которые, потенциально, могут сказать, что переход на сервисы будет плохой идеей. Спорные пункты присутствуют (например последний про ожидание конца), но полезные тоже есть (восьмой пункт о коммуникациях и четвертый, о выносе горизонтальных частей одного слоя). Для каждого пункта даются советы как задетектить проблему и почему стоит подумать о пункте.

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

Incremental Rewrites with GraphQL

Во время работы в toptal я занимался проблемой ститчинга (объединения) схем из сервисов в общую схему. Тогда решалась проблема доступа с фронтенда к бэкенду, так как apollo client мог нормально работать только с одной схемой + верили, что apollo GQL gateway поможет предоставить единственную точку входа в  систему. В итоге, toptal решил, что проще написать кастомный аналог GQL gateway (чем закончилась эпопея - не знаю, к сожалению).

Кроме этого, была мечта использовать GQL ститчинг для выноса сервисов из монолитов, что описывается в статье. Для этого, ребята из khanacademy, также решили взять GQL apollo federation. При этом, кроме распила монолита разработчики хотели переписать систему с python2 на golang. В итоге, инженеры кастомизировали стандартный gateway добавив туда описание 4 режимов для простоты переезда с монолита на новые сервисы.

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

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

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

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

Engineering dependability and fault tolerance in a distributed system

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

Понравилось, что в тексте даются определения из которых понятна разница между dependability, availability, reliability и fault tolerance. А также описывается связь между stateful/stateless и reliability/availability.  А дальше описывается, что использовали инженеры Ably (спойлер - dynamic placement mechanism, выявление неполадок и channel persistence layer). А в конце описываются вопросы, которые могут возникнуть во время введения отказоустойчивости.

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

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

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

The Endpoint Responsibility Checklist

Еще одна ссылка “чеклист”, которая является рассуждением о том, что должен предоставлять фреймворк основанные на Clean API Architecture. Чеклист состоит из двух секций: base responsibility и write responsibility. А в конце показывается пример, как использовать чеклист для проектирования API.

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

Dealing with Chaos

Продажный пост от компании flexera, в котором показывается как используя платформу визуализировать сервисы в системе. Для этого ребята используют 4 подхода как основу: Design First, Diagrams as Code, Static code analysis via “Chaos” и Service Map. Из подходов интерес вызывает “Chaos”, который помогает собрать API specs, readme файлы, чеки на “запахи” сервисов (например вызов из сервиса другого сервиса), а также наличие диаграмм и описания работы сервиса.

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

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

- Пример использования Event Storming для описания Subway
- Notion выкатил API, поэтому появилась платформа для комментариев, основная на этом API

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

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

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



How to Use Redis as an Event Store for Communication Between Microservices

Event store хранит события в системе в определенном виде. Обычно используется в event sourcing для получения стейта за определенное время, например из постгреса, или для коммуникаций между системами (привет Кафка).

В статье пример того, что для эвент стора можно использовать любую технологию, даже редис. Автор описывает опыт использования редис как персистенс слоя, который будет поддерживать порядок событий, быстрых операций на запись, высокий scalability и так далее. Для этого будет использоваться примитив streams и, в качестве примера, реализация OrderShop приложение. В самом тексте автор дает некоторые пояснения по коду (что делает каждый из тестов), а так же приводит пример пары запросов для получения данных.

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

Quality Attributes

Лет пять назад я не понимал зачем думать о quality attributes, главное сделать приложения “чтобы работало”, а остальное излишне. Сейчас кволити атрибуты позволяют собрать не функциональные требования заранее, понять, в каком состоянии система и что стоит улучшить, определиться, где можно забить, а где стоит спроектировать систему детальнее, а также помочь “продать” решение бизнесу, если решение улучшает проседающий атрибут.

К сожалению, запомнить все атрибуты сложно (а их много), поэтому статья оказалась в рассылке. В тексте найдете описание восьми групп, на которые разбиваются атрибуты. Понравилось, что для каждой из групп приводятся примеры. А после описания найдете два интересных подхода: Quality Attribute Scenario и Quality attribute tactic. Первый приносит стандартизацию в документирование атрибутов, а второй - описание плана улучшения (пример также найдете в статье).

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

Beginners Guide to Incident Postmortems

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

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

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

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

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

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

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

Decomposing the Monolith with Event Storming

Event storming - личное открытие 2019 года, благодаря которому я могу либо уйти от модельного исследования системы к событийно/командной, либо выделить домены по бизнес процессам. В канале уже упоминались статьи об этом подходе, сегодня статья в которой приводится пример в виде семи шагов, которые помогают исследовать систему с помощью эвент шторминга. Кроме этого, понравилось, что автор описывает два заблуждения связанных с DDD и Design Thinking.

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

My Favorite Interservice Communication Patterns for Microservices

Если простить о способах коммуникации между сервисами - вспоминаются синхронная и асинхронная. Поэтому, удивился, когда, в статье, кроме API calls и async event увидел еще два нестандартных способа.

Первый - напрямую коммуницировать через сокеты, а второй - использовать “Lightweight events”, под которыми подразумевается микс из легких событий и API вызовов для шаринга данных. К сожалению, ни разу не видел, чтобы использовался подход с сокетами в продакшене (если у вас обратный опыт - с радостью почитаю отзыв или мнение о подходе). А в случае с Lightweight events - не хватило объяснения подхода, подробного примера, а также главного: ответа на вопрос “зачем” и почему не использовать два вида событий (стриминг данных + бизнес событие на вызов команды).

Для каждого подхода дается краткое описание + pros/cons секции. А статью сложно назвать “обязательной”, но текст помог пофантазировать на тему “а что если?”.

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

Six Key Event-Driven Architecture Patterns

Статья от infra dev в wix, где инженеры, через кафку, реализовают event-driven систему с 1400 сервисами. В тексте найдете описание шести паттернов, используемых в компании. Каждый из паттернов, в первую очередь, относится к кафке (но исключения присутствуют), а полный список выглядит следующим образом:

- Consume and Project, который решает проблемы больших объектов в кафке с помощью ”materialized views”№;
- Event-driven from end to end, который предлагает сделать websocket service для пашей на фронт о том, что асинхронная цепочка выполнилась;
- Личный опыт: аналог паттерна также можно использовать в e-commerce, для синхронизации корзины между клиентами;
- In memory KV store, который, используя compacted topics, реализует KV store без лишних баз данных (если есть кафка);
- Schedule and Forget, который говорит о том, что если есть шедулер сервис, который вызывает нужный бизнес сервис, то в бизнес сервисе стоит сразу отправить событие в брокер, что бы потом его идемпотентно обработать. А в случае ошибки реализовать логику ретрая;
- Events in Transactions, который говорит о том, как средствами кафки избежать дублирования событий в системе;
- Events Aggregation, который говорит о том, как обрабатывать батч событий (например, когда надо распарсить файл, который отправляется батчем событий в кафку);

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

- Если хотели контрибьютить в psql - гайд с описанием первых шагов и идей для патчей

Заболел модной болезнью, поэтому какое-то время постов не будет. Беру перерыв на время, пока не приду в себя.

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

Спасибо всем, кто желал здоровья 💗

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

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

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

A Reference Architecture for Responsive Asynchronous Task Execution

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

В статье, автор описывает вариант реализации архитектуры, которая не только создает асинхронные задачи, но и оповещает клиентов, когда задача выполнилась. Решение состоит из task API + message broker/queue для запуска задачи и вебсокет сервера, который отправляет статус по задаче в реалтайме клиенту. Понравилось, что в конце дается 3 идеи для улучшения (менеджмент задач, добавление прогресс бара и поллинг).

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

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

4 Key Observability Metrics for Distributed Applications

Еще один пост с метриками, которые стоит добавить к приложению. Понравилась мысль в начале текста, в которой метрики делятся на Impact Data и Causal Data. Первые ответят на вопрос “who is being affected”, вторые на вопрос “what is being affected and why”.

А метрики, которые стоит собирать выглядят так: Latency, Traffic, Error Rates и Saturation. Для некоторых метрик дается пример Impact Data и Causal Data. Например, для задержки это будет выглядеть так:  Impact Data - отслеживание одного события на протяжении всей жизни. Causal Data - стоит еще отметить задержку между сервисами и чем больше контекста тем лучше.

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

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

SHIFT Commerce’s Journey: Deconstructing Monolithic Applications into Services

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

Однозначный мастхэв для тех кто переходит с монолита на сервисы.