Netflix: Federated Platform Console

Фрагментация, которая росла вместе с компанией

Netflix славится культурой свободы и ответственности: компания даёт инженерам широкие полномочия и ожидает от них самостоятельных решений. Платформенная команда из примерно 150 человек обслуживает всё инженерное сообщество, а 80 из них занимаются developer productivity: владеют сборкой, тестированием, CI, управлением зависимостями и общим опытом разработки.

Со временем эта свобода породила предсказуемую проблему — ту, которую решают внутренние платформы разработчика. Инженер Netflix за день переключался между Bitbucket (код и pull requests), Spinnaker (деплой), Jenkins (сборки), внутренними дашбордами алертинга и ещё десятком специализированных тулов. Каждый инструмент делал свою работу хорошо, но вместе они создавали когнитивную нагрузку, которую Brian Leathem из команды PXD описал на PlatformCon 2022: разработчики тратили время на навигацию между инструментами вместо написания кода. Новые сотрудники с трудом осваивали ландшафт инструментов, а опытные инженеры иногда не знали о существовании полезных платформенных сервисов, которые могли бы ускорить их работу.

Решение: федеративная консоль

Команда Platform Experiences and Design (PXD) выбрала стратегию, которая отличается от подхода Spotify. Вместо того чтобы строить монолитный портал с плагинами, Netflix поставил на федерацию на трёх уровнях: API, UI и дизайн.

На уровне API команда использовала GraphQL Federation. Каждая доменная команда (CI, деплой, алертинг, мониторинг) поднимала свой граф-сервис, который выставлял данные через GraphQL-схему. Единый gateway собирал все эти схемы в федеративный граф, и фронтенд консоли делал запросы к одной точке, которая делегировала их нужным сервисам. Netflix уже активно использовал GraphQL Federation для своих продуктовых API, поэтому команда PXD взяла проверенную технологию вместо того, чтобы изобретать новую.

На уровне UI команда взяла Backstage как основу. Они не стали писать портал с нуля, а адаптировали open source фреймворк Spotify под свои нужды. Доменные команды писали UI-компоненты для своих сервисов и встраивали их в консоль.

На уровне дизайна Netflix применил внутреннюю дизайн-систему Hawkins и Figma-библиотеку, чтобы все части консоли выглядели единообразно, даже если их создавали разные команды.

End-to-end workflows как ключ к adoption

Первые версии консоли страдали от проблемы холодного старта. Команда PXD собрала портал, наполнила его информацией, но инженеры продолжали ходить в привычные инструменты напрямую. Зачем открывать новый портал, если Spinnaker и так работает?

Leathem рассказал на PlatformCon 2023, как они решили эту проблему: вместо отдельных виджетов для каждого инструмента команда начала строить сквозные workflows, которые проходили через несколько доменов. Например, workflow «создание нового сервиса» включал генерацию репозитория, настройку CI-пайплайна, регистрацию в service mesh, создание алертов и деплой в staging. Раньше инженер делал все эти шаги вручную в пяти разных инструментах. Теперь консоль вела его через весь процесс в одном интерфейсе.

Этот подход дал уникальную ценность, которую ни один из отдельных инструментов предоставить не мог. Инженеру стало выгодно приходить в консоль, потому что она экономила реальное время на реальных задачах.

Архитектурные решения и trade-offs

Федеративная модель Netflix имеет сильные и слабые стороны.

Сильная сторона: доменные команды сохраняют полную ответственность за свои данные и бизнес-логику. Команда CI не зависит от команды PXD в вопросах, как представлять данные о сборках. Каждая команда развивает свой граф-сервис в своём темпе, а gateway подхватывает изменения.

Вторая сильная сторона: инвестиция в GraphQL-федерацию окупается за пределами консоли. Тот же API используют CLI-инструменты, Slack-боты и специализированные дашборды. Команда PXD подчёркивала, что платформенный API стал самостоятельным продуктом, а консоль лишь один из его потребителей.

Слабая сторона: федерация создаёт проблему координации. Когда десять доменных команд выставляют свои схемы, конфликты в именовании, несогласованность типов данных и разная степень зрелости API становятся повседневной реальностью. Netflix справляется с этим через schema registry и процесс ревью схем, но это дополнительная нагрузка на инженеров.

Ещё один trade-off: Netflix строит консоль силами относительно небольшой команды PXD, которая зависит от готовности доменных команд инвестировать время в интеграцию. Если команда алертинга не видит ценности в консоли, её инструменты там не появятся. Leathem решал эту проблему через «доказательство ценности»: PXD сама делала первую интеграцию, показывала рост adoption, и после этого доменная команда подхватывала поддержку.

Сравнение с подходом Spotify

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

Подход Spotify проще для начала: плагинная архитектура Backstage хорошо документирована, есть open source экосистема. Подход Netflix лучше масштабируется, когда доменные команды уже имеют зрелые инструменты и не готовы переписывать их как плагины.

Рекомендации

Федеративная модель Netflix подходит организациям, где платформенные команды владеют зрелыми инструментами с собственными API. Если у вас такая ситуация, начните с GraphQL-федерации: пусть каждая команда выставит свой граф, а вы соберите единый gateway. Дальше стройте один end-to-end workflow (самый болезненный, который сегодня требует пяти переключений контекста) и покажите ценность. Не пытайтесь объединить все инструменты сразу. Выберите два-три самых востребованных и постройте workflow вокруг них. Остальные добавите, когда инженеры начнут приходить в консоль по привычке.