Страница телеграм канала Pepegramming

pepegramming logo

Pepegramming

587 подписчиков

Грустно о программировании. Все проблемы сюда: @davydovanton Ссылки на конкретные посты: http://telegra.ph/Pepegramming-Contents-03-11 Обратная связь: https://goo.gl/forms/iUd1Gufq6WnTsaO62


Входит в категории: Технологии
Pepegramming
17.09.2021 13:09
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Reactive in practice, Unit 1: Event storming the stock trader domain В канале уже упоминалась статья о декомпозиции монолита с помощью event storming. Event storming - способ обнаружения компонентов системы (на ряду с actor/action и workflow approaches). Пришла из ДДД и специфика подхода - упор на команды и события, как способ вызова одной команды из другой. Пока готовлюсь ко второму потоку курса нашел сегодняшнюю ссылку. Это первый урок из серии статей о создании event-driven системы, в котором рассказывается как использовать ES в определении доменов системы, а также команд и событий. Подробно описывается сам подход, части из которых состоит и на примере stock trader системы, состоящей из трех доменов, раскладываются команды и события. ————————————— 5 Database technologies used by 2000 Wix microservices Как можно понять из названия - в wix используется 2к сервисов, написанных на разных языках и использующие пять баз данных: MySQL, MongoDB, DynamoDB, ElasticSearch и S3. Каждая из БД решает определенную проблему, например монга используется для блога, а динамо - для чатов. В статье найдете, когда использовать базу, плюсы и минусы, а также юзкейсы компании, в которых используется каждая из баз данных. Понравилось, что в статье описали юзкейсы компании и концовка текста, в которой описываются критерии выбора БД, а также диаграмма для принятия решения. Кажется, что если в компании больше пары баз - подход поможет выбрать нужную бд под задачу каждой команды/сервиса. ————————————— Версионирование API или единая кодовая база для всех версий Один из способов соблюдения эволюции API при изменении требований - придерживаться выбранного уровня совместимости для response/request схем. Если случаются ситуации, когда совместимость нельзя соблюсти, приходится вводить версионирование. Что работает не только в синхронных коммуникациях, но и в асинхронных (я рассказываю об этом у себя в курсе). В статье рассказывается о трех способах версионирования API: - Feature-версионирование, когда клиент запрашивает доступ к определенным фичам; - Версионирование средствами VCS, когда версия зашивается в код и в инстанс приложения, что дорого и костыльно для web-api; - Версионирование средствами языка, когда код приложения реализует каждую версию в отдельном контроллере (как пример); - Версионирование Blueprints, не путать с API Blueprint. Это способ, придуманный в SuperJob, при котором конфиг с описанием версий и сущностях, по которому вызывается нужная бизнес логика. Остаток статьи - описание последнего способа версионирования, включая список инструментов и библиотек без которых будет сложно внедрить подход, плюсы/минусы и примеры тестирования версий.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
10.09.2021 13:09
Пятничное чтиво 24 и 25 сентября состоится конференция RubyRussia. Я каждый год рассказываю о мероприятии и 2021 не исключение. В этом году она опять будет онлайн, из интересного - круглый стол по руби в крупных компаниях. Старые записи стримов можно найти на ютубе. Хочу в ближайшее время сделать стрим с реализацией биллинга на событиях + ES. Хочется показать, как проектирую и делаю биллинги у клиентов. Если интересно или есть вопросы которые можно будет покрыть - пишите в комментарии. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Техники обработки отказов сервиса в микросервисных архитектурах, или Альтернативы Circuit Breaker Две недели назад публиковал ссылку о реализации Circuit Breaker паттерна. К сожалению, это не серебряная пуля и у паттерна присутствуют ограничения и проблемы (не возможность повторно отправить сообщение, например, если тарифный план сервиса изменился в худшую сторону, уменьшение скорости работы при отказах и не возможность параллельной обработки). В случае системы, описанной автором статьи, изначальное решение с fire-and-forget заменилось на Circuit Breaker. Но в скоре Circuit Breaker тоже оказалось не достаточно. Поэтому инженеры решили переехать на очереди, что в итоге привело к симбиозу reschedule подхода с очередями и Circuit Breaker. ————————————— Zero Trust Security Architecture Overview Я не слышал о подходе Zero Trust Architecture. Как оказалось, философия Zero Trust - никогда не доверять и каждый раз просить подтверждать личность. В случае Zero Trust Architecture - придется использовать строгие условия повторной авторизации для каждого запроса из сети. Для большего погружения в тему - обзорная статья, из которой узнаете о плюсах подхода для бизнеса (хотелось бы еще узнать о минусах), о примерах использования Zero Trust (говорится о трех гигантах, google, microsoft, aws и IBM), а также шаги, с помощью которых можно внедрить Zero Trust. ————————————— Navigating the 8 fallacies of distributed computing | Ably Blog: Data in Motion Текст с описанием восьми ложных предположений, с которыми можно столкнуться, создавая распределенные системы. Список тем из статьи: - The network is reliable. Сеть падает и в целом, она не предсказуема. - Latency is zero. Когда локально работаешь с сервером кажется, что система работает быстро, в продакшене оказывается, что данным нужно время чтобы дойти. С этим и прошлым пунктом встречался в реальности, когда запрос в кластере k8s “магическим” образом раз в N времени длился 2 секунды (при среднем в 100 мс) и отваливаться по тайм-ауту. Причину так и не нашли. - Bandwidth is infinite. Пропускная способность частей системы может оказаться меньше, чем рассчитывал. С этим столкнулся, когда сервис не успевал продьюсить 4к сообщений поштучно (вместо матча) в кафку за достаточное количество времени. - The network is secure. - Topology doesn’t change. Это о том, что сегодня сеть может быть реализована как звезда, а завтра стать mesh. Такие переходы могут повлиять на работу системы. - There is one administrator. - Transport cost is zero. Это о том, что иногда забываются низкоуровневые абстракции, которые нужны для отправки данных из точки в точку. Что может влиять на финансовую стоимость. - The network is homogeneous. Тут о том, что в распределенных системах могут быть разные устройства с разной конфигурацией, что приводит к мысли: “it’s critical to focus on interoperability, thus ensuring that all these components can “talk” to each other, despite being different”
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
03.09.2021 13:09
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Letter from the editor – Increment: Mobile Вышел новый выпуск журнала Increment. В канале упоминался журнал до этого, а выпуск апреля 2021 года - мобильная разработка и мобильные приложения. Из статей выбрал фаворитов, которыми хочу поделиться: An Introduction to the Microapps Architecture Подход с микросервисами вдохновил фронтенд на создание microfronted, теперь на очереди мобильная разработка. Microapps подход собирает приложение из модульных частей, часть которых можно независимо протестировать локально, запустив только необходимые модули. Из плюсов, также, отмечают скорость сборки. Сами приложения состоят из user-facing application (координационный слой), feature модулей (что-то в духе доменов и бизнес логики в них), UI модуля, foundation/utility модулей (low-level функционал) и тувинка. Подробнее о видах модулей, челенджах и компромиссах, прочтете в конце статьи. Feature Flags for Mobile Development Короткая статья о том, как инженеры CreatorStack используют feature флаги в повседневной разработке. В тексте найдете информацию о кросс командном тестировании, версионировании и удалении флагов, которые перестали проверять гипотезы. ————————————— Observability with RabbitMQ and microservices Статья с описанием реализации observability для событий в rabbitMQ. Уделяется внимание четырем аспектам: events history, events reply, topology visibility и трассировки. Понравилось, как ребята сделали трассировку (спойлер: хранят id продюсера как родителя, консьюмера и trace_id одинаковый для всех событий), после чего Google Trace показывает трейс каждого из событий. Для visibility используется хак с описанием конфета транспорта, с последующей визуализацией конфигов. А для истории - редирект каждого события в системе в отдельную очередь. ————————————— Protecting Sensitive Data in Event-Sourced Systems with Crypto Shredding Один из популярных вопросов, которые я слышу касаемо event sourcing - как работать с sensitive данными, которые надо удалять или маркировать удаленными. Такие вопросы возникают, потому что каждое событие иммутабельно, что значит - удалить или мутировать события возможности нет. Один из способов решить такую проблему - Crypto Shredding, т.е. шифрование необходимых данных. А при требовании удалить информацию - ключ шифрования “теряется”. Об этом статья, в которой описывается реализация Crypto Shredding в 11 шагов. Сама реализация подробно описана на C#, думаю и в других языках реализация будет похожей.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
27.08.2021 13:08
Пятничное чтиво Сегодня только две статьи, так как ничего интересного найти не смог за неделю. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Disasters I’ve seen in a microservices world Микросервисы - сложно и больно. При этом, сервисная архитектура заставляет решать проблемы, которых нет в монолитах. И сегодняшняя статья как раз об этом. В тексте описывается шесть проблем, с которыми столкнулась компания Adevinta, когда перешла на сервисную архитектуру. Среди проблем найдете: какой размер сервисов оптимален, к чему приводят общие базы данных, стоимость, тестирование, согласованность, таймауты, ретраи и так далее. Закралось подозрение, что часть описанных проблем связана с проблемами вокруг декомпозиции сервисов. Нравятся подобные статьи, потому что чужой опыт позволяет не только собрать список проблем, но и понять какие из них чаще повторяются. А в будущем, быть готовым к обоснованию, почему 200 сервисов на 10 строк кода - плохая идея. Русский перевод ————————————— Стратегии обработки ошибок: Circuit Breaker pattern Не ведитесь на название статьи, текст не только о Circuit Breaker, который упоминался в канале полтора года назад, но и в целом о подходах обработки ошибок в синхронных коммуникациях. В тексте, упоминается четыре способа: - параллельная отправка запросов, при которой данные, даже если один из инстансов сервиса упадет, будут полученны сервисом; - Idempotency Key, который выполняет одну команду один раз, вне зависимости от количества вызовов; - Retry pattern, который ретраит до победного запрос; - Circuit Breaker pattern, который не только обрывает соединение при каком-то условии (например 50% запросов с таймаутом), но и сразу же отдает клиенту ошибку, в обход таймаутам; Я нашел эту статью, пока искал нормальное описание Circuit Breaker паттерна и был удивлен, что она оказалась общей, а не о конкретном паттерне. Если говорить о Circuit Breaker, то понравилось, что описываются возможные три состояния, а пример с оплатой карты оказался полезным для первичного понимания.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
20.08.2021 13:08
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Bartosz Ciechanowski В подборке ссылок редко появляются темы не связанные с IT, но сегодня исключение, которое захватило меня на три дня. Речь идет о блоге, где автор разбирает как работают механизмы или системы. Например, по ссылке найдете объяснение работы шестеренок, камер и линз, чисел с плавающей точкой, двигателя внутреннего сгорания и других вещей. Каждая статья - лонгрид, который подробно и в деталях объясняет природу явлений. Кроме того, автор добавляет динамическое взаимодействие с вещами, о которых говорит. Так, например, для двигателя внутреннего сгорания, крутится модель двигателя и каждой из ее частей, а для шестеренок, поиграть с размерами и видами шестерен. Кратко характеризовать блог можно фразой - "vas3k блог о механизмах с динамическими примерами". Жаль, что не было подобных объяснений, пока учился в институте. И хотелось бы видеть что-то подобное связанное с архитектурой или программированием. ————————————— Архитектура распределенной очереди в Mail.ru Cloud Solutions Mail ru продолжает экспериментировать с Tarantool и в сегодняшней статье описывается, как с помощью собственной базы данных инженеры сделали распределенную очередь, которая используется в cloud платформе от mail. Компания вдохновилась Simple Queue Service, а реализация амазона описывается в статье. Из интересного - архитектура сервиса, особенно часть, в которой говорится о том, как сообщения хранятся. Не хватило графиков и бенчмарков. Но если хотите сделать собственную SQS - статья поможет вдохновиться и начать. ————————————— Give me /events, not webhooks Относительно короткая статья, смысл которой сводится к тому, что кроме пуш стратегии в вебхуках, есть еще вариант с пуллингом. Этот вариант реализуется через эндпоинт /events, который предоставляет список событий, произошедших для пользователя. А курсор (отметка прочитанных сообщений) выбирает каждый сервис локально. Плюс такого подхода: если сервис будет в дауне, вебхуки не пропадут, а также, не приходится думать как ускорить получение события на стороне консьюмера. В качестве примера используется HTTP API от stripe. Из интересного - в конце статьи приводится идея, что кроме пуллинга со стороны консьюмера можно использовать long-polling. Это значит, что после стандартного запроса на /events не дропаем коннекшн, а ждем новые данные в реалтайме и обновляем курсор. Если конекшен прервался (даун или редеплой) - делаем еще один запрос и продолжаем обрабатывать события с последнего прочитанного. Стоит отметить, что у пул и пуш стратегий есть плюсы и минусы. И для каждого случая стоит выбирать архитектуру исходя из требований.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
13.08.2021 13:08
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Cell-Based Architecture and Federated Microservices GitHub: wso2/reference-architecture Короткая статья с рассуждениями о cell-based архитектуре, которая привлекла взгляд только потому, что последние пол года играю в факторио и в фоне думаю как концепцию сити блоков переложить на архитектуру приложений. Главное, что нашел в статье - ссылка на референс документ по теме, а также, рассуждения на тему схожести Federated Microservices и cell based подхода. Но самое интересное начинается, если открыть документ. В котором будет 5 секций: интро в абстракции, интро в юниты энтерпрайз архитектуры, обсуждение гибкости структуры, определение архитектуры и определение правил. Сама архитектура состоит из клеток (cells), которые содержат в себе 1+ компонент и каждая клетка изолирована, как по смыслу, так и по деплойменту. При этом компоненты общаются между собой по своему протоколу, а коммуникации между клетками тоже разрешены. Т.е., как я понял, это следующая абстракция над SoA, которая группирует сервисы по бизнес признаку. Кажется, что подобный подход может работать только в больших компаниях, где отделы работают над кусками приложений. Также, хочется оставить цитатой мысль, которая понравилась: “Cell-based architecture aims to create business focused architectural constructs that can be reused at a higher level, so naturally organizing the teams and cells around business functions is essential.”. А больше информации о том, как это работает и примере системы построенной на «клеточной» архитектуре найдете в документе. ————————————— The Lakehouse Architecture При проектировании систем стоит помнить, что данные, хранимые в системе, будут нужны для аналитики. Это значит, что если встает выбор делать аудит лог за ту же стоимость или нет - скорее всего аудит лог появится, так как для аналитики временные данные ценнее. Кроме проектирования модели данных стоит помнить о том, как данные выгружать, особенно если баз данных больше одной. Для этого, стараюсь обращать внимание на современные подходы вокруг data engineering. И сегодняшний текст о подходе, который называется The Lakehouse Architecture и смысл которого сводится к попытке взять лучшее из data lakes и data warehouses подходов. В статье найдете исторический контекст подхода, как работает и зачем нужен. И что приятно, какие у архитектуры ограничения и рассуждения о будущем. ————————————— Building a Reactive Architecture Around Redis В моей практике редис используют для кэширования и бэкграунд процессинга. Поэтому каждый новый способ использования базы - автоматически становится текстом для ознакомления. Сегодняшняя статья о том, как с помощью редиса можно построить reactive architecture, что в понимании автора - способ создания системы в основе которой идеи observer pattern-а. Для этого, предлагается воспользоваться тремя особенностями редиса: pub/sub, streams и keyspace notifications (до этого не слышал о нотификациях, будет что изучить). А дальше рассказывается, как, на примере микросервисов, можно создать message broker из редиса, описывая какую из особенностей стоит использовать в каждом конкретном случае. Понравилось, что объясняется как сделать триггеры по времени (пример - отправь событие, если через N времени ничего не произошло). Спойлер - через keyspace notifications.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
07.08.2021 19:08
Федя позвал выступить на курсе о росте в следующую пятницу 13 числа и разбавить выступления СТО технической стороной развития. В моей практике, под техническим развитием подразумевают “написал супер сложный драйвер или операционку” и с такая логика линейна. Делаешь проекты, находишь OSS, получаешь офер от компании, которой необходима компетенция или человек с доступом к OSS проекту. Мне же, хотелось уйти в проектирование систем и тут вскрылись проблемы: 1. “А что стратегически делать и куда развиваться?”. Гайдлайнов нет, карт развития тоже, приходится учиться на опыте + на разрозненных источниках информации (курсы либо о специфической теме, либо о микросервисах с одинаковым набором тем, которые ничего не говорят о стратегическом развитии); 2. Фидбэк луп длиннее, чем в коде. PoC (proof of concept) куска системы может делаться днями, а то и неделями или месяцами. Это похоже на то, что видел на НПО Салют, когда проходил там практику. Разбираешься, проектируешь, объясняешь что необходимо сделать, ждешь, получаешь фидбэк. Никакого REPL и тестов с мгновенной обратной связью; 3. Из второго пункта вытекает, что самому проектировать и реализовывать большее чем мелкий сервис - больно и долго. Поэтому появляются люди, которые реализуют спроектированное. Либо начинаешь сам и сгораешь из-за нагрузки. Из-за этого, попадаешь в ситуацию, когда без менеджерских навыков невозможно развивать технические навыки. Поэтому, в следующую пятницу, расскажу, как развиваюсь технически, занимаясь менеджерской работой половину (а то и больше) времени. Поделюсь инсайтами о том, как попытался в менеджмент сам того не подозревая и к чему это привело (спойлер: к проблемам, но проблема решилась). Ну и куда без депрессий, кризисов и рассуждений о том, что чем больше системы проектируешь, тем больше людей, а значит и меньше шансов отсидеться отсидеться в тишине. PEPEGROW дает 10%, а курс начнется во вторник.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
06.08.2021 13:08
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— GitHub’s Journey from Monolith to Microservices Гитхаб появился в 2008 как рельсовый монолит, а за последние 1.5 года компания увеличила штат инженеров в 2 раза. Ситуация стала отправной точкой, что бы компания начина миграцию на сервисы. В итоге ребята получили архитектуру с Twirp, кафкой (если правильно понял), отдельным authN/authZ сервисами и self-service runtime platform для деплоя. К сожалению, статья поверхностная. Но, понравилось что инженеры решили начать миграцию не с выноса кода в отдельные модули, а с разделения данных на отдельные базы данных. Что позволило определять cross boundaries вызовы для последующего рефакторинга. Кажется, что это важнейшая идея из текста, о которой забывают в других компаниях. Также, подтвердился личный опыт, что scientist помогает переключать трафик на новую часть кода с меньшей тревогой (если логика не меняется). И было бы интересно подробнее почитать больше о AuthN сервисе и почему монолит ходит в этот сервис через Twirp. ————————————— Architecting Modern Decentralized Applications Под dApp подразумевают приложения, работающие в децентрализованной системе (например поверх смарт контрактов). Кажется, что dApp подойдут в аукционах, идентификации пользователя, играх и около биржах. К сожалению, проектирование таких систем достаточно болезненно в виду того, что надо учитывать security, usability и decentralization со своими ограничениями и особенностями. А также думать о имутабельности данных. В статье приводится пример реализации 5 видов децентрализованных систем с кратким описанием, плюсами и минусами. Полный список видов выглядит следующим образом: - Fully Decentralized (The Pure Dapp) - Semi Decentralized (The common Dapp) - Semi Decentralized (The other common Dapp) - Semi Decentralized (Backend + Wallet) - Centralized (Backend + Centralized Wallet) ————————————— Building an Idempotent Event Consumer with Quarkus and Kafka Возникающий вопрос при проектировании асинхронных систем - как сделать идемпотентность для событий. Т.е. как сделать так, чтобы отправка одного события 2+ раза, каждый раз, приводила только к одному вызову консьюмера для события. Это необходимо, чтобы избежать проблемы дублирования данных, особенно когда дело касается денег. Текст начинается с описания ситуаций, в которых может возникнуть такая проблема, а причин три: ошибка консьюмера, ошибка message broker и ошибка сети. Дальше автор объясняет зачем нужна идемпотентность в асинхронных коммуникациях. А в качестве решения проблемы предлагает использовать логику, поверх уникального message id, таблицы со всеми message id и логики, которая проверяет сообщения на уникальность. Для большей наглядности - приводится пример основанный на Quarkus, MySQL и Kafka. Также, понравилось, что в конце найдете два альтернативных решения проблемы, описанных в другой статье.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
30.07.2021 13:07
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— A Reference Architecture for Responsive Asynchronous Task Execution Иногда, возникают ситуации, в которых вместо запрос-ответа приходится использовать асинхронное выполнение (async task execution). Очевидные примеры - процессинг больших файлов и(или) сложных вычислений, оплата из кучи шагов с долгими таймаутами, генерация больших отчетов. В статье, автор описывает вариант реализации архитектуры, которая не только создает асинхронные задачи, но и оповещает клиентов, когда задача выполнилась. Решение состоит из task API + message broker/queue для запуска задачи и вебсокет сервера, который отправляет статус по задаче в реалтайме клиенту. Понравилось, что в конце дается 3 идеи для улучшения (менеджмент задач, добавление прогресс бара и поллинг). Добавлю, что похожую стратегию можно использовать для синхронизации корзин между клиентами, а в системе сделать отдельный сервис для реалтайм нотификаций к клиентам (не только для отправки статуса задач), который будет слушать очередь/топик и работать как транспорт без бизнес логики. ————————————— 4 Key Observability Metrics for Distributed Applications Еще один пост с метриками, которые стоит добавить к приложению. Понравилась мысль в начале текста, в которой метрики делятся на Impact Data и Causal Data. Первые ответят на вопрос “who is being affected”, вторые на вопрос “what is being affected and why”. А метрики, которые стоит собирать выглядят так: Latency, Traffic, Error Rates и Saturation. Для некоторых метрик дается пример Impact Data и Causal Data. Например, для задержки это будет выглядеть так: Impact Data - отслеживание одного события на протяжении всей жизни. Causal Data - стоит еще отметить задержку между сервисами и чем больше контекста тем лучше. В конце статьи дается пример установки графаны, но главная ценность текста - виды метрик, которые стоит добавить в документ с описанием дефолтных метрик каждого из сервисов. ————————————— SHIFT Commerce’s Journey: Deconstructing Monolithic Applications into Services Ссылка, которую чаще всего использую по работе. Текст упоминался в канале, но это было 2 года, поэтому решил повторить. Нравится, что грамотно описана экстракция, которая начинается с продюсинга данных, после чего эти данные обрабатываются на пустом сервисе (без бизнес логики, только миграция данных в бд) и только после уже появляются бизнес логика и события. Важно понимать, что описанный подход можно сделать и без кафки, главная мысль текста - начинайте миграцию с данных и событий для стриминга данных, а не с кода и бизнес вызовов. Потому что в противном случае придется страдать с дампами и расхождением данных между монолитом и сервисом. Основываясь на опыте: описанный способ - безопасный вариант экстракции сервиса и данных из монолита. Понравились картинки, которые экономят время в момент объяснения подхода. Однозначный мастхэв для тех кто переходит с монолита на сервисы.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
23.07.2021 13:07
Вчера закончился мой больничный и я полностью восстановился (запахи вернулись, усталости больше нет). Это значит, что со следующей недели возвращаюсь в обычный ритм и возвращаю ссылки. Спасибо всем, кто желал здоровья
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
28.06.2021 10:06
Заболел модной болезнью, поэтому какое-то время постов не будет. Беру перерыв на время, пока не приду в себя.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
25.06.2021 13:06
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Decomposing the Monolith with Event Storming Event storming - личное открытие 2019 года, благодаря которому я могу либо уйти от модельного исследования системы к событийно/командной, либо выделить домены по бизнес процессам. В канале уже упоминались статьи об этом подходе, сегодня статья в которой приводится пример в виде семи шагов, которые помогают исследовать систему с помощью эвент шторминга. Кроме этого, понравилось, что автор описывает два заблуждения связанных с DDD и Design Thinking. ————————————— My Favorite Interservice Communication Patterns for Microservices Если простить о способах коммуникации между сервисами - вспоминаются синхронная и асинхронная. Поэтому, удивился, когда, в статье, кроме API calls и async event увидел еще два нестандартных способа. Первый - напрямую коммуницировать через сокеты, а второй - использовать “Lightweight events”, под которыми подразумевается микс из легких событий и API вызовов для шаринга данных. К сожалению, ни разу не видел, чтобы использовался подход с сокетами в продакшене (если у вас обратный опыт - с радостью почитаю отзыв или мнение о подходе). А в случае с Lightweight events - не хватило объяснения подхода, подробного примера, а также главного: ответа на вопрос “зачем” и почему не использовать два вида событий (стриминг данных + бизнес событие на вызов команды). Для каждого подхода дается краткое описание + pros/cons секции. А статью сложно назвать “обязательной”, но текст помог пофантазировать на тему “а что если?”. ————————————— Six Key Event-Driven Architecture Patterns Статья от infra dev в wix, где инженеры, через кафку, реализовают event-driven систему с 1400 сервисами. В тексте найдете описание шести паттернов, используемых в компании. Каждый из паттернов, в первую очередь, относится к кафке (но исключения присутствуют), а полный список выглядит следующим образом: - Consume and Project, который решает проблемы больших объектов в кафке с помощью ”materialized views”№; - Event-driven from end to end, который предлагает сделать websocket service для пашей на фронт о том, что асинхронная цепочка выполнилась; - Личный опыт: аналог паттерна также можно использовать в e-commerce, для синхронизации корзины между клиентами; - In memory KV store, который, используя compacted topics, реализует KV store без лишних баз данных (если есть кафка); - Schedule and Forget, который говорит о том, что если есть шедулер сервис, который вызывает нужный бизнес сервис, то в бизнес сервисе стоит сразу отправить событие в брокер, что бы потом его идемпотентно обработать. А в случае ошибки реализовать логику ретрая; - Events in Transactions, который говорит о том, как средствами кафки избежать дублирования событий в системе; - Events Aggregation, который говорит о том, как обрабатывать батч событий (например, когда надо распарсить файл, который отправляется батчем событий в кафку); ——— одной строкой ——— - Если хотели контрибьютить в psql - гайд с описанием первых шагов и идей для патчей
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
18.06.2021 13:06
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— How to Use Redis as an Event Store for Communication Between Microservices Event store хранит события в системе в определенном виде. Обычно используется в event sourcing для получения стейта за определенное время, например из постгреса, или для коммуникаций между системами (привет Кафка). В статье пример того, что для эвент стора можно использовать любую технологию, даже редис. Автор описывает опыт использования редис как персистенс слоя, который будет поддерживать порядок событий, быстрых операций на запись, высокий scalability и так далее. Для этого будет использоваться примитив streams и, в качестве примера, реализация OrderShop приложение. В самом тексте автор дает некоторые пояснения по коду (что делает каждый из тестов), а так же приводит пример пары запросов для получения данных. ————————————— Quality Attributes Лет пять назад я не понимал зачем думать о quality attributes, главное сделать приложения “чтобы работало”, а остальное излишне. Сейчас кволити атрибуты позволяют собрать не функциональные требования заранее, понять, в каком состоянии система и что стоит улучшить, определиться, где можно забить, а где стоит спроектировать систему детальнее, а также помочь “продать” решение бизнесу, если решение улучшает проседающий атрибут. К сожалению, запомнить все атрибуты сложно (а их много), поэтому статья оказалась в рассылке. В тексте найдете описание восьми групп, на которые разбиваются атрибуты. Понравилось, что для каждой из групп приводятся примеры. А после описания найдете два интересных подхода: Quality Attribute Scenario и Quality attribute tactic. Первый приносит стандартизацию в документирование атрибутов, а второй - описание плана улучшения (пример также найдете в статье). ————————————— Beginners Guide to Incident Postmortems Постмортемы позволяют разобраться в действительных причинах проблемы на свежую голову, а также помочь предотвратить похожие проблемы в будущем и собрать статистику о надежности частей приложения. К сожалению, в командах где я работал, практика написания постмортемов либо отсутствовала, либо не развивалась дальше «опишим инцидент через несколько дней». Также, темплейт постмортема вызывал долгие обсуждения и на это тратилось время. Поэтому сегодня статья с описанием пунктов, которые должны быть описаны в документации. Понравилось, что автор описывает когда использовать постмортемы (спойлер - для любого инцидента, но такой подход не всегда работает, о чем сказано в тексте). Здорово, что даются идеи для следующих шагов (как улучшить и как исправить быстрее), а также приводится список контрпродуктивных пунктов, которые стоит избегать. Если думаете о вводе подобной практики в компании и не знаете с чего начать - мастрид. Русский перевод
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
11.06.2021 13:06
Пятничное чтиво Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— Engineering dependability and fault tolerance in a distributed system Проектировать и реализовывать распределенные системы - сложно. Проектировать и реализовывать отказоустойчивые распределенные системы - невероятно сложно. В лонгриде рассматриваются подходы для обеспечения отказоустойчивость Ably. Понравилось, что в тексте даются определения из которых понятна разница между dependability, availability, reliability и fault tolerance. А также описывается связь между stateful/stateless и reliability/availability. А дальше описывается, что использовали инженеры Ably (спойлер - dynamic placement mechanism, выявление неполадок и channel persistence layer). А в конце описываются вопросы, которые могут возникнуть во время введения отказоустойчивости. Текст - однозначный мастрид, если появилась необходимость разобраться в теме. Русский перевод ————————————— The Endpoint Responsibility Checklist Еще одна ссылка “чеклист”, которая является рассуждением о том, что должен предоставлять фреймворк основанные на Clean API Architecture. Чеклист состоит из двух секций: base responsibility и write responsibility. А в конце показывается пример, как использовать чеклист для проектирования API. ————————————— Dealing with Chaos Продажный пост от компании flexera, в котором показывается как используя платформу визуализировать сервисы в системе. Для этого ребята используют 4 подхода как основу: Design First, Diagrams as Code, Static code analysis via “Chaos” и Service Map. Из подходов интерес вызывает “Chaos”, который помогает собрать API specs, readme файлы, чеки на “запахи” сервисов (например вызов из сервиса другого сервиса), а также наличие диаграмм и описания работы сервиса. Мне статья понравилась по двум причинам: - давно думаю о реализации “стратегической карты” для сервисов. Даже попробовал написать такой сервис, но в итоге забил, так и не найдя клиентов; - список подходов/инструментов может оказаться полезным, если возникли мысли “не понимаю, как сервисная система выглядит в компании”; ——— одной строкой ——— - Пример использования Event Storming для описания Subway - Notion выкатил API, поэтому появилась платформа для комментариев, основная на этом API
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Pepegramming
04.06.2021 13:06
Пятничное чтиво Завтра выступаю в питере с докладом о сагах, никакой хардкорности, зато будет музыка и шутки о шаверме. ссылка на стрим по конференции. Будет стрим конференции, так что можно посмотреть из дома. Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму. ————————————— The Outbox Pattern in Event-Driven ASP.NET Core Microservice Architectures Практическая статья с пошаговой реализацией outbox pattern-а в экосистеме дотнета. Сам паттерн автоматически стримит агрегаты в систему, через outbox table. Существуют готовые библиотеки, чтобы не реализовать паттерн самому, но кажется, что реализация руками практичнее в целях обучения (если интересно - можем на стриме сделать имплементацию для руби). Кроме реализации, в тексте найдете информацию, как тестировать паттерн, а также углубленные темы, например: Publisher Notify, Acknowledgments и Resilient Message Handling. ————————————— Ten Signs You Don’t Understand This “Microservices” Thing Переход на сервисы дорогое мероприятие, так как накладывает доп расходы на инфраструктуру и на экспертизу инженеров/архитекторов (и консультантов). К счастью, переход на сервисы может быть обусловлен только желанием отдельных людей и(или) “мы видели это у других и нам тоже поможет”. Чтобы избежать бессмысленной траты ресурсов - стоит также знать, когда останавливать переезд. Автор собрал список из 10 пунктов, которые, потенциально, могут сказать, что переход на сервисы будет плохой идеей. Спорные пункты присутствуют (например последний про ожидание конца), но полезные тоже есть (восьмой пункт о коммуникациях и четвертый, о выносе горизонтальных частей одного слоя). Для каждого пункта даются советы как задетектить проблему и почему стоит подумать о пункте. ————————————— Incremental Rewrites with GraphQL Во время работы в toptal я занимался проблемой ститчинга (объединения) схем из сервисов в общую схему. Тогда решалась проблема доступа с фронтенда к бэкенду, так как apollo client мог нормально работать только с одной схемой + верили, что apollo GQL gateway поможет предоставить единственную точку входа в систему. В итоге, toptal решил, что проще написать кастомный аналог GQL gateway (чем закончилась эпопея - не знаю, к сожалению). Кроме этого, была мечта использовать GQL ститчинг для выноса сервисов из монолитов, что описывается в статье. Для этого, ребята из khanacademy, также решили взять GQL apollo federation. При этом, кроме распила монолита разработчики хотели переписать систему с python2 на golang. В итоге, инженеры кастомизировали стандартный gateway добавив туда описание 4 режимов для простоты переезда с монолита на новые сервисы. Русский перевод
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме