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 собирал все схемы в федеративный граф, и фронтенд консоли делал запросы к одной точке, которая делегировала их нужным сервисам. GraphQL Federation в Netflix к тому моменту активно использовалась для продуктовых 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-инструменты, боты в корпоративном чате и специализированные дашборды. Команда PXD подчёркивала: платформенный API стал самостоятельным продуктом, консоль лишь один из его потребителей.

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

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

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

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

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

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

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