Пятничное чтиво
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
How does an email service work?
Статья из серии «как работает штука, которой пользуешься каждый день». На этот раз о том, как работает емейл сервис и зачем нужны SMTP и IMAP (или POP3) протоколы.
В начале говориться о SMTP сервере, который нужен для отправки и получения писем и работает на 25 и 587 портах (25 - стандартный для TCP, который уже не используется, если верить википедии и на замену пришел 587 или 465). SMTP сервер выполняет следующие функции: передача сообщений, проверка почтовых адресов, роутинг доставки и предоставление security и authority (например, для предотвращения спама). После этого автор описывает основные команды и ограничения протокола, например SMTP не поддерживает mailbox как концепцию.
После этого рассказывается о IMAP и POP3 протоколах, которые используются для пуллингаписем и реализации mailbox. А в самом конце описывается полный флоу отправки и получения писем в трех шагах (отправка письма, передача через интернет и получение входящих писем). Отдельно отмечу, что понравилось, что автор оставил три вопроса для самопроверки, так как это редкость в подобных текстах.
#how_it_works #email
—————————————
Isolating Rails Engines with RuboCop
Не смотрите на то, что статья о ruby/rails и экосистеме. В данном случае важна идея, которая описывается в статье, а именно то, как можно проверять связанность элементов системы используя линтеры. При этом, такой подход можно использовать для создания fitness functions, которые помогут проверить соответствие системы заданным характеристикам. Например, в питоне, есть библиотека, которая делает что-то похожее, а в джаве – ArchUnit.
В тексте найдете что именно автор хочет изолировать в модулях (произвольные записи и чтение в обход публичных интерфейсов). Если интересна рубишная специфика – автор рассказывает какие есть инструменты в рельсовых энджинах, как используется рубокоп и какие плюсы и ограничения у такого подхода. Кроме этого, рассуждается как еще можно провернуть аналогичную проверку.
#ruby #isolation #fitness_functions
—————————————
YouTube Database – How Does It Store So Many Videos Without Running Out Of Storage Space?
Как неоднократно говорил - я фанат статей о том, как что-то работает. Поэтому вторая статья из этой серии о том, как ютуб хранит информацию. Единственное, не до конца понял, это рассуждения о том, как такое делать или действительно описание внутренней кухни (но больше похоже на внутрянку). В начале описывается инфраструктура в виде микросервисов на джаве, си, крестах, го и питоне, а в качестве базы данных - MySQL, при этом, для каждого видео используется глобальный id, который уникален для системы. После этого, автор описывает как устроена мастер-слейв репликация данных, шардирование и disaster management. После этого уделяется внимание Vitess - система кластеризации баз данных поверх MySQL для горизонтального скейлинга. В конце информация о GFS (google file system), благодаря которой происходит магия с хранением данных.
#how_it_works #datamanagment
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
How does an email service work?
Статья из серии «как работает штука, которой пользуешься каждый день». На этот раз о том, как работает емейл сервис и зачем нужны SMTP и IMAP (или POP3) протоколы.
В начале говориться о SMTP сервере, который нужен для отправки и получения писем и работает на 25 и 587 портах (25 - стандартный для TCP, который уже не используется, если верить википедии и на замену пришел 587 или 465). SMTP сервер выполняет следующие функции: передача сообщений, проверка почтовых адресов, роутинг доставки и предоставление security и authority (например, для предотвращения спама). После этого автор описывает основные команды и ограничения протокола, например SMTP не поддерживает mailbox как концепцию.
После этого рассказывается о IMAP и POP3 протоколах, которые используются для пуллингаписем и реализации mailbox. А в самом конце описывается полный флоу отправки и получения писем в трех шагах (отправка письма, передача через интернет и получение входящих писем). Отдельно отмечу, что понравилось, что автор оставил три вопроса для самопроверки, так как это редкость в подобных текстах.
#how_it_works #email
—————————————
Isolating Rails Engines with RuboCop
Не смотрите на то, что статья о ruby/rails и экосистеме. В данном случае важна идея, которая описывается в статье, а именно то, как можно проверять связанность элементов системы используя линтеры. При этом, такой подход можно использовать для создания fitness functions, которые помогут проверить соответствие системы заданным характеристикам. Например, в питоне, есть библиотека, которая делает что-то похожее, а в джаве – ArchUnit.
В тексте найдете что именно автор хочет изолировать в модулях (произвольные записи и чтение в обход публичных интерфейсов). Если интересна рубишная специфика – автор рассказывает какие есть инструменты в рельсовых энджинах, как используется рубокоп и какие плюсы и ограничения у такого подхода. Кроме этого, рассуждается как еще можно провернуть аналогичную проверку.
#ruby #isolation #fitness_functions
—————————————
YouTube Database – How Does It Store So Many Videos Without Running Out Of Storage Space?
Как неоднократно говорил - я фанат статей о том, как что-то работает. Поэтому вторая статья из этой серии о том, как ютуб хранит информацию. Единственное, не до конца понял, это рассуждения о том, как такое делать или действительно описание внутренней кухни (но больше похоже на внутрянку). В начале описывается инфраструктура в виде микросервисов на джаве, си, крестах, го и питоне, а в качестве базы данных - MySQL, при этом, для каждого видео используется глобальный id, который уникален для системы. После этого, автор описывает как устроена мастер-слейв репликация данных, шардирование и disaster management. После этого уделяется внимание Vitess - система кластеризации баз данных поверх MySQL для горизонтального скейлинга. В конце информация о GFS (google file system), благодаря которой происходит магия с хранением данных.
#how_it_works #datamanagment
Пятничное чтиво
Ежегодно рассказываю о конференции rubyrussia. В этом году конференция пройдет 30 сентября онлайн. Предположу, что для не рубистов интересны будут два доклада - по игровым движкам и по работе с бизнес процессами.
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Understanding Redis High-Availability Architectures
Редис, как и постгрес, две базы которые встречаю в 95% проектов, вне зависимости размеров компании. При этом, пока проект не большой, хватает одного инстанса редиса, но как только количество данных увеличивается и нагрузка на базу - начинаются проблемы. Сегодняшняя статья от инженеров semaphore как раз рассказывает о том, как добиться высокой доступности для инстанса (или инстанов) редиса. Для этого рассматривается четыре подхода:
- Репликация, в которой все попадает в мастер инстанс и после этого данные перетекают на рид онли реплики;
- Кластер (шардирование);
- Sentinel - реализация кластера через мастер реплику, которая работает для ситуаций, когда обычный кластер не подходит;
- Прокси решение через сторонние инструменты, например twemproxy;
Каждый вариант подробно описывается, а в конце даются плюсы и минусы каждого из подходов.
#availability #redis
—————————————
A Playbook to Scale MLOps
Хоть я и не имею никакого отношения к машинному обучению, но иногда возникают ситуации, в которых приходиться взаимодействовать и помогать ML командам. Поэтому иногда читаю статьи про около ML. Поэтому сегодня статья о том, как скейлить MLOps в компании, где под MLOps подразумевается переход компании от создания нескольких мл моделей к постоянной работе над алгоритмами.
Для этого авторы предлагают рассмотреть пять направлений:
- Measurement and Impact – как команды отслеживают и измеряют прогресс;
- Deployment & Infrastructure – способы деплоймента;
- Monitoring – поддержка качества и перфоманса моделей;
- Governance – получение контроля и наблюдаемости над моделями;
- Evangelizing MLOps – обучение бизнеса и других тех команд тому, как использовать MLOps;
Для каждого направления описывается что нужно делать, даются идеи для дальнейших шагов и на примере Ford Motors показывается как авторы статьи показатели MLOps в компании.
#mlops
—————————————
Пишем менеджер пакетов
Написание менеджеров пакетов, как отмечает автор статьи выше, довольно редкая практика. При этом, менеджеры пакетов используются везде, начиная от языков программирования и заканчивая homebrew редакторами. Автор решил написать менеджер пакетов для плагинов SQLite и делится опытом. Статья состоит из двух частей: описания общих принципов работы и реализации на го. В описании принципов работы рассказывается о спецификации пакетов, видимости, версионировании, лок файлах, работе с зависимостями, контрольных суммах, установки и обновлении. В секции с реализацией найдете примеры кода и описание что каждый из модулей делает, например кусок кода для обновления зависимостей.
Если не пишите с нуля язык программирования и не решили помочь в развитию нового языка, в котором нет менеджера пакетов, то скорее всего информация из статьи будет лишней. Но информацию из статьи можно использовать, чтобы лучше понять как работают пакетные менеджеры, благодаря чему начать опенсорс карьеру мейнтейнера менеджера пакетов в выбранной экосистеме.
#how_it_works #package_manager
Ежегодно рассказываю о конференции rubyrussia. В этом году конференция пройдет 30 сентября онлайн. Предположу, что для не рубистов интересны будут два доклада - по игровым движкам и по работе с бизнес процессами.
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Understanding Redis High-Availability Architectures
Редис, как и постгрес, две базы которые встречаю в 95% проектов, вне зависимости размеров компании. При этом, пока проект не большой, хватает одного инстанса редиса, но как только количество данных увеличивается и нагрузка на базу - начинаются проблемы. Сегодняшняя статья от инженеров semaphore как раз рассказывает о том, как добиться высокой доступности для инстанса (или инстанов) редиса. Для этого рассматривается четыре подхода:
- Репликация, в которой все попадает в мастер инстанс и после этого данные перетекают на рид онли реплики;
- Кластер (шардирование);
- Sentinel - реализация кластера через мастер реплику, которая работает для ситуаций, когда обычный кластер не подходит;
- Прокси решение через сторонние инструменты, например twemproxy;
Каждый вариант подробно описывается, а в конце даются плюсы и минусы каждого из подходов.
#availability #redis
—————————————
A Playbook to Scale MLOps
Хоть я и не имею никакого отношения к машинному обучению, но иногда возникают ситуации, в которых приходиться взаимодействовать и помогать ML командам. Поэтому иногда читаю статьи про около ML. Поэтому сегодня статья о том, как скейлить MLOps в компании, где под MLOps подразумевается переход компании от создания нескольких мл моделей к постоянной работе над алгоритмами.
Для этого авторы предлагают рассмотреть пять направлений:
- Measurement and Impact – как команды отслеживают и измеряют прогресс;
- Deployment & Infrastructure – способы деплоймента;
- Monitoring – поддержка качества и перфоманса моделей;
- Governance – получение контроля и наблюдаемости над моделями;
- Evangelizing MLOps – обучение бизнеса и других тех команд тому, как использовать MLOps;
Для каждого направления описывается что нужно делать, даются идеи для дальнейших шагов и на примере Ford Motors показывается как авторы статьи показатели MLOps в компании.
#mlops
—————————————
Пишем менеджер пакетов
Написание менеджеров пакетов, как отмечает автор статьи выше, довольно редкая практика. При этом, менеджеры пакетов используются везде, начиная от языков программирования и заканчивая homebrew редакторами. Автор решил написать менеджер пакетов для плагинов SQLite и делится опытом. Статья состоит из двух частей: описания общих принципов работы и реализации на го. В описании принципов работы рассказывается о спецификации пакетов, видимости, версионировании, лок файлах, работе с зависимостями, контрольных суммах, установки и обновлении. В секции с реализацией найдете примеры кода и описание что каждый из модулей делает, например кусок кода для обновления зависимостей.
Если не пишите с нуля язык программирования и не решили помочь в развитию нового языка, в котором нет менеджера пакетов, то скорее всего информация из статьи будет лишней. Но информацию из статьи можно использовать, чтобы лучше понять как работают пакетные менеджеры, благодаря чему начать опенсорс карьеру мейнтейнера менеджера пакетов в выбранной экосистеме.
#how_it_works #package_manager
Пятничное чтиво
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google
Если проходили курс по проектированию, то знаете, что выбирать технические решения стоит основываясь на необходимых свойствах систем (это о нефункциональных требованиях, кволити аттрибутах, системных свойствах, архитектурных характеристиках и так далее). При этом, найти статьи или книги, которые о процессе нормально расскажу - довольно сложно, но сегодня исключение в виде пейпера от гугла. Смысл в использовании легковесного алгоритма, который состоит из трех шагов:
- определение критических юзер флоу и связанных кволити атрибутов
- моделирование атрибутов через QAS
- моделирование элементов и поведения
Дальше, на примере системы мониторинга доступности, корректности, производительности и других аспектов, показывается как применять каждый из шагов. Для этого показывается как система выглядела до редизайна и что получилось в итоге. Также интересен 8 пункт, с уроками, которые были получены командой, где понравился вывод о разделении формальных и функциональных аспектах системы на разные модели.
Пересказ пейпера на русском
#availability #redis
—————————————
Mastering Scalable and Maintainable Applications: A Comprehensive Guide to 12-Factor App Development
12-Factor подход состоит из 12 советов (неожиданно), которые позволяют увеличить качество проектируемых систем, через работу с кодом, деливери, зависимостями, конфигурациями и так далее. В интернете можно найти тонну статей о подходе, сегодняшняя ссылка - упрощенный вариант с картинками, в которой автор попытался человеческим языком объяснить каждый из советов. Понравилось, что для каждого пункта была нарисована картинка, которая позволит лучше запомнить совет. Если до этого не слышали о подходе - мастрид вместе со ссылкой на оригинальный сайт с советами.
#12_factor
—————————————
7 аргументов почему UUID лучше, чем автоинкрементные идентификаторы
В канале упоминаются статьи связанные с использованием UUID как pk в базе данных. Если месяц назад приводились примеры почему uuid плох (спойлер: увеличение поиска по рандомному индексу), то сегодня обратная статья, в которой приводятся плюсы. Автор приводит следующие доводы в поддержку uuid: уникальность, нет централизованности, рандомность, не нужно повторно к базе обращаться, лучше для распределенных систем, совместимость с разными бд и подходящий вариант для автономной генерации данных. В комментариях можно найти ссылку на седьмой стандарт, который позволит ускорить время индексирования ключей.
#data_managment #uuid
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google
Если проходили курс по проектированию, то знаете, что выбирать технические решения стоит основываясь на необходимых свойствах систем (это о нефункциональных требованиях, кволити аттрибутах, системных свойствах, архитектурных характеристиках и так далее). При этом, найти статьи или книги, которые о процессе нормально расскажу - довольно сложно, но сегодня исключение в виде пейпера от гугла. Смысл в использовании легковесного алгоритма, который состоит из трех шагов:
- определение критических юзер флоу и связанных кволити атрибутов
- моделирование атрибутов через QAS
- моделирование элементов и поведения
Дальше, на примере системы мониторинга доступности, корректности, производительности и других аспектов, показывается как применять каждый из шагов. Для этого показывается как система выглядела до редизайна и что получилось в итоге. Также интересен 8 пункт, с уроками, которые были получены командой, где понравился вывод о разделении формальных и функциональных аспектах системы на разные модели.
Пересказ пейпера на русском
#availability #redis
—————————————
Mastering Scalable and Maintainable Applications: A Comprehensive Guide to 12-Factor App Development
12-Factor подход состоит из 12 советов (неожиданно), которые позволяют увеличить качество проектируемых систем, через работу с кодом, деливери, зависимостями, конфигурациями и так далее. В интернете можно найти тонну статей о подходе, сегодняшняя ссылка - упрощенный вариант с картинками, в которой автор попытался человеческим языком объяснить каждый из советов. Понравилось, что для каждого пункта была нарисована картинка, которая позволит лучше запомнить совет. Если до этого не слышали о подходе - мастрид вместе со ссылкой на оригинальный сайт с советами.
#12_factor
—————————————
7 аргументов почему UUID лучше, чем автоинкрементные идентификаторы
В канале упоминаются статьи связанные с использованием UUID как pk в базе данных. Если месяц назад приводились примеры почему uuid плох (спойлер: увеличение поиска по рандомному индексу), то сегодня обратная статья, в которой приводятся плюсы. Автор приводит следующие доводы в поддержку uuid: уникальность, нет централизованности, рандомность, не нужно повторно к базе обращаться, лучше для распределенных систем, совместимость с разными бд и подходящий вариант для автономной генерации данных. В комментариях можно найти ссылку на седьмой стандарт, который позволит ускорить время индексирования ключей.
#data_managment #uuid
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
What is the V-model software development methodology?
V-model можно встретить в книгах по системной инженерии, в тестировании или на предприятиях. Смысл в том, чтобы описать процесс производства систем за три этапа: “подготовка”, реализация и тестирование. А на каждом из этапов от трех шагов (для подготовки это сбор требований, работа над архитектурой и дизайном). Но в отличие от ватерфола, где последовательно проходятся по всем шагам, в случае валидации, если какой-то из шагов не прошел - работа над системой возвращается на связанный с шагом валидации шаг “подготовки”. Благодаря этому получается зациклить производство и добиться 100% корректного результата. Но и минусов у подхода тоже хватает: модель плохо подходит для сложных систем, которые разрабатываются длительное время, а требования меняются каждую неделю.
По ссылке выше найдете подробное объяснение подхода, историю возникновения, описание каждого шага. А в конце описываются плюсы и минусы похода.
#systems #software_development
—————————————
Role-Based Access Control (RBAC) VS. Relationship-Based Access Control (ReBAC)
Когда говорят об авторизации («может ли пользователь что-то сделать») первое что приходит в голову - добавить пользовательскую роль с правами доступов. Такой подход называют RBAC, где права доступа крутятся вокруг роли. Кроме RBAC можно найти и другие подходы: основанные на атрибутах (ABAC), графовых запросах (GBAC) и так далее. При этом, знать про все виды аутентификации стоит по причине того, что не каждую систему можно описать через RBAC и что бы не городить 200+ композитных ролей (видел такое в реальности), проще выбрать другую модель.
Сегодняшняя статья о ReBAC, системе прав, основанной на том, как ресурсы и пользователи связаны между собой. В тексте найдете краткое описание RBAC, после чего рассказывается о ReBAC, из чего состоит и пример реализации полиси на rego. После чего дается сравнение между RBAC и ReBAC в разных аспектах: юзкейсах, перфомансе, сложности реализации, сложности аудита и так далее. Также, советую уделить внимание картинке в самом конце, где показывается сравнение двух подходов через редактирование чужих файлов.
#authorization
—————————————
Automated Software Architecture Visualization & Emergent Understanding
Одной из проблем архитектурных и дизайн моделей (которые квадраты и стрелки) можно назвать поддержку моделей в актуальном состоянии. Для этого можно либо руками обновлять схемы при каждом изменении системы, а можно попробовать автоматизировать генерацию схем так, чтобы каждое изменение в системе автоматически отображалось в моделях. Благодаря чему можно дешевле понимать систему и находить решения. Решением приходящим сразу в голову будет либо автоматическая генерация UML, либо С4 моделей благодаря Structurizr. Кроме того, начинают появляться каталоги сервисов (три года назад я даже пытался сделать похожий проект, если у вас есть потребность в чем-то похожем, давайте поговорим).
В статье выше, автор рассуждает о плюсах, которые появляются при реалтайм генерации моделей системы, для чего вводится понятие emergent understanding (эмерджентность - термин из теории систем, который говорит о новых свойствах системы, которых нет у отдельных частей, самый простой пример - песочные часы, которые показывают время, при этом стекло и песок время показывать не могут по отдельности). А в конце автор оптимистично предполагает, что реалтайм модели помогут иначе посмотреть на систему и дает список референсов и инструментов.
#architecture #visualization
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
What is the V-model software development methodology?
V-model можно встретить в книгах по системной инженерии, в тестировании или на предприятиях. Смысл в том, чтобы описать процесс производства систем за три этапа: “подготовка”, реализация и тестирование. А на каждом из этапов от трех шагов (для подготовки это сбор требований, работа над архитектурой и дизайном). Но в отличие от ватерфола, где последовательно проходятся по всем шагам, в случае валидации, если какой-то из шагов не прошел - работа над системой возвращается на связанный с шагом валидации шаг “подготовки”. Благодаря этому получается зациклить производство и добиться 100% корректного результата. Но и минусов у подхода тоже хватает: модель плохо подходит для сложных систем, которые разрабатываются длительное время, а требования меняются каждую неделю.
По ссылке выше найдете подробное объяснение подхода, историю возникновения, описание каждого шага. А в конце описываются плюсы и минусы похода.
#systems #software_development
—————————————
Role-Based Access Control (RBAC) VS. Relationship-Based Access Control (ReBAC)
Когда говорят об авторизации («может ли пользователь что-то сделать») первое что приходит в голову - добавить пользовательскую роль с правами доступов. Такой подход называют RBAC, где права доступа крутятся вокруг роли. Кроме RBAC можно найти и другие подходы: основанные на атрибутах (ABAC), графовых запросах (GBAC) и так далее. При этом, знать про все виды аутентификации стоит по причине того, что не каждую систему можно описать через RBAC и что бы не городить 200+ композитных ролей (видел такое в реальности), проще выбрать другую модель.
Сегодняшняя статья о ReBAC, системе прав, основанной на том, как ресурсы и пользователи связаны между собой. В тексте найдете краткое описание RBAC, после чего рассказывается о ReBAC, из чего состоит и пример реализации полиси на rego. После чего дается сравнение между RBAC и ReBAC в разных аспектах: юзкейсах, перфомансе, сложности реализации, сложности аудита и так далее. Также, советую уделить внимание картинке в самом конце, где показывается сравнение двух подходов через редактирование чужих файлов.
#authorization
—————————————
Automated Software Architecture Visualization & Emergent Understanding
Одной из проблем архитектурных и дизайн моделей (которые квадраты и стрелки) можно назвать поддержку моделей в актуальном состоянии. Для этого можно либо руками обновлять схемы при каждом изменении системы, а можно попробовать автоматизировать генерацию схем так, чтобы каждое изменение в системе автоматически отображалось в моделях. Благодаря чему можно дешевле понимать систему и находить решения. Решением приходящим сразу в голову будет либо автоматическая генерация UML, либо С4 моделей благодаря Structurizr. Кроме того, начинают появляться каталоги сервисов (три года назад я даже пытался сделать похожий проект, если у вас есть потребность в чем-то похожем, давайте поговорим).
В статье выше, автор рассуждает о плюсах, которые появляются при реалтайм генерации моделей системы, для чего вводится понятие emergent understanding (эмерджентность - термин из теории систем, который говорит о новых свойствах системы, которых нет у отдельных частей, самый простой пример - песочные часы, которые показывают время, при этом стекло и песок время показывать не могут по отдельности). А в конце автор оптимистично предполагает, что реалтайм модели помогут иначе посмотреть на систему и дает список референсов и инструментов.
#architecture #visualization
Пятничное чтиво
Пришел в подкаст к двум Иванам, поговорили о системах, сервисах, v-model и event-driven коммуникациях
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Risk-based failure modelling for increased resilience
Пока смотрел на новый архитектурный радар от thoughtworks наткнулся на подход моделирования отказов основанном на риске в trial секции радара. Подход является формальным процессом, которым занимается команда, которая деливерит фичу/продукт. Для этого, на основе опыта и знаний, команда отвечает на вопросы в духе «что произойдет, когда упадет компонент» или «на сколько серьезным может быть отказ». Благодаря чему можно рассчитать оценки criticality (CRIT) and risk priority number (RPN), на основе которых определяются риски, которые необходимо обработать в первую очередь. Кроме того, в тексте, можно найти цепочку вопросов, которая помогает обрабатывать возможные риски. Статья довольно маркетинговая, но текст можно рассмотреть как энтри поинт в работу с рисками.
#risk_managment
—————————————
Distributed Task Scheduler
Статья из серии «давайте сделаем N с нуля», где N – распределенный шедулер задач. При этом, автор предлагает чтобы шедулер имел следующие свойства: высокая доступность как для планировщика, так и для выполнения тасков, минимум отказов, скейлинг на неограниченное количество задач и как можно меньшее время ожидание запуска задачи. В качестве решения предлагается система из пяти элементов: «добавлятель» задач, база данных с задачами, приоритезация и группировка задач (тут предполагается, что сразу будет добавляться N задач в обработку), очередь задач и resource manager, который отвечает за выполнение каждой задачи. При этом, задачи предлагается разбить на три группы - срочные задачи, задачи которые могут подождать и периодические задачи. Каждый из видов задач попадает в отдельную очередь. Кроме этого, в тексте найдете как автор предлагает решать проблему идемпотентности задач, оптимизировать капасити выполнения. А в самом конце, описывается как дизайн вписывается в заданные в самом начале свойства.
#distributed_systems #task_scheduler
—————————————
Legacy Architecture Modernisation With Strategic Domain-Driven Design
Обычно, слыша о DDD, в голове появляются агрегаты, энтити и value objects. На деле, DDD в первую очередь помогает определить problem space компании (проблемы решаемые компанией) и связать проблемы с решениями (тут важно забыть о технических решениях, обычная гугл таблица может быть валидным решением проблем компании). Благодаря этому можно не только определить элементы из которых состоит компания, но и характеристики как системы целиком, так и отдельного элемента (например, этому посвящена половина курса по анализу систем).
В тексте автор делится опытом модернизации системы используя стратегический ДДД, для этого работа над изменениями разбивается на три этапа: анализ бизнеса, работа над архитектурой и планирование. А в каждый из этапов состоит из набора отдельных шагов. После чего, для каждого шага описываются практики из стратегического DDD, которые позволяют закрыть шаг. Ну и вся статья пояснение к изначальной модели. Попутно, стоит отметить, что кроме стратегического ddd, также указываются смежные вещи (карты вордли, с4, quality storming и прочее)
#architecture #ddd
Пришел в подкаст к двум Иванам, поговорили о системах, сервисах, v-model и event-driven коммуникациях
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Risk-based failure modelling for increased resilience
Пока смотрел на новый архитектурный радар от thoughtworks наткнулся на подход моделирования отказов основанном на риске в trial секции радара. Подход является формальным процессом, которым занимается команда, которая деливерит фичу/продукт. Для этого, на основе опыта и знаний, команда отвечает на вопросы в духе «что произойдет, когда упадет компонент» или «на сколько серьезным может быть отказ». Благодаря чему можно рассчитать оценки criticality (CRIT) and risk priority number (RPN), на основе которых определяются риски, которые необходимо обработать в первую очередь. Кроме того, в тексте, можно найти цепочку вопросов, которая помогает обрабатывать возможные риски. Статья довольно маркетинговая, но текст можно рассмотреть как энтри поинт в работу с рисками.
#risk_managment
—————————————
Distributed Task Scheduler
Статья из серии «давайте сделаем N с нуля», где N – распределенный шедулер задач. При этом, автор предлагает чтобы шедулер имел следующие свойства: высокая доступность как для планировщика, так и для выполнения тасков, минимум отказов, скейлинг на неограниченное количество задач и как можно меньшее время ожидание запуска задачи. В качестве решения предлагается система из пяти элементов: «добавлятель» задач, база данных с задачами, приоритезация и группировка задач (тут предполагается, что сразу будет добавляться N задач в обработку), очередь задач и resource manager, который отвечает за выполнение каждой задачи. При этом, задачи предлагается разбить на три группы - срочные задачи, задачи которые могут подождать и периодические задачи. Каждый из видов задач попадает в отдельную очередь. Кроме этого, в тексте найдете как автор предлагает решать проблему идемпотентности задач, оптимизировать капасити выполнения. А в самом конце, описывается как дизайн вписывается в заданные в самом начале свойства.
#distributed_systems #task_scheduler
—————————————
Legacy Architecture Modernisation With Strategic Domain-Driven Design
Обычно, слыша о DDD, в голове появляются агрегаты, энтити и value objects. На деле, DDD в первую очередь помогает определить problem space компании (проблемы решаемые компанией) и связать проблемы с решениями (тут важно забыть о технических решениях, обычная гугл таблица может быть валидным решением проблем компании). Благодаря этому можно не только определить элементы из которых состоит компания, но и характеристики как системы целиком, так и отдельного элемента (например, этому посвящена половина курса по анализу систем).
В тексте автор делится опытом модернизации системы используя стратегический ДДД, для этого работа над изменениями разбивается на три этапа: анализ бизнеса, работа над архитектурой и планирование. А в каждый из этапов состоит из набора отдельных шагов. После чего, для каждого шага описываются практики из стратегического DDD, которые позволяют закрыть шаг. Ну и вся статья пояснение к изначальной модели. Попутно, стоит отметить, что кроме стратегического ddd, также указываются смежные вещи (карты вордли, с4, quality storming и прочее)
#architecture #ddd
Пятничное чтиво
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
The advantages of queues on logs
В августе появился пропозал о добавлении очередей в кафку, поэтому сегодня статья в которой автор разбирается в чем отличие очередей от логов, где что использовать и как кафка реализует концепцию очередей поверх логов.
В начале текста как раз разбирается как работает и лог и очередь, где как раз говориться о главной проблемы очередей - отсутствия реализации нескольких консьюмеров для одной очереди (решается созданием очереди под консьюмер с дублированием событий). После этого рассматриваются проблемы ретраев и реализацию отправки сообщений по сети с нужными гарантиями. После этого, рассказывается о том, как реализовать очереди поверх логов (с помощью сохранения метаданных доставки сообщений и виртуальных очередей под каждый консьюмер). В конце рассказывается о том, как будет реализовываться порядок сообщений.
#queue #kafka
—————————————
Future-Proofing Data Architecture for Better Data Quality
Без валидных данных, которые удовлетворяют требованиям бизнеса - проект превратиться в тыкву, поэтому вокруг качества данных так много разговоров, особенно дата инженеров. В сегодняшней статье описываются три направления, как можно улучшить данные: мониторинг качества, восстановление данных и предотвращение ухудшения качества данных. В самом начале говорится о том, как задать характеристики для данных, чтобы считать, что данные в порядке. После этого рассказывается о Write-Audit-Publish (WAP) паттерне, который состоит из пайплайн в три шага (которые указаны в названии паттерна). В секции с восстановлением говорится о ситуациях, когда могут возникнуть проблемы с данными (человеческие ошибки, не поддерживаемые источники данных, ошибки в источниках данных, нет уверенности в источнике данных), и рассказывается как для батчед и стриминг систем разруливать ситуации восстановления данных. В секции предотвращения деградации качества говорится о контрактах, тестах и так далее. Статья не хардкорная, но говорит о концепциях, которые можно изучить дальше самостоятельно.
#data_managment
—————————————
Riverbed: Optimizing Data Access at Airbnb’s Scale
Distributed Materialized Views: How Airbnb’s Riverbed Processes 2.4 Billion Daily Events
Статья от инженеров airbnb, в которой рассказывается о riverbed - лямбда фреймворка для работы с продьюсинга и работы с распределенными materialized views (что бы это не значило). На деле, это CDC события (стриминг) через кафку, с последующей обработкой в нужные materialized views. Из интересных решений - рейс кондишены фиксятся через индификаторы нужных вью и партишенов кафки, а конфигурирование происходит через генерацию spark sql, основанному на дефинишенах GQL, которые задаются в фреймворке. По первой ссылке найдете оригинальную статью от airbnb, в которой рассказываются причины создания фреймворка и описание дизайна со стримингом, батч процессингом и версионированием. Во второй ссылке - краткий пересказ первой статьи (если читать лень).
#distributed_systems #data_managment
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
The advantages of queues on logs
В августе появился пропозал о добавлении очередей в кафку, поэтому сегодня статья в которой автор разбирается в чем отличие очередей от логов, где что использовать и как кафка реализует концепцию очередей поверх логов.
В начале текста как раз разбирается как работает и лог и очередь, где как раз говориться о главной проблемы очередей - отсутствия реализации нескольких консьюмеров для одной очереди (решается созданием очереди под консьюмер с дублированием событий). После этого рассматриваются проблемы ретраев и реализацию отправки сообщений по сети с нужными гарантиями. После этого, рассказывается о том, как реализовать очереди поверх логов (с помощью сохранения метаданных доставки сообщений и виртуальных очередей под каждый консьюмер). В конце рассказывается о том, как будет реализовываться порядок сообщений.
#queue #kafka
—————————————
Future-Proofing Data Architecture for Better Data Quality
Без валидных данных, которые удовлетворяют требованиям бизнеса - проект превратиться в тыкву, поэтому вокруг качества данных так много разговоров, особенно дата инженеров. В сегодняшней статье описываются три направления, как можно улучшить данные: мониторинг качества, восстановление данных и предотвращение ухудшения качества данных. В самом начале говорится о том, как задать характеристики для данных, чтобы считать, что данные в порядке. После этого рассказывается о Write-Audit-Publish (WAP) паттерне, который состоит из пайплайн в три шага (которые указаны в названии паттерна). В секции с восстановлением говорится о ситуациях, когда могут возникнуть проблемы с данными (человеческие ошибки, не поддерживаемые источники данных, ошибки в источниках данных, нет уверенности в источнике данных), и рассказывается как для батчед и стриминг систем разруливать ситуации восстановления данных. В секции предотвращения деградации качества говорится о контрактах, тестах и так далее. Статья не хардкорная, но говорит о концепциях, которые можно изучить дальше самостоятельно.
#data_managment
—————————————
Riverbed: Optimizing Data Access at Airbnb’s Scale
Distributed Materialized Views: How Airbnb’s Riverbed Processes 2.4 Billion Daily Events
Статья от инженеров airbnb, в которой рассказывается о riverbed - лямбда фреймворка для работы с продьюсинга и работы с распределенными materialized views (что бы это не значило). На деле, это CDC события (стриминг) через кафку, с последующей обработкой в нужные materialized views. Из интересных решений - рейс кондишены фиксятся через индификаторы нужных вью и партишенов кафки, а конфигурирование происходит через генерацию spark sql, основанному на дефинишенах GQL, которые задаются в фреймворке. По первой ссылке найдете оригинальную статью от airbnb, в которой рассказываются причины создания фреймворка и описание дизайна со стримингом, батч процессингом и версионированием. Во второй ссылке - краткий пересказ первой статьи (если читать лень).
#distributed_systems #data_managment
Пятничное чтиво
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
LISP — исследование оригинального языка ИИ
Так как скобки в моем сердце - не мог пройти мимо статьи о языке, который был на марсе (почти), а именно о lisp. Статья не хардкорная, скорее рассказывает в целом о языке: как он появился в 1959 году, с кем конкурировал, в чем смысл декларированного подхода, при чем тут s-exp. Так же затрагиваются lisp-machines, специальные компьютеры, заточенные на высокую производительность выполнения кода на лиспе. А так же затрагивается тема метапрограммирование и искусственного интеллекта.
Если вы никогда не сталкивались с лиспом, статья будет интересна, но хардкора тут не встретить, как и learn lisp in Y minutes. К сожалению, оригинал на английском можно получить только по подписке на linux format. Поэтому ссылка на перевод
#lisp
—————————————
Event Modeling Traditional Systems
Про эвент моделинг писал в последних ссылках 2022 года. Идея в том, что, в отличии от event storming, поведение системы строится от интерфейса, а не от списка событий. Т.е. рассматривается UI/UX который видит пользователь, после чего определяются события, комманды, read model и так далее (возможно есть обратные примеры - но я их не встречал, поделитесь пожалуйста, если видели создание event modeling модели не от UI).
В сегодняшней статье показывается процесс моделирования системы через event modeling, на примере формы регистрации, где благодаря двум UI формам показывается как найти события, команды (и данные для этих команд), read model (и данные к ним) и как из этого достается информация об автоматизации (на примере отправки письма). После этого рассказывается как проектирование системы перед ее реализацией (с поиском необходимых данных) помогает снизить итоговую сложность и стоимость полученной системы. При этом, затрагивается тема аджайла, в котором нет времени на предварительную работу, и как в таком контексте встраивается анализ с помощью EM.
Русский перевод
#event_modeling #system_analysis
—————————————
Практический пример использования pgvector
В канале упоминались статьи рассказывающие о векторных базах данных и векторах в целом. В двух словах, это способ хранения характеристик объектов, благодаря которому можно решить проблему поиска похожих объектов по характеристикам, что часто используется в AI. И если до этого была статья о том, как работать с векторами в редисе, то сегодня статья о pgvector – расширении для постгреса.
В самом начале статьи найдете краткое описание того, как работают вектора и дается пример в виде таблицы с ноутбуками и вариантом создания вектора «в лоб» (каждая характеристика бинарно отображается в N-ом значении вектора). После этого рассказывается о двух видах индексов, IVFFlat и HNSW, которые предоставляет расширение, из интересного - скорость выполнения запросов и вставки данных (возможная причина, почему с векторами в постгресе стоит повременить). В конце показывается на сколько точно работает поиск по векторам, дается ссылка на документацию и рассказывается как повторить пример.
#psql #vectors
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
LISP — исследование оригинального языка ИИ
Так как скобки в моем сердце - не мог пройти мимо статьи о языке, который был на марсе (почти), а именно о lisp. Статья не хардкорная, скорее рассказывает в целом о языке: как он появился в 1959 году, с кем конкурировал, в чем смысл декларированного подхода, при чем тут s-exp. Так же затрагиваются lisp-machines, специальные компьютеры, заточенные на высокую производительность выполнения кода на лиспе. А так же затрагивается тема метапрограммирование и искусственного интеллекта.
Если вы никогда не сталкивались с лиспом, статья будет интересна, но хардкора тут не встретить, как и learn lisp in Y minutes. К сожалению, оригинал на английском можно получить только по подписке на linux format. Поэтому ссылка на перевод
#lisp
—————————————
Event Modeling Traditional Systems
Про эвент моделинг писал в последних ссылках 2022 года. Идея в том, что, в отличии от event storming, поведение системы строится от интерфейса, а не от списка событий. Т.е. рассматривается UI/UX который видит пользователь, после чего определяются события, комманды, read model и так далее (возможно есть обратные примеры - но я их не встречал, поделитесь пожалуйста, если видели создание event modeling модели не от UI).
В сегодняшней статье показывается процесс моделирования системы через event modeling, на примере формы регистрации, где благодаря двум UI формам показывается как найти события, команды (и данные для этих команд), read model (и данные к ним) и как из этого достается информация об автоматизации (на примере отправки письма). После этого рассказывается как проектирование системы перед ее реализацией (с поиском необходимых данных) помогает снизить итоговую сложность и стоимость полученной системы. При этом, затрагивается тема аджайла, в котором нет времени на предварительную работу, и как в таком контексте встраивается анализ с помощью EM.
Русский перевод
#event_modeling #system_analysis
—————————————
Практический пример использования pgvector
В канале упоминались статьи рассказывающие о векторных базах данных и векторах в целом. В двух словах, это способ хранения характеристик объектов, благодаря которому можно решить проблему поиска похожих объектов по характеристикам, что часто используется в AI. И если до этого была статья о том, как работать с векторами в редисе, то сегодня статья о pgvector – расширении для постгреса.
В самом начале статьи найдете краткое описание того, как работают вектора и дается пример в виде таблицы с ноутбуками и вариантом создания вектора «в лоб» (каждая характеристика бинарно отображается в N-ом значении вектора). После этого рассказывается о двух видах индексов, IVFFlat и HNSW, которые предоставляет расширение, из интересного - скорость выполнения запросов и вставки данных (возможная причина, почему с векторами в постгресе стоит повременить). В конце показывается на сколько точно работает поиск по векторам, дается ссылка на документацию и рассказывается как повторить пример.
#psql #vectors
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
BFF: Alternatives & decision tree
О backend for frontend (BFF) в канале уже был пост. В двух словах: BFF предоставляет прокси между клиентом и приложением и цель подхода - убрать реализацию специфических клиентских вещей с бека на слой между. Поэтому сегодня статья не о реализации паттерна, а о том, как выбрать подходящий инструмент, не сравнивая техническую имплементацию. Т.е. крутость статьи в том, что вместо выбора библиотек, а автор рассуждает о том, какой набор фичей, для какого размера организаций и вида клиентов необходим. А на основе этого уже можно выбрать конкретную библиотеку или сервис.
В тексте автор сравнивает следующие подходы (каждый подход детально описан):
- Over The Air (OTA или code push), идея которого в пуше кода для апдейта клиентов напрямую, в обход апдейтов руками;
- HATEOAS, который говорит о реализации API;
- Server-Driven UI, по сути, отправка информации о UI с бекенда;
А в конце дается таблица, благодаря которой можно выбрать необходимые фичи и после этого найти техническую реализацию (или написать свою), которая будет удовлетворять выбранным пунктам.
#bff #communications
—————————————
Working with Money in Postgres
Работа с деньгами встречается в 100% коммерческих проектах, следовательно это то, что каждый разработчик должен уметь реализовывать в коде и на уровне данных (я плохо отношусь к фразам с «должен», но в данном случае это единственное исключение). Поэтому сегодня статья о том, как реализовать тип денег в psql (если у вас есть информация по другим базам - делитесь в комментариях). В статье описываются следующие варианты:
- monetary Types , который хорош в форматировании, но не всегда лучший выбор;
- float, о котором лучше сразу забыть;
- int, который хорошо работает в ситуациях, когда точно известно сколько копеек у вас будет (крипта и новое требование о 0.1 центах сразу ломают всю картину);
- numeric, который считается лучшим вариантом;
После этого, автор рассуждает как хранить деньги в разных валютах и приводит примеры частых запросов, которые могут пригодиться (среднее, медианы, как в money тип переводить).
#data_modelling #money
—————————————
Управление знаниями в продукте
Последние года три я трачу много времени на изучение системной инженерии, анализа и прочим странным штукам со словом «система» в названии. На русском нормальной информации мало, не считая пары книг, поэтому для меня радость найти пост, который объясняет «системные» концепции.
По ссылке найдете лонгрид который пересказать в двух словах сложно, поэтому напишу список тем, которые найдете в тексте:
- что такое система (приводится понятие системно-структурного подхода), что можно с системой делать;
- сложность и системная сложность. Какие виды сложности встречаются и почему стоит иногда отказаться от упрощения;
- что за знания такие (допущения и договоренности) и почему ими управлять надо. Какие бывают знания (три типа: смыслообразующие, инструментальные, объектные);
- Блок о гипотезах и допущениях;
- Правила и практика системы знаний;
- Практические советы;
- 13 доп материалов;
Хоть статья об управлении знаниями, советую прочитать хотя бы первую треть лонгрида. А если интересна тема управления знаниями - однозначный мастрид года.
#systems #управление_знаниями
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
BFF: Alternatives & decision tree
О backend for frontend (BFF) в канале уже был пост. В двух словах: BFF предоставляет прокси между клиентом и приложением и цель подхода - убрать реализацию специфических клиентских вещей с бека на слой между. Поэтому сегодня статья не о реализации паттерна, а о том, как выбрать подходящий инструмент, не сравнивая техническую имплементацию. Т.е. крутость статьи в том, что вместо выбора библиотек, а автор рассуждает о том, какой набор фичей, для какого размера организаций и вида клиентов необходим. А на основе этого уже можно выбрать конкретную библиотеку или сервис.
В тексте автор сравнивает следующие подходы (каждый подход детально описан):
- Over The Air (OTA или code push), идея которого в пуше кода для апдейта клиентов напрямую, в обход апдейтов руками;
- HATEOAS, который говорит о реализации API;
- Server-Driven UI, по сути, отправка информации о UI с бекенда;
А в конце дается таблица, благодаря которой можно выбрать необходимые фичи и после этого найти техническую реализацию (или написать свою), которая будет удовлетворять выбранным пунктам.
#bff #communications
—————————————
Working with Money in Postgres
Работа с деньгами встречается в 100% коммерческих проектах, следовательно это то, что каждый разработчик должен уметь реализовывать в коде и на уровне данных (я плохо отношусь к фразам с «должен», но в данном случае это единственное исключение). Поэтому сегодня статья о том, как реализовать тип денег в psql (если у вас есть информация по другим базам - делитесь в комментариях). В статье описываются следующие варианты:
- monetary Types , который хорош в форматировании, но не всегда лучший выбор;
- float, о котором лучше сразу забыть;
- int, который хорошо работает в ситуациях, когда точно известно сколько копеек у вас будет (крипта и новое требование о 0.1 центах сразу ломают всю картину);
- numeric, который считается лучшим вариантом;
После этого, автор рассуждает как хранить деньги в разных валютах и приводит примеры частых запросов, которые могут пригодиться (среднее, медианы, как в money тип переводить).
#data_modelling #money
—————————————
Управление знаниями в продукте
Последние года три я трачу много времени на изучение системной инженерии, анализа и прочим странным штукам со словом «система» в названии. На русском нормальной информации мало, не считая пары книг, поэтому для меня радость найти пост, который объясняет «системные» концепции.
По ссылке найдете лонгрид который пересказать в двух словах сложно, поэтому напишу список тем, которые найдете в тексте:
- что такое система (приводится понятие системно-структурного подхода), что можно с системой делать;
- сложность и системная сложность. Какие виды сложности встречаются и почему стоит иногда отказаться от упрощения;
- что за знания такие (допущения и договоренности) и почему ими управлять надо. Какие бывают знания (три типа: смыслообразующие, инструментальные, объектные);
- Блок о гипотезах и допущениях;
- Правила и практика системы знаний;
- Практические советы;
- 13 доп материалов;
Хоть статья об управлении знаниями, советую прочитать хотя бы первую треть лонгрида. А если интересна тема управления знаниями - однозначный мастрид года.
#systems #управление_знаниями
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Gossip Protocol in Social Media Networks
Статья выше - первый раз когда я столкнулся с Gossip Protocol, до этого подобного термина не слышал. В двух словах, протокол является схемой коммуникации в распределенных системах и основан на epidemic algorithm, который использует рандомизированную связь для передачи информации (свое состояние и состояние соседей) между узлами системы. При этом, можно увеличить fault-tolerance, scalability и convergence. В случае социальных сетей, протокол можно использовать для того, чтобы фолловеры пользователя увидели новый пост человека. Что-то подобное, если правильно помню, реализовала одна недавно купленная соц сеть, для пользователей с большим количеством фолловеров. В тексте, кроме описания протокола, показывается упрощенная реализация на питоне. К сожалению, нет бенчмарков и детальной реализации алгоритма для больших данных. Но как энтри поинт текст подойдет.
#distributed_systems #gossip_protocol
—————————————
Проектирование отказоустойчивости IT-систем
Сделать работающую систему сложно, а сделать так, что при отказах и ошибках система продолжит работать (даже не полностью), еще сложнее. Для этого могут использоваться интуитивные подходы, такие как рестарты или минимальная связанность. С другой стороны, можно изучить набор подходов и идей, которые помогают в построении подобных систем. Сегодня такой текст, в котором автор собрал 7 принципов и пять подходов/паттернов в одном месте.
Кроме базовых подходов с избеганием единого места отказа, проектировании с учетом отказов, Circuit Breaker и стресс тестировании, можно почитать о таких вещах как graceful degradation, tolerant reader, resources segregation и прочем. Кроме принципов и подходов, автор, в начале текста, объясняет какая система является отказоустойчивой и стабильной и объясняет зачем нужны стресс тесты (привет chaos eng и другим фитнесс функциям).
Также, кроме статьи выше, для дальнейшего чтения, могу посоветовать изучить философию erlang, которая строится, в том числе, на принципе fail fast и которой уже почти 40 лет.
#resilience #system_design
—————————————
Measuring Git performance with OpenTelemetry
Статья от инженера гитхаба, в которой рассказывается о проекте trace2receiver. Все началось с миграции кодовой базы майкрософта в гит, точнее с операционки, которая содержала 3.5 миллиона файлов и весила 300 гигов. Из-за размеров гит репозитория пришлось заняться оптимизацией гита. Для этого можно воспользоваться trace2, который является кор частью гита, но итоговый результат сложен для понимания. Для этого сделали trace2receiver, который берет результат trace2 и переводит его в OpenTelemetry, что позволяет визуализировать перфоманс каждой вызываемой команды. В тексте найдете примеры использования trace2receiver с картинками трейсов, как собирались данные для трассировки и отбирались часто используемые команды для улучшения и как гит хуки подпортили трассировку. А в конце даются примеры того, что можно делать с библиотекой и трейсами.
#git #tracing
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Gossip Protocol in Social Media Networks
Статья выше - первый раз когда я столкнулся с Gossip Protocol, до этого подобного термина не слышал. В двух словах, протокол является схемой коммуникации в распределенных системах и основан на epidemic algorithm, который использует рандомизированную связь для передачи информации (свое состояние и состояние соседей) между узлами системы. При этом, можно увеличить fault-tolerance, scalability и convergence. В случае социальных сетей, протокол можно использовать для того, чтобы фолловеры пользователя увидели новый пост человека. Что-то подобное, если правильно помню, реализовала одна недавно купленная соц сеть, для пользователей с большим количеством фолловеров. В тексте, кроме описания протокола, показывается упрощенная реализация на питоне. К сожалению, нет бенчмарков и детальной реализации алгоритма для больших данных. Но как энтри поинт текст подойдет.
#distributed_systems #gossip_protocol
—————————————
Проектирование отказоустойчивости IT-систем
Сделать работающую систему сложно, а сделать так, что при отказах и ошибках система продолжит работать (даже не полностью), еще сложнее. Для этого могут использоваться интуитивные подходы, такие как рестарты или минимальная связанность. С другой стороны, можно изучить набор подходов и идей, которые помогают в построении подобных систем. Сегодня такой текст, в котором автор собрал 7 принципов и пять подходов/паттернов в одном месте.
Кроме базовых подходов с избеганием единого места отказа, проектировании с учетом отказов, Circuit Breaker и стресс тестировании, можно почитать о таких вещах как graceful degradation, tolerant reader, resources segregation и прочем. Кроме принципов и подходов, автор, в начале текста, объясняет какая система является отказоустойчивой и стабильной и объясняет зачем нужны стресс тесты (привет chaos eng и другим фитнесс функциям).
Также, кроме статьи выше, для дальнейшего чтения, могу посоветовать изучить философию erlang, которая строится, в том числе, на принципе fail fast и которой уже почти 40 лет.
#resilience #system_design
—————————————
Measuring Git performance with OpenTelemetry
Статья от инженера гитхаба, в которой рассказывается о проекте trace2receiver. Все началось с миграции кодовой базы майкрософта в гит, точнее с операционки, которая содержала 3.5 миллиона файлов и весила 300 гигов. Из-за размеров гит репозитория пришлось заняться оптимизацией гита. Для этого можно воспользоваться trace2, который является кор частью гита, но итоговый результат сложен для понимания. Для этого сделали trace2receiver, который берет результат trace2 и переводит его в OpenTelemetry, что позволяет визуализировать перфоманс каждой вызываемой команды. В тексте найдете примеры использования trace2receiver с картинками трейсов, как собирались данные для трассировки и отбирались часто используемые команды для улучшения и как гит хуки подпортили трассировку. А в конце даются примеры того, что можно делать с библиотекой и трейсами.
#git #tracing
Запустился второй поток курса по анализу систем и принятию технических решений
Привет!
После первого потока, который прошел весной, оказалось что:
- Мои опасения в экспериментальности курса были напрасны;
- Сторителлинг (который я терпеть не могу) людям понравился;
- Сервис нотификаций можно не делать, а общие по реализации части системы не объединять;
- Самое удивительное для меня -- p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт, вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
В течении месяца будем учиться анализировать системы -- выбирать элементы системы, определять связи и свойства. Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview - курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и странный бизнес на эксплуатации кошачьих удовольствий;
Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать всю информацию в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Если хотите самостоятельно все изучить - у меня есть список из тринадцати книг которые помогут. Если возник вопрос в чем отличие от асинхронной архитектуры - ответил в комментариях к прошлому посту.
Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов.
Полная программа и половина первого урока -- на странице курса. Начало 15 ноября, до 6 ноября действует промокод PEPENALYSIS на 10% скидки.
Марьяна отдельно попросила указать: следующий поток не раньше, чем через полгода. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Привет!
После первого потока, который прошел весной, оказалось что:
- Мои опасения в экспериментальности курса были напрасны;
- Сторителлинг (который я терпеть не могу) людям понравился;
- Сервис нотификаций можно не делать, а общие по реализации части системы не объединять;
- Самое удивительное для меня -- p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт, вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
В течении месяца будем учиться анализировать системы -- выбирать элементы системы, определять связи и свойства. Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview - курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и странный бизнес на эксплуатации кошачьих удовольствий;
Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать всю информацию в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Если хотите самостоятельно все изучить - у меня есть список из тринадцати книг которые помогут. Если возник вопрос в чем отличие от асинхронной архитектуры - ответил в комментариях к прошлому посту.
Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов.
Полная программа и половина первого урока -- на странице курса. Начало 15 ноября, до 6 ноября действует промокод PEPENALYSIS на 10% скидки.
Марьяна отдельно попросила указать: следующий поток не раньше, чем через полгода. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
A vision for managing Kafka schemas more effectively
На практике, при работе с брокерами событий/сообщений, отсутствующая схема событий – мина замедленного действия, которая приводит к проблемам в продакшене. Связанно это с тем, что без общего понимания что ждать от данных, консьюмер может ждать одно, а продьюсер отправит другие данные. Из-за этого возникают ошибки в коде, потеря данных (иногда критичных, так как связанны с деньгами) и каскадные отказы системы (например: упал консьюмер, за ним инстанс, за ним несколько бизнесовых процессов, что приводит к отказу системы). Если читаете канал давно, могли заметить, что я упоминаю эту проблему пару раз в год, как и способы решения что в курсах, что в отдельных выступлениях и даже стримах.
Автор статьи рассуждает о похожих проблемах, в результате чего описываются два принципа (избегания изменений схемы и необходимость в инструменте для надежной работы со схемами) и три рекомендации (обратная совместимость как дефолтное значение, отдельное апи для десериализации и усложненная проверка совместимости схем). Кроме этого, автор рассказывает в чем проблема на примерах, говорит о прямой и обратной совместимости. Из минусов - не нашел конкретных решений в виде технологий.
#distributed_systems #event_versioning
—————————————
Распределенные данные. Секционирование
Рано или поздно наступает момент, когда приложение приходиться масштабировать на уровне данных. Для этого используется либо репликация (копия данных), либо шардирование (разбивка данных на изолированные куски). При этом, каждый из вариантов может как помочь, так и усложнить жизнь, например, на одном проекте использовалось шардирование (по месяцу) для ссылок в сокращателе ссылок. В какой-то момент оказалось, что старыми ссылками пользуются также активно как и новыми, из-за чего получение ссылок могло занимать секунды (там был не оптимизированная рельсовая библиотека, которая делала по селекту в каждую таблицу, от новой к старой).
Что бы подобных проблем не возникало, стоит разобраться с тем, как работает шардирование, с чем помогает текст выше. Автор объясняет отличие шардирования и репликации, зачем распределять данные равномерно, чем отличается шардирование по ключу и хешу, как работают индексы. Также говорится о перебалансировке и какие существуют подходы. В конце рассказывается о том, как строить запросы в шарды. Если до этого читали DDIA, то наверно нового ничего не узнаете, а если не читали и с шардами не работали - стоит уделить внимание.
#data_managment #db
—————————————
Sharding vs. partitioning: What’s the difference?
В продолжение темы шардирования: кроме шардирования иногда встречается термин партицирование. Оба подхода на выходе дают решение по разделению данных на меньшие части (что упрощает работу с данными), но способы как этот результат достигается отличается. Шардирование (или горизонтальное партицирование) реализуется через две+ таблицы с одной схемой используют shard key, благодаря которому определяется в каком из шардов лежат необходимые данные. А партицирования (или вертикальное партицирование) реализуется без использования ключа, но с помощью разделения данных по заданной логике. Статья выше описывает оба подхода, даются примеры на SQL (там примеры с MySQL). Кроме этого, автор говорит о плюсах и минусах каждого из вариантов.
#data_managment #sql
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
A vision for managing Kafka schemas more effectively
На практике, при работе с брокерами событий/сообщений, отсутствующая схема событий – мина замедленного действия, которая приводит к проблемам в продакшене. Связанно это с тем, что без общего понимания что ждать от данных, консьюмер может ждать одно, а продьюсер отправит другие данные. Из-за этого возникают ошибки в коде, потеря данных (иногда критичных, так как связанны с деньгами) и каскадные отказы системы (например: упал консьюмер, за ним инстанс, за ним несколько бизнесовых процессов, что приводит к отказу системы). Если читаете канал давно, могли заметить, что я упоминаю эту проблему пару раз в год, как и способы решения что в курсах, что в отдельных выступлениях и даже стримах.
Автор статьи рассуждает о похожих проблемах, в результате чего описываются два принципа (избегания изменений схемы и необходимость в инструменте для надежной работы со схемами) и три рекомендации (обратная совместимость как дефолтное значение, отдельное апи для десериализации и усложненная проверка совместимости схем). Кроме этого, автор рассказывает в чем проблема на примерах, говорит о прямой и обратной совместимости. Из минусов - не нашел конкретных решений в виде технологий.
#distributed_systems #event_versioning
—————————————
Распределенные данные. Секционирование
Рано или поздно наступает момент, когда приложение приходиться масштабировать на уровне данных. Для этого используется либо репликация (копия данных), либо шардирование (разбивка данных на изолированные куски). При этом, каждый из вариантов может как помочь, так и усложнить жизнь, например, на одном проекте использовалось шардирование (по месяцу) для ссылок в сокращателе ссылок. В какой-то момент оказалось, что старыми ссылками пользуются также активно как и новыми, из-за чего получение ссылок могло занимать секунды (там был не оптимизированная рельсовая библиотека, которая делала по селекту в каждую таблицу, от новой к старой).
Что бы подобных проблем не возникало, стоит разобраться с тем, как работает шардирование, с чем помогает текст выше. Автор объясняет отличие шардирования и репликации, зачем распределять данные равномерно, чем отличается шардирование по ключу и хешу, как работают индексы. Также говорится о перебалансировке и какие существуют подходы. В конце рассказывается о том, как строить запросы в шарды. Если до этого читали DDIA, то наверно нового ничего не узнаете, а если не читали и с шардами не работали - стоит уделить внимание.
#data_managment #db
—————————————
Sharding vs. partitioning: What’s the difference?
В продолжение темы шардирования: кроме шардирования иногда встречается термин партицирование. Оба подхода на выходе дают решение по разделению данных на меньшие части (что упрощает работу с данными), но способы как этот результат достигается отличается. Шардирование (или горизонтальное партицирование) реализуется через две+ таблицы с одной схемой используют shard key, благодаря которому определяется в каком из шардов лежат необходимые данные. А партицирования (или вертикальное партицирование) реализуется без использования ключа, но с помощью разделения данных по заданной логике. Статья выше описывает оба подхода, даются примеры на SQL (там примеры с MySQL). Кроме этого, автор говорит о плюсах и минусах каждого из вариантов.
#data_managment #sql
Forwarded from Продукты, книги и любовь
Получили премию Digital Learning 2023. Часть 1.
Я ни разу не рассказывала на канале о нашем курсе-флагмане «Анализ систем» , в котором качаем навыки проектирования сложных систем. Потому что летом мы подали заявку на премию Digital Learning 2023, в номинации «Онлайн-курс» и мне хотелось дождаться результатов, чтобы подтвердить свои гипотезы успеха.
И вот в эту пятницу, была церемония, после которой, Федя прислал мне фотку с заветным первым местом в номинации «Онлайн программа»(сайт премии, еще не обновился). Я до сих пор в шоке и не могу подобрать слов, потому что основная часть участников — это большие компании с гигантскими ресурсами. Мы, малыши, обошли Сбер, МТС, РТК и других. Радуюсь вдвойне, в буткемп, который делала Ира Никулина под моим присмотром тоже забрал первое место в номинации «Смешанные программы». Ира, еще раз поздравляю вас! А команде — еще раз спасибо за то, что так вложились!
Я не рассчитывала на победу, но искренне согласна с ней, потому что курс у нас и правда крутой был. Далее расскажу почему 👇
Я ни разу не рассказывала на канале о нашем курсе-флагмане «Анализ систем» , в котором качаем навыки проектирования сложных систем. Потому что летом мы подали заявку на премию Digital Learning 2023, в номинации «Онлайн-курс» и мне хотелось дождаться результатов, чтобы подтвердить свои гипотезы успеха.
И вот в эту пятницу, была церемония, после которой, Федя прислал мне фотку с заветным первым местом в номинации «Онлайн программа»(сайт премии, еще не обновился). Я до сих пор в шоке и не могу подобрать слов, потому что основная часть участников — это большие компании с гигантскими ресурсами. Мы, малыши, обошли Сбер, МТС, РТК и других. Радуюсь вдвойне, в буткемп, который делала Ира Никулина под моим присмотром тоже забрал первое место в номинации «Смешанные программы». Ира, еще раз поздравляю вас! А команде — еще раз спасибо за то, что так вложились!
Я не рассчитывала на победу, но искренне согласна с ней, потому что курс у нас и правда крутой был. Далее расскажу почему 👇
Forwarded from Продукты, книги и любовь
Почему нам досталось 1 место. Часть 2.
1/ Мы год писали контент и пытались решить задачку, как сложный академический талмуд, который у нас получался на старте — превратить в что-то с посильной сложностью, интересным и не в три тома. И несмотря на то, что курс довольно объемный по контенту, больше, чем мы хотели, но он затягивает. Мы смогли это сделать за счет того, что вместо того, чтобы вывалить на человека всю сложность, наслаивали сложность — 4 недели проектировали систему и с недели в неделю, специально давали ошибиться ученикам, чтобы далее они осознали сложность.
2/ Домашка. Ее сделали 83% учеников, это лучшее что я видела на рынке. Обычно показатель от 5 до 20%. Немногие и доходимостью в просмотре лекций могут похвастаться. А у нас практика на таком уровне. Опять за счет сквозной истории: 4 раза ребята переделывали одну и ту же систему, наращивая сложность.
3/ Шеринг опыта и поддержка. Мы попросили учеников проверять домашку друг друга, научили давать обратную связь и подсвечивать не только точки роста, но и то, что классно получилось. И это стало точкой вдохновения и источником инфы. И это кроме бурлящего чата, где Антон отвечал на каждый вопрос и непонимание. NPS = 9,15.
4/ Мы дали возможность ученикам заякориться и расслабиться. У нас был сторителинг (героев сгенерировал нам Midjourney). Главный герой проходил путь проектирования сложной системы, очень приближенной к жизни. У него были взлеты и падения, постоянно менялись вводные, люди не выходили на связь. Через эти истории ученикам было проще коммуницировать: то и дело в чате появлялись в формулировки в духе «Я не понял кусок, где Ибрагим (главный герой) разговаривал с заказчиком и…». Это проще, чем «в 2 лонгриде, второй половине… » А еще мы добавляли моменты, где надо было выпустить пар, когда все достало.
За неделю до объявления результатов премии, мы открыли запись на второй поток. Стартуем 15 ноября, закончим в январе. Будет перерыв на зимние каникулы. Подробности на сайте. Вдруг вам надо поучиться или подсмотреть форма. Или знаете, кому переслать.
#фичи_курсов
1/ Мы год писали контент и пытались решить задачку, как сложный академический талмуд, который у нас получался на старте — превратить в что-то с посильной сложностью, интересным и не в три тома. И несмотря на то, что курс довольно объемный по контенту, больше, чем мы хотели, но он затягивает. Мы смогли это сделать за счет того, что вместо того, чтобы вывалить на человека всю сложность, наслаивали сложность — 4 недели проектировали систему и с недели в неделю, специально давали ошибиться ученикам, чтобы далее они осознали сложность.
2/ Домашка. Ее сделали 83% учеников, это лучшее что я видела на рынке. Обычно показатель от 5 до 20%. Немногие и доходимостью в просмотре лекций могут похвастаться. А у нас практика на таком уровне. Опять за счет сквозной истории: 4 раза ребята переделывали одну и ту же систему, наращивая сложность.
3/ Шеринг опыта и поддержка. Мы попросили учеников проверять домашку друг друга, научили давать обратную связь и подсвечивать не только точки роста, но и то, что классно получилось. И это стало точкой вдохновения и источником инфы. И это кроме бурлящего чата, где Антон отвечал на каждый вопрос и непонимание. NPS = 9,15.
4/ Мы дали возможность ученикам заякориться и расслабиться. У нас был сторителинг (героев сгенерировал нам Midjourney). Главный герой проходил путь проектирования сложной системы, очень приближенной к жизни. У него были взлеты и падения, постоянно менялись вводные, люди не выходили на связь. Через эти истории ученикам было проще коммуницировать: то и дело в чате появлялись в формулировки в духе «Я не понял кусок, где Ибрагим (главный герой) разговаривал с заказчиком и…». Это проще, чем «в 2 лонгриде, второй половине… » А еще мы добавляли моменты, где надо было выпустить пар, когда все достало.
За неделю до объявления результатов премии, мы открыли запись на второй поток. Стартуем 15 ноября, закончим в январе. Будет перерыв на зимние каникулы. Подробности на сайте. Вдруг вам надо поучиться или подсмотреть форма. Или знаете, кому переслать.
#фичи_курсов
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Anti-patterns in event modelling - Clickbait event
В системе может возникнуть ситуация, когда существует событие в котором ничего кроме названия и идентификатора ресурса не присутствует. Автор статьи называет такие события «кликбейтными», так как подобные события не содержат никакого контекста, а говорят о том, что что-то произошло, а что произошло не понятно из названия. В качестве примера приводится событие
Важно отметить, что хоть события без данных и могут говорить о проблемах в проектировании систем, но иногда возникают ситуации, когда сам факт произошедшего уже достаточный контекст (обычно такое в бизнес событиях происходит, в статье даже есть примеры с shopment событиями). Поэтому, постарайтесь без крайностей: если существует обоснование почему другие данные не нужны (например – не используются в системе) - то сидеть и придумывать что добавить из полей в тело события - смысла не имеет.
#events #event_driven
—————————————
6 Software Engineering Templates I Wish I Had Sooner
Иногда возникает ситуация, когда необходимо написать «базовое» сообщение или внедрить новый процесс, состоящий из заполнения документов (ADR, postmortem, etc). Вроде понятно что делать, но затык может случиться в придумывании структуры документа. Что бы подобной ситуации не возникло, я сохраняю себе разные темплейты документов или пишу собственные, а когда надо, не думая достаю из закромов готовую структуру. По ссылке найдете короткую статью, смысл которой в шести ссылках на темплейты документов, которые потенциально могут пригодиться. Документы, которые найдете в статье:
- Eng design doc (очень похоже на ADR, но с планом выполнения);
- Postmortem review;
- PR summary;
- Direction doc (документ описывающий стратегию, т.е. какая проблема на текущий момент, куда придти хотим, хайлевел план движения, как убедиться что проблема решена);
- Eng project management (автор дает ссылку на gantt chart);
- Launch post (запуск фичи: что произошло, что поменялось, какие результаты, следующие шаги, слова благодарности);
Если у вас есть другие темплейты или другая структура описанных выше документов – будет круто если поделитесь в комментариях.
#managment #documentation
—————————————
Distributed coordination service: Zookeeper
Скорее всего название zookeeper слышал каждый кто работал с кафкой или стоял рядом с людьми, которые обсуждали кафку (иногда кликхаус). На деле, знания о технологии дальше «какая-то штука для координации» не уходят (с чем я также страдаю). Поэтому статья - гайд в сервис координатор zookeeper: какие проблемы решает, design goals, что могут делать ноды и наблюдатели, как выглядит API и какие гарантии дает технология. Если хотите разобраться в технологии но не знаете с чего начать - мастрид. Из минусов, нет практики, т.е. не показано как из кода работать и какой практический смысл в использовании zookeeper для «веб» разработки.
#distributed_systems #distributed_coordinator #zookeeper
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Anti-patterns in event modelling - Clickbait event
В системе может возникнуть ситуация, когда существует событие в котором ничего кроме названия и идентификатора ресурса не присутствует. Автор статьи называет такие события «кликбейтными», так как подобные события не содержат никакого контекста, а говорят о том, что что-то произошло, а что произошло не понятно из названия. В качестве примера приводится событие
ShipmentStatusChanged, в котором содержится только идентификатор груза (без статусов и прочего). После чего автор сравнивает подобные события с синхронной коммуникацией, рассуждает о гранулярности событий, рассказывает о проблемах возникающих с подобными событиями (включая рейс кондишены). А в конце приводятся идеи, как исправить ситуацию и при чем тут event notification паттерн.Важно отметить, что хоть события без данных и могут говорить о проблемах в проектировании систем, но иногда возникают ситуации, когда сам факт произошедшего уже достаточный контекст (обычно такое в бизнес событиях происходит, в статье даже есть примеры с shopment событиями). Поэтому, постарайтесь без крайностей: если существует обоснование почему другие данные не нужны (например – не используются в системе) - то сидеть и придумывать что добавить из полей в тело события - смысла не имеет.
#events #event_driven
—————————————
6 Software Engineering Templates I Wish I Had Sooner
Иногда возникает ситуация, когда необходимо написать «базовое» сообщение или внедрить новый процесс, состоящий из заполнения документов (ADR, postmortem, etc). Вроде понятно что делать, но затык может случиться в придумывании структуры документа. Что бы подобной ситуации не возникло, я сохраняю себе разные темплейты документов или пишу собственные, а когда надо, не думая достаю из закромов готовую структуру. По ссылке найдете короткую статью, смысл которой в шести ссылках на темплейты документов, которые потенциально могут пригодиться. Документы, которые найдете в статье:
- Eng design doc (очень похоже на ADR, но с планом выполнения);
- Postmortem review;
- PR summary;
- Direction doc (документ описывающий стратегию, т.е. какая проблема на текущий момент, куда придти хотим, хайлевел план движения, как убедиться что проблема решена);
- Eng project management (автор дает ссылку на gantt chart);
- Launch post (запуск фичи: что произошло, что поменялось, какие результаты, следующие шаги, слова благодарности);
Если у вас есть другие темплейты или другая структура описанных выше документов – будет круто если поделитесь в комментариях.
#managment #documentation
—————————————
Distributed coordination service: Zookeeper
Скорее всего название zookeeper слышал каждый кто работал с кафкой или стоял рядом с людьми, которые обсуждали кафку (иногда кликхаус). На деле, знания о технологии дальше «какая-то штука для координации» не уходят (с чем я также страдаю). Поэтому статья - гайд в сервис координатор zookeeper: какие проблемы решает, design goals, что могут делать ноды и наблюдатели, как выглядит API и какие гарантии дает технология. Если хотите разобраться в технологии но не знаете с чего начать - мастрид. Из минусов, нет практики, т.е. не показано как из кода работать и какой практический смысл в использовании zookeeper для «веб» разработки.
#distributed_systems #distributed_coordinator #zookeeper
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Мониторинг с Grafana. Best practices
В канале часто появляются ссылки связанные с обсервабилити. Обычно в статьях рассказывают какие виды обсервабилити существуют или как добавить метрики или трассировку в проект. Но сегодня исключение ибо ссылка - концентрация чужого опыта, оформленная в набор подходов, которые автор советует использовать для улучшения работы с метриками. В начале статьи дается алгоритм о том, как сделать дашборд (определить для кого дашборд делается и в каком случае будут использоваться метрики), после чего рассматриваются две стратегии мониторинга: USE, 4 golden signals и RED. А после этого идут советы по улучшению дашбордов, поделенные на 4 пункта:
- Базовая настройка. Все о таймзонах, перфомансе отображения (автоапдейт, таймрейнджи), панелях для группировки и скрытия метрик, переменных;
- Работа с панелями. Советы по агрегированию данных;
- Отображение. Говорится о видах панелей, порядках значений, тултипах на графиках, какие метрики стоит отображать на одном графике, работе с отклонениями;
- Остальное. Обсуждаются правила нейминга, проблемы вокруг кардиналити, как изменять дашборды, аннотации для деплоймента;
В конце найдете доп ссылки, где найдете больше информации.
#observability #metrics
—————————————
Contentsquare Uses Microservices and Apache Kafka for Notification Delivery
У меня сложное отношение к сервису нотификаций, так как я не видел приемлемой реализации подобных сервисов. Обычно под сервисом нотификаций подразумевают штуку, которая сама решает какой темплейт использовать, хранит данные от всей системы и вместо реализации транспорта отправки информации, по определенному каналу, используют сторонние SAAS решения, что превращается в god service. А сервис содержит в себе информацию о всей системе, что приводит к повышенной связности, глобальной сложности и другим страшным вещам. Поэтому, когда вижу статью о том, как нотификации сделаны у других – стараюсь не пропускать подобные статьи, чтобы найти пример хорошей реализации (пока не нашел).
Сегодняшняя статья рассказывает о том, как устроен сервис нотификаций в компании contentsquare. Зачем используется кафка, как выглядит роутинг нотификаций (с помощью кафки). Рассказывается зачем решили разделять топики (для скейлинга), как решали проблемы с отправкой нотификаций по почте и что использовали для обсервабилити.
#notification_service
—————————————
Web Mapping with Free Software Tools
Радуюсь как в первый раз, когда встречаю статьи с объяснением как что-то работает. Сегодняшний день не исключение: в рассылку попал лонгрид пятилетней давности о том, как работают карты и как работать с геоданными в вебе. Из текста узнаете как работают GIS (geographic information systems): как хранить данные в таблицах, почему с координатами могут быть проблемы и как работают слои в таких системах. После этого рассказывается как подготовить геоданные для дальнейшего маппинга данных на гугл карту. Дальше описываются проекты QGIS и qgis2web, которые позволяют работать с геоданными и в самом конце найдете блок о том, как работать с геоданными используя язык R.
#how_it_works #maps
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Мониторинг с Grafana. Best practices
В канале часто появляются ссылки связанные с обсервабилити. Обычно в статьях рассказывают какие виды обсервабилити существуют или как добавить метрики или трассировку в проект. Но сегодня исключение ибо ссылка - концентрация чужого опыта, оформленная в набор подходов, которые автор советует использовать для улучшения работы с метриками. В начале статьи дается алгоритм о том, как сделать дашборд (определить для кого дашборд делается и в каком случае будут использоваться метрики), после чего рассматриваются две стратегии мониторинга: USE, 4 golden signals и RED. А после этого идут советы по улучшению дашбордов, поделенные на 4 пункта:
- Базовая настройка. Все о таймзонах, перфомансе отображения (автоапдейт, таймрейнджи), панелях для группировки и скрытия метрик, переменных;
- Работа с панелями. Советы по агрегированию данных;
- Отображение. Говорится о видах панелей, порядках значений, тултипах на графиках, какие метрики стоит отображать на одном графике, работе с отклонениями;
- Остальное. Обсуждаются правила нейминга, проблемы вокруг кардиналити, как изменять дашборды, аннотации для деплоймента;
В конце найдете доп ссылки, где найдете больше информации.
#observability #metrics
—————————————
Contentsquare Uses Microservices and Apache Kafka for Notification Delivery
У меня сложное отношение к сервису нотификаций, так как я не видел приемлемой реализации подобных сервисов. Обычно под сервисом нотификаций подразумевают штуку, которая сама решает какой темплейт использовать, хранит данные от всей системы и вместо реализации транспорта отправки информации, по определенному каналу, используют сторонние SAAS решения, что превращается в god service. А сервис содержит в себе информацию о всей системе, что приводит к повышенной связности, глобальной сложности и другим страшным вещам. Поэтому, когда вижу статью о том, как нотификации сделаны у других – стараюсь не пропускать подобные статьи, чтобы найти пример хорошей реализации (пока не нашел).
Сегодняшняя статья рассказывает о том, как устроен сервис нотификаций в компании contentsquare. Зачем используется кафка, как выглядит роутинг нотификаций (с помощью кафки). Рассказывается зачем решили разделять топики (для скейлинга), как решали проблемы с отправкой нотификаций по почте и что использовали для обсервабилити.
#notification_service
—————————————
Web Mapping with Free Software Tools
Радуюсь как в первый раз, когда встречаю статьи с объяснением как что-то работает. Сегодняшний день не исключение: в рассылку попал лонгрид пятилетней давности о том, как работают карты и как работать с геоданными в вебе. Из текста узнаете как работают GIS (geographic information systems): как хранить данные в таблицах, почему с координатами могут быть проблемы и как работают слои в таких системах. После этого рассказывается как подготовить геоданные для дальнейшего маппинга данных на гугл карту. Дальше описываются проекты QGIS и qgis2web, которые позволяют работать с геоданными и в самом конце найдете блок о том, как работать с геоданными используя язык R.
#how_it_works #maps
Чёрная пятница в Школе сильных программистов
Ребята из школы второй раз решили в черную пятницу сделать большую скидку. Хотел написать об этом в пятницу, как обычно, с ссылками. Но промокод BFPEPE на скидку 25% действует до 12 часов дня по мск, а ссылки выйдут только спустя 1.5 часа после дедлайна, поэтому неожиданное включение.
Ребята из школы второй раз решили в черную пятницу сделать большую скидку. Хотел написать об этом в пятницу, как обычно, с ссылками. Но промокод BFPEPE на скидку 25% действует до 12 часов дня по мск, а ссылки выйдут только спустя 1.5 часа после дедлайна, поэтому неожиданное включение.
Telegram
FEDOR BORSHEV
Чёрная пятница 2
В прошлом году мы первый раз запустили в школе чёрную пятницу. Сработало хорошо — много новых учеников познакомились с нашими курсами, а мы смогли инвестировать в LMS и другие внутренние проекты.
В этом году повторяем историю — если вы…
В прошлом году мы первый раз запустили в школе чёрную пятницу. Сработало хорошо — много новых учеников познакомились с нашими курсами, а мы смогли инвестировать в LMS и другие внутренние проекты.
В этом году повторяем историю — если вы…
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
The LMAX Architecture
Оказалось, что в блоге Мартина Фаулера существует серия постов под названием «experience reports» в которой рассказывается о том, как были сделаны те или иные проекты. Сегодняшняя статья опубликована в 2011 году и рассказывает о том, как in-memory event sourcing позволил создать финтрейдинг платформа, которая обрабатывала 6 миллионов ордеров в секунду в одном треде (использовался jvm).
Статья начинается с описания хайлевел структуры, состоящей из трех частей: input disruptor, business logic processor и output disruptor. При этом, процессор бизнес логики - программа на чистой джаве, которая не зависит от баз данных и фреймворков, потому что стейт хранится в памяти и обрабатывается с помощью event sourcing. Дальше описываются причины такого выбора, как тестировался перфоманс и как, в общих словах, реализовывалась бизнес логика. После этого рассказывается о disruptors: входную и выходную часть, которая отвечает за предварительную обработку событий, хранение данных, фильтрацию и работу с консьюмерами. При этом, код disruptors заопенсорсили. После чего рассуждается о том, что итоговая структура отличается от того, что делали в 2011 году и говорится о причинах выбора подобного «стиля» (все упиралось в перфоманс, как я понял). А в конце рассуждается когда стоит использовать подобный подход (стоит смотреть на требуемые от системы характеристики).
#how_it_works #event_sourcing #banking
—————————————
Киберпанк, который мы заслужили. Какие технологии внедряют в сельском хозяйстве
Не техническая статья, а скорее рассказ о том, как технологии помогают в областях далеких от абстрактного веба, а именно в работе агрохолдинга. Из статьи узнаете:
- как исследование поверхности вместе с бигдатой помогает предсказывать проблемы, количество/качество урожая и ловить водителей на сливе топлива;
- где уже работает автопилот и почему это экономит топливо и помогает выдерживать 12 часовые смены людям;
- как хранить овощи свежими год (на самом деле, пункт об автоматизации систем хранения урожая почему-то стал открытием)
В тексте нет никаких технических деталей, скорее только описание проблем где используется автоматизация. Если знаете статьи с техническим описанием как автоматизируется сельхоз работы - пишите в комментарии, буду рад почитать.
#how_it_works
—————————————
Applying Kappa Architecture to Make Data Available
Статья заинтересовала описанием kappa architecture - подходе который позволяет в реальном времени обрабатывать большое количество данны. Достигается это за счет стрим процессинга данных из распределенного лога (все почему-то упоминают кафку), после чего данные в обработанном виде попадают в БД для дальнейшего чтения. Судя по тому что видел - паттерн является реализацией event sourcing с cqrs, где в виде эвент лога (write model) используется распределенный лог, стриминг процессинг выполняет роль проджекшена (штука которая собирает состояние из событий), а БД с резултатом - кеш проджекшена (read model).
Из плюсов подхода: кто угодно в лог писать может, тайм тревел по данным, быстро читать закешированные в бд данные. А из минусов: сложность подхода в реализации. Т.е. все плюсы и минусы обычного event sourcing. Также, подход любят сравнивать с “lambda архитектурой”, в которой, как я понял, вместо эвент лога, события просто трансформируются и сразу попадают в базу.
В тексте, кроме описания подхода и сравнении с лямбдой, найдете набор пример реализации. А если не хотите читать на английском - нашел статью о подходе на русском, в которой примеров использования еще больше.
#data_processing #event_sourcing
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
The LMAX Architecture
Оказалось, что в блоге Мартина Фаулера существует серия постов под названием «experience reports» в которой рассказывается о том, как были сделаны те или иные проекты. Сегодняшняя статья опубликована в 2011 году и рассказывает о том, как in-memory event sourcing позволил создать финтрейдинг платформа, которая обрабатывала 6 миллионов ордеров в секунду в одном треде (использовался jvm).
Статья начинается с описания хайлевел структуры, состоящей из трех частей: input disruptor, business logic processor и output disruptor. При этом, процессор бизнес логики - программа на чистой джаве, которая не зависит от баз данных и фреймворков, потому что стейт хранится в памяти и обрабатывается с помощью event sourcing. Дальше описываются причины такого выбора, как тестировался перфоманс и как, в общих словах, реализовывалась бизнес логика. После этого рассказывается о disruptors: входную и выходную часть, которая отвечает за предварительную обработку событий, хранение данных, фильтрацию и работу с консьюмерами. При этом, код disruptors заопенсорсили. После чего рассуждается о том, что итоговая структура отличается от того, что делали в 2011 году и говорится о причинах выбора подобного «стиля» (все упиралось в перфоманс, как я понял). А в конце рассуждается когда стоит использовать подобный подход (стоит смотреть на требуемые от системы характеристики).
#how_it_works #event_sourcing #banking
—————————————
Киберпанк, который мы заслужили. Какие технологии внедряют в сельском хозяйстве
Не техническая статья, а скорее рассказ о том, как технологии помогают в областях далеких от абстрактного веба, а именно в работе агрохолдинга. Из статьи узнаете:
- как исследование поверхности вместе с бигдатой помогает предсказывать проблемы, количество/качество урожая и ловить водителей на сливе топлива;
- где уже работает автопилот и почему это экономит топливо и помогает выдерживать 12 часовые смены людям;
- как хранить овощи свежими год (на самом деле, пункт об автоматизации систем хранения урожая почему-то стал открытием)
В тексте нет никаких технических деталей, скорее только описание проблем где используется автоматизация. Если знаете статьи с техническим описанием как автоматизируется сельхоз работы - пишите в комментарии, буду рад почитать.
#how_it_works
—————————————
Applying Kappa Architecture to Make Data Available
Статья заинтересовала описанием kappa architecture - подходе который позволяет в реальном времени обрабатывать большое количество данны. Достигается это за счет стрим процессинга данных из распределенного лога (все почему-то упоминают кафку), после чего данные в обработанном виде попадают в БД для дальнейшего чтения. Судя по тому что видел - паттерн является реализацией event sourcing с cqrs, где в виде эвент лога (write model) используется распределенный лог, стриминг процессинг выполняет роль проджекшена (штука которая собирает состояние из событий), а БД с резултатом - кеш проджекшена (read model).
Из плюсов подхода: кто угодно в лог писать может, тайм тревел по данным, быстро читать закешированные в бд данные. А из минусов: сложность подхода в реализации. Т.е. все плюсы и минусы обычного event sourcing. Также, подход любят сравнивать с “lambda архитектурой”, в которой, как я понял, вместо эвент лога, события просто трансформируются и сразу попадают в базу.
В тексте, кроме описания подхода и сравнении с лямбдой, найдете набор пример реализации. А если не хотите читать на английском - нашел статью о подходе на русском, в которой примеров использования еще больше.
#data_processing #event_sourcing
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Это база: нюансы работы с Redis. Часть 1
В моей практике, редис – наиболее популярная база, которая так или иначе встречается в проектах. Это может быть как персистенс слой для кеша, бэкграунд процессинга или же в ручную реализованное хранилище для быстрого доступа (за счет хранения данных в памяти). По этой причине, когда встречаю посты о базе, стараюсь их не пропускать.
Из сегодняшнего текста узнаете:
- Что такое редис и почему однопоточная работа как плюс, так и минус базы;
- Как удалять старые данные без использования
- Какие типы данных реализованы в базе, как работают, какие ограничения и где что использовать. При этом, рассказывается о ziplist - специальном двусвязном списке оптимизированном для меньшего потребления памяти;
- Как хранить данные из редиса на диске. Есть два варианта: полный бекап или хранение выполненных операций в файл (аля эвент сорсинг). Там же даются нюансы по каждому из вариантов;
В конце даются общие рекомендации по настройке и обслуживания базы. Например: советы по длине строк, как контролировать и анализировать содержимое редиса и так далее.
#db #redis
—————————————
Software Architecture: Code Modularity Matrices
Считается, что в программировании две проблемы: инвалидация кеша и нейминг. От себя добавлю третью: модульность и поиск границ элементов. Поэтому сегодня статья связана с модульностью. Из текста узнаете: при чем тут связанность (как coupling, так и cohesion) и какие виды связанности бывают. Что такое abstractness (метрика того, на сколько абстрактный элемент) и по какой формуле считается. После чего рассказывается об instability (по опыту - недооцененная метрика из программирования). После чего, instability связывается с abstractness и получается distance from the main sequence - концепция из ADD, показывающая на сколько элемент “сбалансированный”. В конце рассказывается о метрике из ооп - connasecence и какие виды метрики выделяют.
#modularity #coupling
—————————————
Building Immune Authorization: AppSec in Healthcare Apps
Одной из проблем healthcare приложений является сенситивность данных клиентов. Это может быть выражено как комплаенсами (привет HIPPA), так и здравым смыслом (никто не захочет, чтобы личные диагнозы стали доступны другим людям без собственного разрешения). При этом, проблема аутентификации в healthcare связана с большим количеством пользователей (клиентов, врачей, сотрудников, инспекцией) и данных, а доступы реализуются путем сложного алгоритма. В теории, можно было бы алгоритм описать условиями с ролями и связями в базе, но могут возникнуть сложности с когнитивной нагрузкой на разработчиков, пример чего можно найти в тексте выше.
Кроме примера сложной авторизации, автор сравнивает три подхода: RBAC (авторизация по ролям), ABAC (авторизация по характеристикам) и ReBAC (фокусируется на взаимоотношениях между пользователями и ресурсами, что позволяет создавать группы ресурсов и пользователей). Дальше рассказывается о том, какие еще проблемы могут возникать в healthcare проектах и в качестве примера предлагают статью с описанием демо приложения.
#authN #ReBAC
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Это база: нюансы работы с Redis. Часть 1
В моей практике, редис – наиболее популярная база, которая так или иначе встречается в проектах. Это может быть как персистенс слой для кеша, бэкграунд процессинга или же в ручную реализованное хранилище для быстрого доступа (за счет хранения данных в памяти). По этой причине, когда встречаю посты о базе, стараюсь их не пропускать.
Из сегодняшнего текста узнаете:
- Что такое редис и почему однопоточная работа как плюс, так и минус базы;
- Как удалять старые данные без использования
EXPIRE. Вместо этого использовать key eviction - удаления группы ключей (определяемых по полиси), при достижении максимального размера памяти;- Какие типы данных реализованы в базе, как работают, какие ограничения и где что использовать. При этом, рассказывается о ziplist - специальном двусвязном списке оптимизированном для меньшего потребления памяти;
- Как хранить данные из редиса на диске. Есть два варианта: полный бекап или хранение выполненных операций в файл (аля эвент сорсинг). Там же даются нюансы по каждому из вариантов;
В конце даются общие рекомендации по настройке и обслуживания базы. Например: советы по длине строк, как контролировать и анализировать содержимое редиса и так далее.
#db #redis
—————————————
Software Architecture: Code Modularity Matrices
Считается, что в программировании две проблемы: инвалидация кеша и нейминг. От себя добавлю третью: модульность и поиск границ элементов. Поэтому сегодня статья связана с модульностью. Из текста узнаете: при чем тут связанность (как coupling, так и cohesion) и какие виды связанности бывают. Что такое abstractness (метрика того, на сколько абстрактный элемент) и по какой формуле считается. После чего рассказывается об instability (по опыту - недооцененная метрика из программирования). После чего, instability связывается с abstractness и получается distance from the main sequence - концепция из ADD, показывающая на сколько элемент “сбалансированный”. В конце рассказывается о метрике из ооп - connasecence и какие виды метрики выделяют.
#modularity #coupling
—————————————
Building Immune Authorization: AppSec in Healthcare Apps
Одной из проблем healthcare приложений является сенситивность данных клиентов. Это может быть выражено как комплаенсами (привет HIPPA), так и здравым смыслом (никто не захочет, чтобы личные диагнозы стали доступны другим людям без собственного разрешения). При этом, проблема аутентификации в healthcare связана с большим количеством пользователей (клиентов, врачей, сотрудников, инспекцией) и данных, а доступы реализуются путем сложного алгоритма. В теории, можно было бы алгоритм описать условиями с ролями и связями в базе, но могут возникнуть сложности с когнитивной нагрузкой на разработчиков, пример чего можно найти в тексте выше.
Кроме примера сложной авторизации, автор сравнивает три подхода: RBAC (авторизация по ролям), ABAC (авторизация по характеристикам) и ReBAC (фокусируется на взаимоотношениях между пользователями и ресурсами, что позволяет создавать группы ресурсов и пользователей). Дальше рассказывается о том, какие еще проблемы могут возникать в healthcare проектах и в качестве примера предлагают статью с описанием демо приложения.
#authN #ReBAC
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Мутации в микросервисах: применяем Temporal
Я скептически отношусь к распределенным оркестраторам (поэтому написал свою реализацию). Но это не значит, что стоит забивать на существующие на рынке решения. Сегодня статья о temporal - workflow engine, шаги в котором можно описывать кодом, само выполнение кода децентрализованно, присутствует настройка ретраев и так далее. В тексте кратко описываются составные части энджина (но с ссылкой на визуальный гайд). После дается пример в котором рассказывается как вынести кусок биллинга из системы. Для примера описывается каждый шаг на пхп, показывается как запустить кластер энджина и отдельные воркеры. После чего показывается как обрабатываются ошибки и падения. А в конце дается список плюсов (универсальность, надежность) и минусов (риски появления распределенного монолита, высокий порог входа и так далее)
#distributed_transactions #workflow_engines
—————————————
GDPR for busy developers
Иногда возникает ситуация “забыть” всю информацию о пользователе. В Европе вариант такой ситуации "называют" GDPR, в котором необходимо либо удалить информацию, либо анонимизировать. К сожалению, подобная ситуация может возникнуть не только из-за законов, но из-за специфики домена (пару раз в аккаунтинге на такое натыкался).
Сегодняшняя статья отвечает на вопрос, что делать в ситуации, когда система ограничена подобными правилами. В начале рассуждается о выборе между двумя подходами: удалять данные полностью, либо анонимизировать данные о пользователях. При этом, у каждого варианта можно найти как плюсы, так и минусы. После этого даются советы о том, как хранить данные для каждого случая. Причем хранить не только в базе данных основного приложения, но и, как пример, что делать с логами. Потом затрагивается тема бекапов и даются рекомендации по настройке (разделять данные пользователя от основных, настроить правила удаления старых данных, и так далее). А в конце дается ссылка на запись, где рассказывается о том, как подобные ограничения могут работать в event sourcing, где данные нельзя мутировать.
#events #data_storage
—————————————
How to ace stakeholder management (and deliver more winning projects)
Можно оказаться в ситуации, когда, работая над проектом год, за день до релиза, появляется кричащий бухгалтер. При этом, единственное что можно разобрать из крика – либо сворачиваем проект, либо дружно начинаем сушить сухари. Такие ситуации связаны с тем, что во время работы над проектом не уделялось внимание заинтересованным сторонам, или stakeholders. Статья выше как раз рассказывает как работать с такими сторонами.
Текст состоит из трех частей. В первой части объясняется зачем управлять стейкхолдерами: поможет с сотрудничеством и взаимоотношениями между людьми, а также упростит разруливание конфликтов и потенциально поможет генерировать больше идей.
Во второй части рассказывается о трех шагах для работы с заинтересованными сторонами, которые советует автор:
1. определить стейкхолдеров. Приятно, что рассказывается о двух инструментах (stakeholder map и карт RACI).
2. приоритизировать стейкхолдеров. Тут о том, что некоторые стейкхолдеры важнее других, а что бы понять кто равнее - может помочь квадрат “влияние/интерес”
3. описать стратегию взаимодействия со стейкхолдерами. Тут рассказывается о Stakeholder Communications Plan (главное персональное открытие текста)
В заключительной, третьей части, дается еще три совета, по работе со стейкхолдерами, и описывается чек лист “что делать на каждом этапе жизни проекта”.
Перевод на русский
#stakeholders
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Мутации в микросервисах: применяем Temporal
Я скептически отношусь к распределенным оркестраторам (поэтому написал свою реализацию). Но это не значит, что стоит забивать на существующие на рынке решения. Сегодня статья о temporal - workflow engine, шаги в котором можно описывать кодом, само выполнение кода децентрализованно, присутствует настройка ретраев и так далее. В тексте кратко описываются составные части энджина (но с ссылкой на визуальный гайд). После дается пример в котором рассказывается как вынести кусок биллинга из системы. Для примера описывается каждый шаг на пхп, показывается как запустить кластер энджина и отдельные воркеры. После чего показывается как обрабатываются ошибки и падения. А в конце дается список плюсов (универсальность, надежность) и минусов (риски появления распределенного монолита, высокий порог входа и так далее)
#distributed_transactions #workflow_engines
—————————————
GDPR for busy developers
Иногда возникает ситуация “забыть” всю информацию о пользователе. В Европе вариант такой ситуации "называют" GDPR, в котором необходимо либо удалить информацию, либо анонимизировать. К сожалению, подобная ситуация может возникнуть не только из-за законов, но из-за специфики домена (пару раз в аккаунтинге на такое натыкался).
Сегодняшняя статья отвечает на вопрос, что делать в ситуации, когда система ограничена подобными правилами. В начале рассуждается о выборе между двумя подходами: удалять данные полностью, либо анонимизировать данные о пользователях. При этом, у каждого варианта можно найти как плюсы, так и минусы. После этого даются советы о том, как хранить данные для каждого случая. Причем хранить не только в базе данных основного приложения, но и, как пример, что делать с логами. Потом затрагивается тема бекапов и даются рекомендации по настройке (разделять данные пользователя от основных, настроить правила удаления старых данных, и так далее). А в конце дается ссылка на запись, где рассказывается о том, как подобные ограничения могут работать в event sourcing, где данные нельзя мутировать.
#events #data_storage
—————————————
How to ace stakeholder management (and deliver more winning projects)
Можно оказаться в ситуации, когда, работая над проектом год, за день до релиза, появляется кричащий бухгалтер. При этом, единственное что можно разобрать из крика – либо сворачиваем проект, либо дружно начинаем сушить сухари. Такие ситуации связаны с тем, что во время работы над проектом не уделялось внимание заинтересованным сторонам, или stakeholders. Статья выше как раз рассказывает как работать с такими сторонами.
Текст состоит из трех частей. В первой части объясняется зачем управлять стейкхолдерами: поможет с сотрудничеством и взаимоотношениями между людьми, а также упростит разруливание конфликтов и потенциально поможет генерировать больше идей.
Во второй части рассказывается о трех шагах для работы с заинтересованными сторонами, которые советует автор:
1. определить стейкхолдеров. Приятно, что рассказывается о двух инструментах (stakeholder map и карт RACI).
2. приоритизировать стейкхолдеров. Тут о том, что некоторые стейкхолдеры важнее других, а что бы понять кто равнее - может помочь квадрат “влияние/интерес”
3. описать стратегию взаимодействия со стейкхолдерами. Тут рассказывается о Stakeholder Communications Plan (главное персональное открытие текста)
В заключительной, третьей части, дается еще три совета, по работе со стейкхолдерами, и описывается чек лист “что делать на каждом этапе жизни проекта”.
Перевод на русский
#stakeholders
Пятничное чтиво
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Graceful degradation. Доклад Яндекс.Такси
При создании распределенных систем, приходиться думать о том, что делать, если часть системы вышла из строя и не отвечает. В случае асинхронной репликации данных – можно работать со старыми данными, но в случае синхронных коммуникаций, такое решение отсутствует. Сегодня статья – пересказ доклада, в котором яндекс делится советами по работе с graceful degradation: «правильной» деградации системы, чтобы основной бизнес флоу работал как можно дольше. Для этого можно либо выключать сервисы, а если выключение не возможно - заменить функционал на урезанный или макет.
В начале говорится о том, как структурно сделать систему, которая позволит деградировать (спойлер - распределенные и изолированные сервисы). Дальше рассказывается, как можно подменять функционал на «тыкву», для чего можно использовать прокси, который будет переключать трафик между реальным сервисом и урезанным функционалом. Например, вместо предсказания возможных точек в такси, можно использовать заранее предопределенные популярные точки. Дальше рассказывается о том, как определить когда включать «мок», а когда выключать. А в конце рассказывается о консистентности в таком подходе.
#graceful_degradation #communications
—————————————
Expand/Contract: making a breaking change without a big bang
Кроме деградации функционала, в коммуникациях возникает проблема связанная с breaking changes – когда схема контракта между продьюсером и консьюмером меняется. Это может произойти как на уровне базы, синхронных вызовов (там две схемы), так и на уровне событий. В статье выше как раз рассказывается о такой проблеме и о том, как Expand/Contract подход может помочь с изменениями, ломающими совместимость.
Начинается текст с объяснения breaking change, где в качестве примера приводится схема блог поста, в котором консьюмер вместо bool
#braking_changes #communications
—————————————
Our Experience with Bi-temporal Event Sourcing
В event sourcing состояние системы рассчитывается по событиям, которые произошли над системой и которые хранятся в отдельном event store (любимая аналогия - коммиты в гите, которые собираются в код). В случае bi-temporal event sourcing события не только хранят момент времени, но и время, когда данные вступают в силу. Например, когда вы вносите информацию об отпуске, сначала ставите неделю с 20 декабря, а через время понимаете, что будет лучше уйти в отпуск 18 декабря на две недели.
Автор статьи делится опытом работы с такой информацией. Хоть статья начинается с примера отпуска, дальше приводится пример сложнее, когда меняются права доступа на время (тот же отпуск). Если использовать дефолтный es, то теряется промежуток во времени, который перезаписывается новыми данными. После этого, в статье рассказывается как взяв F# и немного магии, реализовать подобную систему, которая учитывает не только время добавления информации, но и время, когда эта информация является актуальной. Отдельно отмечу секцию о проджекшенах (место где события собираются в состояния) и личный опыт, описанный в самом конце.
#event_sourcing
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Graceful degradation. Доклад Яндекс.Такси
При создании распределенных систем, приходиться думать о том, что делать, если часть системы вышла из строя и не отвечает. В случае асинхронной репликации данных – можно работать со старыми данными, но в случае синхронных коммуникаций, такое решение отсутствует. Сегодня статья – пересказ доклада, в котором яндекс делится советами по работе с graceful degradation: «правильной» деградации системы, чтобы основной бизнес флоу работал как можно дольше. Для этого можно либо выключать сервисы, а если выключение не возможно - заменить функционал на урезанный или макет.
В начале говорится о том, как структурно сделать систему, которая позволит деградировать (спойлер - распределенные и изолированные сервисы). Дальше рассказывается, как можно подменять функционал на «тыкву», для чего можно использовать прокси, который будет переключать трафик между реальным сервисом и урезанным функционалом. Например, вместо предсказания возможных точек в такси, можно использовать заранее предопределенные популярные точки. Дальше рассказывается о том, как определить когда включать «мок», а когда выключать. А в конце рассказывается о консистентности в таком подходе.
#graceful_degradation #communications
—————————————
Expand/Contract: making a breaking change without a big bang
Кроме деградации функционала, в коммуникациях возникает проблема связанная с breaking changes – когда схема контракта между продьюсером и консьюмером меняется. Это может произойти как на уровне базы, синхронных вызовов (там две схемы), так и на уровне событий. В статье выше как раз рассказывается о такой проблеме и о том, как Expand/Contract подход может помочь с изменениями, ломающими совместимость.
Начинается текст с объяснения breaking change, где в качестве примера приводится схема блог поста, в котором консьюмер вместо bool
is_published начинает использовать enum значение pub_state. Такое изменение приводит к нарушению обратной совместимости (старое поле «удаляется»), следовательно появляется breaking change, при котором консьюмер и продьюсер несовместимы. Дальше рассказывается о подходе, при котором сначала создается новая версия схемы, потом переносится на нее продьюсер (или консьюмер, на самом деле, в зависимости от уровня совместимости), после чего на новую версию переходит второй участник коммуникации.#braking_changes #communications
—————————————
Our Experience with Bi-temporal Event Sourcing
В event sourcing состояние системы рассчитывается по событиям, которые произошли над системой и которые хранятся в отдельном event store (любимая аналогия - коммиты в гите, которые собираются в код). В случае bi-temporal event sourcing события не только хранят момент времени, но и время, когда данные вступают в силу. Например, когда вы вносите информацию об отпуске, сначала ставите неделю с 20 декабря, а через время понимаете, что будет лучше уйти в отпуск 18 декабря на две недели.
Автор статьи делится опытом работы с такой информацией. Хоть статья начинается с примера отпуска, дальше приводится пример сложнее, когда меняются права доступа на время (тот же отпуск). Если использовать дефолтный es, то теряется промежуток во времени, который перезаписывается новыми данными. После этого, в статье рассказывается как взяв F# и немного магии, реализовать подобную систему, которая учитывает не только время добавления информации, но и время, когда эта информация является актуальной. Отдельно отмечу секцию о проджекшенах (место где события собираются в состояния) и личный опыт, описанный в самом конце.
#event_sourcing