привет, на этой неделе ссылки сделать не успел, поэтому до встречи в следующую пятницу

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

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

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

From Monolith to Event-Driven: Finding Seams in Your Future Architecture

Еще один лонгрид от infoq о миграции с монолита на событийную архитектуру. На этот раз в статье дается упор на событийную составляющую: типы событий, ES/CQRS, миграционные события и миграцию/синхронизацию данных. В конце дается пример системы, в котором описываются принципы из статьи. Понравился пример из статьи и то, что о видах и типах событий стали говорить чаще. А так же то, что сново поднимают тему миграции/синхронизации данных, потому что в моем опыте о таком забывают.

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

Designing for Privacy — An Emerging Software Pattern

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

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

Scalable Microservice Architecture Using RabbitMQ RPC

Статья пример того, как используя rabbitMQ RPC построить микросервисную архитектуру. Примеры кода на питоне, в конце получится пример из двух сервисов для расчета чисел Фибоначчи. Один сервис предоставляет http интерфейс для показа чисел, а второй - executor. Оба сервиса общаются между собой посредством RPC вызовов.

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

- Пример реализации персональной вики;

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

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

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

Handling Distributed Transactions in the Microservice world

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

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

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

What is distributed tracing and how does OpenTelemetry work for event-driven integration?
Building Netflix’s Distributed Tracing Infrastructure

Две статьи об распределенной трассировке. Первая рассказывает об опыте salesforce и OpenTelemetry, вторая - netfix и самочинного решения Edgar. Из статей узнаете что такое распределенная трассировка, зачем нужна, а также посмотреть на  примеры использования в компаниях. Так же, стоит отметить, что есть OpenZipkin, который умеет трейсить асинхронные вызовы и, например, кафку.

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

Debugging Microservices Networking Issues

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

Открытие четвертого сезона


2020 год оказался самым психологически и эмоционально сложным годом в моей жизни. Это подтверждается несколькими фактами:

- Проблемы со здоровьем, которые начались на фоне напряженной работы в toptal (6+ часов митингов в день + перманентное “it’s fine” состояние). При этом работа дала опыт, который пригодился в последующей работе и проектах. Да и в целом, я бы повторил, если бы оказался в такой же ситуации еще раз.
- Рекордное количество часов проведенных на психотерапии. 250 в 2020 году против 170 в 2019.
- Полная социальная изоляция. Забил на ссылки, опенсорс, соцсети. Увольнение в никуда. 2-4 часа работы в день максимум, которые могу позволить себе последние полгода.

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

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

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

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

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

Сергей Константинов. API

Вместо ссылки - книга о проектировании API, но хочется остановиться только на 11 главе, которая тянет на отдельную статью. В главе описывается 20 советов для проектирования апи, которые помогут в стандартизации API.

Что лично практикую:
- использование uuid вместо id;
- возвращение полного состояния системы после мутаций;

Что запомнилось:
- люди явно пишут что объектов нет, вместо отдачи пустого списка.
- понравилась идея с порядком ошибок: от критических до некритических. Возник вопрос: можно ли подобную идею использовать в условном dry-v?
- понравилась идея с указанием политики кэширования в документации. почему-то сам так не делал до этого момента.

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

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

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

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

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

В конце статьи описывается 4 стратегии изменения легаси систем: "Переписать", "Оставляем как было", "Strangler Application" (создать новое, поверх старого), "Переработка по модулям". Для каждой стратегии приводится описание, плюсы, минусы и рекомендации. Если мало - бонусом идет 11 историй работы с легаси системами от сторонних авторов.

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

Kafka is Not a Database

Кафка не только стримит данные, но и хранит сообщения, а также имеет из коробки projections для сбора состояния по сообщениям (kSQL). Поэтому велик риск использовать message broker как базу данных и хранить там данные (сам с таким сталкивался). Авторы статьи рассуждают, как отсутствие isolation levels в кафке может помешать этой идее. На примере онлайн магазина собирается система которая показывает нарушение concurrency control между чтением данных и записью мутаций с этими данными. Как решение, приводится вариант “change-data-capture”, который использует стриминг через кафку для наполнения “традиционных” баз данных.

Одним подкастом в мире стало больше

С Федей я познакомился пока консультировал ребят из igooods. Федя - техдир с 15-летним стажем, консультирует крупные компании и ведет канал @pmdaily. По работе приходилось часто созваниваться и в какой-то момент решили попробовать выносить обсуждаемые темы в публичное пространство.

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

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

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

Слушайте на  Soundcloud  и  Apple Podcasts.

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

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

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

Introduction To Distributed Tracing Pattern

Я публиковал ссылку, рассказывающую что такое распределенная трассировка. В сегодняшнем посте автор делает акцент на связывании логирования и трассировки. Для этого необходимо использовать уникальный id в логах (очевидный вариант использую больше 4 лет и реализация кочует из проекта в проект), что позволит смотреть логи для запроса. Магия начинается, когда логи и трейсы объединяются одним уникальным id. В таком случае можно сразу посмотреть поведение и производительность распределенной системы. В конце статьи приводится 4 примера того, как это сделать.

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

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

Building production-ready services

Статья с концепциями, которые желательно учитывать для сервисной архитектуры. Бо’льшая часть отдается AuthN и AuthZ. Поверхностно рассказывается о конфигурации. В конце найдете список необходимых вещей для обсервабилити (а также крутую картинку с обсервабилити паттернами). Статья больше тянет на набор терминов, которые можно выписать в readiness checklist или в список на изучение.

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

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

Things I Wished More Developers Knew About Databases

Лонгрид солянка из 17 пунктов о том, что стоит знать по базам данных. Жалею, что не прочитал текст 4-5 лет назад. Каждый пункт подробно расписывается (иногда приводятся диаграммы или код). Перечислять 17 пунктов лень, поэтому опишу те, которые понравились:

- Третий пункт о consistency и isolation capabilities, так как каждый раз путаюсь в isolation levels для SQL. Так же понравилась картинка с concurrency models и связями между ними.
- Восьмой и девятые пункты. Там рассказывается о application-level sharding вне application-level и AUTOINCREMENT-ге, который может быть вредным, так как не сталкивался с подобным.

Ну и два пункта, которые рекомендую:
- Седьмой пункт. Это причина, почему в rom-rb не хотели делать #first  и #last методы.
- 13 и 14 пункты о вложенных транзакциях и транзакциях + стейте приложения.

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

-----

Курс

В прошлом году, когда записывали подкасты с Федей, он рассказал об опыте с курсом для тимлидов. Я давно хотел попробовать себя в этой роли, поэтому предложил написать адвансед курс для его школы.

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

В итоге, получилось 4 недели, за которые расскажем об  асинхронной архитектуре и эволюции этой архитектуры. В курсе будет больше упора на проектирование: как из идей event storming и стратегического слоя DDD найти сервисы, которые реализовать придется. А также, как превратить эту информацию в рабочий проект, помня об эволюции данных и заложив фундамент для будущих изменений.

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

Записаться можно тут, если хотите спасти попугов - save-popugi даст скидку в 10%.

-----

Стрим будет в среду, 3 февраля, 20:00 по москве. Пока пишу заметки, накопилось уже записей столько, что записи сложно обрабатывать, так как не хватает визуализации связей и сложных поисков, которые нужны как для курса, так и для основной работы. Я пробовал obsidian и roam, но, в итоге, остановился на inkdrop. Поэтому, за стрим напишем штуку, которая сливает заметки в neo4j и на реальной проблеме разберемся, как использовать графовые базы.

Начинаем стрим

https://www.twitch.tv/davydovanton

донаты - https://www.donationalerts.com/r/davydovanton

