Harnessing the Universal Geometry of Embeddings (Рубрика #Security)

Буквально на днях я выступал на PHDays, рассказывая про надежность и безопасность как фундаментальную часть наших систем, отмечая новые риски от AI. Вроде модель угроз была мне относительно понятна, но вчера читая канал Сергея Николенко Sinекура (@sinecor), наткнулся на рассказ про whitepaper "Harnessing the Universal Geometry of Embeddings", в котором авторы буквально разработали метод vec2vec для трансформации векторов из одного пространства представлений (embeddings) в другое. Сергей дальше в своем посте объясняет последствия

Ничего вроде бы сверхгениального в самом методе нету, но качество результата поразительное: на рис. 3 показано, как пять почти ортогональных друг другу векторов превратились в векторы со скалярными произведениями от 0.8 до 0.95.

На практике это очень много чего значит, и в основном не очень хорошее. Получается, что базы данных, которые содержат векторные представления, надо защищать так же тщательно, как исходный текст (чего никто сейчас, насколько я понимаю, не делает). В одном эксперименте они взяли эмбеддинги корпоративных email'ов Enron, перевели их в пространство известной модели (рис. 4) и смогли извлечь чувствительную информацию (имена, даты, суммы) из 80% документов.

В общем, еще один интересный вектор атаки, только уже не на базы с оригинальными данными, а на векторные базы с embeddings. Может у меня дойдут руки и я почитаю этот whitepaper в ближайшее время:)

P.S.
Я подписался на канал Сергея Николенко после того, как написал отзыв на книгу "Глубокое обучение. Погружение в мир нейросетей" 2018 года, соавтором который был Сергей. Суть в том, что один из подписчиков канала сказал, что у автора есть прикольный tg-канал, я проверил - канал оказался действительно интересным и теперь я его иногда почитываю. Спасибо за эту рекомендацию!

#Security #AI #Software #Engineering #Database #Data

Microsoft Build 2025 | Satya Nadella Opening Keynote (Рубрика #AI)

На прошлой неделе Сатья Наделла, CEO Microsoft, открывал большую конференцию MS Build интересным keynote докладом, в котором подключались гости в виде Сэма Альтмана, Илона Маска и других. И вот ключевые моменты, что были в его выступлении

1. GitHub Copilot как автономный агент
GitHub Copilot эволюционировал в полноценного агентного помощника, способного самостоятельно выполнять задачи разработки: от добавления новых функций и исправления ошибок до рефакторинга и генерации документации. Он использует Model Context Protocol (MCP) для взаимодействия с внешними данными и инструментами, а также поддерживает мультимодальные входные данные, включая скриншоты и макеты.
2. Azure AI Foundry: более 1900 моделей и мультиагентная оркестрация
Платформа Azure AI Foundry расширена до поддержки более 1900 моделей, включая интеграцию с Grok 3 от xAI. Она предоставляет инструменты для создания и управления мультиагентными системами, позволяя разработчикам строить сложные ИИ-приложения с высокой степенью кастомизации.
3. NLWeb: открытый протокол для агентного веба
Представлен NLWeb — открытый протокол, позволяющий внедрять ИИ-интерфейсы на веб-сайты с минимальным кодом. Он поддерживает подключение к различным LLM и использует MCP для взаимодействия с контентом сайта, открывая путь к созданию "агентного интернета".
4. Windows AI Foundry: локальная разработка ИИ на Windows
Новая платформа Windows AI Foundry предоставляет инструменты для локальной разработки, оптимизации и развертывания ИИ-моделей на Windows и macOS. Она поддерживает интеграцию с MCP и обеспечивает доступ к системным функциям, таким как файловая система и WSL.
5. Copilot Studio и настройка агентов
Copilot Studio теперь позволяет создавать и настраивать ИИ-агентов, используя внутренние данные компании. Это включает в себя настройку поведения агентов, их взаимодействие с другими системами и поддержку мультиагентных сценариев.
6. Интеграция моделей Grok от xAI в Azure
Microsoft объявила о партнерстве с xAI, предоставляя доступ к моделям Grok 3 и Grok 3 mini через Azure AI Foundry. Это расширяет выбор LLM для разработчиков и снижает зависимость от OpenAI. Именно на этой новости подключался Илон:)
7. Открытие исходного кода Windows Subsystem for Linux (WSL)
Microsoft открыла исходный код ключевых компонентов WSL, включая wsl.exe и wslg.exe, под лицензией MIT. Это шаг к большей прозрачности и вовлечению сообщества в развитие инструмента.
8. MCP как стандарт взаимодействия
MCP становится ключевым стандартом для взаимодействия ИИ-моделей с внешними данными и инструментами. Он обеспечивает унифицированный способ подключения моделей к различным источникам данных и системам, включая Windows и Azure.
9. Microsoft Discovery: платформа для научных исследований
Представлена платформа Microsoft Discovery, использующая специализированных ИИ-агентов для управления научными исследованиями — от генерации гипотез до анализа результатов. Она предназначена для ускорения научных открытий и повышения эффективности исследований. Интересно, что у Google и OpenAI уже были такие платформы
10. Фокус на мультиагентных системах и их оркестрации
Microsoft делает акцент на разработке мультиагентных систем, где агенты могут взаимодействовать друг с другом для выполнения сложных задач. Copilot Studio и Azure AI Agents Service предоставляют инструменты для создания таких систем с возможностью делегирования задач между агентами.

