2pegramming

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Why, after 6 years, I’m over GraphQL Why, after 8 years, I still like GraphQL sometimes in the right context Споры вокруг надобности graphQL не утихают уже лет 8, поэтому сегодня две диаметральные статьи на тему graphQL, где говорится о диаметральных ситуациях и каждый автор описывает собственный опыт. Кто прав, а кто нет – решать вам. В первой рассказывается о проблемах, которые могут возникнуть при использовании graphQL для публичного API. Начиная с авторизации и получения доступов к данным. Сложности возникают, когда разные поля одного объекта могут быть как доступны, так и не доступны для пользователей, в зависимости от контекста. Следующая проблема – сложность в ограничении запроса на объем возвращаемых данных или циклических вызовов. Далее рассказывается о возможном OOM (out of memory) во время парсинга невалидных строк запроса, что также приводит к проблемам перфоманса (привет N+1 и проблемы авторизации с N+1). После, автор говорит о проблеме утекания бизнес логики в транспортный слой и проблемами связанными с HTTP кодами, жирными батчами данных и сложностью эволюции схем. В конце приводятся примеры технологий, которые могут заменить graphQL. Вторая статья – комментарий к первой, где автор рассказывает об опыте использования graphQL для приватного API. В самом начале, автор рассказывает о важности persisted queries, после чего пытается объяснить, что большая часть проблем с авторизацией либо связана с публичным API, либо также вызывает боль вне graphQL, что также относится и к ограничениям в запросах. В случае перфоманса, упоминается, что без dataloader жизни нет. Ну и в конце обсуждается как не допустить протекание логики в транспортный слой и как производить эволюцию API. Русский перевод первой статьи #sync_communications #graphql ————————————— Decentralized Identifiers as an Identifier Metasystem Одна из «mind-blowing» тем с курса по event-driven коммуникациям – meta id для ресурсов во всей системе, отличных от pk в каждом сервисе (это всякие public_id или global_id). В нормальном мире, за такой идентификатор отвечает identifier metasystem, например DNS, national ID, ISBNs у книг и так далее. В статье, автор рассуждает о том, можно ли использовать DIDs как identifier metasystem для системы. Текст начинается с объяснения терминов identifier metasystem и DID, после чего объясняется разница между DID и general identifiers (это условный pk из базы), при этом плюсы описываются с точки зрения улучшения характеристик системы (flexibility, interoperability и так далее). Дальше приводятся примеры использования. А в конце описываются потенциальные риски и возможные проблемы. #identifier ————————————— AWS Lambda Under the Hood Очередная статья из серии «как работает Х». На этот раз лямбды aws. В начале описывается что это такое и некоторая статистика по лямбдам (10+ триллионов запросов в месяц, сколько кастомеров и так далее). После чего рассказывается о двух способах вызова функций: синхронно и асинхронно. После рассказывается об управлении стейтом в функциях. А после, рассказывается о Assignment Service, который помогает с управлением вызова: показывается структура и функции которые выполняет. Потом говорится о микро vm – Firecracker, которая запускает функции изолированно, нужна для секьюрити и быстрого запуска. В конце поднимаются тема хранения информации (кода, данных). #how_it_works #aws #faas