У меня начала слишком быстро садиться батарея, поэтому придется сделать 40 минутный перерыв. Продолжим в 21:30 (я все отпишу)

Продолжаем стрим

https://www.twitch.tv/davydovanton

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

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

Introducing the Polyglot Code Explorer

Лонгрид в котором автор рассказывает о собственном проекте - OSS инструменте для визуализации сложных кодовых баз. При этом, инструмент работает с различными языками. Изначально, инструмент родился как ответ на вопрос «как можно визуализировать кодовую базу без сложных парсеров для конкретного языка?». Состоит эта штука из трёх вещей: сканера кода в json, добавления layouts, визуализатора. В статье найдете как пользоваться инструментом, скриншоты UI и виды слоев, которые предоставляет проект. В моей голове крутилась похожая идея, сделать систему слоев для dry-system-dependency_graph, хотя дальше головы идея не ушла.

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

The Story of a Microservice Transformation in Hepsiburada

Ещё одна статья о том, как компания распилила монолит сервисы. В этом случае выносилась checkout система и вышло 40 сервисов. Статья разбивается на три части. Личную ценность принесла первая часть, в которой определяются проблемы и решения проблем. Из решений:
- DDD, как способ разделения доменов и понимания бизнеса
- CQRS как способ справиться с нагрузкой

Вторая и третья часть говорят о выборе технологий, что специфично.

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

Kafka as a storage system

Я плохо отношусь к идее хранить данные в кафке как в базе данных. При этом, каждый раз интересно читать обратный опыт. Сегодня статья из инженерного блога твиттера, в которой рассказывается о том, как компания хранит информацию в кафке для Account Activity API. Важно отметить, что хранится ограниченное количество информации (до пяти дней). В статье найдете детальный технический обзор того, как это сделано. Например как выбирались партишены и при чем тут snappy.

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

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

- GitHub - One-way pipe rack application builder - идея заменить концепцию rack middleware на чейн operations. Как концепция - хочу дальше следить за проектом.

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

Анонсы:
- Две недели до начала курса и закрытия продаж;
- Ребята из RubyRussia  ищут спикеров на митап;
- Ребята из @saintprug проведут оффлайн/онлайн митап 25 февраля;

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

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

Fixing Your Microservices Architecture Using Graph Analysis

На прошлой неделе сливал заметки в neo4j. Сегодня статья о том, как neo4j может помочь в анализе сервисной архитектуры. В статье, автор переносит мета информацию из java приложения в neo4j. После этого можно узнать HTTP вызовы, cross-service dependencies, определить распределенный монолит или нет. А после - сделать экспорт в GraphML. Идея выглядит как перспективный PoC и хочется сделать похожее для других языков и экосистем.

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

Exceptions and Retry Policy in Kafka

Мир приходит к распределенным системам, но базовые концепции все еще с нами. Одна из таких концепций - эксепшены, а попытка использования в распределенной системе - та еще боль. Поэтому сегодня - лонгрид о том, как работать с ретраями и эксепшенами в кафке. Автор делит эксепшены на 2 класса (stateless & stateful), а так же на 4 типа (retryable/blocking). Ну а дальше, приводится примеры того, как работать с каждым из эксепшенов. Примеры заточены под джаву, хотя концепции должны работать во всех экосистемах.

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

4 Microservices Caching Patterns at Wix

Опыт Wix в хешировании системы из 1500 сервисов. В статье найдете описания четырех паттернов, используемых в компании:

- Locally Persisted (or S3 backed) Configuration Data Cache
- Kafka topic based 0-latency Cache
- (Dynamo)DB+CDC based Cache
- HTTP Reverse Proxy Caching (Varnish cache)

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

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

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

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

Google Translate: Analyzing Clubhouse for fun and profit

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

- API
- Agora.io как реалтайм войс и видео платформа (Китай и Калифорния)
- PubNub как реалтайм чат