Интересно, что после этого нас порадовал и Google со своей презентацией достижений народного хозяйства на Google I/O 2025

#AI #Software #Engineering

State of platform engineering in the age of AI (Рубрика #AI)

Интересный отчет конца 2024 года, который подготовлен компанией Red Hat совместно с исследовательским агентством Illuminas. Red Hat — мировой лидер в области корпоративных open source-решений, активно развивает платформенную инженерию и внедрение ИИ в инфраструктуру предприятий. Illuminas — опытная исследовательская компания, специализирующаяся на IT и B2B-рынках. Этот отчет построен на опросе 1000 инженеров платформ и IT-руководителей из США, Великобритании и стран Азиатско-Тихоокеанского региона.

Методология исследования была следующей
- Это был онлайн-опрос на 20 минут, где было 1000 респондентов (поровну инженеров и руководителей)
- 35% участников представляло средние компании, а 65% — крупные
- Участвовали сотрудники компаний из отраслей: IT, финансы, ритейл, здравоохранение, профессиональные сервисы
- География опроса: США, Великобритания, англоязычные страны APAC

Ключевые идеи и выводы опроса следующие
1. Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
2. Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.
3. Модель зрелости платформенной инженерии
Red Hat выделяет 4 уровня зрелости:
- Exploring - исследование
- Emerging - начало внедрения
- Established - устоявшаяся практика
- Advanced - продвинутый уровень
Компании с высокой зрелостью достигают на 41% лучших результатов (по продуктивности, инновациям, безопасности).
4. Основные драйверы внедрения
- Безопасность
- Улучшение взаимодействия между командами
- Автоматизация и ускорение процессов
5. Эволюция инвестиций
- На ранних этапах — фокус на модернизации инфраструктуры (55%)
- На продвинутых этапах — автоматизация (85%), безопасность (59%), инструменты для разработчиков (55%)
6. Проблемы и вызовы
На всех уровнях зрелости сохраняются сложности с интеграцией рабочих процессов и рисками безопасности (по 37%).
- На ранних этапах — нехватка навыков и бюджета (40%)
- На продвинутых этапах — несовместимость инструментов, нестабильность платформ, дефицит знаний (около 30%)
7. Метрики успеха
Зрелые компании отслеживают больше показателей (в среднем 7), включая продуктивность, безопасность, производительность приложений, удовлетворённость разработчиков. На ранних этапах чаще фокус на снижении затрат.

Если подводить итоги отчета, то можно заключить, что
- Платформенная инженерия становится отдельной профессией, требующей новых навыков и командной структуры.
- Компании и вендоры должны интегрировать ИИ в платформенные решения, а не рассматривать ИИ как отдельный инструмент.
- Стандартизация архитектур и best practices ускоряет внедрение и снижает риски.
- Безопасность и автоматизация — ключевые приоритеты для будущего развития.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Code of Leadership #39 - Interview with Denis Pakhomov about social platforms (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Денис Пахомов, который является техническим руководителем в управлении разработки социальных платформ. Возглавляет 14 команд, которые разрабатывают социальную платформу и два продукта на её основе: Пульс и Линк. Команды e2e делают бэкэнд сервисы, мобильные SDK и продуктовые интеграции в клиентские поверхности. Собственно, с Денисом мы поговорили про его путь в IT, а также про развитие социальных сервисов внутри Т.

За час мы обсудили следующие темы
- Знакомство с гостем, обсуждение его биография и старта карьеры
- Переезд в Москву и работа в Сбербанке
- Переход в Тинькофф: работа над маркетинговыми проектами
- Проблемы, новый модуль и его задачи
- Рост команды и управленческие изменения
- Переключение на развитие соцплатформ и объединение команд
- Архитектурные процессы и формирование продукта
- Интеграция решений, внутренняя соцсеть и гибридизация мобильных и веб-платформ
- Культура, структура команд и видение социальных механик
- Роль менеджера, вызовы и советы по развитию

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)

Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней

