Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
How PayPal Scaled Kafka to 1.3 Trillion Daily Messages
Статья из серии: «Как Х реализован в Y?», в этот раз информация о том, как PayPal скейлит кафку, чтобы обрабатывать 19 миллионов mps (message per second). Изначально рассказывается почему и когда выбрали кафку, а именно с 15 года, для стриминга данных и интеграций. На текущий момент в компании 1500 брокеров и 20к топиков с SLA в 99.99%. Ну и перечисляется некоторые примеры использования (особенно заинтересовал risk detection).
Дальше рассказывается как инфраструктурно крутится кафка, заинтересовало разделение на distributed data centers и security zones. Первое – физический объект с инфрой, а security zone – логический кусок в рамках дата центра для изоляции доступов (например зона для обработки конфиденциальных платежных данных). Для синхронизации данных используется MirrorMaker. Дальше рассказывается о «PayPal’s Kafka Landscape», наборе элементов используемых для разворачивания и operational инфраструктуры. Сюда входит сервер конфигурации, штуки для обсервабилити, библиотеки для клиентов, ACLs и так далее. В конце упоминается как происходит автоматизация вокруг брокера: добавление топика, настройка репликации и так далее.
#how_it_works #kafka
—————————————
Good Product Team / Bad Product Team
Неформатная для канала ссылка, но может быть кого-то заинтересует, особенно если любите team topology или user story mapping. Сама статья сводится к набору утверждений, сделанных автором после опыта работы с «many of the very best technology product teams» и другими командами, благодаря чему появились эти утверждения. Т.е. каждый пункт эмпирический (на всякий случай предупреждаю). В тексте 17 пунктов, но без того, как сделать хорошую продуктовую команду.
В пунктах есть как и очевидные вещи: мышление наемной команды плохо, вместо требований – цели и анализ бизнеса, самим определять что делать дальше, в любой ситуации брейнстормит сама. Так встречаются и заметки, о которых забывают или не думают: хорошая команда закрывает необходимые компетенции для работы (включая дизайнеров и другие роли), помнит о стейкхолдерах, а не только о клиентах, могут выкинуть прототипы, а не цепляться за них и так далее.
#product_managment #ppl_managment
—————————————
CAP Theorem for Developers: What It Is and How It Affects Distributed Systems
О CAP теореме уже упоминались статьи в канале (включая статьи, почему пора идти дальше). Сегодняшняя ссылка зацепила объемом материала вокруг теоремы.
В начале автор рассказывает о теореме (берем consistency, availability и partition tolerance, а после оставляем два варианта из трех). Причем подробно рассказывая о каждом из трех вариантов и трейдофах выбора, понравился список пунктов, о которых стоит подумать при выборе подхода. После приводятся примеры реальных инструментов, которые реализуют AP, CP, CA варианты выбора (в список попали: динамо, Google’s Spanner, кассандра и блокчейн). В конце описывается чеклист по проектированию систем на основе CAP теоремы и приводятся альтернативные модели (без подробностей): PACELC, BASE, CAP Twelve Years Later.
Если хотите за одну статью разобраться с теоремой – мастрид этого года.
#CAP
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
How PayPal Scaled Kafka to 1.3 Trillion Daily Messages
Статья из серии: «Как Х реализован в Y?», в этот раз информация о том, как PayPal скейлит кафку, чтобы обрабатывать 19 миллионов mps (message per second). Изначально рассказывается почему и когда выбрали кафку, а именно с 15 года, для стриминга данных и интеграций. На текущий момент в компании 1500 брокеров и 20к топиков с SLA в 99.99%. Ну и перечисляется некоторые примеры использования (особенно заинтересовал risk detection).
Дальше рассказывается как инфраструктурно крутится кафка, заинтересовало разделение на distributed data centers и security zones. Первое – физический объект с инфрой, а security zone – логический кусок в рамках дата центра для изоляции доступов (например зона для обработки конфиденциальных платежных данных). Для синхронизации данных используется MirrorMaker. Дальше рассказывается о «PayPal’s Kafka Landscape», наборе элементов используемых для разворачивания и operational инфраструктуры. Сюда входит сервер конфигурации, штуки для обсервабилити, библиотеки для клиентов, ACLs и так далее. В конце упоминается как происходит автоматизация вокруг брокера: добавление топика, настройка репликации и так далее.
#how_it_works #kafka
—————————————
Good Product Team / Bad Product Team
Неформатная для канала ссылка, но может быть кого-то заинтересует, особенно если любите team topology или user story mapping. Сама статья сводится к набору утверждений, сделанных автором после опыта работы с «many of the very best technology product teams» и другими командами, благодаря чему появились эти утверждения. Т.е. каждый пункт эмпирический (на всякий случай предупреждаю). В тексте 17 пунктов, но без того, как сделать хорошую продуктовую команду.
В пунктах есть как и очевидные вещи: мышление наемной команды плохо, вместо требований – цели и анализ бизнеса, самим определять что делать дальше, в любой ситуации брейнстормит сама. Так встречаются и заметки, о которых забывают или не думают: хорошая команда закрывает необходимые компетенции для работы (включая дизайнеров и другие роли), помнит о стейкхолдерах, а не только о клиентах, могут выкинуть прототипы, а не цепляться за них и так далее.
#product_managment #ppl_managment
—————————————
CAP Theorem for Developers: What It Is and How It Affects Distributed Systems
О CAP теореме уже упоминались статьи в канале (включая статьи, почему пора идти дальше). Сегодняшняя ссылка зацепила объемом материала вокруг теоремы.
В начале автор рассказывает о теореме (берем consistency, availability и partition tolerance, а после оставляем два варианта из трех). Причем подробно рассказывая о каждом из трех вариантов и трейдофах выбора, понравился список пунктов, о которых стоит подумать при выборе подхода. После приводятся примеры реальных инструментов, которые реализуют AP, CP, CA варианты выбора (в список попали: динамо, Google’s Spanner, кассандра и блокчейн). В конце описывается чеклист по проектированию систем на основе CAP теоремы и приводятся альтернативные модели (без подробностей): PACELC, BASE, CAP Twelve Years Later.
Если хотите за одну статью разобраться с теоремой – мастрид этого года.
#CAP
Собираю темы для новой версии АА курса
Привет!
В этом году решил переписать АА (асинхронная архитектура) курс и медленно, но верно собираю темы, которые должны попасть в новую версию курса. В связи с этим, решил написать в канал вопрос для тех, кто проходил прошлую версию курса, ответив на который вы поможете моей работе:
Какие у вас возникли проблемы, после окончания курса?
Это могут быть как проблемы технические (не знаете как что-то сделать), так и проблемы, которые возникли (взяли схему реджистри, а что дальше - не понятно), так и социальные (предложили решение, а команда завернула и не понятно как объяснить)
Буду рад комментариям, ибо это сильно поможет в работе над новой версией курса.
Привет!
В этом году решил переписать АА (асинхронная архитектура) курс и медленно, но верно собираю темы, которые должны попасть в новую версию курса. В связи с этим, решил написать в канал вопрос для тех, кто проходил прошлую версию курса, ответив на который вы поможете моей работе:
Какие у вас возникли проблемы, после окончания курса?
Это могут быть как проблемы технические (не знаете как что-то сделать), так и проблемы, которые возникли (взяли схему реджистри, а что дальше - не понятно), так и социальные (предложили решение, а команда завернула и не понятно как объяснить)
Буду рад комментариям, ибо это сильно поможет в работе над новой версией курса.
Новый ответ: планируем долгие и большие проекты
Продолжаю отвечать на вопросы. Сегодняшний вопрос связан с планированием и наблюдением за проектами. Хоть я и не менеджер (и не планирую идти в эту сторону), но иногда приходится заниматься подобной работой.
Как слежу за большими проектами
В ответе затронул следующие темы:
- Почему project management инструменты меня запутывают и заставляют грустить;
- Почему список задач не сработает для проектов на 6+ месяцев и как, используя графы, сделать «концептуальный» план работ. Благодаря которому можно посчитать ресурсы чуть лучше, чем «пальцем в небо»;
- Как следить за тем, что происходит в проекте на этапе имплементации
- Как находить проблемы в планировании: либо до начала работ, либо ретроспективно разбираться, что и где пошло не так;
Сразу скажу, подход абстрактный и хард скиловым менеджерам скорее всего не поможет. Но если поможет решить текущие проблемы (или вдохновит на что-то), буду только рад, так же как и комментариям с предложениями и вопросами.
Продолжаю отвечать на вопросы. Сегодняшний вопрос связан с планированием и наблюдением за проектами. Хоть я и не менеджер (и не планирую идти в эту сторону), но иногда приходится заниматься подобной работой.
Как слежу за большими проектами
В ответе затронул следующие темы:
- Почему project management инструменты меня запутывают и заставляют грустить;
- Почему список задач не сработает для проектов на 6+ месяцев и как, используя графы, сделать «концептуальный» план работ. Благодаря которому можно посчитать ресурсы чуть лучше, чем «пальцем в небо»;
- Как следить за тем, что происходит в проекте на этапе имплементации
- Как находить проблемы в планировании: либо до начала работ, либо ретроспективно разбираться, что и где пошло не так;
Сразу скажу, подход абстрактный и хард скиловым менеджерам скорее всего не поможет. Но если поможет решить текущие проблемы (или вдохновит на что-то), буду только рад, так же как и комментариям с предложениями и вопросами.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
Inside Shopify’s Modular Monolith
Еще одна статья о том, как компания решает технические проблемы (подобных статей накопилось много, поэтому на следующей неделе будет спецвыпуск). Сегодня речь пойдет о том, как в шопифае сделали модульный монолит. Напомню, что компания сделала один из самых больших ruby on rails монолитов в мире.
Ничего технического от текста не ждите, так как статья – текстовое интервью одного из principal engineer. Интервью можно разбить на четыре части:
- Интро, в котором рассказывается о госте и что принципалы в компании делают;
- Описание тех стека шопифая и упоминание, что кор разрабы руби, рельсы, mySQL работают в компании. Плюс упоминается «pods architecture», благодаря которой магазины шардируются как по данным, так и по нагрузке;
- Рассказ о модульном монолите, но тут лучше прочитать оригинальный пост в tech блоге компании;
- как происходит «operational»: тестирование (понравилось, что описали пайплайн), деплоймент (собственный инструмент), обработка ошибок;
#how_it_works
—————————————
How to Share Data Between Microservices on High Scale
Типовая проблема в распределенных системах – получение данных, когда источник правды другой сервис. Статья как раз о таком случае. История начинается с проблемы – появился новый функционал, для которого нужны были данные из другого сервиса. Так как фича была MVP, то инженеры решили делать синхронные запросы, но потом оказалось, что данные нужны еще двум сервисам из-за чего возник вопрос, как лучше получать информацию.
Автор рассматривает три варианта:
- синхронный запрос;
- асинхронное событие;
- аналог event notification, когда сначала информация передается асинхронно, а потом делается синхронный запрос для получения консистентной информации;
Для каждого примера дается краткое описание с диаграммой. Плюс описываются плюсы и минусы каждого из описанных подходов.
#communications
—————————————
The Problem with OpenTelemetry
Способов реализации распределенной трассировки много, но на слуху – OpenTelementry, у которого есть как плюсы, так и минусы. Как раз о минусах сегодняшняя статья от основателя Sentry, который рассказывает в чем проблема стандарта (спойлер: стандарт перестал решать одну конкретную проблему) и как автор хотел бы видеть мир трассировок. Сразу предупреждаю, статья не практическая, а скорее «мысли в слух».
В начале рассказывается предыстория, о том, как появился OpenTracing, который в последующем стал OpenTelementry. При этом, как начиная со стандартизации трассировки, инженеры начали придумывать стандарты для логов и метрик, что привело к главному минусу – отсутствие vision и leadership. Из-за чего стандарт перестал быть “завершенным” и не пониманию автора, какие проблемы решает стандарт.
Далее автор пытается на примере показать, как можно исправить ситуацию. Для этого автор возвращается в прошлое (нулевые) и описывает проблему с наблюдаемостью и какие способы решения существовали. И как, в текущее время, одного stacktrace по ошибкам не хватает в распределенных системах. В конце, автор рассуждает о том, как он видит «идеальный» стандарт трассировок и получения информации о системе, а примеры приводит с оглядкой на Sentry.
#observability #open_telementry
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
Inside Shopify’s Modular Monolith
Еще одна статья о том, как компания решает технические проблемы (подобных статей накопилось много, поэтому на следующей неделе будет спецвыпуск). Сегодня речь пойдет о том, как в шопифае сделали модульный монолит. Напомню, что компания сделала один из самых больших ruby on rails монолитов в мире.
Ничего технического от текста не ждите, так как статья – текстовое интервью одного из principal engineer. Интервью можно разбить на четыре части:
- Интро, в котором рассказывается о госте и что принципалы в компании делают;
- Описание тех стека шопифая и упоминание, что кор разрабы руби, рельсы, mySQL работают в компании. Плюс упоминается «pods architecture», благодаря которой магазины шардируются как по данным, так и по нагрузке;
- Рассказ о модульном монолите, но тут лучше прочитать оригинальный пост в tech блоге компании;
- как происходит «operational»: тестирование (понравилось, что описали пайплайн), деплоймент (собственный инструмент), обработка ошибок;
#how_it_works
—————————————
How to Share Data Between Microservices on High Scale
Типовая проблема в распределенных системах – получение данных, когда источник правды другой сервис. Статья как раз о таком случае. История начинается с проблемы – появился новый функционал, для которого нужны были данные из другого сервиса. Так как фича была MVP, то инженеры решили делать синхронные запросы, но потом оказалось, что данные нужны еще двум сервисам из-за чего возник вопрос, как лучше получать информацию.
Автор рассматривает три варианта:
- синхронный запрос;
- асинхронное событие;
- аналог event notification, когда сначала информация передается асинхронно, а потом делается синхронный запрос для получения консистентной информации;
Для каждого примера дается краткое описание с диаграммой. Плюс описываются плюсы и минусы каждого из описанных подходов.
#communications
—————————————
The Problem with OpenTelemetry
Способов реализации распределенной трассировки много, но на слуху – OpenTelementry, у которого есть как плюсы, так и минусы. Как раз о минусах сегодняшняя статья от основателя Sentry, который рассказывает в чем проблема стандарта (спойлер: стандарт перестал решать одну конкретную проблему) и как автор хотел бы видеть мир трассировок. Сразу предупреждаю, статья не практическая, а скорее «мысли в слух».
В начале рассказывается предыстория, о том, как появился OpenTracing, который в последующем стал OpenTelementry. При этом, как начиная со стандартизации трассировки, инженеры начали придумывать стандарты для логов и метрик, что привело к главному минусу – отсутствие vision и leadership. Из-за чего стандарт перестал быть “завершенным” и не пониманию автора, какие проблемы решает стандарт.
Далее автор пытается на примере показать, как можно исправить ситуацию. Для этого автор возвращается в прошлое (нулевые) и описывает проблему с наблюдаемостью и какие способы решения существовали. И как, в текущее время, одного stacktrace по ошибкам не хватает в распределенных системах. В конце, автор рассуждает о том, как он видит «идеальный» стандарт трассировок и получения информации о системе, а примеры приводит с оглядкой на Sentry.
#observability #open_telementry
Пятничное чтиво
Спецвыпуск. Сегодня три ссылки о трех компаниях, каждая из которых решала свои проблемы.
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
Cloudflare’s Trillion-Message Kafka Infrastructure: A Deep Dive
Текст о взаимоотношениях между Cloudflare и кафкой, которые начались в 2014 году. А не так давно, компания обработала 1 триллион сообщений (это 10^12). На текущий момент Cloudflare управляет 14 кафка кластерами состоящим из 330 нод по всему миру.
Изначально компания сделала монолит на пхп и столкнулась с проблемами: высокий каплинг и проблемы с реализацией ретраев. Для решения решили взять кафку со стандартизацией: добавили схему реджистри, message bus client library (которая мапила протобаф схему на топик, что добавляет проблем). После этого, компания начала выделять паттерны, используемые с кафкой. Интересная идея, что после инженеры смогли сделать генерацию сервиса реализующий нужный паттерн. Дальше рассказываются проблемы, которые возникли у компании: visibility, проблемы с алертами и проблемы с email.
#how_it_works #kafka
—————————————
How Netflix Scales its API with GraphQL Federation (Part 1)
How Netflix Scales its API with GraphQL Federation (Part 2)
Две статьи от нетфликса и того, как используется GraphQL federation в компании.
В первой статье речь идет о Studio Edge – части системы, которая помогает в создании контента от компании. В качестве интерфейса команда взяла graphQL, что привело к проблемам. Но инженеры решили, что раз с микросервисами получилось, то с graphQL тоже так выйдет, с чем помог GraphQL Federation. Дальше рассказывается, как добавлялся гейтвей, к которому подключались сервисы в виде отдельных доменных графов и сервис со схемами. После рассказывается о специфике: композиции схемы, query planning, entity resolver и так далее. В конце статьи найдете картинку с эволюцией системы.
Вторая статья рассказывает, что происходило после. Доведя решение с graphQL до ума, компания начала вкладываться в operational штуки. В тексте рассказывается как добавлялся инструментарий для котлина, проводилось обучение. Понравилось, что описывается процесс верификации graphql схемы. Также рассказывается об observability и распределенную трассировку. Последние две темы касаются секьюрити и architecting for failure.
#how_it_works #graphQL
—————————————
Building and scaling Notion’s data lake
С ковида, количество пользователей ноушена только растет, из-за чего компании пришлось думать, как хранить данные для аналитики. Изначально, данные хранилось в одном инстансе постгреса, который переделали на 420 логических шарда. Статья как раз рассказывает о том, как компания решала проблему с использованием данных для аналитики, обучения AI, поиска и так далее).
Сначала решили сделать ETL, который использовал Fivetran для репликации Postgres WAL в Snowflake. У такого подхода возникли проблемы: масштабирование, куча коннектов которые надо обслуживать, скорость данных, проблемы с обработкой данных в ETL. Все это привело к тому, что команда решила сделать собственный даталейк. Реализовали через CDC и кафку (debezium) и клали данные в s3. В s3 данные обогащаются нужным образом и после попадают в нужную часть системы (аналитика, обучение AI). При этом, в статье объясняются причины выбора каждой технологии и решения. В конце дается итог решения с плюсами (минусов, к сожалению, не написали).
Перевод на русский
#how_it_works #etl #datalake
Спецвыпуск. Сегодня три ссылки о трех компаниях, каждая из которых решала свои проблемы.
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно найти на сайте.
—————————————
Cloudflare’s Trillion-Message Kafka Infrastructure: A Deep Dive
Текст о взаимоотношениях между Cloudflare и кафкой, которые начались в 2014 году. А не так давно, компания обработала 1 триллион сообщений (это 10^12). На текущий момент Cloudflare управляет 14 кафка кластерами состоящим из 330 нод по всему миру.
Изначально компания сделала монолит на пхп и столкнулась с проблемами: высокий каплинг и проблемы с реализацией ретраев. Для решения решили взять кафку со стандартизацией: добавили схему реджистри, message bus client library (которая мапила протобаф схему на топик, что добавляет проблем). После этого, компания начала выделять паттерны, используемые с кафкой. Интересная идея, что после инженеры смогли сделать генерацию сервиса реализующий нужный паттерн. Дальше рассказываются проблемы, которые возникли у компании: visibility, проблемы с алертами и проблемы с email.
#how_it_works #kafka
—————————————
How Netflix Scales its API with GraphQL Federation (Part 1)
How Netflix Scales its API with GraphQL Federation (Part 2)
Две статьи от нетфликса и того, как используется GraphQL federation в компании.
В первой статье речь идет о Studio Edge – части системы, которая помогает в создании контента от компании. В качестве интерфейса команда взяла graphQL, что привело к проблемам. Но инженеры решили, что раз с микросервисами получилось, то с graphQL тоже так выйдет, с чем помог GraphQL Federation. Дальше рассказывается, как добавлялся гейтвей, к которому подключались сервисы в виде отдельных доменных графов и сервис со схемами. После рассказывается о специфике: композиции схемы, query planning, entity resolver и так далее. В конце статьи найдете картинку с эволюцией системы.
Вторая статья рассказывает, что происходило после. Доведя решение с graphQL до ума, компания начала вкладываться в operational штуки. В тексте рассказывается как добавлялся инструментарий для котлина, проводилось обучение. Понравилось, что описывается процесс верификации graphql схемы. Также рассказывается об observability и распределенную трассировку. Последние две темы касаются секьюрити и architecting for failure.
#how_it_works #graphQL
—————————————
Building and scaling Notion’s data lake
С ковида, количество пользователей ноушена только растет, из-за чего компании пришлось думать, как хранить данные для аналитики. Изначально, данные хранилось в одном инстансе постгреса, который переделали на 420 логических шарда. Статья как раз рассказывает о том, как компания решала проблему с использованием данных для аналитики, обучения AI, поиска и так далее).
Сначала решили сделать ETL, который использовал Fivetran для репликации Postgres WAL в Snowflake. У такого подхода возникли проблемы: масштабирование, куча коннектов которые надо обслуживать, скорость данных, проблемы с обработкой данных в ETL. Все это привело к тому, что команда решила сделать собственный даталейк. Реализовали через CDC и кафку (debezium) и клали данные в s3. В s3 данные обогащаются нужным образом и после попадают в нужную часть системы (аналитика, обучение AI). При этом, в статье объясняются причины выбора каждой технологии и решения. В конце дается итог решения с плюсами (минусов, к сожалению, не написали).
Перевод на русский
#how_it_works #etl #datalake
Новый ответ: уменьшаем размер событий в асинхронной коммуникации
Продолжаю отвечать на вопросы. Сегодняшний вопрос связан с асинхронными коммуникациями, а именно с ситуацией, когда payload события слишком большой для системы и данные в событии надо уменьшать.
Уменьшаем размер событий
В ответе затронул следующие темы:
- Event granularity и state (fact) vs delta (action) events. Рассказал что есть что. Плюс связал концепции, что бы оптимальнее выбирать размер события в системе;
- Описать некоторые паттерны, которые могут потенциально помочь: event notification, message chunking и другие;
- Сделал decision flow chart в конце, со всеми описанными темами;
Уверен, что это не все возможные варианты, поэтому, если знаете еще способы уменьшения размера событий – буду рад обсудить в комментариях.
Продолжаю отвечать на вопросы. Сегодняшний вопрос связан с асинхронными коммуникациями, а именно с ситуацией, когда payload события слишком большой для системы и данные в событии надо уменьшать.
Уменьшаем размер событий
В ответе затронул следующие темы:
- Event granularity и state (fact) vs delta (action) events. Рассказал что есть что. Плюс связал концепции, что бы оптимальнее выбирать размер события в системе;
- Описать некоторые паттерны, которые могут потенциально помочь: event notification, message chunking и другие;
- Сделал decision flow chart в конце, со всеми описанными темами;
Уверен, что это не все возможные варианты, поэтому, если знаете еще способы уменьшения размера событий – буду рад обсудить в комментариях.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
An example of example-driven development
На статью наткнулся, пока разбирался с Glamorous Toolkit. Идея в том, что автор решил отойти от тестов в сторону примеров для валидации того, что система работает как надо (тут хочется сослаться на классику в виде Readme Driven Development). Одной из причин, почему отдается предпочтение примерам – примеры могут быть составлены из других примеров (это когда сложный пример разбивается на набор примеров из которых сложный пример состоит). Дальше автор на примерах (простите), показывает как подход с example-driven development помогает в написании и понимании кода. Плюс показывает как gtoolkit помогает динамически «играть» с примерами и генерировать документацию.
Выглядит как еще одна попытка заменить валидацию системы на что-то «удобнее». Для кругозора статья отличная, но возникают вопросы, чем edd лучше, чем написание документации с примерами. Использовать данный подход в проектах – решать только вам, но, пожалуйста, сверяйтесь с требованиями перед тем, как выкатывать код в продакшен (tdd, bdd, readme dd, и так далее).
#testing #system_validation
—————————————
How to discover all the data sources, low-fuss way
При анализе систем можно попасть в ситуацию, когда не понятно что происходит с данными. Например, есть сервис, который работает с данными в собственной бд. А ответить на вопросы: где именно находятся данные, как они попадают в бд, кто создает данные и так далее, с ходу не получается.
Чтобы решить эту проблему и помочь в изучении системы, автор предлагает «фреймворк» состоящий из пяти вопросов:
- Q1. Where is it stored?
- Q2. Is it a copy of another dataset?
- Q3. Why did we decide to create it?
- Q4. How is it designed?
- Q5. Where is it documented?
В статье раскрывается каждый вопрос, даются советы и объясняется зачем вопрос нужен. Если встречались с проблемой, связанной с пониманием данных в системе и не знали что делать – однозначный мастхев.
#system_analysis #data_managment
—————————————
10 Kubernetes Cost Optimization Techniques
«Пора уменьшать косты» – фраза, которая возникает в компании, как только она перестает быть стартапом, либо когда инвестиции начинают заканчиваться, а проекта все еще нет. При этом, общей стратегии не видел, каждая компания делает как знает/чувствует. Либо компания не только знает о FinOps, и использует подход в работе, но тогда статью можно пропустить. Поэтому мн нвятся подобные посты, из которых можно сделать полноценную стратегию для уменьшения костов. Сегодня о кубере и 10 советов, куда смотреть, чтобы платить меньше.
Автор делит стратегии на 3 группы:
- Pre-Deployment Strategies;
- Post-Deployment Strategies;
- Ongoing Improvements;
Кроме специфичных для кубера тем (лимиты, rightsizing, автоскейлинг, провайдеры и так далее), затрагиваются общие темы, такие как архитектура системы, инструменты для мониторинга костов. Каждая тема описывается поверхностно, но тут ценность в том, что текст даст направления, которые дальше самому можно будет раскрыть.
#finops #cost_managment #k8s
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
An example of example-driven development
На статью наткнулся, пока разбирался с Glamorous Toolkit. Идея в том, что автор решил отойти от тестов в сторону примеров для валидации того, что система работает как надо (тут хочется сослаться на классику в виде Readme Driven Development). Одной из причин, почему отдается предпочтение примерам – примеры могут быть составлены из других примеров (это когда сложный пример разбивается на набор примеров из которых сложный пример состоит). Дальше автор на примерах (простите), показывает как подход с example-driven development помогает в написании и понимании кода. Плюс показывает как gtoolkit помогает динамически «играть» с примерами и генерировать документацию.
Выглядит как еще одна попытка заменить валидацию системы на что-то «удобнее». Для кругозора статья отличная, но возникают вопросы, чем edd лучше, чем написание документации с примерами. Использовать данный подход в проектах – решать только вам, но, пожалуйста, сверяйтесь с требованиями перед тем, как выкатывать код в продакшен (tdd, bdd, readme dd, и так далее).
#testing #system_validation
—————————————
How to discover all the data sources, low-fuss way
При анализе систем можно попасть в ситуацию, когда не понятно что происходит с данными. Например, есть сервис, который работает с данными в собственной бд. А ответить на вопросы: где именно находятся данные, как они попадают в бд, кто создает данные и так далее, с ходу не получается.
Чтобы решить эту проблему и помочь в изучении системы, автор предлагает «фреймворк» состоящий из пяти вопросов:
- Q1. Where is it stored?
- Q2. Is it a copy of another dataset?
- Q3. Why did we decide to create it?
- Q4. How is it designed?
- Q5. Where is it documented?
В статье раскрывается каждый вопрос, даются советы и объясняется зачем вопрос нужен. Если встречались с проблемой, связанной с пониманием данных в системе и не знали что делать – однозначный мастхев.
#system_analysis #data_managment
—————————————
10 Kubernetes Cost Optimization Techniques
«Пора уменьшать косты» – фраза, которая возникает в компании, как только она перестает быть стартапом, либо когда инвестиции начинают заканчиваться, а проекта все еще нет. При этом, общей стратегии не видел, каждая компания делает как знает/чувствует. Либо компания не только знает о FinOps, и использует подход в работе, но тогда статью можно пропустить. Поэтому мн нвятся подобные посты, из которых можно сделать полноценную стратегию для уменьшения костов. Сегодня о кубере и 10 советов, куда смотреть, чтобы платить меньше.
Автор делит стратегии на 3 группы:
- Pre-Deployment Strategies;
- Post-Deployment Strategies;
- Ongoing Improvements;
Кроме специфичных для кубера тем (лимиты, rightsizing, автоскейлинг, провайдеры и так далее), затрагиваются общие темы, такие как архитектура системы, инструменты для мониторинга костов. Каждая тема описывается поверхностно, но тут ценность в том, что текст даст направления, которые дальше самому можно будет раскрыть.
#finops #cost_managment #k8s
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
It’s Time to Rethink Event Sourcing
Event sourcing (es) упоминался раз пять в канале, даже сохранились старые записи стримов о паттерне. Сегодня статья рассуждение о том, куда es может развиваться. Сразу скажу, статья довольно дискуссионная и стоит самому решать как к ней относиться. Главная идея статьи (как сам понял) – вместо использования чистого es, который каждый раз пишется с нуля, взять Change Data Capture паттерн, которого, со слов автора, хватит в 95% случаев.
В начале автор перечисляет ситуации, где es может оказаться полезным. После приводит два идейных примера: bank ledger и version control system (в конце объясню почему пример так себе). После этого перечисляются проблемы: сложность с парадигмой, eventual consistency, сложности с реализацией и так далее. После подвязывает Change Data Capture паттерн и рассказывает как использовать, чтобы получить плюсы хранения изменений, не усложняя систему.
Единственное, не считайте git event sourcing системой. Идейно похожей – да, но это не «каноничная реализация» так как коммит не хранит дельту изменений, а tree + blob (следующая статья об этом).
#event_sourcing #cdc
—————————————
Creating a Git commit: The Hard Way
В канале уже упоминал статьи с хардкорными примерами использования гита. Сегодня статья о том, как сделать коммит в гите не используя
В начале автор рассказывает о состояниях файлов в гите и о разделах гит проектов. После объясняет разницу между blob, tree и commit объектами в гите (хотите одробнее – советую документацию). После начинается магия, в которой создается блоб через
Использовать подобный подход в ежедневной рутине – самоубийство. Но статья, на примере, рассказывает об объектах гита, благодаря чему разбивается миф о том, что гит хранит дельту изменений в коммите. Плюс, можно лучше понять как устроена технология.
Русский перевод
#git #how_it_works
—————————————
Just use Postgres
Давайте договоримся на берегу: я люблю постгрес (с mysql/oracle не сложилось) и, по дефолту, выберу pg для нового проекта без особых требований к данным. Но если понадобиться и будут на это причины – с радостью выберу любую другую базу под требования и ограничения, проектируемой системы. Поэтому со статьей согласен только на половину.
Статья состоит из объяснения, почему определенный вид бд не подходит как primary bd для хранения данных. Рассматриваются следующие технологии (хоть и навалено все в кучу):
- sqlite
- DynamoDB, Cassandra, MongoDB
- Valkey (замена редиса)
- Datomic (тут посмеялся)
- XTDB (о такой бд не слышал, будет что почитать)
- Kafka (пожалуйста, почитайте если планируете в кафке данные держать)
- ElasticSearch
- MSSQL или Oracle DB
- MySQL
- векторные бд
- Google Sheets (хоть автор добавил для смеха, но лучше таблиц ничего не придумали)
Статью стоит рассматривать в контексте «начинаю проект новый и не знаю какую бд выбрать». Если проект большой и одной бд не добиться нужных свойств (либо изначально понятно, что pg не закроет характеристики) – можно не читать.
Русский перевод, отдельно стоит посмотреть комментарии
#data_bases #psql
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
It’s Time to Rethink Event Sourcing
Event sourcing (es) упоминался раз пять в канале, даже сохранились старые записи стримов о паттерне. Сегодня статья рассуждение о том, куда es может развиваться. Сразу скажу, статья довольно дискуссионная и стоит самому решать как к ней относиться. Главная идея статьи (как сам понял) – вместо использования чистого es, который каждый раз пишется с нуля, взять Change Data Capture паттерн, которого, со слов автора, хватит в 95% случаев.
В начале автор перечисляет ситуации, где es может оказаться полезным. После приводит два идейных примера: bank ledger и version control system (в конце объясню почему пример так себе). После этого перечисляются проблемы: сложность с парадигмой, eventual consistency, сложности с реализацией и так далее. После подвязывает Change Data Capture паттерн и рассказывает как использовать, чтобы получить плюсы хранения изменений, не усложняя систему.
Единственное, не считайте git event sourcing системой. Идейно похожей – да, но это не «каноничная реализация» так как коммит не хранит дельту изменений, а tree + blob (следующая статья об этом).
#event_sourcing #cdc
—————————————
Creating a Git commit: The Hard Way
В канале уже упоминал статьи с хардкорными примерами использования гита. Сегодня статья о том, как сделать коммит в гите не используя
git commit команду.В начале автор рассказывает о состояниях файлов в гите и о разделах гит проектов. После объясняет разницу между blob, tree и commit объектами в гите (хотите одробнее – советую документацию). После начинается магия, в которой создается блоб через
hash-object, tree объект через update-index и write-tree, а коммит через commit-tree.Использовать подобный подход в ежедневной рутине – самоубийство. Но статья, на примере, рассказывает об объектах гита, благодаря чему разбивается миф о том, что гит хранит дельту изменений в коммите. Плюс, можно лучше понять как устроена технология.
Русский перевод
#git #how_it_works
—————————————
Just use Postgres
Давайте договоримся на берегу: я люблю постгрес (с mysql/oracle не сложилось) и, по дефолту, выберу pg для нового проекта без особых требований к данным. Но если понадобиться и будут на это причины – с радостью выберу любую другую базу под требования и ограничения, проектируемой системы. Поэтому со статьей согласен только на половину.
Статья состоит из объяснения, почему определенный вид бд не подходит как primary bd для хранения данных. Рассматриваются следующие технологии (хоть и навалено все в кучу):
- sqlite
- DynamoDB, Cassandra, MongoDB
- Valkey (замена редиса)
- Datomic (тут посмеялся)
- XTDB (о такой бд не слышал, будет что почитать)
- Kafka (пожалуйста, почитайте если планируете в кафке данные держать)
- ElasticSearch
- MSSQL или Oracle DB
- MySQL
- векторные бд
- Google Sheets (хоть автор добавил для смеха, но лучше таблиц ничего не придумали)
Статью стоит рассматривать в контексте «начинаю проект новый и не знаю какую бд выбрать». Если проект большой и одной бд не добиться нужных свойств (либо изначально понятно, что pg не закроет характеристики) – можно не читать.
Русский перевод, отдельно стоит посмотреть комментарии
#data_bases #psql
Новый ответ: как пользуюсь обсидианом
Последние 3 недели вижу больше вопросов и статей о том, как заменить ноушен на обсидиан, что приводит к спорам и проблемам. Поэтому, настало время ответить на вопрос, который задают каждый раз, как видят, что я использую обсидиан.
Сразу скажу, текст холиварный и не по теме о которой хотел бы писать и в которой разбираюсь. Поэтому, хочется верить, что это в первый и последний раз, когда я пишу о личной продуктивности.
Как и почему использую Obsidian
Главной целью в ответе было не рассказать как обсидианом пользуюсь, а больше обсудить концептуальные проблемы и выбор инструментов. Из-за чего текст получился абстрактным и растекающимся по древу (40к знаков говорят сами за себя).
В ответе не найдете последовательных шагов о том, как взяв обсидиан стать мастером продуктивности. Или рассказов о том, как используя zettelkasten стать вторым Луманом и писать по 10 книг в час. Вместо этого затронул темы целеполагания и стиля ведения заметок. Рассказал о том, зачем и как пользуюсь обсидианом для создания контента.
Последние 3 недели вижу больше вопросов и статей о том, как заменить ноушен на обсидиан, что приводит к спорам и проблемам. Поэтому, настало время ответить на вопрос, который задают каждый раз, как видят, что я использую обсидиан.
Сразу скажу, текст холиварный и не по теме о которой хотел бы писать и в которой разбираюсь. Поэтому, хочется верить, что это в первый и последний раз, когда я пишу о личной продуктивности.
Как и почему использую Obsidian
Главной целью в ответе было не рассказать как обсидианом пользуюсь, а больше обсудить концептуальные проблемы и выбор инструментов. Из-за чего текст получился абстрактным и растекающимся по древу (40к знаков говорят сами за себя).
В ответе не найдете последовательных шагов о том, как взяв обсидиан стать мастером продуктивности. Или рассказов о том, как используя zettelkasten стать вторым Луманом и писать по 10 книг в час. Вместо этого затронул темы целеполагания и стиля ведения заметок. Рассказал о том, зачем и как пользуюсь обсидианом для создания контента.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Manages 238 Million Memberships?
Очередная статья о том, как в компании X сделали Y. Сегодня это membership платформа нетфликса, которая обслуживает 238 миллионов пользователей. А «цикл» работы сводится к пяти шагам: регистрация, изменение планов подписки, оплата ( с решением проблем) и отмена/остановка подписки.
Автор начинает статью с развития membership платформы: от двух сервисов (один с подписками, второй с ценами) к системе из 10 сервисов, кафки, кассандры, apache spark и CockroachDB. После описывается процесс регистрации, трекинга действий пользователя. В конце описывается тех стек и как реализован observability.
#how_it_works #kafka
—————————————
How a Single Line of Code Brought Down a Billion Dollar Rocket
Статья о том, как и где используется код в аэрокосмической промышленности. К сожалению, рассказывается о трех случаях, в которых ошибки в коде привели к катастрофическим последствиям. Рассматривается три истории:
- Ariane 5 (ракета европейская). Обошлось без погибших, но потеряли два геостационарных спутника связи. Причиной послужил баг в системе наведения, который отвечал за курс ракеты;
- SQLException который остановил 11000 полетов;
- Катострофа Boeing 737 MAX. Ошибки в программном обеспечении, которое должно было помочь пилотам с управлением самолета;
В конце каждой истории можете посмотреть референсы, которые использовал автор. Также понравилось, что автор дает рекомендации по каждому случаю. Хотя важно напомнить, что рекомендации для ракет/самолетов и стартапов в фазе поиска прибыльной гипотезы будут отличаться (так как требования к системам отличаются).
#failures #systems
—————————————
Failure testing Kafka
Может показаться, что если в системе используется кафка, то скорее развалится написанный код, чем возникнут проблемы с брокером. На деле, кафка тоже сбоит и в качестве примера – статья выше, где автор описывает личный опыт тестирования сбоев.
Сначала описывается контекст, в котором компания использовала кафку, но возникла цель увеличить durability и resilience системы. Для этого подняли кластер из трех брокеров, настроили репликацию и
Важно: статья больше о кишках кафки, т.е. статья будет интересна SRE и инфраструктурным командам, чем разработчикам (исключение, если интересуетесь chaos engineering). Но если интересен deep dive – почему бы и нет.
#kafka #testing #chaos_engineering
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Manages 238 Million Memberships?
Очередная статья о том, как в компании X сделали Y. Сегодня это membership платформа нетфликса, которая обслуживает 238 миллионов пользователей. А «цикл» работы сводится к пяти шагам: регистрация, изменение планов подписки, оплата ( с решением проблем) и отмена/остановка подписки.
Автор начинает статью с развития membership платформы: от двух сервисов (один с подписками, второй с ценами) к системе из 10 сервисов, кафки, кассандры, apache spark и CockroachDB. После описывается процесс регистрации, трекинга действий пользователя. В конце описывается тех стек и как реализован observability.
#how_it_works #kafka
—————————————
How a Single Line of Code Brought Down a Billion Dollar Rocket
Статья о том, как и где используется код в аэрокосмической промышленности. К сожалению, рассказывается о трех случаях, в которых ошибки в коде привели к катастрофическим последствиям. Рассматривается три истории:
- Ariane 5 (ракета европейская). Обошлось без погибших, но потеряли два геостационарных спутника связи. Причиной послужил баг в системе наведения, который отвечал за курс ракеты;
- SQLException который остановил 11000 полетов;
- Катострофа Boeing 737 MAX. Ошибки в программном обеспечении, которое должно было помочь пилотам с управлением самолета;
В конце каждой истории можете посмотреть референсы, которые использовал автор. Также понравилось, что автор дает рекомендации по каждому случаю. Хотя важно напомнить, что рекомендации для ракет/самолетов и стартапов в фазе поиска прибыльной гипотезы будут отличаться (так как требования к системам отличаются).
#failures #systems
—————————————
Failure testing Kafka
Может показаться, что если в системе используется кафка, то скорее развалится написанный код, чем возникнут проблемы с брокером. На деле, кафка тоже сбоит и в качестве примера – статья выше, где автор описывает личный опыт тестирования сбоев.
Сначала описывается контекст, в котором компания использовала кафку, но возникла цель увеличить durability и resilience системы. Для этого подняли кластер из трех брокеров, настроили репликацию и
acks=all и реплику для топиков. Это помогло в ситуации, когда 1 из 3 брокеров выходили из строя, но когда падали сразу два брокера – возникали ошибки. Чтобы избежать таких ситуаций, автор решил описать failure scenarios. Для чего, в тексте описываются ключевые места, в которых могут возникнуть проблемы. После, в тексте, описываются возможные сценарии отказов и ожидаемое поведение кафки. После чего описываются способы тестирования сценариев. В конце рассказывается к чему пришли инженеры и описываются выводы.Важно: статья больше о кишках кафки, т.е. статья будет интересна SRE и инфраструктурным командам, чем разработчикам (исключение, если интересуетесь chaos engineering). Но если интересен deep dive – почему бы и нет.
#kafka #testing #chaos_engineering
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Questions about Team Topologies
Team Topologies (ТТ) – подход к проектированию систем, основанный на социальном аспекте (читай командах). При этом, из подобных подходов, чаще упоминается в постах/книгах последних пяти лет. Сегодняшний текст от автора другого подхода, основанного на architecture layering model, в котором выложена дискуссия с автором ТТ.
Сама дискуссия строится вокруг идей ТТ: на сколько глубокими vertical slices в командах могут быть, автономности команд, как сделать «одноразовую» и сложную работу в компаниях практикующих ТТ, и так далее. Дальше авторы обсуждают идею experience и business доменов (use-case специфичны, вторые общие аля «энтити»).
Если хотите глубже разобраться в ТТ или управления командами – стоит ознакомиться.
#team_topologies #team_managment
—————————————
How Stripe Scaled to 5 Million Database Queries Per Second
В 2023 году страйп обрабатывал 5 миллионов ДБ запросов при SLA в 99.999. Такие показатели стали возможны благодаря горизонтальному скейлингу, которое стало возможно благодаря личному DBaaS, которое назвали DocDB. Статья выше как раз описывает работу DocDB.
Начинается текст с причин, почему так пришлось с DBaaS заморачиваться. Страйп хотел получить availability, durability и performance от бд, оптимизированные запросы в бд, горизонтальную масштабируемость, multi-tenancy с квотами и надежную защиту. Для этого и сделали DocDB, что привело к возможности работать с тысячами шаров и поддержкой 10к различных запросов. Дальше рассказывается как docDB работает: как приложения получают данные, как данные хранятся между шардами и как данные мигрируются между шардами. Причем, о миграции данных в шести шагах оставшаяся треть статьи.
#how_it_works #scalability #db
—————————————
A Web API Design Methodology
Наблюдаю, что тема проектирования API популярная в кругу аналитиков и разработчиков. Напомню, что в 2021 году упоминал книгу по дизайну API (спустя три года считаю, что это лучшая книга по проектированию API). Сегодняшняя ссылка еще один подход к тому, как проектировать API (в данном случае http), которая представляет семь шагов проектирования API, описанные в RESTful Web APIs книге.
Сами шаги выглядят следующим образом:
- Обозначение данных, необходимых в API;
- Изображение state diagram, чтобы понять какие данные и как будут использоваться;
- Согласование «магических» названий полей (когда read list становится «collection from IANA Link Relation Values»);
- Определение способа передачи данных (http, json, xml, etc);
- Создание семантического профиля;
- Реализация API;
- Паблишинг API документации;
#http_api
——— одной строкой ———
- Автор C4 model обновил сайт. Теперь доступна нормальная документация и «динамический» выбор инструментов, на основе чекбоксов;
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Questions about Team Topologies
Team Topologies (ТТ) – подход к проектированию систем, основанный на социальном аспекте (читай командах). При этом, из подобных подходов, чаще упоминается в постах/книгах последних пяти лет. Сегодняшний текст от автора другого подхода, основанного на architecture layering model, в котором выложена дискуссия с автором ТТ.
Сама дискуссия строится вокруг идей ТТ: на сколько глубокими vertical slices в командах могут быть, автономности команд, как сделать «одноразовую» и сложную работу в компаниях практикующих ТТ, и так далее. Дальше авторы обсуждают идею experience и business доменов (use-case специфичны, вторые общие аля «энтити»).
Если хотите глубже разобраться в ТТ или управления командами – стоит ознакомиться.
#team_topologies #team_managment
—————————————
How Stripe Scaled to 5 Million Database Queries Per Second
В 2023 году страйп обрабатывал 5 миллионов ДБ запросов при SLA в 99.999. Такие показатели стали возможны благодаря горизонтальному скейлингу, которое стало возможно благодаря личному DBaaS, которое назвали DocDB. Статья выше как раз описывает работу DocDB.
Начинается текст с причин, почему так пришлось с DBaaS заморачиваться. Страйп хотел получить availability, durability и performance от бд, оптимизированные запросы в бд, горизонтальную масштабируемость, multi-tenancy с квотами и надежную защиту. Для этого и сделали DocDB, что привело к возможности работать с тысячами шаров и поддержкой 10к различных запросов. Дальше рассказывается как docDB работает: как приложения получают данные, как данные хранятся между шардами и как данные мигрируются между шардами. Причем, о миграции данных в шести шагах оставшаяся треть статьи.
#how_it_works #scalability #db
—————————————
A Web API Design Methodology
Наблюдаю, что тема проектирования API популярная в кругу аналитиков и разработчиков. Напомню, что в 2021 году упоминал книгу по дизайну API (спустя три года считаю, что это лучшая книга по проектированию API). Сегодняшняя ссылка еще один подход к тому, как проектировать API (в данном случае http), которая представляет семь шагов проектирования API, описанные в RESTful Web APIs книге.
Сами шаги выглядят следующим образом:
- Обозначение данных, необходимых в API;
- Изображение state diagram, чтобы понять какие данные и как будут использоваться;
- Согласование «магических» названий полей (когда read list становится «collection from IANA Link Relation Values»);
- Определение способа передачи данных (http, json, xml, etc);
- Создание семантического профиля;
- Реализация API;
- Паблишинг API документации;
#http_api
——— одной строкой ———
- Автор C4 model обновил сайт. Теперь доступна нормальная документация и «динамический» выбор инструментов, на основе чекбоксов;
Новый ответ: как убедиться, что техническое решение нужно
Сегодня решил уйти в абстрактные дебри и рассказать о двух идеях, благодаря которым можно понять насколько обдуманно техническое решение, а следовательно на сколько решение нужно. Поэтому держите в голове, что ответ получился абстрактным, а слово «система» упоминается недопустимое количество раз.
Как убедиться, что техническое решение нужно?
Так как тема сложная, а ответить хочется описав идею, а не шаги для валидации, то не ждите конкретных действий. Поэтому в ответе затронул три этапа эволюции: начальное состояние, конечный результат и путь, который придется сделать для изменений. А также надсистемы, благодаря которым можно шире посмотреть на решение и убедиться, что техническое решение не будет болтаться в вакууме.
Кроме этого привел список вопросов, который использую сам, чтобы проанализировать описания решения, привел список надсистем, на которые стоит посмотреть и затронул тему продажи решения бизнесу.
Сегодня решил уйти в абстрактные дебри и рассказать о двух идеях, благодаря которым можно понять насколько обдуманно техническое решение, а следовательно на сколько решение нужно. Поэтому держите в голове, что ответ получился абстрактным, а слово «система» упоминается недопустимое количество раз.
Как убедиться, что техническое решение нужно?
Так как тема сложная, а ответить хочется описав идею, а не шаги для валидации, то не ждите конкретных действий. Поэтому в ответе затронул три этапа эволюции: начальное состояние, конечный результат и путь, который придется сделать для изменений. А также надсистемы, благодаря которым можно шире посмотреть на решение и убедиться, что техническое решение не будет болтаться в вакууме.
Кроме этого привел список вопросов, который использую сам, чтобы проанализировать описания решения, привел список надсистем, на которые стоит посмотреть и затронул тему продажи решения бизнесу.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Trillions of Indexes: How Uber’s LedgerStore Supports Such Massive Scale
Еще одна статья о том, как компания сделала X. Сегодня о том, как убер работает с финансовыми транзакциями под нагрузкой. Причем финансовые транзакции связаны не только с пассажирами, но и с водителями, продавцами и другими клиентами.
Сам LedgerStore – внутренняя разработка убера, которая хранит в себе фин операции и которая должна быть иммутабельной и хранить индексы для поиска нужной информации. Причем индексы делятся на три группы: strongly consistent, eventually consistent и time-range. В статье найдете объяснение каждого вида индекса, включая то, как индекс работает и где используется. А также информацию о управлении жизненным циклом индексов (через стейт машину), валидацию. В конце описывается процесс миграции убера со старого решения поверх DynamoDB на LedgerStore.
#how_it_works #finances #scalability
—————————————
Kafka and Event Streaming — simple explanation
Изначально ожидал, что статья покажет на примере, как объяснить бизнесу необходимость использования event-driven коммуникаций. На деле текст оказался больше техническим (в моей голове), но при этом, статья не перестает быть полезной.
В тексте рассматривается два подхода: когда коммуникация происходит через команды и через события. Каждый вид коммуникации рассматривается отдельно. Дается определение что командам, что событиям. Понравилось, что поднимается тема связанная с реакционным подходом к выполнению кода для событий (об этом забывают). В конце даются плюсы event-driven коммуникации с направлением, как плюс объяснить бизнесу. К сожалению, минусов не хватило.
#event_driven #communications
—————————————
Six Degrees of Kevin Bacon - Postgres Style
Лучше графов (по мнению канала) могут быть только графовые базы данных. При этом, каждый раз радуюсь, когда нахожу статьи связанные с применением графов в контексте постгреса или чего-то более распространенного чем neo4j и аналогов. Поэтому сегодня статья, в которой приводится пример решения задачи Six Degrees of Kevin Bacon с помощью постгреса и sql.
В начале статьи рассказывается о подготовке, а точнее о выгрузке базы IMDB (с примерами схем). Далее рассказывается о pgRouting, расширении для поиска маршрута, который будет использоваться автором поста как graph solver. Для этого делается таблица
#graph #graphDB #psql
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Trillions of Indexes: How Uber’s LedgerStore Supports Such Massive Scale
Еще одна статья о том, как компания сделала X. Сегодня о том, как убер работает с финансовыми транзакциями под нагрузкой. Причем финансовые транзакции связаны не только с пассажирами, но и с водителями, продавцами и другими клиентами.
Сам LedgerStore – внутренняя разработка убера, которая хранит в себе фин операции и которая должна быть иммутабельной и хранить индексы для поиска нужной информации. Причем индексы делятся на три группы: strongly consistent, eventually consistent и time-range. В статье найдете объяснение каждого вида индекса, включая то, как индекс работает и где используется. А также информацию о управлении жизненным циклом индексов (через стейт машину), валидацию. В конце описывается процесс миграции убера со старого решения поверх DynamoDB на LedgerStore.
#how_it_works #finances #scalability
—————————————
Kafka and Event Streaming — simple explanation
Изначально ожидал, что статья покажет на примере, как объяснить бизнесу необходимость использования event-driven коммуникаций. На деле текст оказался больше техническим (в моей голове), но при этом, статья не перестает быть полезной.
В тексте рассматривается два подхода: когда коммуникация происходит через команды и через события. Каждый вид коммуникации рассматривается отдельно. Дается определение что командам, что событиям. Понравилось, что поднимается тема связанная с реакционным подходом к выполнению кода для событий (об этом забывают). В конце даются плюсы event-driven коммуникации с направлением, как плюс объяснить бизнесу. К сожалению, минусов не хватило.
#event_driven #communications
—————————————
Six Degrees of Kevin Bacon - Postgres Style
Лучше графов (по мнению канала) могут быть только графовые базы данных. При этом, каждый раз радуюсь, когда нахожу статьи связанные с применением графов в контексте постгреса или чего-то более распространенного чем neo4j и аналогов. Поэтому сегодня статья, в которой приводится пример решения задачи Six Degrees of Kevin Bacon с помощью постгреса и sql.
В начале статьи рассказывается о подготовке, а точнее о выгрузке базы IMDB (с примерами схем). Далее рассказывается о pgRouting, расширении для поиска маршрута, который будет использоваться автором поста как graph solver. Для этого делается таблица
actor_graph в которой связывается актер, кино и другие актеры. А дальше, используя алгоритм дейкстры, считать количество edges между выбранным актером и Бейконом (перфоманс оставляем за скобками). В конце рассказывается о том, как recursive CTE использовать с pgRouting.#graph #graphDB #psql
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Historical Data in Databases. Audit Tables. Event Sourcing
Открытие 2024 года – блог автора, который писал об онлайн гейм девелопменте с фокусом на базы и структуры данных (статей из блога будет еще много в ссылках). Сегодня статья связанная с историческими данными – информацией о том, кто, что и когда сделал. Важно это, так как аналитика строится на исторической информации.
Статья рассказывает четыре темы, связанные с аудит данными:
- Что стоит и не стоит писать в аудит таблицы (как минимум, данные вокруг денег);
- Использовать одну общую таблицу или кучу разных. Тут описываются трейдоффы каждого из решений и упоминается event sourcing, как один из вариантов решений;
-
- Обрезка или перенос аудит записей. Что делать со старыми данными, как уменьшить размер БД;
Помните, что специфика автора – MMO игры, поэтому будет много примеров из геймдева. Но если ничего не знаете об аудите и нужно реализовать историю действий – статья мастхев.
#event_sourcing #audit
—————————————
The Trillion Message Kafka Setup at Walmart
Статья из серии «как в компании Х сделали Y». Сегодня это волмарт (крупная торговая сеть) и проблема работы с большим количеством данных в консьюмерах кафки. Из-за размеров компании и спайков трафика (распродажи и другие случайные события), компании приходится тратить ресурсы на поддержку асинхронной коммуникации через кафку, причем по требованиям необходим SLA в 99.99%.
В начале текста описываются три основные проблемы (детально), которые возникли у инженеров при использовании кафки: проблема с ребалансировкой консьюмеров, появление сообщений которые ломают консьюмеры и высокая цена скейлинга связанная с каплингом между топиками. Основываясь на проблемах и требованиях, в компании решили сделать Messaging Proxy Service (MPS) – сервис прослойка между брокером и консьюмерами, через который можно синхронно взаимодействовать с кафкой из консьюмера и в случае проблем отправлять события в DLQ. Далее рассказывается как работает Messaging Proxy Service, из чего состоит и при чем тут kafka connect.
Понравилось, что в конце статьи приводятся проблемные места, такие как увеличение сложности, странный выбор REST для взаимодействия и проблемы ребалансировки, но уже со стороны консьюмеров MPS.
#how_it_works #kafka #events
—————————————
Good programmers worry about data structures and their relationships
Может показаться, что выбрав «лучший» язык программирования или «популярные» паттерны, приложение будет качественным и работать корректно. На деле, в реализации, важнее оказывается моделирование данных и структур. Это одна из причин, почему в ответе на вопрос о визуализации данных столько времени уделялось концептуальной модели. Сегодняшняя короткая статья как раз является рассуждением проблемы моделирования как данных, так и структур.
Автор начинает рассуждение с цитаты Линуса, о том, что «хорошие» программисты беспокоятся о структуре данных. Далее автор рассказывает историю из жизни, когда функция на 500 строк уменьшилась в 10 раз, потому что поменяли структуру данных. Ну а дальше приводятся цитаты из The Art of Unix Programming и сообщества unix, чтобы раскрыть мысль. Ну и в конце, автор, приводит идею, что подобный подход к проектированию от данных полезен и в карьерном продвижении в FAANG.
#conceptual_data_model #data_model
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Historical Data in Databases. Audit Tables. Event Sourcing
Открытие 2024 года – блог автора, который писал об онлайн гейм девелопменте с фокусом на базы и структуры данных (статей из блога будет еще много в ссылках). Сегодня статья связанная с историческими данными – информацией о том, кто, что и когда сделал. Важно это, так как аналитика строится на исторической информации.
Статья рассказывает четыре темы, связанные с аудит данными:
- Что стоит и не стоит писать в аудит таблицы (как минимум, данные вокруг денег);
- Использовать одну общую таблицу или кучу разных. Тут описываются трейдоффы каждого из решений и упоминается event sourcing, как один из вариантов решений;
-
audit_id поле, необходимое для определения записей. Какой id выбирать, зачем нужен и как использовать;- Обрезка или перенос аудит записей. Что делать со старыми данными, как уменьшить размер БД;
Помните, что специфика автора – MMO игры, поэтому будет много примеров из геймдева. Но если ничего не знаете об аудите и нужно реализовать историю действий – статья мастхев.
#event_sourcing #audit
—————————————
The Trillion Message Kafka Setup at Walmart
Статья из серии «как в компании Х сделали Y». Сегодня это волмарт (крупная торговая сеть) и проблема работы с большим количеством данных в консьюмерах кафки. Из-за размеров компании и спайков трафика (распродажи и другие случайные события), компании приходится тратить ресурсы на поддержку асинхронной коммуникации через кафку, причем по требованиям необходим SLA в 99.99%.
В начале текста описываются три основные проблемы (детально), которые возникли у инженеров при использовании кафки: проблема с ребалансировкой консьюмеров, появление сообщений которые ломают консьюмеры и высокая цена скейлинга связанная с каплингом между топиками. Основываясь на проблемах и требованиях, в компании решили сделать Messaging Proxy Service (MPS) – сервис прослойка между брокером и консьюмерами, через который можно синхронно взаимодействовать с кафкой из консьюмера и в случае проблем отправлять события в DLQ. Далее рассказывается как работает Messaging Proxy Service, из чего состоит и при чем тут kafka connect.
Понравилось, что в конце статьи приводятся проблемные места, такие как увеличение сложности, странный выбор REST для взаимодействия и проблемы ребалансировки, но уже со стороны консьюмеров MPS.
#how_it_works #kafka #events
—————————————
Good programmers worry about data structures and their relationships
Может показаться, что выбрав «лучший» язык программирования или «популярные» паттерны, приложение будет качественным и работать корректно. На деле, в реализации, важнее оказывается моделирование данных и структур. Это одна из причин, почему в ответе на вопрос о визуализации данных столько времени уделялось концептуальной модели. Сегодняшняя короткая статья как раз является рассуждением проблемы моделирования как данных, так и структур.
Автор начинает рассуждение с цитаты Линуса, о том, что «хорошие» программисты беспокоятся о структуре данных. Далее автор рассказывает историю из жизни, когда функция на 500 строк уменьшилась в 10 раз, потому что поменяли структуру данных. Ну а дальше приводятся цитаты из The Art of Unix Programming и сообщества unix, чтобы раскрыть мысль. Ну и в конце, автор, приводит идею, что подобный подход к проектированию от данных полезен и в карьерном продвижении в FAANG.
#conceptual_data_model #data_model
Марьяна попросила рассказать о том, что курс по анализу систем номинировали на образовательную премию. Если проходили курс, буду очень признательным, если поможете и проголосуете. А для тех, кто проголосовал проведем факультатив на тему систем и архитектуры (тему пока не придумали).
Telegram
Продукты, книги и любовь
Нас номинировали на премию за лучший образовательный опыт
Новая премия от School of Education, пожалуй, единственная из русскоговорящих, принципы которой мне близки.
Поэтому я сразу подала заявку, как только узнала, что они основали премию. И как обычно…
Новая премия от School of Education, пожалуй, единственная из русскоговорящих, принципы которой мне близки.
Поэтому я сразу подала заявку, как только узнала, что они основали премию. И как обычно…
Новый ответ: как перевести EventStorming модель в код
EventStorming становится популярнее с каждым годом и рассказать, как, используя толпу людей и стикеры, улучшить жизнь в компании уже мало. Теперь чаще возникает следующая проблема: что разработчикам делать с этим набором стикеров и стрелок.
Поэтому сегодня расскажу, как сам бы мапил каждый стикер в код, если бы мне дали требования и готовый EventStorming.
Как перевести EventStorming модель в код
Понимаю, что ответ будет дискуссионным, так как нет стандарта в структурах проектов: у кого-то солянка из абстракций, кто-то использует domain model pattern, а у кого-то чистый MVC. Поэтому постарался затронуть каждый из возможных вариантов, которые пришли в голову.
Кроме этого, будет интересно почитать другие варианты маппинга, так как ответ, в первую очередь, попытка начать дискуссию и сделать «generic гайдлайн» в отрыве от специфики языков и фреймворков. Поэтому, пишите в комментарии, постараюсь дополнить ответ в будущем.
Анонсмент: в виду загруженности, в следующий ответ на вопрос будет не раньше 11 ноября, пятничные ссылки будут без перебоев.
EventStorming становится популярнее с каждым годом и рассказать, как, используя толпу людей и стикеры, улучшить жизнь в компании уже мало. Теперь чаще возникает следующая проблема: что разработчикам делать с этим набором стикеров и стрелок.
Поэтому сегодня расскажу, как сам бы мапил каждый стикер в код, если бы мне дали требования и готовый EventStorming.
Как перевести EventStorming модель в код
Понимаю, что ответ будет дискуссионным, так как нет стандарта в структурах проектов: у кого-то солянка из абстракций, кто-то использует domain model pattern, а у кого-то чистый MVC. Поэтому постарался затронуть каждый из возможных вариантов, которые пришли в голову.
Кроме этого, будет интересно почитать другие варианты маппинга, так как ответ, в первую очередь, попытка начать дискуссию и сделать «generic гайдлайн» в отрыве от специфики языков и фреймворков. Поэтому, пишите в комментарии, постараюсь дополнить ответ в будущем.
Анонсмент: в виду загруженности, в следующий ответ на вопрос будет не раньше 11 ноября, пятничные ссылки будут без перебоев.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
A crash course on building a distributed message broker like Kafka from scratch - Part 1
Считаю, что если хочешь понять технологию лучше – реализуй технологию самостоятельно. Так, сделав интерпретатор scheme, я лучше разобрался с lisp. Сегодня первая статья из серии (других нет пока), в которой автор, взяв go, реализует аналог kafka.
В начале объясняется главная идея кафки в виде «distributed commit log» и рассказывается, когда append-only log data structure могут быть полезны (кроме брокеров: аудит, эвент сорсинг, управление спорами). Понравилось, что упоминаются базы данных, в которых реализуется аналогичный append-only log, для фиксации транзакций. После, рассказывается о cluster node – отдельный инстанс кластера в распределенной системе. В случае кафки, нода хранит commit log. После показывается как написать ноду и лог и в конце запускается «простой» инстанс, который хранит и пишет данные в лог.
#how_it_works #kafka
—————————————
How to deal with Technical Debt in legacy projects
Тех долг присутствует в каждом первом проекте. Причем, работа с ним превращается в бесконечный бэклог задач, на которые нет ресурсов. Что бы избежать подобной ситуации, придется научиться определять критичный для бизнеса тех долг и сегодняшняя статья показывает, как используя CodeScene искать подобные места.
В начале дается определение тех долга. Отдельно отмечу, что указывается, что тех долг – бизнесовая проблема и описываются пять бизнесовых причин, на которые влияет тех долг. После, автор дает определение легаси и после связывает легаси с тех долгом описывая, что такое «плохой» код. Дальше описываются подходы для «наблюдения/измерения» тех долга (DORA, DevX и другие метрики, плюс упоминается CodeScene). Плюс советы по уменьшению тех долга: тесты, документация, код ревью, стандарты и постоянный рефакторинг.
В конце самое интересное: на примере CodeScene показывается как анализировать кодовую базу проекта. Описывается как найти high interest rates, определить hotspots, работать с complexity trends. В качестве примера разбирается open source проект на dotnet
#tech_debt
—————————————
API Versioning at Monite
Если продукт – API first (это не только HTTP API, но еще и библиотеки и прочее), то для развития системы придется задуматься, как развивать публичные интерфейсы. Вариантов два: либо никогда не менять или сделать сразу «идеальный» интерфейс, либо же версионировать. Сегодняшняя статья, как раз опыт решения проблемы изменения интерфейсов, через версионирование.
Сначала автор описывает три подхода к реализации версионирования API: через гейтвей, через копирование только изменяющихся эндпоинтов и через полное копирование каждого эндпоинта из версии в версию. Плюс, затрагиваются темы количества версий и общей стоимости решения. После, указываются проблемы, которые пришлось решать в компании: как поддерживать сразу много версий и легко удалять старые и добавлять новые версии API.
А как решение проблемы, автор сделал библиотеку для питона, которая реализует подход страйпа. Дальше описывается как происходит изменение между версиями, как работает чейн версий для эндпоинтов, работа с ошибками и поиск «опасных» мест в API. Каких-то откровений от текста не ждите, но если никогда до этого не работали с версионированием или хотите сделать аналогичную библиотеку для другого языка – статью стоит прочитать (и коментарии на хабре).
Русский перевод
#api #versioning #sync_communication
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
A crash course on building a distributed message broker like Kafka from scratch - Part 1
Считаю, что если хочешь понять технологию лучше – реализуй технологию самостоятельно. Так, сделав интерпретатор scheme, я лучше разобрался с lisp. Сегодня первая статья из серии (других нет пока), в которой автор, взяв go, реализует аналог kafka.
В начале объясняется главная идея кафки в виде «distributed commit log» и рассказывается, когда append-only log data structure могут быть полезны (кроме брокеров: аудит, эвент сорсинг, управление спорами). Понравилось, что упоминаются базы данных, в которых реализуется аналогичный append-only log, для фиксации транзакций. После, рассказывается о cluster node – отдельный инстанс кластера в распределенной системе. В случае кафки, нода хранит commit log. После показывается как написать ноду и лог и в конце запускается «простой» инстанс, который хранит и пишет данные в лог.
#how_it_works #kafka
—————————————
How to deal with Technical Debt in legacy projects
Тех долг присутствует в каждом первом проекте. Причем, работа с ним превращается в бесконечный бэклог задач, на которые нет ресурсов. Что бы избежать подобной ситуации, придется научиться определять критичный для бизнеса тех долг и сегодняшняя статья показывает, как используя CodeScene искать подобные места.
В начале дается определение тех долга. Отдельно отмечу, что указывается, что тех долг – бизнесовая проблема и описываются пять бизнесовых причин, на которые влияет тех долг. После, автор дает определение легаси и после связывает легаси с тех долгом описывая, что такое «плохой» код. Дальше описываются подходы для «наблюдения/измерения» тех долга (DORA, DevX и другие метрики, плюс упоминается CodeScene). Плюс советы по уменьшению тех долга: тесты, документация, код ревью, стандарты и постоянный рефакторинг.
В конце самое интересное: на примере CodeScene показывается как анализировать кодовую базу проекта. Описывается как найти high interest rates, определить hotspots, работать с complexity trends. В качестве примера разбирается open source проект на dotnet
#tech_debt
—————————————
API Versioning at Monite
Если продукт – API first (это не только HTTP API, но еще и библиотеки и прочее), то для развития системы придется задуматься, как развивать публичные интерфейсы. Вариантов два: либо никогда не менять или сделать сразу «идеальный» интерфейс, либо же версионировать. Сегодняшняя статья, как раз опыт решения проблемы изменения интерфейсов, через версионирование.
Сначала автор описывает три подхода к реализации версионирования API: через гейтвей, через копирование только изменяющихся эндпоинтов и через полное копирование каждого эндпоинта из версии в версию. Плюс, затрагиваются темы количества версий и общей стоимости решения. После, указываются проблемы, которые пришлось решать в компании: как поддерживать сразу много версий и легко удалять старые и добавлять новые версии API.
А как решение проблемы, автор сделал библиотеку для питона, которая реализует подход страйпа. Дальше описывается как происходит изменение между версиями, как работает чейн версий для эндпоинтов, работа с ошибками и поиск «опасных» мест в API. Каких-то откровений от текста не ждите, но если никогда до этого не работали с версионированием или хотите сделать аналогичную библиотеку для другого языка – статью стоит прочитать (и коментарии на хабре).
Русский перевод
#api #versioning #sync_communication
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Content Engineering makes a federated graph searchable
Очередная статья из серии «как в компании X решили проблему Y». На этот раз продолжение истории с graphQL в нетфликсе, только вместо скейлинга – поиск по графу.
Напомню, что в нетфликсе сделали аналог энтити сервисов с graphql интерфейсом, где каждая сущность – отдельный сервис со своей командой разработки. В какой-то момент возникла проблема поиска на основе атрибутов других объектов (например, получить список текущих фильмов, где снимается Райан Рейнольдс). Т.е. как искать по графу (который структура, а не graphQL) в рамках распределенной системы. Ну и не трудно догадаться, что для этого сделали еще один сервис, который назвали studio search.
Дальше рассказывается о внутреннем устройстве сервиса и о том, как изначальная идея реализации поиска через индексы каждого подграфа поверх ElasticSearch сработала. Для создания индекса стримятся данные, после, для поиска используется полученный индекс. Из интересного – механизм обратного поиска для проверки консистентности данных.
Русский перевод
#how_it_works #graphql #searching
—————————————
Здоровье кодовой базы
Лет 50-20 назад, люди придумывали метрики, которые помогали автоматически оценить «качество» кодовой базы. Одна из таких метрик – distance from the main sequence, которая говорит на сколько модуль полезен или проблематичен, основываясь на instability и abstractness метриках. Например, в джаве есть JDepend, который из коробки посчитает значение метрики.
В статье выше подробно объясняется, в чем смысл distance from the main sequence. Текст начинается с afferent и efferent coupling (набор инструментов для пхп опускаю), после чего рассказывается об instability, показывающей степень подверженности изменениям рассматриваемого класса при изменении зависимостей. После рассказывается о том, как добавив abstractness, получить плоскость, в которой можно определить «качество» модуля.
Может показаться, что подобные метрики архаика и нужны только в джаве/дотнете .Но так как метрика связана больше с каплингом, а не с кодовой реализацией, то нет никаких проблем перенести distance from the main sequence и похожие метрики на уровень выше и считать таким образом «качество» сервисов в распределенных системах.
#oop #code_metrics
—————————————
Databases 101: ACID, MVCC vs Locks, Transaction Isolation Levels, and Concurrency
Данную ссылку сложно назвать полноценной статьей, скорее это набор определений вокруг баз данных. В данном случае автор затрагивает следующие темы:
- Виды баз данных (аналитические, OLTP, archive DB и real-time reporting) ;
- ACID. Расшифровывается каждая буква термина с примерами;
- Lock-based Concurrency Control, где рассказывается о четырех видах транзакций: read uncommitted/committed, repeatable reads и serializable;
- Multi-Versioned Concurrency Control (MVCC);
- Сравнении между lock-based и multi-versioned;
Если искали энтри поинт в работу баз данных, статья однозначно подойдет. Единственный минус – это не полноценный учебник, поэтому глубины DDIA или database internals книг не ждите. Ну и напомню, что автор специализируется на MMO играх, поэтому специфика информации и примеры отличаются от веба.
#db #acid
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Content Engineering makes a federated graph searchable
Очередная статья из серии «как в компании X решили проблему Y». На этот раз продолжение истории с graphQL в нетфликсе, только вместо скейлинга – поиск по графу.
Напомню, что в нетфликсе сделали аналог энтити сервисов с graphql интерфейсом, где каждая сущность – отдельный сервис со своей командой разработки. В какой-то момент возникла проблема поиска на основе атрибутов других объектов (например, получить список текущих фильмов, где снимается Райан Рейнольдс). Т.е. как искать по графу (который структура, а не graphQL) в рамках распределенной системы. Ну и не трудно догадаться, что для этого сделали еще один сервис, который назвали studio search.
Дальше рассказывается о внутреннем устройстве сервиса и о том, как изначальная идея реализации поиска через индексы каждого подграфа поверх ElasticSearch сработала. Для создания индекса стримятся данные, после, для поиска используется полученный индекс. Из интересного – механизм обратного поиска для проверки консистентности данных.
Русский перевод
#how_it_works #graphql #searching
—————————————
Здоровье кодовой базы
Лет 50-20 назад, люди придумывали метрики, которые помогали автоматически оценить «качество» кодовой базы. Одна из таких метрик – distance from the main sequence, которая говорит на сколько модуль полезен или проблематичен, основываясь на instability и abstractness метриках. Например, в джаве есть JDepend, который из коробки посчитает значение метрики.
В статье выше подробно объясняется, в чем смысл distance from the main sequence. Текст начинается с afferent и efferent coupling (набор инструментов для пхп опускаю), после чего рассказывается об instability, показывающей степень подверженности изменениям рассматриваемого класса при изменении зависимостей. После рассказывается о том, как добавив abstractness, получить плоскость, в которой можно определить «качество» модуля.
Может показаться, что подобные метрики архаика и нужны только в джаве/дотнете .Но так как метрика связана больше с каплингом, а не с кодовой реализацией, то нет никаких проблем перенести distance from the main sequence и похожие метрики на уровень выше и считать таким образом «качество» сервисов в распределенных системах.
#oop #code_metrics
—————————————
Databases 101: ACID, MVCC vs Locks, Transaction Isolation Levels, and Concurrency
Данную ссылку сложно назвать полноценной статьей, скорее это набор определений вокруг баз данных. В данном случае автор затрагивает следующие темы:
- Виды баз данных (аналитические, OLTP, archive DB и real-time reporting) ;
- ACID. Расшифровывается каждая буква термина с примерами;
- Lock-based Concurrency Control, где рассказывается о четырех видах транзакций: read uncommitted/committed, repeatable reads и serializable;
- Multi-Versioned Concurrency Control (MVCC);
- Сравнении между lock-based и multi-versioned;
Если искали энтри поинт в работу баз данных, статья однозначно подойдет. Единственный минус – это не полноценный учебник, поэтому глубины DDIA или database internals книг не ждите. Ну и напомню, что автор специализируется на MMO играх, поэтому специфика информации и примеры отличаются от веба.
#db #acid
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Counting Billions of Content Usage at Canva
Еще одна статья о компании, которая решала проблемы. На этот раз текст о проблеме не правильных расчетов в canva во время работы над Creators Program (это когда дизайнеры продают дизайн другим людям). Проблема возникла с подсчетом использования контента от креаторов, а точнее в трех вещах: точность подсчета, скейлинг под нагрузку (количество использований увеличивалось в 2 раза каждый месяц) и operability (сложность обслуживания).
После описания проблемы рассказывается изначальный вариант системы, который состоял из трех основных частей: получения данных и хранения сырой информации, удаление дубликатов использования и отчищения данных и куска с инкрементацией каунтеров использования контента. Дальше возникла проблема с базой, которая стала ботлнеком. В качестве решения проблемы компания мигрировала dynamoDB для сбора сырых данных и объединила «чистку данных» и расчет количества использования контента в один ETL подобный сервис с OLAP. После чего рассказывается какие плюсы появились при использовании OLAP. В конце даются выводы и плюсы решения. Понравилось, что указаны новые проблемы, которые появились из-за решения.
#how_it_works
—————————————
Architectural Retrospectives: the Key to Getting Better at Architecting
В разработке (и не только) ретро повсеместная практика. В случае архитектурных команд подобного не встречал (но надеюсь, что это личная ошибка выжившего). Сегодняшняя статья как раз рассказывает об архитектурных ретроспективах, благодаря которым оценивается не решение, а сам процесс принятия решения командой (включая вопросы, которые задаются, во время принятия решений). В результате чего, в теории, процесс принятия архитектурных решений должен улучшаться.
В начале статьи автор описывает разницу между ретро и ревью (ревью как раз оценивает решение, а не то, как к этому решению пришли). После этого даются советы о том, как проводить ретро – в этом помогут отделение ретро от ревью и набор вопросов из скрама.
Важно отметить, что статья больше об идеи, чем о практике. Т.е. текст из той области, где говорится о том, что можно изучить самостоятельно, вместо конкретных шагов и набора действий.
#decision_making #retro #ppl_managment
—————————————
Testing Automation, What are Pyramids and Diamonds?
Возможно вы слышали о пирамиде тестирования: это когда в проекте много unit тестов, чуть меньше integration тестов и еще меньше e2e тестов. Вроде как, концепцию предложил Фаулер (возможно ошибаюсь), но, в спустя время, поняв, что не всегда тесты стоит писать по пирамиде, добавилось еще два подхода: test diamond и перевернутая пирамида.
Сегодняшняя короткая статья как раз в трех подходов в тестировании. В самом начале рассказывается о видах тестирования (чем юнит от интеграционного и e2e отличается). После автор рассматривает три подхода, рассказывая как реализовать каждый из подходов. Самое интересное, в последней части: автор приводит две таблицы, одну для описания когда какой подход подходит, а вторая – показывающая связь между свойствами системы и выбранной пирамидой (только с обратной пирамидой я не согласен). В конце еще шесть референсов по теме, если не хватит статьи.
#testing #testing_pyramid
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Counting Billions of Content Usage at Canva
Еще одна статья о компании, которая решала проблемы. На этот раз текст о проблеме не правильных расчетов в canva во время работы над Creators Program (это когда дизайнеры продают дизайн другим людям). Проблема возникла с подсчетом использования контента от креаторов, а точнее в трех вещах: точность подсчета, скейлинг под нагрузку (количество использований увеличивалось в 2 раза каждый месяц) и operability (сложность обслуживания).
После описания проблемы рассказывается изначальный вариант системы, который состоял из трех основных частей: получения данных и хранения сырой информации, удаление дубликатов использования и отчищения данных и куска с инкрементацией каунтеров использования контента. Дальше возникла проблема с базой, которая стала ботлнеком. В качестве решения проблемы компания мигрировала dynamoDB для сбора сырых данных и объединила «чистку данных» и расчет количества использования контента в один ETL подобный сервис с OLAP. После чего рассказывается какие плюсы появились при использовании OLAP. В конце даются выводы и плюсы решения. Понравилось, что указаны новые проблемы, которые появились из-за решения.
#how_it_works
—————————————
Architectural Retrospectives: the Key to Getting Better at Architecting
В разработке (и не только) ретро повсеместная практика. В случае архитектурных команд подобного не встречал (но надеюсь, что это личная ошибка выжившего). Сегодняшняя статья как раз рассказывает об архитектурных ретроспективах, благодаря которым оценивается не решение, а сам процесс принятия решения командой (включая вопросы, которые задаются, во время принятия решений). В результате чего, в теории, процесс принятия архитектурных решений должен улучшаться.
В начале статьи автор описывает разницу между ретро и ревью (ревью как раз оценивает решение, а не то, как к этому решению пришли). После этого даются советы о том, как проводить ретро – в этом помогут отделение ретро от ревью и набор вопросов из скрама.
Важно отметить, что статья больше об идеи, чем о практике. Т.е. текст из той области, где говорится о том, что можно изучить самостоятельно, вместо конкретных шагов и набора действий.
#decision_making #retro #ppl_managment
—————————————
Testing Automation, What are Pyramids and Diamonds?
Возможно вы слышали о пирамиде тестирования: это когда в проекте много unit тестов, чуть меньше integration тестов и еще меньше e2e тестов. Вроде как, концепцию предложил Фаулер (возможно ошибаюсь), но, в спустя время, поняв, что не всегда тесты стоит писать по пирамиде, добавилось еще два подхода: test diamond и перевернутая пирамида.
Сегодняшняя короткая статья как раз в трех подходов в тестировании. В самом начале рассказывается о видах тестирования (чем юнит от интеграционного и e2e отличается). После автор рассматривает три подхода, рассказывая как реализовать каждый из подходов. Самое интересное, в последней части: автор приводит две таблицы, одну для описания когда какой подход подходит, а вторая – показывающая связь между свойствами системы и выбранной пирамидой (только с обратной пирамидой я не согласен). В конце еще шесть референсов по теме, если не хватит статьи.
#testing #testing_pyramid
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Github: Using SQL's Turing Completeness to Build Tetris
Не статья в привычном понимании, но пройти стороной не могу. ТЛДР: берем постгрес и на SQL пишем полноценный тетрис. В результате получился репозиторий с кодом и объяснением как код работает, плюс скрипт на питоне для запуска запроса и отлова команд. Код разбит на три части: гейм луп через рекурсию, инпут реализованный через таблицу и аутпут. Поле сделано через одномерный массив, текущая фигура хранится в массиве состоящем из позиции, поворота и id фигуры. Также рассказывается о реализации рандома, рендеринга и приводятся расчеты по resource usage. Отдельно отмечу, что в сиквел коде подробные комментарии с тем, как работает каждая функция.
Проект скорее шуточный, чем продакшен реди. Но, если хотите глубже разобраться с сиквелом и узнать новые функции (сам узнал о
#sql
—————————————
Exactly-Once Payments At Airbnb
Одна из проблем с онлайн платежам связана с необходимостью exactly-once доставки, что становится не выполнимым в распределенных системах. В качестве решения на помощь приходит идемпотентность. В статье выше рассказывается о том, как airbnb использует идемпотентность для реализации платежной системы с использованием rpc.
Инженеры делят каждый запрос, в контексте бекенда, на 3 фазы: pre-RPC, RPC and post-RPC. В pre-RPC фазе проверяется ключ и лочится ресурс по ключу, после чего вызывается RPC, а на фазе post-RPC происходит сохранение ответа. При этом, каждый зафейленый результат маркируется как retryable и non-retryable и эта информация отправляется клиенту для дальнейшей обработки. После рассказывается о клиентской части, причем автор отсылается к опыту страйпа. Описываются три свойства для обработки failed requests к идемпотентным серверам: consistency, safety и responsibility.
#how_it_works #payment #idempotency
—————————————
Postgres webhooks with pgstream
Когда упоминается стриминг данных из части системы в другую (читай CDC), в голову приходят брокеры и события. Кроме этого, можно вспомнить о синхронной коммуникации по средствам http/rpc. Но о вебхуках, в контексте CDC говорят редко, поэтому сегодня статья о pgstream, благодаря которому можно стримить изменения в данных и через вебсокеты.
Для работы библиотеки придется поднять постгрес с wal2json, который сериализует изменения в json. После чего запустить pgstream. Важно: это не экстеншен для постгреса, а отдельный сервис на го, который кроме вебхуков еще умеет отправлять данные в эластик/OpenSearch и кафку. В посте найдете как работает сервис для вебхуков и какие данные передаются.
Подобная библиотека может использоваться как замена debezium, когда консьюмеры CDC не могут работать через кафку. Из плюсов – модульность продьюсеров (можно разные продьюсеры одновременно использовать), а из минусов – завязка на плагин для json сериализации и кафку, плюс мало звезд на гитхабе.
#data_streaming #cdc
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Github: Using SQL's Turing Completeness to Build Tetris
Не статья в привычном понимании, но пройти стороной не могу. ТЛДР: берем постгрес и на SQL пишем полноценный тетрис. В результате получился репозиторий с кодом и объяснением как код работает, плюс скрипт на питоне для запуска запроса и отлова команд. Код разбит на три части: гейм луп через рекурсию, инпут реализованный через таблицу и аутпут. Поле сделано через одномерный массив, текущая фигура хранится в массиве состоящем из позиции, поворота и id фигуры. Также рассказывается о реализации рандома, рендеринга и приводятся расчеты по resource usage. Отдельно отмечу, что в сиквел коде подробные комментарии с тем, как работает каждая функция.
Проект скорее шуточный, чем продакшен реди. Но, если хотите глубже разобраться с сиквелом и узнать новые функции (сам узнал о
RAISE NOTICE и LATERAL), либо же написать тетрис на другом языке – мастхев.#sql
—————————————
Exactly-Once Payments At Airbnb
Одна из проблем с онлайн платежам связана с необходимостью exactly-once доставки, что становится не выполнимым в распределенных системах. В качестве решения на помощь приходит идемпотентность. В статье выше рассказывается о том, как airbnb использует идемпотентность для реализации платежной системы с использованием rpc.
Инженеры делят каждый запрос, в контексте бекенда, на 3 фазы: pre-RPC, RPC and post-RPC. В pre-RPC фазе проверяется ключ и лочится ресурс по ключу, после чего вызывается RPC, а на фазе post-RPC происходит сохранение ответа. При этом, каждый зафейленый результат маркируется как retryable и non-retryable и эта информация отправляется клиенту для дальнейшей обработки. После рассказывается о клиентской части, причем автор отсылается к опыту страйпа. Описываются три свойства для обработки failed requests к идемпотентным серверам: consistency, safety и responsibility.
#how_it_works #payment #idempotency
—————————————
Postgres webhooks with pgstream
Когда упоминается стриминг данных из части системы в другую (читай CDC), в голову приходят брокеры и события. Кроме этого, можно вспомнить о синхронной коммуникации по средствам http/rpc. Но о вебхуках, в контексте CDC говорят редко, поэтому сегодня статья о pgstream, благодаря которому можно стримить изменения в данных и через вебсокеты.
Для работы библиотеки придется поднять постгрес с wal2json, который сериализует изменения в json. После чего запустить pgstream. Важно: это не экстеншен для постгреса, а отдельный сервис на го, который кроме вебхуков еще умеет отправлять данные в эластик/OpenSearch и кафку. В посте найдете как работает сервис для вебхуков и какие данные передаются.
Подобная библиотека может использоваться как замена debezium, когда консьюмеры CDC не могут работать через кафку. Из плюсов – модульность продьюсеров (можно разные продьюсеры одновременно использовать), а из минусов – завязка на плагин для json сериализации и кафку, плюс мало звезд на гитхабе.
#data_streaming #cdc