29 февраля в гостеприимном Санкт-Петербурге на Saint P Ruby Meetup Winter 2024 рассказал про запущенный проект "Аутентификации об монолит" (слайды и видео-запись)

💡Идея в том, чтобы дать возможность новым микро-сервисам обслуживать аутентифицированный трафик, и разблокировав реализацию новых фичей в обособленном сервисе (а не в монолите).

1️⃣Входящий трафик аутентифицируем "об монолит" отдельным запросом
2️⃣Заменяем оригинальные аутентификационный заголовки - внутренним X-Auth-Identity, в котором содержится результат аутентицикации
3️⃣Оригинальный запрос снабжаем аутентификационными данными (UUID пользователя)

На первый взгляд решение костыльное: поскольку изначально вся логика аутентификации находится в Rails-монолите, то и предлагаемое решение завязано на монолит. В этом смысле как будто ничего не меняется!

Но нет же! Можно еще хуже: пустить трафик в новый сервис через монолит, делегировав ему предварительную аутентификацию и роль API-гейтевея!

С такой перспективы все неплохо, тем более что предложенное решение:
- позволяет быстро абстрагироваться от монолита (как будто его вовсе нет)
- за счет унификации API на базе кастомных HTTP-заголовков не противоречит дальнейшему переходу к обстоятельному системному решению (чем обычно грешат временные схемы)

Более того, на личном опыт подтверждаю, что схема рабочая, как для запуска, так и для дальшейшего расширения в системное решение!

А сам подход универсальный, и может быть применен для монолитной архитектуры любого стека. Хотя в докладе добрая половина времени уделена специфике Rails-монолита.

Ссылку на слайды и видео-запись прилагаю.

В книге "Staff Engineer: Leadership beyond the management track" Уилл Ларсон классифицирует роли стаффов по выполняемым задачам (в зависимости от особенностей и потребностей компании), выделяя 4 базовых архетипа:

1️⃣Tech Lead (технический эксперт): ведет проекты и команды, обеспечивая техническое руководство, сотрудничая как с командами так и с их менеджментом.

Может заниматься:
- принятием ключевых архитектурных решений и помощью в выборе технологического стека.
- развитием навыков других инженеров через наставничество и обучение
- обеспечением высокого стандарта разработки и его оптимизацией

2️⃣Architect (архитектор): отвечает за направление и качество архитектурных подходов к критически важной области системы. Имея глубокую техническую экспертизу и учитывая запросы бизнеса и пользователей, проектирует гибкую, масштабируемую и устойчивую архитектуру.

Может заниматься:
- созданием, поддержкой и актуализацией технической документации систем
- анализом и управлением техническими рисками при проектировании системы
- умелым балансированием между скоростью продуктового развития и тяжестью техдолга
- помощью разработчикам в понимании и внедрении архитектурных решений


3️⃣Solver (спецназ): глубоко погружается в сложную проблему и находит подходящий путь ее решения. Некоторые сосредотачиваются на определенной области в течение длительного времени (например выделяют сервисы из монолита 😉). Другие перемещаются из одной горячей точки в другую, руководствуясь приоритетами компании.

Может заниматься:
- исследованием узких мест в архитектуре, интеграции, коде систем с целью выявить слабые места
- выработкой возможных вариантов решения и их практической валидацией
- глубокой проработкой плана и его реализацией


4️⃣Right Hand (правая рука): оказываем помощь и поддержку руководителю команды в управлении, а так же консультирование по ключевым решениям.

Может заниматься: практически всем


🤔На мой взгляд стафф/принципал - роль очень гибкая, а решаемые задачи в первую очередь обусловлены потребностью компании.
На практике, ярко-выраженный стабильный архетип из списка для конкретного инженера выявить не получится, скорее это будет смешение разных вариантов, причем в разных пропорциях в зависимости от компании/отдела, ситуации и даже времени. Себя эпизодически вижу в каждой из категорий.

💡Дополнительно кратко отмечу ряд отличительных моментов работы стаффа/принципала, которые, по моему мнению, являются общими вне зависимости от архетипа:
- менторство: помощь коллегам в развитии, обучение (лекции, доклады, семинары), а так же поддержка команд в решении сложных задач
- исследования: прототипирование и отчетность, data-driven подход
- пропоганда: решений, технологий, участие в сообществе, формирование мнений

🖐 У меня в детстве была игровая приставка, реплика Dendy (хотя Dendy сама по себе тоже реплика приставки Nintendo), с которой начался опыт гейминга. Дальше немного видеоигр, которые удавалось запустить на тормозном Пентиуме. Когда появились свои деньги и возможность купить мощное железо - интереса уже не было.

Такой скудный опыт не позволил своевременно погрузиться в игровую культуру, и до недавнего времени я об этом совсем не думал, пока случайно не включил в машине аудиокнигу "Игродром: что нужно знать о видеоиграх и игровой культуре" Александра Вертушинского.


❓Автор с академической точки зрения подошел к вопросу изучения игр, систематизировал исторические этапы развития и их ключевые особенности. А дальше в социально-культурном, антропологическом и философском контексте исследовал развитие игр в динамике.


💣Это разрыв шаблона (у не играющего человека)! Книга о взаимном влиянии техники и технологий на множество аспектов жизни (культура, психология, экономика, социальные взаимоотношения, образование и этика) и в другую сторону. Книга не техничекая, но технарям зайдет!

Только из первой главы вы узнаете множество интересного:
- кто такой Марио (Super Mario) и как появился Pac-Man
 - почему в футболе расположение поля горизонтальное, а в хоккее - вертикальное
- как в России появилась Dendy (грустно)
- как фантазия геймеров дополняла геймплей в стародавние времена


🔥️️️️️️Горячо рекомендую всем инженерам! Если желаете отдохнуть от технического чтива, или послушать аудио в дороге.


#Games  #Reading #NonTechnical

👋 Привет!

2 октября прошла долгожданная оффлайн конференция RubyRussia, на которой я рассказывал о разработке и стандартизации платформенных решений на Ruby в Купере. Платформенная разработка весьма специфична, в первую очередь потому, что пользователи конечного продукта - разработчики.

Запись доклада стала недавно ограниченно доступна на youtube, rutube, а так же прилагаю слайды.

По большей части доклад не технический, и не только про Ruby: принципы справедливы для языкоспецифичной части платформенной разработки на любом стеке.

В докладе обобщены и освещаются следующие темы:
- принципы разработки платформенного тулинга
- жизненный цикл платформенных разработок
- тестирование платформенного тулинга
- источники формирования беклога платформенной команды

Приятногно просмотра! Буду рад вопросам, предложениям и обратной связи в треде.

🖐Всем привет!

📣 С радостью аннонсирую контент по-существу канала! Вышла первая часть моей статьи о стафф-инженерах.
В основе статьи десяток интервью с моими коллегами - стафф/принципал инженерами Купера.

Из статьи вы узнаете:
1️⃣кто такие staff-инженеры
2️⃣какие задачи они решают
3️⃣какие ожидания у менеджмента от этой инженерной позиции

Статья написана с фокусом на карьерный рост и будет полезна senior-разработчикам.
Забегая вперед, скажу, что на следующей неделе выйдет ее продолжение с практическими советами куда и как развиваться в эту роль.

Приглашаю погрузиться в контекст, и разобраться, кто он - стафф инженер по ссылке.

Жду ваших комментариев, отзывов и предложений тут или на Хабре!

Привет! 🤚

Месяц назад мы частью команды Ruby-платформы Купера собрались в Московском офисе, чтобы вместе поработать над изучением проблемы OSS реализации GRPC-сервера для Ruby, которую мы используем.

🎬 И сняли из этого реалити-шоу, в стиле "один день из жизни..." 


За день получилось:

 - обсудить разные варианты и подходы к решению
 - собрать их "на коленке"
 - провести нагрузочное тестирование
 - сравнить результаты
 - выложить исследования на Github
- и сходить на обед с коллегами 🙂

А еще договорились онлайн с руководителем отдела о выкатке в фикса в продакшен.


На мой взгляд получилось интересно и содержательно, приоткрывает завесу "тайны" вокруг платформенной разработки и процессов в компании.

Приглашаю к просмотру на Youtube 🍿 и жду ваших преложений и комментариев!

🖖 Рубрика "Что почитать технарю".

Неделю назад дочитал художественную книгу Нила Стивенсона "Криптономикон". И пребываю в полном восторге, отчего хочу порекомендовать подписчикам!

Представьте, если бы Квентин Тарантино написал фантастический визионерский экшен-роман на основе исторических событий второй мировой войны, фокусируя внимание на завинчивающейся спирали противостояния и развития криптографии (шифровальная машина "Энигма") и криптоанализа (дешифровка сообщений), проводя параллели с современностью (1999 год), в которой увлеченные криптографией потомки участников войны строят IT-стартап в духе "Цифровой рай". Технические моменты автор поясняет мастерски вплетенными в повествования графиками и схемами.

Повествование сдобрено тонким чувством юмора, некоторые идеи даже спустя 25 лет удивляют, а сюжет настолько закручен, что ни страницы не будет скучно!

🧑‍💻Эта книга от технаря, о технарях и для технарей!
Перед тем, как решится на ~1000-страничное чтиво, рекомендую статью-обзор книги на Хабре.

Меня, книга навела на банальную мысль, о том, что "Война - это двигатель прогресса", и IT-индустрия и развитие компьютеров - тому подтверждение; а еще погрузила в исторический контекст развития криптографии.

Теперь хочу сходить в музей-криптографии, как буду в Москве. Кто был в музее, или читал книгу - поделитесь, пжс, впечатлениями.

#Reading #NonTechnical

На прошлой неделе посетил конференцию RustCon.

Язык Rust для меня - хобби. Мне нравится новизна заложенных концепций (ownership, borrowing). Местами он похож на Ruby (еще больше на C, который я учил студентом).

💡Внутри популярных Ruby-библиотек часто скрывается код, написанный на C. В основном это специфические гемы для решения определенных задач:
- эффективные структуры данных (murmurhash)
- профилировщики и дебаггеры (stack-prof, byebug, ruby/debug)
- cpu-bound задачи: парсинг, сериализация (pg_query, nokogiri, oj, json, puma (парсинг http1.1))
- шифрование и криптография (bcrypt, digest-crc, xxhash)
- функциональные биндинги к С-библиотекам (karafka-rdkafka, grpc)
- низкоуровневые библиотеки, базирующиеся на системных вызовах (semian)
- клиенты для бд (pg, mysql2)

😡С появлением Rust - некоторые низкоуровневые вещи начинают писать на нем. Я провел небольшое исследование зависимостей Ruby-монолитов в Купере. Итоги:
- ~450 зависимостей
- 34 - используют под капотом С
- 3 - используют Rust (prometheus-client-mmap, pact-ffi)

Дополнительно в Ruby-экосистеме есть:
- packs - аналог фреймворка модуляризации Packwerk
- artichoke - альтернативная MRI-совместимая имплементация Ruby
- поддержака создания ruby-гема с Rust-кодом (статья)


Пока не выглядит как тренд замещения внутренностей Ruby-гемов кодом на Rust, но лед тронулся!

На эту тему на конференции был классный доклад, о переводе cpu-bound задач c Python на Rust, где автору местами удалось достигнуть ускорения x3 (пока доступны только слайды).

Пару кварталов назад наша команда занималась декомпозицией API.

Вынос бизнес-логики из монолитного приложения и ее локализация в ограниченных контекстах ведут к выделению более целостных и идиоматичных API (в противовес монолитным, где данные из различных предметный областей перемешаны воедино). Вместо одного удобного энд-пойнта "обо всем" логично появляется несколько независимых.

С другой стороны, не всегда есть возможность мигрировать на новый API по ряду причин:
- сложности в обновлением клиентов (например мобильное приложение)
- невозможность отключить старых клиентов (если их много)
- потенциальное замедление клиента (вместо одного запроса с нужной информацией - нужно делать несколько запросов в разные сервисы)

При этом поддержка совместимости API со старыми клиентами выглядит как тех. долг, который на мой взгляд разумно вынести на BFF (backend for frontend), реализовав композицию новых энд-пойнтов для совместимости старых клиентов.
Это не очень типовой сценарий использования BFF, ведь обычно концепцию применяют для композиции API, а в случае в выделением сервисов - это декомпозиция (надо разобрать старый энд-пойнт на запчасти, каждая из которых получается из отдельного сервиса).

Чтобы процесс был безопасным мы применили Strangler-паттерн, сравнивали результат работы декомпозированной системы с легаси. Это дало возможность постепенно доводить новый функционал до ума, и плавно выкатываться без ущерба для продакшена.

С таким фокусом на надежность, требовалось очень много бойлерплейт-кода, по манипулированию трафиком и расчетом метрик "совпания/точности" (о которых я рассказывал в статье). Поэтому коробочное решение нам не подходило (в индустрии используется Krakend). И мы приняли решения писать композицию вручную.

Поскольку работа предполагалась на нескольких эндпойнтах, мы допилили OSS решение со странглер-паттерном, для поддержки композиции, описанной через DSL.

Получилось удобно: более гибко, чем конфигурировать композицию в манифесте (например в Krakend), но при этом достаточно стандартизованно, чтобы строить унифицированные метрики композиции.

⁉️Но делать композицию вручную - решение частное (и дорогое), и не может быть масштабировано на всю компанию (иначе каждая команда будет делать это по своему).

📦После всех работ, когда все стабилизировалось, планируем мигрировать на стандартное коробочное.

Несмотря на то, что предстоит еще раз все переделать (а код частично пойдет на выброс), эта история скорее успешная, потому, что:
- декомпозирован монолитный API-легаси системы, и случился безопасный и постепенный разьезд на сервисы (при сохраненном API)
- мы получили опыт работы с композицией (в каком-то смысле композиция - это антипаттерн, т.к. в результате получаем сильную связность), и как ее варить, чтобы система не была подвержена каскадному сбою

🙄О полученном опыте расскажу в след посте, но прошу Вас в комментарии выбрать, что более Вам более интересно:
1️⃣каким принципами нужно руководствоваться, чтобы композиция не превратилась в ад
2️⃣подробней, почему решили делать самописное на первом этапе и какие нюансы
3️⃣как и за счет чего композиция позволила ускорить эндпойнты в x3

Привет! Прочитал и рекомендую книгу "Изучаем OpenTelemetry: современный мониторинг систем" (далее OT - OpenTelemetry). Особенно, если:
- вы планируете работать над развитием наблюдаемости в своих сервисах
- вы занимаетесь разработкой библиотек
- занимаетесь платформенной разработкой и стандартизацией
- проектируете инфраструктуру под сбор телеметрических данных
- или в вашей компании поддерживается несколько несвязанных друг с другом инструментов (для сбора метрик/логов/трейсов/ошибок и тд), например Sentry vs OpenTracing

Отмечу несколько моментов, которые меня заинтересовали:

1️⃣Авторы рассказывают о концепциях современной телеметрии, как и куда развивается стандарт OpenTelemetry и для чего он нужен. Для меня откровением стала масштабность решения. К примеру, OpenTelemetry заточен не только под сбор трейсов (раньше это был OpenTracing), стандарт гибкий позволяет в перспективе перейти на сбор метрик и логов одинаковым способом. Это определенное новшество, ведь обычно это делается по-разному. Делать по разному визионеры OT называют "текущим положением дел", намекая, что мы уйдем от этого 😄

2️⃣Авторы описывают архитектуру сбора телеметрии (трейсы, логи, метрики), точнее сказать возможные варианты архитектур, которые можно построить на базе стандарта (OT Collector). Стандартизации протокола с коллектором (приемник метрик) позволяет строить различные пайплайны сбора, фильтрации и агрегации данных.

3️⃣Отдельная глава посвящена инструментированию (организации сбора телеметрии из кода) библиотек и приложений, и как его лучше готовить. Авторы сетуют на пока еще небольшой процент поддержки OSS-библиотеками OT.
Как один из разработчиков общего платформенного тулинга - подтверждаю, и платформе приходится посполнять этот пробел.

Авторы (они же и участники движения OT) делают огромную работу, чтобы привести большинство библиотек базовых OT-библиотек разных стеков к общему знаменателю (к примеру, унифицированные настройки через одинаковые ENV-переменные).


💡Я раньше считал, что наблюдаемость библиотеки - это дополнительная фича, которую стоит реализовать в отдельно, заложив возможность расширения поведения, например, через механизм Middleware (промежуточный слой). На деле же рекомендуется делать сбор трейсов нативно, прямо из кода библиотеки. Именно для этого вся OT-инструментация во всех стеках при подключении не активириется по-дефолту (это тоже стандарт). Такой подход снимает массу проблем (зависимости, неактуальности, изменения, актуализация).

4️⃣Отдельная глава посвящена демонстрационной системе, состоящей из нескольких сервисов, иллюстрирующей OT в действии. Запустив все в докере одной командой - можно поэкспериментировать с телеметрией, посмотреть дэшобрды с метриками, логами и трейсами, а так же комбинацией фича-флагов симулировать внештаную ситуацию в системе, чтобы понять как наблюдаемость помогает ее отобразить.

За OT однозначно будущее, потому что:
- системы становятся сложней и нужна интроспекция, чтобы понимать как все работает
- повсеместно используются различные приложения/сервисы/форматы. OT призвана стандартизовать формат. К примеру, Sentry уже поддерживает OT
- при этом стандарт не накладывает органичений на способы применения телеметрии, а скорее помогает. К примему, вы возможно захотите использовать ML для выявления коллеряций и прогнозирования. Или строить архитектурные диаграммы, соответствующие продакшену. Стандарт здесь помогает