1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа
Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей.
2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса.
3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием.
4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга.
5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды.
6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно".
7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества.
8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы.
9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса.
10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.

В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD

P.S.
Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).

#QA #DevOps #Process #Software #Engineering #AI

ArchDays 2025 - CFP (Рубрика #Architecture)

Этой осенью пройдет уже 7 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры.

В общем, если планируете стать спикером, то вам сюда.
А если вы планируете прийти послушать, то уже можно покупать билеты:)

P.S.
Я выступал на всех предыдущих конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:)
1) "Эволюция web’а tinkoff.ru за последние 3 года" в 2019 (youtube)
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" в 2020 (youtube, статья с расшифровкой)
3) "System Design Interview как проверка навыков проектирования систем на собеседованиях" в 2021 (youtube, статья с расшифровкой)
4) "Как подготовиться и пройти System Design Interview" в 2022 (youtube, статья с расшифровкой)
5) "Публичное интервью по System Design про бронирование отелей" в 2022 (youtube, статья с расшифровкой)
6) "Публичное интервью по System Design про простую a/b платформу" в 2023 (youtube)
7) "Архитектура в Т-Банке: вчера, сегодня, завтра" в 2024 (youtube, статья с расшифровкой)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Гибридный поиск на базе OpenSearch и Qdrant / Егор Прохоренко (Рубрика #Architecture)

Интересное выступление моего коллеги, Егора Прохоренко, руководителя отделя поисковых технологий, про гибридный поиск в Т. Гибридный он потому, что Егор и его ребята смешали стандартный полнотекстовый поиск OpenSearch и векторную базу Qdrant для семантического поиска по embeddings. А как они это делали и для чего можно узнать из доклада, в котором были примерно следующие моменты

1. Проблематика поиска в банке
Поиск нужен как клиентам (мобильные приложения, продукты, статьи), так и сотрудникам (внутренние базы, мессенджер, GitLab). В компании достаточно разветвленная инфраструктура - более 100 источников данных и сравнительно высокая нагрузка (1 млн DAU, 150 RPS), много индексов.
2. Концепция гибридного поиска
Гибридный поиск сочетает классический полнотекстовый поиск и векторный (на основе близости эмбеддингов). Это позволяет находить релевантные документы, даже если в них нет прямого совпадения по ключевым словам.
3. Векторные базы данных и их особенности
Векторные БД (например, Qdrant) решают задачу поиска ближайших соседей ANN (Approximate Nearest Neighbor) и часто используют графовый алгоритм HNSW (Hierarchical navigable small world). Хранят вектора и метаданные, поддерживают фильтрацию и масштабирование.
4. Архитектура реализации гибридного поиска
Архитектура делится на слои
- L1 — базовый индекс OpenSearch
- L2 — ML-ранжирование (Catboost)
- L3 — бизнес-логика
Векторный поиск реализован как отдельный сервис, что позволяет быстро экспериментировать и не мешать основному поиску.
5. Эволюция реализации: от монолита к микросервисам
- Первая попытка — интеграция ANN-модуля в монолит на C++ (Elastic), не дала прироста метрик, были проблемы с производительностью.
- Вторая попытка — вынесение векторного поиска в отдельный Python-бэкенд (FastAPI, Qdrant), затем переписан на Rust для ускорения.
6. Фасетная фильтрация и ограничения векторного поиска
В полнотекстовом поиске фильтрация реализуется легко, в векторном — сложно. Пришлось реализовать пост-фильтрацию и комбинированные подходы для отбора релевантных документов.
7. Кеширование эмбеддингов
Для ускорения поиска и снижения нагрузки на эмбеддер реализовано агрессивное кеширование (до 98% cache-hit, 20 млн векторов в кеше).
8. Дообучение моделей и использование пользовательских данных
Для повышения релевантности дообучают эмбеддеры на данных о кликах и релевантности из логов поиска, используют ContrastiveLoss.
9. Объединение результатов полнотекстового и векторного поиска
Проблема была в разных шкалах: BM25 для полнотекста и косинусная близость для эмбеддингов. В качестве решения пробовали разные схемы: нормировка BM25, трафаретные схемы, обучение Catboost-ранжировщика на обоих факторах (это показало лучшие результаты).
10. Масштабирование и ограничения
Гибридный поиск хорошо работает для коротких документов и длинных запросов, снижает число пустых выдач. Для больших документов требуется деление на чанки, поиск идеального решения пока в процессе. Гибридный подход улучшил метрики, но требует сложной архитектуры и постоянных экспериментов.

В качестве вывода можно отметить, что гибридный поиск на базе OpenSearch и Qdrant позволяет повысить полноту и качество поиска, но требует глубокого понимания архитектуры, постоянной оптимизации и доработки моделей ранжирования.

P.S.
Я уже расскаывал про интересный обзор возможностей векторных баз данных, что был в докладе на goto конференции 2024 года "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias". Этот рассказ хорошо дополняет рассказ Егора.

#Architecture #Software #Engineering #ML #AI #DistributedSystems #SystemDesign

Разработка собственного AI-ассистента для кода: спринт или марафон? (Рубрика #AI)

Недавно у нас прошла конференция Platform Engineering Night, которую открывал Игорь Маслов докладом про "AI и Platform Engineering", основные мысли из которого я уже рассказывал. Но на этой конфе еще был целый ряд выступлений, одно из которых было Дениса Артюшина, который рассказал про то, как мы разрабатываем собственного ассистента Nestor, под которым зонтиком объединяются copilot вещи для SDLC (но первым делом copilot для кода в IDE). Основные мысли выступления были примерно следующими

1. В чем мотивация создания собственного ассистента?
Начал Денис с объяснения, а зачем делать своего ассистента, где были несколько основных моментов
- Безопасность решения, что сложно соблюсти при отправке кода внешним вендорам
- Санкционные риски, которые защкаливают в текущих сложных геополитических условиях
- Необходимость интеграции с внутренней инфраструктурой, которую так и так пришлось реализовывать
2. Как подходить к вопросу: как спринтер или как стайер?
Сначала Денис рассказал про быстрые эксперименты в режиме спринтеров - так ребята запустили commit-сообщения, где от идеи до готового прототипа прошел один вечер пятницы. Схема была простой: берем diff, добавляем примеры, формируем промт и отдаем в модель. А потом он рассказал, что code completion требует серьезной инфраструктуры с A/B-тестами, анализом поведения пользователей и поиском похожего кода в кодовой базе, то есть тут нужен системный и размеренный подход
3. Что умеет Nestor?
Основные фичи сейчас достаточно классические
- Автодополнение кода
- Чат с поиском по внутренней документации
- Генерация commit-сообщений
- Прототип редактирования кода
- Генерация тестов (сейчас в разработке)
4. Какие метрики использования у ассистента?
Они уже впечатляют: WAU: 5k, MAU: 9.5k. В некоторых профессиях проникновение превысило 60%, а acceptance rate поднялся до 30% на Go (пора переходить на go, ведь ассистенты на нем лучше всего ассистируют 😉)
5. Как сделали поиск по документации?
На самом деле про поиск можно посмотреть в докладе Егора Прохоренко, про который я уже рассказывал. Но в Nestor пошли примерно так: структурированная документация → краткие описания → эмбеддинги → поисковая база. Также использовали русскоязычную модель TP Pro для лучшего качества ответов.
6. Как решали проблему масштабирования UI в плагине для IDE?
Первоначальные чаты на TypeScript/CSS и Swing оказались немасштабируемыми. Перешли на React и Compose позволил легко добавлять новую функциональность.
7. Как балансировать тем в команде разработки?
Спринты помогают тестировать гипотезы и поддерживать мотивацию олимпиадников в команде (значимая часть команды Nestor - это олимпиадники по программированию). А вот марафоны нужны для создания качественного продукта.
8. На какие метрики качества обращают внимание?
Метрики есть разные
- Adoption Nestor
- Acceptance rate (очищенный от мусорных показов)
- Внутренние бенчмарки для поиска по документации
- Пользовательский фидбек и предложения по улучшению.
9. Какие планы по развитию?
Планов много, но сейчас они видятся такими
- Полноценное редактирование кода
- Генерация тестов
- Платформа агентов для всех отделов компании
- Интеграция в другие продукты экосистемы (платформа для работы с данными Helicopter, observability платформа Sage)

Если подводить итоги и отвечать на вопрос в названии доклада, то создание собственного ассистента требует сочетания быстрых экспериментов (спринты) для проверки гипотез и системной работы (марафоны) для качественного продукта.

#AI #Software #Engineering #Architecture #Agents

Modular Monolith: Is This the Trend in Software Architecture? (Рубрика #Architecture)

Интересный и короткий whitepaper на тему модульных монолитов, который задает вопрос насчет их трендовости. Авторы статьи сделили Systematic Grey Literature Review (SGLR) для анализа этого вопроса. По-факту, это анализ материалов, не прошедшие коммерческое академическое издание (отчёты ведомств и НКО, диссертации, доклады конференций, технические спецификации, preprint-репозитории, сайты проектов и т. д.). Они пытались понять насколько распространены модульные монолиты, стратегически сочетающие простоту разработки традиционных монолитов с преимуществами масштабируемости микросервисов, предлагая альтернативу, избегающую сложностей распределенных систем при сохранении модульных принципов. Вопрос был в том, а сможет ли modular monolith стать жизнеспособным компромиссом, дающим "лучшее из двух миров".Исследование мотивировано анонсом фреймворка Service Weaver от Google, позволяющего писать приложения как модульные монолиты с возможностью микросервисного деплоя. Интересно, что сам Service Weaver от Google и ответил на этот вопрос - с 6 июня он отправится в архив, не достигнув нужного уровня adoption.

Но если возвращаться к самому whitepaper, то авторы пытались показать, что modular monolith обеспечивает:
- Сохранение скорости разработки, характерной для монолитов
- Четкие границы модулей, предотвращающие эволюцию в "big ball of mud"
- Гибкость использования как самостоятельной архитектуры или промежуточного этапа перед микросервисами
- Упрощение процессов отладки и тестирования
- Эффективное масштабирование команд через распределение модулей

Из исследования литературы они выделили следующие ключевые характеристики модульных монолитов
- Segregation of modules: независимые модули с собственными слоями (Domain, Infrastructure, API)
- Modularity: слабая связность и сильная связность внутри модулей, асинхронная коммуникация через API
- Unified Database Schema: единая схема БД вместо отдельных схем на сервис
- Monolithic Deployment: все модули работают в рамках одной VM или распределены по выделенным VM
- Unified Application Process: единый процесс приложения для всех масштабов
- Enhanced Maintainability: измеримое улучшение поддерживаемости vs традиционные монолиты

В самом исследовании отмечалось, что известнейшими компаниями с модульными монолитами являются Shopify, Appsmith, Gusto, PlayTech, правда, они не использовали Service Weaver.

P.S.
Если отходить от самого whitepaper и оценить проблемы, что привели к закрытию Service Weaver, то можно отметить следующие
1) Низкий adop­tion rate - по-факту, это написано на странице проекта в аргументации к его закрытию

We realized that it was hard for users to adopt Service Weaver directly since it required rewriting large parts of existing applications. Therefore, Service Weaver did not see much direct use, and effective December 5, 2024, we will transition Service Weaver into maintenance mode.

2) Только go стек, что сужало целевую аудиторию
3) Опасность абстракций, когда локальный вызов может внезапно стать RPC (remote procedure call) - этим weaver напоминал концепцию CORBA/RMI, которая еще 20 лет назад показала свою непрактичность
4) Недостаточная функциональность - в фреймворке не было готовой маршрутизации/retries как в service mesh, нет встроенной mtls, нет удобного мониторинга
5) Конкуренция внутри самого Google Cloud - большинство кейсов, где weaver помогал пользователи уже решали через Cloud Run, GKE Autopilot + Istio или Functions, то есть им было проще использовать привычный стек, чем учить новую CLI и TOML-конфиги Weaver

