2pegramming

2021-04-30 13:31:00 Пятничное чтиво

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

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

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). Открыть/Комментировать

2021-04-23 13:31:00 Пятничное чтиво

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

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

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

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-ов, которые одной библиотекой реализуют набор неисправностей.


Русский перевод Открыть/Комментировать

2021-04-16 13:31:00 Пятничное чтиво

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

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

Как использовать 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; Открыть/Комментировать

2021-04-09 13:31:00 Пятничное чтиво

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

Слушайте везде (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, поэтому статья оказалась отличным стартом в разборе тем.

Русский перевод Открыть/Комментировать

2021-04-07 13:31:00 Осенью выступал в рамках курса о том, как быть тимлидом, где рассказал о архитектуре. В результате чего родился курс об асинхронных системах, который закончился на этой неделе и о котором хочется написать разбор.

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

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

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

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

#реклама Открыть/Комментировать

2021-04-02 13:31:00 Пятничное чтиво

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

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

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”, которые помогут сориентироваться, если используете сагу для технических ошибок. Открыть/Комментировать

2021-03-26 13:31:00 Пятничное чтиво

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

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

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 Открыть/Комментировать

2021-03-19 16:09:10 Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— How we found and fixed a rare race condition in our session handling Инженеры Github… Открыть/Комментировать

2021-03-19 13:31:00 Пятничное чтиво

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

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

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 в распределенной системе. Открыть/Комментировать

2021-03-12 13:31:00 Пятничное чтиво

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

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

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?”. Книга состоит из двух частей, разбора инструментов и техник для стратегического и тактического дизайна + практическая информация по двум пунктам. Обзор кратко рассказывает о каждом из инструментов и судя по топикам, которые указанные в статье - книгу стоит прочитать.

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

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