Также, автор описывает три возможные секьюрити проблемы.

API клиент на питоне
Оригинал на корейском

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

Zero Downtime API Gateway cloud migration

Дано: компания с 500+ микро сервисами, часть из сервисов вне клауда. Необходимо: перевести API на один домен, а сервисы в клауд без даунтаймов. С таким контекстом начинается статья, в которой инженеры из bukalapak описывают опыт использования API gateway для миграции системы в клауд. описываются две проблемы, с которыми столкнулись инженеры и решения, которые были выбраны. Опыт оказался успешным, а размышления можете прочитать в конце статьи.

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

Kafka for Engineers. Here are things about Kafka that you…

Лонгрид о том, что такое кафка описанный инженерным языком, а не языком инфраструктуры. Понравилось, что в статье объясняется как появилась технология, в чем отличие message queues и кафки. Благодаря объяснению отличия между distributed queue и distributed log автор предполагает, почему инженеры используют кафку как очередь и для чего действительно использовать (спойлер - стримить данные между Bounded Contexts). Ну а дальше описываются концепции из которых состоит технология (топики, партишены, консьюмер группы и так далее). Однозначный мастрид недели.

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

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

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

Patterns for Microservices — Sync vs. Async

Самое подробное описание синхронных и асинхронных коммуникаций в системах на моей памяти. В статье найдете: по три вариации на каждый из видов коммуникации, а также список трейд оффов, с которыми столкнетесь . Важно отметить, что в качестве sync оркестратора может выступать BFF или API Gateway, sync оркестратора с async вызовами - GQL gateway, а CQRS может работать с тем же сервисом, где реализована read model.

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

Real-time monitoring of Formula 1 telemetry data on Kubernetes with Grafana, Apache Kafka, and Strimzi

Я не фанат формулы один, но фанат статей, в которых описывается, как инженеры реализуют сумасшедшие вещи. Сегодня статья с описанием того, как перегнать телеметрию гоночного болида из F1 2020 (игра такая) в InfluxDB и Grafana. Понравилось, что в статье описываются, как может использоваться Apache Camel для трансфера данных из телеметрии в кафку и из кафки в InfluxDB (давно смотрю на него).

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

Saga Orchestration for Microservices Using the Outbox Pattern

Must read статья выпуска.

Transactional outbox pattern позволяет автоматически продьюсить нужный агрегат через outbox таблицу в message broker. Sagas pattern - пример реализации распределенной транзакции.

Авторы задаются вопросом: что произойдет, если совместить оба паттерна в одной системе используя kafka (на самом деле - любой message broker) и Debezium в качестве реализации outbox pattern из коробки. В статье найдете код реализации, описание failure случаев, а также, бонусом, мысли о трассировке.

Особое внимание советую уделить Figure 4 (sequence diagram), в которой показывается как данные будут ходить между тремя сервисами в такой системе.

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

- Upgrow - попытка от Shopify сделать собственный hanami из рельсы;

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

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

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

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

- попробовал себя в монтаже видео, оказалось это сложнее чем ожидалось (зато понял, что стоит переходить с iMovie на профессиональный софт);
- факап с коммуникациями, который пока не понятно как решить, но гипотезы уже проверяем;
- внезапные задачи, которых оказалось в разы больше, чем я мог представить;
- цепочка каждого урока из "сделать скрипт → записать → добавить доп материалы" превратилась в цепочку из 9 пунктов. При этом, только моя работа, занимает от 15 часов на урок;

Кроме проблем - получил фидбэк от ребят:

- Контент — круче чем ожидали. Доп материалы, которые готовим можно продавать за отдельные деньги. Столько пользы мы не закладывали;
- Видосы Федя проверяет на каждый чих чтобы каждому было понятно, Марьяна следит за тем чтобы легко усваивалось и было интересно;
- Придумали как поделить большую домашку на кусочки. Подсказываем как не слететь на каждом шаге;

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

P.S.: бонусом - артефакт в виде нарезки, которую делал на память, видео идеально отражает состояние последних двух недель (осторожно, присутствует ненормативная лексика).

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

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

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

Code review checklist for distributed systems

Люблю идею чек листов для рутинных действий. Ревью кода я воспринимаю  одно из таких действий. А если говорить о сервисах, то количество тем, которые надо помнить возрастает по сравнению с монолитами. Поэтому статья со списком тем/вопросов/проблем, о которых стоит помнить во время написания или ревью кода. Из тем: отказы, медленность работы, идемпотентность API, обсервабилити и так далее. Статья не выглядит как полноценный чеклист, но можно использовать текст как основу для созданию персонального чеклиста в компании.

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

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

EventStorming Glossary & Cheat sheet

Если вы захотите провести event storming сессию в первый раз - cheat sheet с терминами перед глазами поможет не тратить время на поиски определений или избежать ситуаций, когда что-то забылось. Ребята из Domain-Driven Design Crew (советую посмотреть репозитории) решили облегчить жизнь и сделали список терминов, описание процесса и советы, которые могут помочь во время event storming сессии.

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

Tackling Complexity in CQRS

О CQRS в этом канале говорилось (была мастхев статья + стрим где делали блог платформу с CQRS на тему). Сегодня статья - описание ловушек, в которые можно попасть используя паттерн. Ловушки:
- One-Way Commands, or Overzealous Segregation
- Event sourcing
- Too Much of a Good Thing

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

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

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

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

OAuth 2.0 flows explained in GIFs

Мне сложно дается понимание и изучение видов аутентификации на “глубоком” уровне. Кажется, что проблема в большом количестве абстракций/терминов и коммуникаций между ними. И в ограниченном количестве визуальной информации (визуальная информация мной воспринимается проще, чем полотно текста). Сегодня статья - объяснение работы oAuth с помощью гифок с пошаговым выполнением каждого шага. Показывается работа пяти authorization flow и объясняются термины. Настоятельно рекомендую тем, кто сложно воспринимает текст и хочет разобраться в вариантах oAuth.

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

Microservices: monitoring and observability

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

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

Обзор книги “What Is Domain-Driven Design?”

В 2019 Vladik Khononov написал книгу “What Is Domain-Driven Design?”. Книга состоит из двух частей, разбора инструментов и техник для стратегического и тактического дизайна + практическая информация по двум пунктам. Обзор кратко рассказывает о каждом из инструментов и судя по топикам, которые указанные в статье - книгу стоит прочитать.

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

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

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

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

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

How we found and fixed a rare race condition in our session handling

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

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

Communication Between Loosely Coupled Microservices — Webinar FAQ

Транскрипция вебинары о коммуникациях в сервисах. Ценность ищите в описании коммуникаций (с пицца аналогиями), а также в вопросах. Личный топ вопросов:

- Some people recommend not using synchronous communication at all, but use asynchronous communication instead. But for fast tasks, REST seems fine to me and a broker just adds overhead and a point of failure. Can you comment?
- How to decide between commands and events?
- How is microservice orchestration better than point to point connections between microservices? Can you explain this via a metaphor?

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

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

Architecting a Scalable Permissions Service for SaaS Web Applications

Статья в духе: пишем шаг за шагом. В качестве авторизации будет использоваться RBAC. В начале автор знакомит с функциональными и нефункциональными требованиями, дизайном системы и моделью данных. Также используется лоад балансер, мастер/слейв репликации инстансов сервиса. А в качестве следующих шагов предлагается реализовать кеширование, инстансы на чтение и запись (непонятно что делать, когда после записи клиент сразу захочет прочитать данные). Если опустить вопрос: а зачем permissions делать в отдельном сервисе с синхронными коммуникациями - получается статья, из которой можно узнать способ реализации сервисов и вдохновиться тем, как сделать permissions в распределенной системе.