2pegramming

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Netflix Maps Thousands of Microservices in Real-Time Очередная статья о нетфликсе, в которой рассказано, как в компании решали технические проблемы. Сегодня текст о том, как в компании улучшали наблюдаемость системы, а именно строили граф связи сервисов. Для этого создали Service Topology, о которой и рассказывается в тексте. Текст начинается с описания мотивации компании: повторяющиеся вопросы о структуре распределенной системы от инженеров, которые систему чинили или меняли. Плюсом, полезно было бы сразу понимать, что заденет изменения в сервисах. Для этого решили собирать информацию с трех мест: eBPF network flow logs, IPC metrics (для эндпоинтов) и распределенные трассировки. Далее положили собранную информацию в графовую бд, подключили grpc, настроили фильтрацию (включая фильтрацию по времени работы) и получили «карту» системы. Причем, данные хранятся не как снапшот, а с привязкой ко времени, что позволяет собирать временные проджекшены. #how_it_works #observability #distributed_systems ————————————— Fundamental concepts of plugin infrastructures Чем дольше живу, тем больше думаю о недооцененности системы плагинов для создания софта. В частности, недооцененность microkernel архитектурного стиля. Хоть плагины распространены в редакторах, браузерах, играх и других приложениях, но считаю собственным долгом двигать эту тему в массы. Поэтому сегодня статья о четырех концепциях для реализации плагинов. Начинается текст с примера на python, где автор решает сделать blog engine для генерации html. Далее объясняется, при чем тут плагины и показывается подход, который нравится автору: через plugin registry, хуки и discovery через загрузку модулей. Во второй части текста описываются четыре концепции, о которых стоит помнить: discovery, registration, mount points и extension API. В конце рассматривается как в mercurial и wordpress реализованы эти четыре концепции. #microkernel #plugin_system ————————————— Как найти медленный запрос в PostgreSQL: три инструмента мониторинга Продолжение статьей о том, как оптимизировать запросы в постгрес. В тексте найдете описание трех инструментов: - pg_stat_statements. Отслеживает статистику выполнения запросов к бд, попутно группируя одинаковые по структуре запросы. Как примеры использования, приводится поиск частых и медленных запросов, а также запросов с низким уровнем кеширования; - auto_explain. Автоматически выполняет EXPLAIN ANALYZE для медленных запросов с записью плана в лог. Тут важно следить за количеством записанных логов; - log_min_duration_statement. Записывает в лог запросы, которые выполняются медленнее, чем заданный порог. Тоже важно следить за размером лога. Так как каждое из трех инструментов расширения — ставить каждое придется через изменение postgresql.conf (в статье описаны шаги для включения и настройки). В конце найдете «эвристику» для выбора, какое из расширений включать в зависимости от нагрузки и окружения (дев/стейдж/прод). #psql

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Сколько стоит ваш техдолг: методики, цифры, российская специфика В канале раз 5 упоминались статьи связанны с тех долгом, например «вводная» статья упоминалась год назад (остальные статьи по тегу). Сегодня еще один текст о долге, только авторы решили посчитать «долг» в рублях. Текст начинается с объяснения, почему тех долг не видит бизнес и наоборот. Авторы связывают отчетность и фокус внимания бизнеса, куда не попадает техническая составляющая, не говоря уже о долге. Далее предлагается три способа подсветить долг бизнесу: прямые опросы людей, добавление тега «tech dept» в «джиру» и git churn (показывает процент перезаписанного кода за время). В конце предлагается три способа «оценки» долга в деньга: - Считаем время, потраченное на затупы из-за тех долга и умножаем на часовую ставку. Берем цифру и показываем, сколько денег можно сохранить; - Берем SonarQube и SQALE, полученное значение умножаем на часовую ставку, идем к бизнесу и повторяем первый вариант; - Считаем cost of delay. Тут нужно посчитать задержку выхода фичи, в итоге получаем два числа: сколько времени фича реально делалась и сколько делалась бы без задержек. P.S.: Учтите, что статья в блоге компании, которая «продает» собственное приложение. На базовую информацию не влияет, но мало ли. #tech_debt ————————————— PostgreSQL 19: Native Graph Queries Are Here Случайно узнал, что осенью поменяю планы и буду ковыряться с постгресом. Связанно это с тем, что в сентябре выходит 19 версия, где главная, для меня, фича — нативная поддержка графов (хотя возможно гта победит графы). Почему-то уверен, что графы появились благодаря RAG и LLM. Синтаксис запросов уже описан в ISO SQL:2023 Part 16, а язык запросов назвали SQL/PGQ (Property Graph Queries). Статья выше объясняет как будет выглядеть работа с графами в пг. Пересказывать статью не буду, кратно расскажу как работает. Для начала работы с графами определяем property graph. Делается это через CREATE PROPERTY GRAPH, где явно указываются vertex (ноды, вершины) и edges (связи) таблицы (причем таблиц может быть больше одной). А что бы сделать запрос, используется SELECT * FROM GRAPH_TABLE (property_graph MATCH ...). Плюс стандарта в том, что язык запроса похож на cypher. В статье найдете примеры и, что радует, автор описал ограничения: fixed-depth pattern matching. Ну и другие фичи 19 версии тоже описываются. #psql #graph ————————————— What Is the 3-2-1 Backup Rule and Why It's Evolved to 3-2-1-1-0? Я не DBA, поэтому о правиле 3-2-1 слышал, но использую только для 3 наборов данных и это не о коде. Если что, 3-2-1 о том, что нужны 3 копии, на 2 видах носителей и 1 копия должна быть в другом гео месте. Поэтому удивился, когда увидел 3-2-1-1-0 схему, думая что 3-2-1 уже заморочена для 80% проектов, но киберпреступления повлияли на бекапы. Начинается текст с объяснения 3-2-1 подхода, быстро переходя в ответ на вопрос — почему такого подхода уже не хватает (спойлер: с шифровальщиками не помогает). Поэтому, как эволюция подхода, предлагается добавить 1 иммутабельную копию, отключенную от интернета и 0 ошибок от проверки восстановления (поэтому 3-2-1-1-0). Далее рассказывается, как реализовать новое правило: локальный бекап на диске, второй бекап на другом носителе, cloud copy, копия на ленте/в облаке с object lock и автоматизация накатки бекапов. В конце описываются best practices и FAQ (вопросы — пересказ статьи). Русский перевод #db #backups

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Scaling ArchUnit with Nebula ArchRules Статья от нетфликса, в которой инженеры делятся опытом решения проблем с обратной совместимостью совместимостью библиотек. А так как нетфликс использует джаву, то для решения взяли ArchUnit («тесты» для структуры проекта на джаве). Текст начинается с проблемы: библиотека обновилась с breaking changes, из-за чего развалились сервисы на джаве. Как решение управления жизненным циклом библиотек выбрали archnunit, потому что работает поверх байткода (т.е. работает в jvm стеке), позволяет добавлять правила и содержит низкоуровневый API для сложных правил. В самом начале работы, инженеры, решили настроить работу с централизованным стором правил для проектов (чтобы не копировать правила из проекта в проект). Далее описывается как запускаются правила и как работать с артефактами библиотеки. В конце описываются некоторые примеры правил (безопасность, применение nullable аннотаций и так далее) Отдельно отмечу, что в русском переводе встречаются комментарии от джава разработчика, который раскрывает части статьи для людей вне джава экосистемы. Отдельно упомяну первый комментарий (в тексте), где дается ссылка на реддит с обсуждением использования модулей, вместо archunit. Русский перевод #archUnit #fitness_functions ————————————— A Field Guide to Alternative Storage Engines for PostgreSQL Статья из серии «а что, так можно было?» (я не настоящий DBA). В 2019 году в 12 постгресе сделали table access method API. Предполагалось, что будут добавляться новые способы для хранения данных (колонки для аналитики, undo-log для OLTP и так далее). Автор текста выше решил написать, что из себя представляет экосистема. Текст начинается с объяснения принципов работы API. Тут важно, что TAM API не является «настоящим» pluggable storage layer, только tuple-shaped abstraction. При этом, индексы тоже не работают. Ну и механизмы разбиваются на 4 группы: - Heap replacements; - Columnar; - Lakehouse-backed (тут постгрес — интерфейс запросов поверх внешнего колоночного механизма); - Специализированные TAM модели (тут автор упоминает три решения, одно связана с TimescaleDB и уже умерло). Для каждой группы автор приводит примеры реальных проектов, кратко объясняя как TAM работает. А в конце делится советами по выбору подходящего TAM (если конечно решитесь). #psql ————————————— Building a mental model for Stripe payments Мне нравятся статьи в которых описывается реализация домена (8 лет жду аналога книги Фаулера). Статья выше — почти такая статья, потому что текст, в краткой форме, описывает принципы работы и объясняет работу стейт машины для PaymentIntent. Начинается пост с примера: делаете магазин, доходите до страницы оформления заказа — начинаются проблемы. Как минимум, придется думать о взаимодействии с платежными системами, банком клиента, anti fraud процессах, соблюдении нормативов и так далее. Далее рассказывается о PaymentIntent объекте: намерение получить платеж от клиента. Сам объект отслеживает жизненный цикл платежа от старта и до конца (картинка с sequence diagram прилагается). Далее описываются пять этапов, через которые проходит платеж (оформление заказа, токенизация, аунтификация, capture и расчет со сверкой). В конце описывается, как работать с вебкухами страйпа, что бы знать что с платежом происходит. Если устанете читать — на сайте сделали «терминал», где запускается змейка (вызывается на <c>). #payments #domain_implementation

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— A Promising New Metric To Track Maintainability Стараюсь пропагандировать ADD, где ключевая идея — принятие решений на основе характеристик. В случае с исчисляемыми метриками — вопросов нет. Сложности начинаются с «субъективными» и не исчисляемыми метриками, например с maintainability или modifiability. Поэтому сегодня статья, где предлагается математическую модель для расчета maintainability. Начинается текст с предположения, что coupling и cyclic dependencies помогут с расчетом, но, из-за вертикального и горизонтального разбиения, значения считать сложно. Как решение вводится понятие verticalization, благодаря которому, получается Maintainability Level через работу с циклами графа. Во следующей версии метрики, вводится штраф за «длину» цикла. После чего автор занимается fine tuning метрики. Для систем с малым количеством компонентов, метрика работала плохо. Вторая ситуация возникла, когда метрика показала «хорошее» значение, но разработчики были не удовлетворены поддерживаемостью. Проблема оказалась в структуре модулей, которую решили дополнительным условием. #maintainability ————————————— Why senior developers fail to communicate their expertise Проблемы в коммуникации между техническим отделом и «бизнесом» — база. Причин много: отличия в «важности» (у одних — сложность реализации фичи, у вторых — как инвестора на деньги разорить), разные цели от системы и так далее. Причин много, но автор статьи решил пойти по пути разбивки «бизнеса» на два цикла: вывод продукта на рынок и работа с платящими клиентами. Начинается текст с ситуации, когда бизнес приходит с гениальной идеей: «меняем разработчиков на LLM». От подобной идеи у разработчиков дергается глаз из-за сложности (complexity). Через конфликт, автор вводит первый цикл (в котором находятся продажники, продакт-менеджеры, CEO): компания выводит продукт на рынок и получает фидбек. В таком цикле главная проблема — неопределенность, которая решается скоростью получения фидбека. Во втором цикле, где компания предоставляет услугу пользователю и получает деньги, главное — стабильность, а со сложностью проблема. Далее автор связывает два цикла через «компанию» из-за чего получается несогласованность между людьми в разных циклах. В конце предлагаются решения, о чем уже прочтете в статье. Русский перевод #ppl_communications ————————————— On mashing up modelling techniques for fun and profit Статья заинтересовала идеей смешивания context map из ddd и c4 в одну модель. Если что, идея context map в отображении bounded context из DDD и связей между контекстами. А главная ценность — отображение паттернов коммуникаций из DDD. Добавив информацию о «типах» коммуникаций контекстов в с4, получаем больше информации о взаимодействии частей системы не только на техническом, но и на социо уровне (а software system — socio-tech system). Начинается текст с показа автором модели совмещенного context map и c4, которую сделали для воркшопа. А после объяснения плюсов подхода показывается как подобные модели делать. Сначала делается c4 level 1 с интеграциями, после чего добавляется level 2. Далее добавляются паттерны коммуникации на level 2 (open host, anti-corruption и так далее). После чего добавляются контексты и объясняется в чем плюсы и минусы подхода. В конце дается название подходу (Model Storming). Единственное что огорчило — нет конкретных инструментов, а статья сугубо идейная. #c4 #ddd

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Seeing like a spreadsheet Надо признаться — я фанат таблиц (которые sheets). И с каждым годом больше и больше верю, что если бизнес модель нельзя описать в таблицах, то лучше два раза подумать, перед тем как связываться с таким бизнесом. Автор статьи описывает собственные размышления о том, как таблицы поменяли бизнес в америки. Начинается текст с того, как работали до появления таблиц: как страдали коммуникации и почему бизнес был чаще семейным. Далее появляются заводы, следовательно требования к контролю увеличиваются, что приводит к развитию инструментов координации. Но проблемы проверки и расчетов никуда не девались, что привело к появлению таблиц в 60-70тых годах. Далее автор описывает появление VisiCalc (визуальный калькулятор) — прародителя современных таблиц, благодаря которому появился сначала lotus, а потом и excel. В последней части автор описывает как таблицы повлияли на симуляцию и финансы и в конце подвязывает нейронки. #sheets ————————————— Путеводитель по матанализу, который скрывали от вас в вузе На прошлой неделе упоминал статью с попыткой автора «натянуть» концепции из матанализа на код. Пока читал статью, понял, что матан уже забыл, поэтому сегодня — краткое интро в матанализ. Причем не список терминов, а логика развития идей Аристотеля, которые в конце придут к матанализу (в институте был только Коши, поэтому статья и появилась в канале). Сразу скажу, по ссылке лонгрид, также отмечу, что комментарии посмотреть тоже стоит (всего их 325 штук). Текст целиком пересказывать не буду из-за объема (3 части и 11 глав в сумме). Вместо этого расскажу о том, что самому было интересно прочитать. Во первых, понравилась, сама идея объяснения анализа через логические рассуждения, без эпсилон-дельта приколов (пример логического доказательства найдете в самом начале). Также понравилось, как размышления философов подвязали с бесконечностью и множествами. Плюсом, понравилось как вывелось определение производной через «о-малое». #math ————————————— Payment systems don’t move money. They move promises. Статья из серии «как работает Х». В тексте выше, автор, объясняет как работает payment processing, при чем тут две системы («быстрая» и «медленная», которые называет clocks) и почему в момент оплаты ничего, кроме «обещания оплаты» не происходит. Начинается текст с объяснения того, как работает «быстрая» система (говорит, что клиент намерен что-то сделать с доступным балансом). При этом, банк, в этот момент, не включается в процесс. В него только уходит намерение, которое может обрабатываться от секунд, до дней. «Медленная» система уже получает событие из банка и работает с ledger. Далее описывается «стандартная» ошибка: posting to the ledger inside the bank callback (нормального перевода не придумал, поэтому цитатой), что приводит к расхождению данных, дублям и другим проблемам. Далее описывается payout table, таблица, в которую пишутся намерения из «быстрой» системы и которую обновляет колбэк из банка. Ну а ledger уже использует payout table. А в конце, автор отвечает на популярные вопросы (зачем нужен баланс и ledger в разных местах, почему не взять CQRS или сагу и так далее). #payment #fintech

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo Очередная статья, в которой компания описывает, как решала проблемы в технической системе. Сегодня страйп, который сделал один из самых больших руби монорепозиториев (50+ миллионов строк). А возникшая проблема — как перестать гонять миллионы тестов на каждый PR. Спойлер: написали собственный анализатор измененных файлов, на основе которого запускаются только нужные тесты. Мне тема интересна, потому что в топтале (когда я там работал), тесты гонялись полчаса в 60+ потоков. А для решения похожей проблемы для подобной проблемы использовались сети петри. Текст начинается с описания проблемы: 50к сборок в неделю, 1.2 миллиона тестов, каждый раз гонять такое количество тестов возможности нет. Для решения проблемы в компании решили построить граф зависимостей, основанный на том, какие файлы вызываются во время прогона тестов (единственный способ для руби из-за «динамичности»). Сделали это с помощью библиотеки на с++, которая перехватывает «открытые» файлы на уровне ОС. Далее описываются корнер кейсы: что делать с тестами, которые только ищут файлы, что делать с областью видимости, как работает планировщик и выбирает тесты для нового кода. В конце описывается, где хранится мета по тестам (спойлер: в монге) и как хранятся «релизы». #how_it_works #testing ————————————— Математический анализ для разработчика: что действительно нужно понимать В институте проходил и матанализ и линал, в реальной жизни пригодился только линал (матрицы, вектора и пересечения плоскостей). А вот с матанализом не срослось, мозги вправило, но неопределенные интегралы, градиенты и любые эпсилоны больше нуля так и остались воспоминанем. Статья выше — попытка предположить, где абстракции из матанализа могут помочь в анализе кода. Так, автор начинает с области видимости функции. В качестве примера используется функция 1/x, которая не определена в точке 0, что приводит к ошибкам. Далее рассказывается о пределах, который привязывается к bigO. После рассматривается непрерывность и производные. Причем производная привязывается к определению «скорости» роста метрик (latency в случае текста). Далее рассматривается приближения и разложения Тейлора (когда сложная функция раскладывается на бесконечную сумму степенных функций) и многомерный анализ. Хоть текст написан нейронкой (уверен на 90%), статья дает повод подумать о том, где и как использовать абстрактные понятия в работе. #math ————————————— How to Pick a Database for Your System \(Without Guessing\) Еще одна статья о том, как выбирать базу данных, на основе требуемых свойств. В отличии от других статей, упоминавшихся в канале, автор решил выбирать по PACELC, а не CAP. Хотя текст и начинается с объяснения CAP теоремы, автор приходит к обсуждению ситуации, при которой availability и consistency не достижимы одновременно. Благодаря этому происходит переход к PACELC. А после показывается как выбирать между 6 бд (упоминается кассандра, монга, постгрес, редис, динамоДБ и cockroachDB). Для этого автор предлагает в основе выбора использовать характеристики из PACELC и вид бд. А в качестве дополнительных критериев — internal mechanisms и юзкейсы каждой из бд. #db

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Instacart Built a Search for Billions of Products Статья от компании instacart (аналог купера), в которой рассказывается о том, как решалась проблема поиска. Идея в том, что люди по разному ищут продукты. Запросы выглядят как «здоровые продукты», «соус для пасты 227г» и так далее. При этом, результат семантического поиска и поиска по ключевым словам должен соответствовать ожиданиям. Для этого, в компании, решили сделать два параллельных способа поиска, о чем в статье рассказывается. Текст начинается с описания проблемы с параллельными флоу поиска. Причем, особенность поиска в том, что товары быстро появляются и также быстро «пропадают» со склада. Для этого ввели два параметра для оценки поиска — полнота и точность. Далее описывается, почему отказались от elasticsearch (переиндексация на изменения подвела) и как переезжали в постгрес. Следующий этап — добавление семантического поиска с помощью FAISS, который заменили на pgvector. В конце найдете информацию о проблемах подхода и рассуждения о скейлинге поиска. #how_it_works #search ————————————— Going Critical С начала этого года разбираюсь в network science, поэтому сегодняшняя статья по теме. Текст выше о диффузиях в сетях, т.е. о том, как «информация» распределяется в сети (пожары, мемы в интернете, сплетни, вирусы и так далее). Причем статья интерактивная, что редкость для подобных текстов. А если думаете зачем читать о сетях — подобным образом можно симулировать отказы в software systems. Начинается текст с создания «простой» модели в виде сети 7х7, в центре которой «зараженная» нода. При этом, «заражение» происходит с 100% вероятностью для заражений. Далее вводится понятие SIR model, которая состоит из нод в трех состояниях (восприимчивый, зараженный, удаленный). Но такая модель не симулирует ситуации, когда «зараженная» нода перестает быть зараженной и становится снова восприимчивой. В таких случаях помогает SIS simulation (вместо удаления, нода снова становится восприимчивой). Далее рассказывается о critical threshold, точке «перелома» между субкритической и сверхкритической сетью. Также рассказывается о том, как симулируются «заражения» в разных частях сети, иммунитеты у нод, влияние degree (количество связей у ноды, причем, через degree можно «симулировать» города). Ближе к концу найдете примеры симуляции «знаний». А в конце автор рассматривает feedback loop между технологиями и знаниями (знания создают технологии, которые увеличивают знания). #network_science ————————————— The Map of System Topologies Текст выше — не статья в привычном смысле, скорее это попытка систематизировать архитектурные стили и паттерны вокруг структуры кода. Т.е. автор раскидал паттерны на плоскости, в результате чего получил пять «регионов», о которых и рассказывается в статье. В начале текста описывается методология, которой придерживался автор. Так предлагается делить паттерны на техническое разделение (слои), бизнес разделение (сервисы) и шардирование. В результате чего, от шардирования пришлось отказаться, как и от экзотики (в итоге я насчитал 40 паттернов). Далее, автор выделяет пять групп: - Monolithic, система целиком — один компонент; - Layered, система делится технически на слои; - Services, система делится по бизнес функциям; - Fragmented systems, система состоит из множества мелких частей; - Plugins, система состоит из cohesive core и модулей. В самом тексте подробно описывается каждая группа, причем с разбивкой на виды. Так монолиты бывают с плагинами, с auxiliary layers и так далее. А в конце найдете выводы автора по топологии. #patterns

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Why Root Cause Analysis doesn't work in Complex Systems Главная идея Root Cause Analysis — у каждой проблемы существует причина. Поймете причину — проблема больше не повториться. Звучит логично, но для «сложных» систем причины не явно связаны между собой, о чем рассказывает автор в статье выше. Текст начинается с объяснения идей и подходов из Root Cause Analysis. Тут найдете упоминание диаграмм Исикавы (если видели диаграммы в виде скелета рыбы — это оно). А также описываются «5 why?» и другие методы. Далее описываются недостатки RCA: наличие проблем возникающих из суммы причин, а RCA в такие проблемы не умеет. Эта мысль раскрывается через feedback loops, где изменения в одном месте, усиливает/ослабляет эффекты в других частях системы. В качестве альтернативного подхода, к анализу проблем, автор предлагает рассмотреть теорию ограничений (которую автор называет протосистемным подходом), flow diagrams и карты feedback loops. А в последней части текста автор предлагает 3 подхода к улучшающему вмешательству (PDSA и эксперименты) #system_analysis #system_thinking ————————————— Anti-patterns in event modelling - Passive-Aggressive Events Отсутствие событий — ситуация, с которой сталкиваюсь в каждом первом проекте, где реализуют асинхронную коммуникацию. Под «отсутствием событий» подразумевается то, что сообщения, которые передаются либо являются данными (UserEvent), либо командами (CalculatePrice), а не событием (фактом того, что что-то произошло). Статья выше о «скрытых» командах, т.е. «событиях», которые автор называет пассивно-агрессивными. Начинает автор с аналогий из реального мира, где встречается пассивно-агрессивный тон. Далее подводится идея, что подобный тон в событиях говорит о «скрытых командах», т.е. сообщение передает информацию, но ждет, что будет что-то сделано. Подобное поведение, автор, сократил до следующей фразы: «я свою работу выполнил, теперь твоя очередь». Далее возникает утверждение, что если передаем команду, а не событие, то придется делать синхронный вызов. На что приводятся мысли Сэма Ньюмана (написал книгу о микросервисах), что синхронная от асинхронной коммуникации отличается только блокировкой. После чего появляется еще один вид сообщений — документ (если курсы проходили, то это репликация). Ну и в конце рассказывается где использовать события, команды и документы. #event_driven ————————————— Why scrum is stressing you out Модели жизненного цикла принято критиковать за то, что модели перестали быть тем, что изначально закладывали авторы. Такая судьба постигла waterfall, аджайл и другие подходы. По ссылке выше, автор решил описать собственные мысли, почему скрам вызывает столько стресса. Важный момент: в тексте описывается не «каноничный» скрам, а то, что сейчас называют скрамом. В тексте найдете четыре причины почему скрам вызывает стресс: - спринты не кончаются. Т.е. нет периодов нагрузки и отдыха, как в том же waterfall; - отсутствие контроля у команд с какой скоростью надо деливерить и работать; - игнорирование подготовительной работы (обдумывание, обучение, отдых, рефакторинг и так далее); - создание scrumfall, гибрида scrum со спринтами и нагрузки из waterfall в «важный» дедлайн (релиза). Русский перевод #ppl_managment

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

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Keeping a Postgres queue healthy Статьи, связанные с реализацией очередей на постгресе, упоминались в канале еще шесть лет назад. Сегодня текст, который фокусируется на перфомансе очередей в инстансе постгреса, где содержатся основные данные. Начинается текст с описания проблемы: берем пг, в него пихаем очередь, а что делать с нагрузкой в таком случае не понятно. Причем, паттерн поведения в очереди строится вокруг того, что данные пишутся, единоразово читаются. А после, старые данные, необходимо удалить, чтобы база не распухала. Вот тут и начинается проблема, так как появляются dead tuples, т.е. записи, которые для базы «удалены» (запросы игнорируют данные), но в реальности, данные удалятся только после VACUUM. Далее приводится пример очереди jobs, состоящей из 4 колонок (pk, json, status и run_at). И подробно объясняется проблема dead tuples, которую автор симулирует. После объясняется работа вакуума и приводится список решений, которые помогут в удалении «мертвых» данных. #psql ————————————— The Math of Why You Can't Focus at Work В пятничных ссылках редко встречаются тексты связанные с продуктивностью. Связанно это с тем, что 99% подобных статей либо «сео» статьи, либо банальщина вокруг очередной настройки obsidian или todoist. Текст выше крутится вокруг относительно «капитанской» идеи: «меньше прерывания, больше сфокусированной работы, больше удовлетворения работой». Но вы читаете эту подводку из-за того, что автор решил доказать это утверждение используя мат модель, что редкость для подобных статей. Начинается статья с постановки проблемы, связанной с прерываниями. Для этого показывается «хороший» день, когда прерываний мало и в наличии 2 блока на 2+ часа для «глубокой» работы. А также показывается «плохой» день, где времени на «глубокую» работу — меньше двух часов в сумме. Из этого, автор выделяет три главных фактора «хорошего» дня: сколько раз в час прерывают, сколько времени требуется на восстановление концентрации, минимальная продолжительность блока осмысленной работы. И тут же появляется мат модель, которую автор визуализируют. А самое интересное начинается, когда берутся данные о количестве прерываний из исследований, а в визуализации нет времени на работу. Во второй части статьи автор делится советами, как улучшить ситуацию (с проверкой через модель). #productivity ————————————— Какой минимум симптомов нужен врачу для постановки диагноза Не смотрите на название статьи, текст о теории грубых множеств и о том, как определить «значимые» факторы из выборки. Просто для примера автор решил определить важные симптомы для определения диагноза болезни. Текст начинается с истории появления теории грубых множеств, основанной на теориях вероятности и нечеткой логике. А главная идея вертится вокруг согласованности, т.е. ситуации, когда нет объектов с одинаковыми признаками или симптомами, но разными «диагнозами». Причем, размер выборки не важен, даже 10 строк в таблице хватит. Кроме согласованности, придется еще разобраться с вектором значимости и суперредуктом и редуктом. Далее, на примере симптомов и болезни, описывается алгоритм поиска важных признаков. А в конце приводится пример кода на julia. Если говорить о применимости теории в IT, то первое о чем подумал, когда читал текст — было бы интересно воспользоваться теорией для анализа постмортемов. Т.е. берем происшествия, выделяем признаки, после чего получаем вектор значимости для признаков. А на «важные» признаки тратим больше ресурса на проверку в релизах и ежедневной работе. #data_analysis

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— The Myth of Individual Excellence: Why Systems Matter More Than Talent Addendum: The Myth of Individual Excellence Сегодня две философские статьи по цене одной. Обе раскрывают идею: «хотите эффективности — думайте об изменении системы». Автор начинает с вопроса «почему компании с ресурсом так плохо достигают результатов?», что приводит к мифу индивидуализма. Точнее к тому, что результаты достигаются благодаря таланту, интелекту, труду и так далее. Но по итогу, рассуждения приводят к тому, что ответ сложнее и эффективность, в первую очередь, зависит от конкретной системы. Т.е. если в школе учитель будет тратить 90% времени на заполнение документов и 10% на обучение, то эффективность обучения будет хуже, чем в школе, где пропорция обратная. В случае эффективности рабочих команд и технических систем — проблемы аналогичны. По этой же причине, со слов автора, изменения проваливаются, так как не учитывают структуры и условия систем, а фокусируются на отдельных людях. Вторая статья появилась из-за недопонимания идеи из первого текста. И во второй попытке, автор, пытается глубже раскрыть связь эффективности и системы через три примера из жизни. Из интересного: понравилась идея, что противопоставлением individual-as-cause будет method-and-system-as-cause, а не коллектив. #system ————————————— Как построить банк на 130 миллионов клиентов с помощью Clojure Сложно придумать подводку к тексту, поэтому как есть. Автор рассказывает внутрянку бразильского банка Nubank, которые выбрали clojure с datomic и по итогу стали крупным бизнесом (не факт, что благодаря технической системе). Начинается статья с исторической справки появления банка (в бразилии была «монополия» пяти банков, ставки по кредиткам 450% и население не пользовалось банками). В итоге, сделали кредитку, проект выстрелил и овнеры остались довольны. Дальше начинаются технические детали: первое техническое решение связано с выбором datomic (иммутабельная бд), из-за чего выбрали clojure как язык для бекенда (как единственный вариант). В результате такого выбора, в 2020 году, банк выкупил компанию Рича Хики, о чьих идеях автор рассказывает. Далее описывается что такое datalog (подмножество пролога, которое с бд работает) и как в datalog упрощены рекурсивные вызовы. #clojure ————————————— Designing the Unknown Одно из моих хобби — изучать абстрактные концепции. Сегодня речь пойдет о concept-knowledge theory, которую придумали в 2003 году для работы с инновациями. Появилась концепция из-за того, что люди научились работать с четко определенными проблемами, а с неизвестными штуками возникли проблемы. И главная идея оказалась в вопросе: «а что если начать изучать проблемы как развивающиеся во времени». А по ссылке выше найдете вводную информацию в c-k theory. Текст начинается с объяснения причин появления c-k theory. А дальше описываются главная идея — выделяют два пространства, концепций и знаний. По этой логике, работа с инновациями сводится к четырем шагам: - k->c. Благодаря знаниям появляется концепция; - c->c. Концепция усложняется и развивается; - c->k. Изучая концепцию появляются новые знания; - k->k. Знания, полученные из концепции, развиваются, превращаясь в новые знания, которые создают новые концепции. Во второй части автор описывает плюсы подхода и приводит пять примеров, когда использование c-k помогло в решении проблем. Главный минус текста — слишком абстрактно и практическая применимость сводится к «нарисуйте овал, который превратиться в сову». #c_k_theory #rnd

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Emergent properties Если верить теории систем, отличие между «связанными элементами» и «системы» — в наличии эмерджентных свойств. Это такие свойства, которые образуются только во время работы системы целиком, т.е. свойства, которых нет у отдельных элементов системы. Любимый пример: песочные часы умеют отсчитывать время, а песок, стекло и подставка по отдельности — нет. При этом, свойства могут быть как «хорошие» (отсчет времени), так и «плохие» (шатдауны, которые strong emergence). В статье выше, автор, решил разобраться в эмерджентности чтобы доказать, что llm не только генераторы токенов. Текст начинается с понятия редукционизма (чтобы понять систему нужно понять элементы системы), где возникают resultant свойства. Подход работает ровно до момента, когда свойства появляются как результат действия и тут автор переходит к эмерджентности (отдельно отмечу пример с «креативными» статуями). После чего появляются понятия времени и «неизвестного неизвестного». Дальше объясняются виды эмерджентности (strong и weak, еще встречается simple, не описанный в статье). Отдельно понравилось, что рассказывается о характеристиках систем с эмерджентными свойствами. Ну и в конце подвязывается LLM и наличие у модели эмерджентных свойств (до тех пор, пока не поймем «магию» работы). #system_theory ————————————— Pace Layering Сразу предупреждаю, текст и тема не формат ссылок. Но концепция pece layering, описанная в ссылке выше, помогает взглянуть на тренды и технологии под другим углом. Ну и я редко слышу об этой концепции от других людей, что повлияло на добавление ссылки. Концепция предложена Stewart Brand (футуролог), во время работы над развитием зданий (каждый раз поражаюсь количеству идей из строительства, которые не ушли в другие области). Идея в том, что разные части здания развиваются с разной скоростью и «сдвигаются» относительно друг друга. Выделяют 6 слоев: fashion (меняется быстрее остальных), commerce, infrastructure, governance, culture и nature (меняется медленнее остальных). Слои обмениваются информацией между собой, благодаря чему верхние слои «влияют» на нижние. Так, благодаря двум энтузиастам появился markdown, который стал «стандартом» (в тексте найдете пример ежегодным обновлением авто благодаря моде). В обратную сторону обмен тоже присутствует: так без нижних слоев не будут работать слои выше (прибыль от научных исследований ждать не выгодно, поэтому государство спасает, а без науки коммерция не продаст новую технологию). В конце добавлю, что иногда полезно остановиться и подумать в каком слое происходят изменения. И как эти изменения влияют на слой, в котором вы крутитесь. #changes ————————————— Building a graph database using kafka Разбавлю абстрактные тексты статей от автора, который любит делать базы данных поверх кафки. Сегодня текст о том, как взяв кафку получить графовую, document и wide column базы данных. На самом деле, автор читерит и вместо реализации с нуля, берется HGraphDB, которая работает поверх клиента к HBase. А так как никто не мешает реализовать идентичный HBase API в другой бд, то задача сводится к созданию wide column store поверх кафки. Что автор и сделал, взяв за основу KCache (об этой k-v бд упоминалось в ссылках ранее). А что бы реализовать document DB, берется HDocDB — document DB базой поверх HBase (а реализация API через кафку уже написана). В конце автор описывает эксперимент с JanusGraph, который также может работать через HBase. Но вместо HBase, автор интегрирует KCache в JanusGraph (janus поддерживает k-v через BerkeleyDB). #kafka

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Datadog Built a Custom Database to Ingest Billions of Metrics Per Second Очередная статья от компании, в которой описывается решение специфической проблемы. Сегодня это datadog (мониторинг приложений), который столкнулся с проблемой хранения и управления данными. Для чего создали monocle — time series storage для хранения реалтайм метрик. Текст стартует с описания структуры платформы метрик, которая отвечает за сбор, обработку и отображение информации по метрикам. Главная идея в том, что есть два места, где метрики храниться могут, либо в долгосрок, либо для real-time штук. Далее описывается, что надо хранить для реалтайма — данные (дата + значение) и метаданные (теги). И в этот момент появляется кафка, в которую сначала попадают все данные, а после раскидываются по инстансам базы, которую написали в компании. Так как решение кастомное, то и схему хранения данных переписали на map вида «хеш метаданных -> список пар (timestamp, value)», что позволило хранить данные в одном месте. В конце статьи найдете описание того, как бд работает и как происходит параллелизация. #hot_it_works #data_managment ————————————— Holistic Engineering Так как software systems — социо-технические (код и люди которые работают с кодом), то заниматься только технической составляющей не выйдет. Так, «идеальный» с точки зрения ТТМ код, приводит к задержкам в релизах из-за отсутствия навыков или иными предпочтением у разработчиков. Поэтому, при проектировании решений придется учитывать еще и социальный аспект, о чем рассказывает ссылка выше. Текст начинается с обсуждения трех ситуаций, в которых «социо» влияет на «техническое»: - над одной частью системы работают разные люди со своими целями, знаниями и мотивацией; - разные вещи называют одним словом (пример — user, который и клиент и админ и кто угодно); - когда для решения задачи, не к месту, вкладываются знания из прочитанных книг за последние 3 года. Во второй части описывается холистический подход к проектированию, в котором придется еще учитывать не технические факторы, которые автором делятся на внешние (тренды, события и так далее) и внутренние (сотрудники, орг структура, системы вознаграждений). В конце найдете четыре примера использования холистического подхода для решения проблем. #socio_tech_systems ————————————— Rewilding Software Engineering Создатель ворлди карт (Саймон Вордли) пишет новую книгу онлайн. Книга называется Rewilding Software Engineering и пока публично доступно шесть глав. Сегодня ссылка на шестую главу, где рассматриваются мифы вокруг software разработки. Сразу предупрежу — «статья» прямо лонгрид лонгрид, поэтому, вместо краткого пересказа — опишу что жать от текста. В главе рассматривается восемь мифов, которые автор пытается развенчать (в скобках его позиция): - Software engineering только о том, чтобы функционал реализовывать (на самом деле о структуре); - Технический рефакторинг не нужен бизнесу (нужен, так как знания о бизнесе, из голов сотрудников, утекли в код); - Software engineering — инженерия (нет и для объяснения мифа используется тестирование); - LLM заменят разработчиков (тут о переосмыслении использования LLM и трансформации разработки в инженерию); - Архитекторы принимают решения (решение принимает тот, кто делает, а не кто придумывает) - Жить с легаси тяжело (нет, если инвестируете в инженерию); - Не технические люди не могут понять код (с инструментами могут); - Тех долг (идея в том, что причина тех долга в скалярных величинах, например KPI, которые жить мешают). #software_engineering

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Netflix Tudum Supports 20 Million Users With CQRS Очередной текст о том, как работает netflix. Сегодня статья фокусируется на Tudum — платформе для бекстейдж видео, интервью и прочем подобном. Изначально проект делался по заветам CQRS, деля запись и чтение. Но спустя время возникли проблемы с задержками между сохранением материала и его предпросмотром, инфраструктурной стоимостью и затратами времени на создание постов. Текст выше рассказывает о эволюции сервиса. Начинается статья с описания изначальной структуры: вызываем команды, асинхронно (с eventual consistency) реплицируем данные в read model. Важный момент, что в write model хранится метаинформация, при этом, в read model, данные уже подготовлены для пользователей и без лишней информации. Далее описываются проблемы (процессы, кеш, eventual consistency, апдейты и так далее). В качестве решения взяли RAW Hollow — compressed, distributed, in-memory object store, вместо кафки (в тексте найдете основные свойства базы). #hot_it_works #cqrs ————————————— What We Learned Migrating to a Pub/Sub Architecture Еще одна статья о том, как в компании решались технические проблемы. В данной статье описывается ритейл платформа, с 4к+ рпс. Проблема оказалась в монолитном решении, которое переписали на микросервисы с асинхронной коммуникацией (конечно же с кафкой). Текст начинается с объяснения мотивации миграции на сервисы. Тут про масштабируемость, отказоустойчивость и проблемы с ТТМ. В начале, в компании, описали «основные» события и сделали драфтовую модель новой структуры, для масштабирования думали горизонтально скейлить кафку. Далее описывается новая структура коммуникаций, где взяли каждый элемент продюсит собственные доменные события с версиями и подписывается на то, что нужно для работы. После описывается как скейлили кафку через партиции (очевидная история с количеством партишенов == количеству консьюмеров в групе), плюсом подумали об ack. В части моделирования событий описывается опыт версионирования и использования schema registry. А для reliability используют DLQ и ретраи. Понравилось, что есть секция с обсервабилити, где описывают как логируют, какие метрики используют и упоминают correlation. В конце найдете выводы и советы, если захотите подобное разворачивать у себя. #how_it_works #async_communications ————————————— Surviving the 300,000 Request Spike: How I Built a Self-Healing Rate Limiter В случае специфического контекста «стандартные» решения могут только навредить. Текст выше описывает такой случай. Идея в том, что автор решил взять готовый rate limiting и на нагрузке в 30к возникла проблема с работоспособностью системы. В результате пришлось писать собственную реализацию, которая выдерживает 55к рпс. Начинается статья с объяснения работы Token Bucket алгоритма (на каждый запрос проверяем наличие токена в сторе), который используется по дефолту для реализации rate limiting. Причем, реализуется алгоритм поверх redis и скриптов с lua, которые нужны для исправления race condition. И для высокого рпс, большая часть времени запроса проходит в redis. В качестве решения, автор предлагает собственный подход, основанный на distributed mesh и трех уровнях (клиентском, агрегаторах и контроллерах). А что бы rate limiter заработал, вводится понятие drop ratio, которое говорит на сколько необходимо уменьшить текущий трафик. Кроме этого, в статье найдете расчеты и минусы подхода. #high_load

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Why are Event-Driven Systems Hard? К сожалению, встречаю ситуацию, когда отправка рандомных данных в брокер называют event-driven (архитектурой или коммуникацией). Но если хотите event-driven коммуникацию — придется думать о том, что отправляется (нужны события, а не команды), откуда события приходят, кто и почему на них реагирует, как добиться эволюционности событий. Кроме этого, возникают проблемы с обсервабилити и обработкой ошибок (как фейлы, так и потери). Статья выше — краткое описание часто встречаемых проблем в event-driven коммуникациях. Начинается текст с объяснения, что такое событие (факт, который уже произошел и который невозможно отменить, только компенсировать). Ну и дальше автор затрагивает тему эволюционности, точнее нарушение совместимости схемы и дальнейший фикс через версионирование схемы (за упоминание schema registry — лайк). Следующая тема связана с обсервабилити. Тут упоминаются трассировки и correlation_id. После рассказывается о том, как обрабатывать ошибки. Тут огорчило, что упоминается только DLQ. Также рассказывается об идемпотентности. И в конце найдете упоминание консистентности. Важно: учитывайте, что это текст проходит темы по верхам. Будет полезно только как список тем, который стоит помнить/знать, без деталей. Русский перевод #event_driven ————————————— Data Access Patterns in Microservices Статья из серии «Х вещей, которые стоит знать». В данном случае автор описывает пять паттернов, которые помогут в передаче данных между элементами тех системы. А если точнее, то между сервисами в распределенных системах. Первым описывается «антипаттерн» Direct Database Access, при котором сервис A читает данные из базы сервиса B. Причина, почему автор считает этот подход анти паттерном — coupling и consequence. Далее описывается четыре подхода, которые предлагаются взамен прямому вызову бд: - API Access (причем учитывается и реализация с репликой/кешом) - Asynchronous Requests (тут только асинхронный request-response вариант) - ETL - Pub/Sub to maintain Replica (тут event-driven вариант репликации данных) Для каждого подхода указывается концептуальное описание, картинка с имплементацией и где подход работает. Статья поверхностная, поэтому не ждите деталей имплементации или малоизвестных фактов. #data_managment ————————————— Growing a platform: Introducing API versioning in Intercom Продолжая тему коммуникаций и версионирования. Статья от компании intercom, в которой поделились опытом версионирования API. Причем API публичного, не внутреннего. Статья короткая, но идея с чейном изменений для получения нужной версии интересна, вместо того, что бы делать копии эндпоинтов под каждую из схем. Начинается текст с объяснения проблемы: в компании появился блокер на изменения схемы публичного API, так как интеграции с клиентами не предполагают, что уведомления об изменениях хватит. Поэтому в компании решили сначала пообщаться с клиентами и понять, как API используют. Благодаря чему появился подход, основанный на библиотеке серилизации, которую разработали в компании. Суть подхода в «чейне» изменений на каждый запрос. Т.е. делается прослойка, которая накатывает последовательно изменения в схеме для запроса (v1->v2->v3...), после чего, для ответа происходит аналогичная операция, но в обратную сторону (3->2->1). В тексте найдете примеры запроса (на руби) и детали имплементации. #communications #evolution

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Uber Reinvented Access Control for Microservices Статья о том, как в убере решали проблему получения доступов в микросервисах. Для этого разработали charter, систему контроля поверх ABAC. Текст начинается с примеров того, что нужно компании, касаемо прав доступа. Причем, хоть права крутится вокруг акторов, но акторами могут быть как люди, так и другие сервисы. Ну а сам запрос строится по шаблону «актор, действие, ресурс». Далее рассказывается о Charter, отдельном элементе, который хранит полиси, где определяется кто и к чему имеет доступ. Причем, как полиси выглядят — в тексте также показывается. А что бы полиси работали в конкретных сервисах — в компании сделали authfx, библиотеку, которая проверяет доступы на основе полиси из сharter. После идут объяснения, почему был необходим ABAC, а не дефолтный RBAC. Плюсом, объясняется, почему для описания полиси был выбран Common Expression Language (CEL) от гугла. В конце найдете пример того, как система решает, может ли кто-то писать в топик кафки или нет. #how_it_works #auth ————————————— Did you know? Tables in PostgreSQL are limited to 1,600 columns Не уверен, что кто-то в реальности столкнется с лимитом на 1600 колонок в таблице, но текст интересен в разрезе TIL. Статья выше появилась благодаря разговору автора. И начинается текст с отссылки на документацию постгреса, где говорится о максимальном количестве колонок в таблице в 1600 штук. Данное ограничение — хардкод, которое подтверждается автором, через баш скрипт, который создает 1601 колонку. А дальше начинаются эксперименты с таблицей. Первый связан с 1599 записями char(127), второй — с попыткой заджойнить две «1600 таблицы» (будет ошибка), а третий — с попыткой добавить и потом удалить колонку 1600 раз (при 1601 разе будет ошибка). Причем, в третьем случае вакуум не поможет, а автор предлагает два способа, как преодолеть лимит. #psql ————————————— Supporting the transition to Self-Contained Systems using Architecture Fitness Functions at Scale Мне нравится тема верификации систем, поэтому не могу пройти мимо статей связанных с фитнес функциями (также известными как функция пригодности). Сегодня как раз такой случай, хотя статья выше больше о том, как интегрировать в компании Self-Contained Systems. Текст начинается с описания того, как в компании Swissquote происходит адаптация SCS. Главная проблема которая возникла — сложности в отслеживании того, как старые части системы переходят на новый подход. Для чего решили воспользоваться фитнес функциями. Далее автор описывает какие функции применяли, причем используется 16 функций. Далее рассказывается о том, как проверяют приложение на соответствие свойствам. Тут интересен подход, в котором функции интегрируются с командами и тех направлениями. Плюсом, в компании решили добавить «геймификацию» с выдачей медалей о том, как «хорошо» части системы соответствуют требуемым свойствам. Русский перевод #fitness_functions

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Building a Database on S3 На первый взгляд, s3 и базы данных не совместимы. Но автор пересказывает пейпер от 2008 года, где предлагается разделить storage и compute, в результате чего получить stateless clients, которые и выполняют транзакции. Начинается текст с объяснения главной идеи — использования SQS (очередь от aws), как wal лога. В таком случае, клиенты пишут каждое изменение в sqs, вместо того, чтобы ходить на прямую в s3. Далее описываются детали того, как стоит отправлять данные в очередь и что еще необходимо сделать, чтобы собрать стейт. В конце найдете описание isolation guarantees и почему о строгой согласованности можно забыть. Отдельно отмечу, что автор не только пересказывает основные идеи пейпера, но и добавляет собственные комментарии, где сравнивает идеи из 2008 года, с реализацией современных бд. #db ————————————— Retry Storms В прошлом году, в канале упоминалась статья о ретраях. Там описывались основные способы не выстрелить в ногу, добавляя «обычный» ретрай и упоминался retry storms. Сегодняшний текст — как раз дает «базу» связанную с подобными «штормами». Текст начинается с объяснения retry storms, который возникает, когда падает сервис А, а другие элементы системы начинают делать retry для запросов в сервис А. Когда сервис А восстанавливается, лавинообразное количество запросов из-за ретраев снова кладет сервис, что приводит к тому, что из деградации, система скатывается в systemic instability. Далее подробно объясняется эффект (с картинкой). Далее автор упоминает, что circuit breaker не решает подобной проблемы, а некорректные границы сервисов повышают вероятность возникновения «шторма». Далее поднимается интересная тема, связанная с разницей в поведении между человеком и AI, первый быстрее сдается в случае проблем системы и перестает отправлять запросы, а AI будет работать до победного. Что приводит к увеличению «окна» проблемы. Последняя часть текста связана с тем, как исправлять ситуацию. Автор предлагает перенести retry management из элемента, на уровень системы целиком. #retries ————————————— Understanding the Origins and the Evolution of Vi & Vim Пользуюсь вимом последние 13 лет или больше (так и не научился закрывать редактор). Поэтому было интересно найти историю того, как редактор появился и развивался. Хоть и знаю о ex и ed, но автор смог накинуть новых фактов в голову. Так, узнал о том, что емакс был платным и узнал о существовании en и em редакторов, как и об Elvis — vi клоне для MINIX, в котором буфер храниться не в памяти, а на диске. Сам текст начинается с истории ed — линейный текстовый редактор, который разработали для телетайпов (до сих пор используется в unix). Далее рассказывается о em, который создали для «упрощения» ed. После чего автор переходит к ex, который развивал идеи em, а добавление визуального режима превратило редактор в vi. По сути, vi и ex отличаются только наличием визуального режима, благодаря которому можно просматривать текст файла целиком. Тут же рассказывается почему для перехода между строк используется hjkl клавиши (стрелок тогда не было на клавиатурах). Вторая часть текста посвящена клонам vi, тут найдете информацию о stevie, elvis и vim (который изначально строился поверх stevie). Единственный минус текста — автор не дописал продолжение о neovim. Русский перевод #history

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— The First 10-Year Evolution of Stripe’s Payments API Очередная статья «как в компании X решали проблему Y». На этот раз это страйп, который решал проблему развития собственного API. Может показаться, что около 10 строк кода — легко поддерживаются. Но на деле, за строками скрываются десятки стран, в каждой из которых собственные законы, банки и способы оплаты. Статья выше описывает 4 этапа развития компании (с 2011 по 2020 года). Первый этап с 11 по 15 года, когда появилась концепция «токена». Т.е. вместо того, чтобы отправлять информацию о карте в магазин, данные отправлялись из браузера на сервера страйпа, возвращался токен и с этим токеном можно было работать (этот лайфхак сам использую для работы с персухой). Второй этап с 15 по 17 года. Тут появляются новые способы оплаты (что усложняет API). Тут возникла проблема с асинхронными платежами и отслеживанием платежей со стороны продавцов. Третий этап с 17 по 18 года посвящен решению проблем со второго этапа. В результате появился универсальный API для любого из видов платежей. Тут же появляются новые абстракции и правила к API. Четвертый этап связан с тем, что универсальный API оказался слишком сложным для интеграций, следовательно пришлось решать проблему «продажи». #how_it_works #payments ————————————— Being an architect isn’t the sum of skills. It’s the product. Статья от автора книги Architect Elevator, в которой рассуждается о смысле архитекторов как о роли. Связано с тем, что software systems уже давно не technical, а socio-technical systems (тут должна быть отсылка на ТТ), что подтверждается переходом на service модели (это о бизнес услугах, а не о микросервисах). Статья начинается с утверждений вокруг «важности» восприятия IT как socio-technical systems. Далее автор вспоминает девиз консалтинговых компаний «people, process, technology» и через него объясняет где находится роль архитектора. Что приводит к мысли о том, что роль — множитель, а не addition (не добавляет ценность, а умножает то, что есть). Далее приводится три примера этого утверждения: объяснение другим тех решений, руководство тех командой и платформы. #architect_role ————————————— When Should I Write an Architecture Decision Record Если открыть статью об ADR, то в 90% случаев в тексте найдете пример шаблона, какие инструменты использовать и где/как хранить документы. Текст выше попадает в оставшиеся 10%, так как затрагивает вопрос: «когда писать ADR, а когда можно забить?». Начинается статья с преимуществ, которые получил Spotify (музыкальный стриминг) при внедрении ADR. Сюда попал онбординг, помощь с передачей ответственности за части системы и унификацию решений для разных команд. Далее описывается когда документ нужен (когда «решение имеет существенное влияние»). Так как «существенное влияние» субъективный термин, авторы описали три ситуации, в которых стоит задуматься: - Присутствует проблема, решение которой известно, но нет задокументированного описания этого; - Появляются изменения, которые приводят к изменению на стороне клиентов (как пример). Тут советуют сначала RFC написать, потом думать об ADR; - Незначительные решения, которые могут повториться в другой команде; Из минусов — было бы круто, если бы в тексте были примеры, когда не стоит писать ADR. #adr

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— Modeling identity and access hierarchy in Postgres with ltree Для реализации аутентификации (прав доступа), можно либо взять готовые библиотеки, либо написать решение с нуля. Причем, если писать собственное решение, первой мыслью будет взять язык программирования. Но не стоит забывать о постгресе. Автор статьи решил показать, как взяв ltree (hierarchical tree-like data type), делается аутентификация через user, action, resource связку. В начале описывается почему рассматривается user, action, resource tuple. После, рассказывается база по ltree, как делать запросы и сохранять данные. Но подход хорош с получением иерархических данных, а не изменением таких данных, о чем в статье также упоминается. Далее система усложняется. Так, вместо иерархической структуры, автор предлагает использовать отдельные таблицы для прав, ролей и групп юзеров. А вконце, подход сравнивается с cedar. Если ищете идею, как реализовать ABAC — советую статью к прочтению. #auth ————————————— Nobody knows how the whole system works На фоне LLM вижу больше статей о том, как люди разучатся «понимать» системы. Сегодня философский текст о том, что системы стали слишком сложными и люди перестали понимать в деталях, как работают технологии. Текст начинается с обсуждения, который начал Саймон Вордли (придумал «карты»), который вспомнил об антропологии и о том, что люди уже оказывались в ситуации, когда никто не знал, как работают созданные вещи. Может показаться, что это очередной «камень» в сторону llm, но автор текста приводит цитату из 1994 года, где профессор MIT бухтел о том, что люди не знают как работает телефония. После чего вспоминается популярный вопрос с собеседований: что происходит, когда в браузере набирается сайт. Пока читал, вспомнил две истории. Первая — биография инженера (уже не найду), который рассказывал о человеке, который симулировал атомную станцию в своей голове, чтобы найти ошибку. Дело было больше 50 лет назад, когда АЭС были «простыми» и «помещались» в голову. Вторая история связана с ракетой сатурн (людей на луну запускала). Не так давно инженеры думали поднять информацию по проекту и повторить 1 в 1 что делали 50 лет назад (даже изучали экспонаты из музея). На деле оказалось, что материалы поменялись и найти аналоги невозможно. А также, было сделано слишком много недокументированных изменений, которые не сходятся с изначальным проектом. #complexity ————————————— Финансовый язык для тех, кто пишет код, а не отчёты Здорово, когда в компании присутствует описание терминов предметной области в документации. Проблемы начинаются, когда домен сложный, а справочной информации по нулям. В случае финансов выручает investopedia, но сегодня статья, в которой раскрываются «базовые» термины из финансов. В статье найдете описание 15+ терминов. В список попали: бюджет, выручка, Profit and Loss, operational expenditure, capital expenditure, Full‑Time Equivalent, margin, Earnings Before Interest, Cash flow, Break‑even point, Return on Investment, Payback period, Total Cost of Ownership, Burn rate, а также термины из юнит экономики. Сама статья состоит из описания каждого из терминов и примеров, объясняющих значение. Может показаться, что “финансовый словарь” нужен только тем, кто работает в финтехе, но в реальности, термины используются в любом из доменов. Например, благодаря Profit and Loss, можно объяснить денежную выгоду от технического решения. А TCO поможет вспомнить, что в цену технологии входит не только лицензия, но и зарплаты на обучение, интеграцию и оперейшенал. #domain

Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Google Manages Trillions of Authorizations with Zanzibar В канале упоминались статьи связанные с реализацией Zanzibar (Google’s Consistent, Global Authorization System) в airbnb и netflix. Сегодня статья о высокоуровневой архитектуре авторизации через Zanzibar в гугле. При этом, система обрабатывает ~10 миллионов запросов прав в секунду. Начинается текст с описания текущей ситуации: геосистема с десятками дата центров, 2+ триллионов записей с пермишенами, сотни проверок на запрос и так далее. Кроме инфраструктурных проблем, вероятны ситуации, когда удаленный пользователь продолжит видеть новый контент. Чтобы решить описанные проблемы, zanzibar использует tuples, consistency protocol и serving layer. Tuple содержит связку из <object, relation, user>. При этом, объект tuple не только документ, но и другой tuple. Так, если надо дать доступ к файлам в папке, не обязательно хранить отдельные правила для каждого файла, достаточно сослаться на правила для папки. А консистентность решается через токены и временные метки, которые работают поверх Google Spanner. Далее покрываются инфраструктурные вопросы. Так описывается хайлевел архитектура проекта на нескольких кластерах, как работает кэширование и как улучшали перфоманс. #how_it_works #auth ————————————— Beyond Accidental Quality: Finding Hidden Bugs with Generative Testing Главный минус тестов — кейсы которые пишутся учитывают только заранее определенные ситуации, без «неизвестного неизвестного». Это значит, что нет 100% гарантии, что хитрые ситуации (о которых не знали/подумали) обрабатываются корректно. В качестве решения, авторы статьи, предлагают воспользоваться generative tests. Начинается текст с инвариантов — свойств системы, в которой система должна оказаться. С инвариантов начинается работа с генеративным тестированием, после чего тесты пытаются «выбить» систему из найденного свойства. Далее, на примере сложения, показывается, как работают подобные тесты (задаются правила, после чего, перебором данных правила проверяются на корректность). Далее описываются примеры из реальной жизни: показывается как проверять логику для meetings API и для работы с бд, а также как обрабатывать найденные ошибки в тестах. Если читали о residuality theory, найдете пересечения в работе с состояниями системы (аттракторами в residuality). #testing ————————————— Очередь задач на Postgres Если необходимо реализовать message broker, а тащить кролик/кафку/etc нет желания (или возможности), а нагрузка минимальна — можно посмотреть в сторону постгреса. Для этого автор статьи предлагает воспользоваться SKIP LOCKED для выбора задач и lease/heartbeat для возвращения «зависших» задач. В начале текста описываются «требования», которые хочется получить: горизонтальное масштабирование, simple workflow (не путать с easy) и failure стратегии. Далее автор показывает как сделать таблицу с задачами и heartbeat таблицу (для проверки «жизни» воркера). После показывается, как забирать задачи, автоматически помечая «занятыми» и избежать локов одинх и тех же задач. Далее показывается как работать с зависшими задачами и как останавливать воркеры. Понравилось, что в конце присутствует отдельный блок с тем, когда не стоит использовать подход. Сразу предупрежу — подумайте перед тем как в продакшен тащить такое решение. Другую реализацию очередей поверх пг, на руби, можно посмотреть в библиотеке que #psql #message_broker