Привет! Незапланированный пост с разными анонсами: 1. Канал уйдет в ежегодный летний отпуск на весь июль, т.е. с 29 июня по 2 августа постов не будет. Буду отдыхать и пытаться сделать новую рубрику хотя бы в этом году; 2. В субботу выступал в Питере, где попросили про EventStorming рассказать. Попытался подойти к теме с позиции «зачем вообще надо моделировать процессы и как ES тут помогает», вместо заходов про DDD и прочие модные штуки. Если уже знаете что такое ES и как его использовать - скорее всего будет не особо интересно; 3. Сегодня вечером, в 18 по Москве, буду на стриме у ребят из пхп комьюнити обсуждать рост разработчиков и как прокачать себя, если непонятно что делать после становления синьором-помидором. А если сами ищете спикера в подкаст – давайте поговорим; 4. В четверг начнется курс по системам. Попросили напомнить;

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Introducing the RIG Model - The Puzzle of Designing Guaranteed Data-Consistent Microservice Systems При переходе на сервисы возникает проблема консистентности данных. мало того, что strong consistency заменяется на eventual consistency, так еще и eventual consistency не гарантируется, особенно когда появляется saga pattern. Связанно это с тем, что так или иначе придется столкнуться с dirty read, lost update и так далее. Для решения проблем консистентности, авторы статьи, придумали RGI модель, которая расшифровывается как «Reversible, Irreversible, Guaranteed» и по сути, реализует SAGA паттерн с некоторыми условиями. Было интересно увидеть, что RIG вдохновлен event storming. А основная идея подхода – разделить поведение сервисов на три категории, в которых появляются сервисы, в которых бизнес транзакции (не путать с техническими транзакциями): - всегда будут успешны; - могут быть отменены в случае проблем; - сервисы, в которых бизнес транзакции нельзя отменить при возникновении проблем; После, авторы рассказывают об инструменте для создания подобных воркфлоу, правилах, требуемых для модели и RIG system design flow model #eventual_consistency #saga_pattern #distributed_systems ————————————— Understanding idempotent data transformations Не статья, а пост на форме dbt, в которой рассказывается о том, что на самом деле значит идемпотентная трансформация данных в контексте ETL и аналогичных инструментов. При идемпотентной трансформации данных должны соблюдаться следующие условия: - при остановке обновления сорса данных, полученный результат, после трансформации, всегда будет один и тот же; - если данные удаляются, данные можно восстановить с нуля; - если запущена трансформация в ручную, то она приведет к такому же эффекту, как если бы не была запущена (не понял эту идею, если честно); - если трансформация прервалась, следующий запуск приведет к такому же результату, как если бы прерывания не было; После объяснения идемпотентности и связи с трансформацией данных, показывается пример плохой трансформации, которая зависит от времени между запуском флоу. Пример связан с расчетом revenue за 24 часа, где данные собираются не за конкретный день, а за последние 24 часа. Если между запросами пройдет 12 часов - результат будет отличаться и идемпотентности не будет. После, рассказывается о ситуациях, когда идемпотентность для преобразования данных полезна: фейлы в etl, изменение бизнес логики, обновление схемы данных, удаление данных и так далее. #idempotency #data_managment ————————————— Race Conditions Don’t Exist Короткая статья из 2010 года с кликбейтным заголовком. Автор не говорит об полном отсутствии гонок, а объясняет, почему не стоит сразу делать сложное техническое решение для проблем, которых можно избежать изучив требования. Т.е. вместо того, чтобы идти и героически решать проблему, например с race condition, можно найти иную реализацию бизнес процесса и упростить жизнь технически. Для объяснения автор использует пример с оформлением и отменой заказа, которая вызывает гонку. Если разобраться в требованиях, окажется, что алгоритм изменяется так, что заказ отправляется в сборку не сразу, а через определенное время (в статье говорится о часе, но это не важно). Благодаря чему, ситуация с гонкой когда оформление и отмена заказа происходит одновременно исключается. Подобные ситуации встречаются в каждом проекте, в котором работал и если бы не этот лайфхак, то часть систем было бы слишком дорого делать. Поэтому однозначный мастрид. #requirements #race_conditions #system_analisys

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Preventing and Fixing Bad Data in Event Streams — Part 2 Как неоднократно упоминал, главная проблема асинхронных коммуникаций – фикс фиговых данных. Что бы этого не допустить, приходится усложнять решения, но даже такой подход не помогает со 100% вероятностью. Из-за чего, стоит помнить о способах решения проблем, если с данными что-то пошло не так и с этим поможет сегодняшняя статья. Автор начинает статью с объяснения принципов дизайна событий. Для этого рассказывается о двух видах событий: state и action (если от меня слышали о стриминг и бизнес событиях – это одно и тоже). Первые передают состояние на момент времени, вторые говорят о произошедшем действии. Дальше автор рассказывает больше о стейт событиях, как они могут быть сжаты и как из них может быть получено состояние в бд. Дальше говорится о том, как compacting может помочь избавится от разовых, некорректных данных (и конечно говорится о kafka connector). После чего, рассказывается о том, как фиксить данные в action событиях. Для этого предлагается использовать компенсаторную логику (undo), либо ретраи для событий. #async_communications #events #error_handling ————————————— You probably don’t need microservices Автор статьи описывает опыт работы с микросервисами с другой стороны. А именно с позиции проблем. Плюсом текста, является то, что автор сразу говорит, что технология ок. А после, рассказывает историю, как не зная ничего о микросеривсах, была сделана распределенная система, где главным драйвером распределенности были отличия в скейлинге разных частей проекта (о похожем подходе выноса сервисов как раз рассказываю в курсе, но только не ограничиваясь скейлингом). Начинается текст с 4 примеров, которые показывают, что архитектурный стиль используют скорее как серебряную пулю, чем осознанно: слишком много сервисов, связанность высокая, сложность системы неоправданно увеличивается, ну и использование сервисов в стартапах просто потому что модно. После чего автор приводит примеры светил индустрии (Scott Hannen и DHH), которые подтверждают примеры из начала статьи. В конце найдете вывод, что микрсоервисы имеют цену и важно помнить, что не всегда профит от стиля будет выше, чем цена, которую придется заплатить. Ну и принимайте прагматичные решения. #distributed_systems #microservices ————————————— What does idempotent mean in software systems? Тут важно сразу обозначить: статья не об идемпотентности, а скорее о транзакционности в контексте работы бд и отправки событий в брокер. Автор начинает рассказ с идемпотентности и объясняет, что это когда отправка одной и той же команды приводит к выполнению действия один раз. Дальше автор говорит про важность идемпотентности и, в качестве примера, приводит ситуацию, когда надо сохранить пользователя в бд и после отправить событие, что появился новый пользователь. В этот момент текст от идемпотентности переходит к транзакционности. Связанно это с ситуациями, которые возникают когда событие не отправилось, а запись создавалась, либо когда событие отправилось, но записи в бд нет. Как решение проблемы транзакционности отправки событий автор предлагает рассмотреть outbox pattern – подход, при котором события пишутся в основную базу (обычно это events таблица), а после, в отдельном процессе, отправляются в брокер. После чего автор описывает пример реализации outbox pattern на чем-то похожем на дотнет. #outbox_pattern #consistency

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

Привет! Федя предложил пообщаться на тему архитектуры и систем, надобности архитекторов и как принимать технические решения. А также ответить на вопросы, включая вопросы по курсам. И хочется верить, что холивар, связанный с system design interview, пройдет мимо стрима 🥲 Стрим будет в тг канале Феди (@pmdaily) в четверг, 30го мая (завтра), в 16 по мск.

Запустился третий поток курса по анализу систем и принятию технических решений Привет! В течении месяца будем учиться анализировать системы -- выбирать элементы системы, определять связи и свойства. Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview - курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину. Что будет: - Работа с требованиями и стейкхолдерами; - Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD); - Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями; - Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках; - Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»; - Как взаимодействовать с командой, основываясь на подобном описании; - Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее); - Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия; Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений. При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге, пройдя все сложности, получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц. Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали), а некоторые Полная программа и половина первого урока - на странице курса. Начало 15 ноября, до 6 ноября действует промокод 2PENALYSIS на 10% скидки до 1го июня. Марьяна отдельно попросила указать: следующий поток не раньше, чем через полгода. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Code sharing - Decision Node В распределенных системах (например микросервисах) возникает вопрос, как шарить одинаковый код, или одинаковый алгоритм между сервисами. Существует как минимум 2 варианта как сделать это: копировать код или сделать абстракцию, которая будет шарится (библиотека, сервис, сайдкар, etc). При этом, у каждого из подходов есть свои плюсы и минусы. Статья выше как раз рассматривает способы шаринга кода/алгоритмов в распределенной системе. Для каждого варианта присутствует пояснение, картинка, плюсы-минусы (не явно) и доп информация с возможными рисками (rolling out updates для копипасты кода, выбор между количеством зависимостями и размерами библиотеки, у сервисов трейдоффы описываются, а у сайдкара риски и как реализовывать). #distributed_systems #code_sharing ————————————— Designing Resilient Systems: Microservices Architecture Patterns Explained Статья – сборная солянка на тему «паттернов» в распределенных системах. Паттерны которые затрагиваются в тексте: - Load balancer, service registry и как это между собой работает; - Circuit Breaker и принцип работы паттерна (почему-то с api gateway); - EDA, что это, зачем и как работает; - Database per Service подход, какие у него плюсы и минусы; - Централизованная конфигурация сервисов; - BFF, CQRS, SAGA паттерн, Bulkhead паттерн; Для каждой из описанных тем присутствует описание, плюсы минусы, где-то трейдофы, где-то примеры библиотек. Важно понимать, что статья обзорная и тут нет хардовой конкретики по каждому паттерну. Скорее это статья которая поможет найти собственные белые пятна (или «i know what i don't know») по терминам, инструментам и паттернами, которые в будущем можно самостоятельно изучить. #distributed_systems ————————————— How Slack Built a Distributed Cron Execution System for Scale Статья из серии «как сделали X в <companyname>». В этот раз история о том, как слак реализовала скедулер в виде cron-a. Нужен крон для отправки `/remind` пользователям, отправки email нотификаций и клинапов базы для улучшения перфоманса. При этом, при не распределенном варианте крона возникли проблемы с maintainability тасок, со скейлингом и единой точкой отказа джоб. Из-за этого слак решил сделать распределенный крон, который состоит из 3 частей: - Scheduled Job Conductor – «оркестратор» задач, который по API притворяется дефолтным кроном; - The Job Queue – штука, поверх кафки, которая выполняет задачи от кондуктора, предварительно помещая их в редис; - Vitess Database Table for Job Tracking – персистанс для борьбы с дубликатами и отслеживанием статусов джоб. Сделан в угоду reliability системы; В статье найдете подробное описание реализации и проблем. Единственное, чего не понятно (может я слепой) – почему не взяли готовое решение. #how\it_works

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Evolution of Monolithic Systems Статья с рефлексией и рассказом об опыте работы с монолитами от человека с 20 летним стажем. Текст сводится к тому, что автор рассказывает о трех видах монолитов, с которыми сталкивался: - оригинальный монолит - организационный монолит - “Seven Technical Monoliths” Первый - о монолите в начальном этапе жизни, когда разработчик либо один либо пара человек. Технически это монолит с одной базой, сервером и кодом. Главный выбор такого монолита – TTM (time to market) превыше всего, но при этом, тех долг растет. Второй - когда MVP появляется, количество разработчиков увеличивается, становится сложнее его поддерживать и предсказывать что дальше делать. Третий состоит из семи вариантов, четыре простых (монорепа, монолитное приложение, сервер и бд) и три сложных (распределенный монолит, Cloud Native и GraphQL монолиты). Для каждого вида дается объяснение что это такое и какие ключевые свойства монолита. Понравилось, что автор, для каждого из видов монолитов, дает список “Key Design Investments”, которые могут помочь справиться со структурой. #monolith #system_structure ————————————— Understanding Quality Attribute Requirements for Machine Learning Systems Если проходили анализ систем или читали fundamentals of SA то знаете, что технические решения стоит выбирать на основе требуемых от системы свойств (например: распределенная система будет спорным выбором, если денег мало). Статья выше использует эту идею, но вместо веб приложений применяет ее к ML системам. Вначале дается краткое описание характеристик, откуда они берутся и какие существуют (если fundamentals читали - можно пропустить эту часть). После автор переходит к ML моделям, где обычно фокусируются на точности модели, но могут забыть о доступности, перфомансе или надежности. Дальше указывается список характеристик, на которые стоит обратить внимание, причем, даются референсы на работу букинга и пейперы. После, рассказывается как использовать эту информацию – зачем нужны Quality Attribute Scenario и описывается пример использования сценария для одной из ML моделей. #architecture_characteristics ————————————— The Turbo-Mailbox Статья рассказывает о способе коммуникации в мире enterprise applications, который называется Turbo-Mailbox. Данный подход работает вокруг сообщений между компонентами, роутит их и забирает на себя компромиссы из CAP теоремы. Такой паттерн работает как с синхронными вызовами, так и с асинхронными (сообщениями и событиями). При этом, для событий гарантируется «Once and Only Once Delivery», лоад балансинг из коробки, DLH, скалабилити и так далее. При этом, Turbo-Mailbox может работать как оркестратор, так как является federated. В статье найдете больше информации о паттерне, который пока выглядит слишком хорошо, но странно, что минусы и проблемы в тексте не упоминаются. Поэтому, советую скептически относиться. #enterprise_applications #communications

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму. ————————————— Serverless Communication Patterns Хоть статья о серверлесс приложениях, информация связанная с паттернами коммуникаций и reliability тактиками из текста будут полезны в любых распределенных системах. Начинается текст с описания частей из которых состоят серверлесс приложений: compute, storage, broker, event, integration и direction. После автор приводит примеры вопросов, которые возникают при выборе коммуникаций в серверлесс системах: синхронные/асинхронные, какой вид консистентности нужен, направление зависимостей и так далее. Дальше обсуждается какие виды коммуникаций используются в серверлесс мире (request/response, polling, event-driven) и каждый вид коммуникации подробно разбирается с примерами и картинками. А в конце, автор затрагивает тему reliability в контексте коммуникаций, т.е. как сделать так, чтобы система была отказоустойчивой и как выбор коммуникаций влияет на характеристику. Для этого рассматривается пять основных тактик (каждая так же подробно описывается с картинками): fail fast, graceful degradation, reliable states distribution, compensating transaction и softening dependencies. #serverless #reliability #communications ————————————— Транзакция, ACID, CAP теорема и уровни изоляций транзакций простыми словами Статья – выжимка информации по темам связанным с реляционными базами данных и консистентностью данных. Рассказывается про транзакции (в чем разница между коммитами и ролбеками), что такое ACID, немного говорится об CAP теореме (без упоминания о PACELC). В конце кусок об изоляции транзакций: сначала говорится о том, что может произойти с описанием ситуации (dirty read, non repeatable read и non repeatable read), после рассказывается о четырех уровнях изоляции транзакций и какая связь с возможными ситуациями вокруг транзакций и при чем тут перфоманс и консистентность. Если разбираетесь в темах описанных в статье – статью можно пропустить. Если хотите вспомнить базу перед собеседованием или что-то не знаете – лучше прочитать. #data_managment #consistency #db ————————————— 10 Must Know System Design Concepts for Interviews Скептически отношусь к system design interview, но вижу, что подобные интервью становятся популярнее. Поэтому сегодня будет статья, в которой указываются темы, помогающие в прохождении собеседования. Автор выделяет 10 тем: - Scalability - Availability - Reliability - Fault Tolerance - Caching Strategies - Load Balancing - Security - Scalable Data Management - Design Patterns - Performance Optimization Каждый блок кратко описывает тему и приводятся паттерны/подходы, о которых стоит знать. Важно понимать, что текст не претендует на книгу, а скорее перечень тем, которые придется детально изучать самостоятельно. Из плюсов – наличие инфографики, в которой перечисляются описанные в тексте темы. Русский перевод #system_design_interview