Итого, интересная идея не полетела из-за того, что не набрала критической массы пользователей, а также не предложила ответа на концептуальные вопросы вида local/remote procedure calls и их неполное соответствие друг друга в плане НФТ при разных видах deployments. Но для любителей модульных монолитов остались фреймворки вида Spring Modulith.

#Architecture #Whitepaper #DistributedSystems #SystemDesign #Software #Engineering

Research Insights Made Simple #10 - Measuring Developer Experience With a Longitudinal Survey (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject

За 40 минут мы успели обсудить следующие темы

- Опыт Google в проведении опросов
- Преимущества и процесс проведения опросов
- Методология и анализ опросов
- Важность коммуникации и внедрения изменений по итогам опросов
- Роль менеджера и сменяемость ролей в команде
- Масштабирование и частота опросов
- Продуктовый подход и интеграция онлайн-опросов
- Двухсторонний анализ: опросы и логи

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Я разбирал этот whitepaper раньше в своем tg канале в двух частях: 1 и 2

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.

#AI #Software #Engineering #Architecture #Agents

[1/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Последний месяц я потихоньку читаю книгу Zhiyong Tan, что посвящена system design interview и в виде перевода выпущена издательством Питер. Книгу я решил прочесть из интереса, чтобы сравнить с тем подходом, который близок мне и про который я рассказывал и долгое время развивал у нас внутри компании.
TLDR; книга мне показалась полезной и понравилась, причем больше, чем книга Alex Xu, про которую я тоже рассказывал.

Начнем с того, что автор, Zhiyong Tan, сейчас engineering manager в Paypal, а до этого был senior fullstack инженером в Uber, data инженером в небольших стартапах, а также инженером в Teradata. В общем, этот опыт позволил ему посмотреть на вопросы проектирования решений и найма сотрудников в компаниях разного масштаба и уровня зрелости. Сама книга поделена на три части:
1) Первая часть состоит из 6 глав и содержит стрктурированное введение в system design interview - про эту часть мы поговорим ниже подробнее
2) Вторая часть содержит 11 примеров system design задачек
3) В приложениях есть сравнения монолитов и микросервисов, базовыый разбор OAuth 2.0 и OpenID Connect, рассказ про C4 Model, а также разбор того, как устроен двух-фазный коммит. В принципе, все эти темы так или иначе могут быть затронуты на собеседовании

