Страница телеграм канала Pepegramming

pepegramming logo

Pepegramming

587 подписчиков

Грустно о программировании. Все проблемы сюда: @davydovanton Ссылки на конкретные посты: http://telegra.ph/Pepegramming-Contents-03-11 Обратная связь: https://goo.gl/forms/iUd1Gufq6WnTsaO62


Входит в категории: Технологии
Pepegramming
05.11.2021 13:11
Пятничное чтиво После прочтения 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, софт скилы, интеграция, энтерпрайз архитектура.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
29.10.2021 13:10
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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, что приводит к дублированию логики между сервисами для разных клиентов.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
22.10.2021 13:10
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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. Понравилось, что упоминаются внешние системы (розовые стикеры), упоминание которых я видел только в книге и статьи с хабра.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
19.10.2021 19:10
Курс начнется послезавтра (в четверг), промокод на 10% - ptichka10
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
15.10.2021 13:10
Пятничное чтиво Последняя неделя до начала курса по асинхронным коммуникациям. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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, это либо идемпотентная обработка, либо хранить каждое обработанное сообщения и ничего не делать на повторах.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


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

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
08.10.2021 13:10
Пятничное чтиво Осталось две недели до начала курса по асинхронным коммуникациям. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Консистентно о Консенсусе Консистентность (согласованность) и консенсус два понятия фигурирующих в текстах о распределенных системах, которые могут вызвать путаницу. При этом, под консистентностью подразумевают логическую непротиворечивость данных, а под консенсусом - согласие группы касательно значения состояния. Автор текста не только описывает что есть что с примерами из реального мира, но и описывает возможные реализации консенсуса с классификацией. Для каждого подхода дается подробное определение работы и приводятся примеры. Если хотите разобраться подробнее в теме - однозначный маст рид. ————————————— Scalable logging for microservices Пример дизайна системы агрегации и обработки логов, из компании Carousell. Изначальные требования состояли из централизованного лога с фильтрацией и поиском, парсингом основных форматов логов, защитой от потерь. И при этом, надо что бы система магически интегрировалось в сервисы. Реализация состоит из: кастомного лог агента (сайдкар к контейнеру с приложением), лог сервиса, который консьюмит логи от агентов и кидает в кафку, части которая консьюмит логи из кафки, применяет фильтры и отправляет данные в Google Cloud Logging. В тексте найдете подробное описание компонентов, какие проблемы обнаружились у решения и идеи улучшения. ————————————— Microservices Patterns: Sidecar Короткая заметка о Sidecar pattern. Паттерн позволяет создать второй контейнер, который не может существовать без основного. При этом, сайдкар контейнер может переиспользоваться для других сервисов. Дефолтный пример использования - перевести сеть в кластере на https с помощью сайдкар контейнеров, которые в контейнер приложения уже гонят http. В статье найдете описание паттерна, примеры использования (агрегация логов, кеширование, конфиги и так далее), плюсы и минусы паттерна, а также советы по реализации. Если хотите разобраться подробнее - могу посоветовать книгу Designing Distributed Systems, в которой еще об амбассадоре можно почитать.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
01.10.2021 13: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.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
27.09.2021 13:09
Запустился второй поток курса по асинхронным системам В марте этого года решил, что будет хорошей идеей попробовать сделать курс с нуля. Поэтому, поговорив с Федей, мы сделали курс по проектированию и созданию асинхронных систем. За основы курса были взяты идеи и подходы, которые помогают мне в работе последние 4.5 года, которые были собранны в одном месте и дополнены доп материалом и примерами. За 4 недели я успел показать, как спроектировать систему (и почему проектировать надо начинать от бизнеса), а также реализовать эту систему, учтя проблемы эволюции данных в событиях. Уже к концу курса, кроме практики и теории асинхронных систем и коммуникаций, одной из главных ценностей курса оказалось обучение мышлению и как разбирать систему на части (чего сам не ожидал). По отзывам и комментариям - курс вышел полезным для учеников. А для меня этот месяц прошел в страхе и тревоге, но получив отзывы, убедился, что материал то, что надо. А когда прошло время и страх отпустил - захотелось сделать следующую итерацию и улучшить первую версию. Поэтому, я решил заапгрейдить курс и сделать материал еще полнее, засунув в него ответы на вопросы из первого потока, темы, на который казалось не хватит времени, и убрав неопределенность между темами. Бонусом, было решено изменить и картинку. Монтаж на коленке и запись с вебки добавляют атмосферы, но оказалось, что можно круче. Поэтому теперь курс записан в студии, с красивой картинкой, нормальными слайдами, а рисунки с айпада - мое уважение и снимаю шляпу. В этот раз затрону такие темы как: - coupling и cohesion. Решил больше о coupling рассказать, так как считаю это важным в контексте курса и коммуникаций; - transaction outbox / transaction log tailing паттерны; - личный опыт, в этот раз оказалось еще больше примеров из практики, выделил урок для примеров; - попсовые паттерны в виде CQRS, ES, SAGA и как паттерны могут в EDA использоваться (и почему они не являются обязательными); - больше внимания постарался уделить мышлению и обоснованию решений; - отшлифовал то, что было связано с проектированием, чтобы сложилась картинка и было понимание зачем нужен каждый из шагов; - захотелось сделать дз из которого получится "начальный" уровень, который в конце можно будет сравнить с конечным результатом. Кажется, что это поможет не только закончить курс, но и сравнить себя до и после; Курс стартует 21 октября, записаться можно тут, а если хотите спасти попугов - PARROT10 даст скидку в 10%.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
24.09.2021 13:09
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
17.09.2021 13:09
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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, при котором конфиг с описанием версий и сущностях, по которому вызывается нужная бизнес логика. Остаток статьи - описание последнего способа версионирования, включая список инструментов и библиотек без которых будет сложно внедрить подход, плюсы/минусы и примеры тестирования версий.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
10.09.2021 13:09
Пятничное чтиво 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”
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
03.09.2021 13:09
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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#, думаю и в других языках реализация будет похожей.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
27.08.2021 13:08
Пятничное чтиво Сегодня только две статьи, так как ничего интересного найти не смог за неделю. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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, то понравилось, что описываются возможные три состояния, а пример с оплатой карты оказался полезным для первичного понимания.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
20.08.2021 13:08
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— 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 не дропаем коннекшн, а ждем новые данные в реалтайме и обновляем курсор. Если конекшен прервался (даун или редеплой) - делаем еще один запрос и продолжаем обрабатывать события с последнего прочитанного. Стоит отметить, что у пул и пуш стратегий есть плюсы и минусы. И для каждого случая стоит выбирать архитектуру исходя из требований.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме