Телеграм канал «2pegramming»

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

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

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

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