Дальше я расскажу про первые шесть глав, которые показались довольно здравыми

1. A walkthrough of system design concepts
В первой главе автор вводит базовые понятия system design, знакомит с ключевой терминологией и объясняет, что system design - это про дискуссию вокруг компромиссов, на которые надо пойти при проектировании решения:) Дальше автор быстро и по верхам рассазывает про масштабирование различных сервисов, начиная с маленькой инсталляции приложения и накручивая сверху GeoDNS, кеширование, CDN, горизонтальное и вертикальное масштабирование, управление кластерами, разделение на функционально-независимые части. Интересно, что автор разбирает историю про работу с аналитическими данными (ETL), выделение общих сервисов, а также размещение рабочих нагрузок на bare metall, cloud или вообще внутри FaaS:) В общем, большая часть этих блоков может быть раскрыта в отдельную главу, если не книгу, но автор дает неплохое общее представление о самих концепциях

2. A typical system design interview flow
Здесь автор описывает типичный процесс system design interview, акцентируя внимание на важности уточнения требований до начала проектирования. Особое внимание уделяется разделению functional и non-functional requirements. Интересно, что я как-то с ребятами из клуба {между скобок} разбирал flow собеседования, предложенный в книге Alex Xu, а также сравнивал с тем, что принято в Т. Если говорить подробнее про содержание главы, то тут идет речь про
- Уточнение требований
- Создание драфта спек API
- Связь пользователей и данных
- Моделирование моделей данных
- Обсуждение логгирования, мониторинга и алертинга (я часто это оставляю на финал собеседования)