⁉️Поделитесь в комментариях опытом работы с телеметрией/трейсингом, как у вас в компании обстоят дела, какие есть сложности, или кейсы когда телеметрия выручала 🙏

🖐 Всем привет! Давно не виделись!

Я без познавательного контента. Зато с вакантным билетом на конференцию Let's GoConf, которая состоится уже скоро - 12 сентября 2025.

Не сочтите за рекламу - мы его сейчас разыграем!

Билет получит первый, кто расскажет в комментарии курьезный случай из свой практики разработки на Golang, что-нибудь с пустым интерфейсом, забытым замыканием или неправильными использование каналов (тут я не помощник - вы сами все знаете! 😉), и как это заафектило продакшен!


А если курьезов не было - то есть просто скидка 20% на билеты по промокоду salakhutdinov!

Работа клеем (being glue/glue work)

Замечали ли Вы, что делаете множество нетипичной и неинженерной работы, без которой успех проекта не случится, например:
- перевести с инженерного на продуктовый язык
- разрешить затянувшееся противостояние мнений в код-ревью или по архитектурным вопросам
- пофасилитировать встречу и добиться на ней результата
- сформулировать общее понимание/виденье, или написать статью, чтобы систематизировать и распространить знания

В статье "Being Glue" Таня Рейли дала такой работе название "glue work" - "работать клеем".

Это малозаметная,работа на стыке: людей и архитектур, команд и процессов, бизнеса и технологий, которая скрепляет команду и проектную работу воедино. Она важна хотя бы потому, что:
1️⃣ любой крупный проект требует координации множества людей. Без "клеевой" работы проекты распадаются на изолированные части, не стыкующиеся друг с другом (работа клеем неизбежна)
2️⃣ это эффективный способ масштабировать работу. К примеру, Вы провели звонок и устранили блокер для дальнейшей работы. ЭТо позволило целой группе инженеров работать продуктивно (force multiplication)
3️⃣взяв организационные и коммуникационные преграды на себя, вы позволяете другим инженерам войти в состояние «потока» и сосредоточиться на сложной технической работе, создав для них возможность войти в поток (creating flow)

⁉️Автор настаивает, что это не "менеджмент на минималках", а полноценная инженерная дисциплина, требующая глубоких технических знаний для принятия верных решений. Являсь необходимой частью успеха любого проекта, "работа клеем" зачастую остается незамеченной и не оцененной, не фиксируется как "приносимая результат", не используется на перформанс-ревью как аргумент.

Парадокс в том, что хороший исполнитель подобной работы рискует попасть в ловушку (the glue trap) - навсегда стать закрепленным за этой ролью. Менеджмент воспринимает его как "человека, решаюшего проблемы" (как Мистер Вульф из Криминального Чтива), и всю такую работу автоматически делегируют ему. Отчего инженер перестает заниматься глубокой инженерной работой (deep technical work), теряет навыки и техническую экспертизу, а вместе с ней — и свой авторитет, который и позволял ему эффективно заниматься клеевой работой.

Чтобы разорвать этот порочный круг, автор рекомендует

❓Инженерам:
- вести свой дневник клеевой работы (glue journal), фиксировать что сделано и на что повлияло. Дневник превратит невидимую работу в видимую, поможет представить ее прозрачной и понятной. На эту есть классный доклад.
- частично делегировать работу клеем мидлам, чтобы развивать их и не концентрировать скилл решения проблем в одних руках и разгрузить себя
- не позволять работе клеем занять все ваше время - стоит резервировать время под грубокую инженерную работу в том числе
- приоритезировать, а не просто реагировать на все подряд. Спросить себя "Какая деятельность максимально приблизит нас к стратегическим целям?"

❓Управленцам:
- повышать прозрачность такой работы, формулировать ее явно и признавать. Например обсудить на 1-1 какую клеевую работу проделал инженер, и что из этого можно задокументировать?
- включить в критерии карьерного роста - продвигать необходимость явной оценки glue-work наравне с техническими достижениями
- защищать время инженера - ограждать время для глубокой работы, взяв на себя часть организационного давления

Далее в своей книге (The Staff Engineer's Path), Таня приходит к выводу, что это не случайная дополнительная нагрузка, а основной инструмент воздействия staff-инженера. А ключ к успеху - управлять ею стратегически, делая видимой и обеспечивая баланс с технической работой, не попадая в ловушку. А не проcто ее делать 🤔

Что думаете о работе клеем? Часто ее делаете? Фиксируете где-то? Как повышаете ее прозрачность? Расскажите в комментариях 🙏