Продолжение обзора первой части книги в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

[2/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Продолжая рассказ про книгу о system design, расскажу про оставшиеся четыре главы первой части.

3. Non-functional requirements
Эта глава целиком посвящена нефункциональным требованиям, которые часто называются архитектурными характеристиками ("-ilities") или атрибутами качества. Автор отдельно разбирает такие штуки как scalability, availability, fault-tolerance, performance/latency и throughput, consistency, accuracy, maintainability, cost, security, privacy, cloud native. Интересно, что я много раз рассказывал про НФТ или "-ilities", например с теми же ребятами из {между скобок} мы как-то разбирали работу с архитектурными характеристиками. Ну и недавно у меня был обзор whitepaper "Quality Metrics in Software Architecture" в трех частях: 1, 2 и 3.

4. Scaling databases
Эта глава целиком посвящена том, а как жить с состоянием, которое надо где-то хранить. В system deisgn задачах обычно эта stateful часть одна из самых интересных и она требует умения ее масштабировать и отвечачть на вопрос, а как обрабатывать сотни миллионов пользователей и миллиарды запросов. Здесь автор рассказывает про репликацию и шардирование, аггрегацию событий, батчинг и стриминг. Дальше наступает время денормализации и кеширования, где обсуждаются разные техники кеширования, инвалидации кешей, а также их прогрева. Рекомендую почитать книгу "Database Internals", про которую я рассказывал в двух частях: storage engines и distributed systems.

5. Distributed transactions
Целая глава посвящена распределенным транзакциям, хотя двух-фазный коммит вынесен в приложение и автор рассказывает о спрособах избежать распределенных транзакций. Для этого он говорит про крупные темы вида
- Event driven architecture и event sourcing - интересно, что эту тему отличо разбирает Влад Хононов в книге ""Learning Domain-Driven Design", я даже делал обзор этой темы в виде статьи в своем блоге.
- CDC - описание как отливать изменения из баз данных, используя условный Debezium
- Использование супервизоров транзакций, а также использование саг (оркестрируемых и хореографируемых)
В общем, интересная глава, но короткая - для реального понимания затронутых тем придется почитать книги поглубже

6. Common services for functional partitioning queue
В этой главе автор рассказывает про общую функциональность, что нужна сервисам:
- Аутентификация, авторизация, шифрование
- Проверка ошибок: валидация, дедубликация
- Производительность и надежность: опять кеширование, rate limiting
- Логгирование и аналитика
Дальше идут паттерны для декомпозиции вида service mesh (istio) и sidecars, service discovery, использование библиотек для общей функциональности или вынос сервисов. Ну и финализируется все обсуждением API, которое автор начинает с рассказа про модель OSI, а дальше идут стандартные REST, RPC, GraphQL, WebSocket и их сравнения.

В общем, в первой части излагаются важные концепции, которые полезны не только на собеседованиях, но и в практической работе:) Структурированный подход к работе с требованиями, анализу trade-offs и принятию архитектурных решений помогает в реальных проектах. Особое внимание автор книги уделяет коммуникации и зрелости инженеров — умению объяснять решения, обсуждать компромиссы, адаптироваться к изменяющимся требованиям. Эти качества важны для взаимодействия с другими командами и бизнес-стейкхолдерами.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering