Backstage: от Spotify до CNCF

Как Spotify пришёл к Backstage

В 2016 году в Spotify работало больше 200 инженерных команд, и каждая выбирала инструменты на своё усмотрение — часть знаменитой модели автономных «скводов». Свобода выбора давала скорость на старте, но породила то, что внутри компании называли rumour-driven development: единственный способ узнать, как что-то сделать, — спросить коллегу, который, возможно, знает. Документация была разбросана по десяткам систем. Каталога сервисов не существовало. Новые инженеры тратили недели, чтобы понять, какие сервисы существуют и кто за них отвечает.

Spotify начал строить Backstage как внутренний developer portal — единую точку входа для всей инженерной экосистемы. Каталог сервисов, шаблоны для создания новых компонентов, агрегированная документация, интеграции с CI/CD и мониторингом — всё в одном месте. К 2020 году Backstage охватывал более 2000 внутренних компонентов Spotify, и компания вынесла проект в open source.

Open source и путь в CNCF

Spotify открыл исходный код Backstage в марте 2020 года. В сентябре того же года CNCF принял проект в sandbox, а в 2022-м перевёл в incubation. По состоянию на 2025 год Backstage проходит аудит безопасности для перехода в статус graduated — высший уровень зрелости проектов CNCF.

Цифры проекта по данным CNCF и Spotify: более 3400 организаций-адоптеров, свыше 2 миллионов разработчиков используют Backstage, около 1600 контрибьюторов, 13 000 инженеров получили сертификацию Backstage (CBA). В 2023 году Backstage вошёл в пятёрку самых активных проектов CNCF по количеству коммитов. Среди пользователей — Airbnb, LinkedIn, American Airlines, Twilio, LEGO, Booking.com, Toyota.

Архитектура: три кита

Backstage строится вокруг трёх компонентов, и в эту архитектуру стоит вникнуть до начала внедрения.

Software Catalog

Каталог — сердце Backstage. Каждый сервис, библиотека, API, инфраструктурный ресурс, документация и даже команда описывается через YAML-файл catalog-info.yaml, который лежит в корне репозитория. Backstage читает эти файлы и строит граф зависимостей: какой сервис использует какой API, кто владелец, какие зависимости вверх и вниз по стеку. Открываешь страницу сервиса — и видишь CI-статус, документацию, связанные API, владельца, Kubernetes-деплойменты и алерты на одном экране.

Software Templates (Scaffolder)

Scaffolder — реализация golden paths. Шаблон описывается в YAML: какие параметры запросить у разработчика (название сервиса, язык, тип базы данных), какие файлы сгенерировать, какие действия выполнить (создать репозиторий в GitHub, зарегистрировать в каталоге, настроить CI-пайплайн). Разработчик заходит в раздел /create, выбирает шаблон «Backend Service on Node.js», заполняет форму, нажимает Create — и через минуту получает репозиторий с кодом, пайплайном, мониторингом и записью в каталоге. Вся конфигурация соответствует стандартам компании, потому что платформенная команда заложила эти стандарты в шаблон.

TechDocs

TechDocs — встроенная система документации по модели docs-as-code. Документация пишется в Markdown рядом с кодом (MkDocs-формат), а Backstage генерирует из неё страницы и показывает прямо в портале, на странице соответствующего сервиса. Обновляется при каждом мерже в main. Не нужно искать документацию в Confluence, Outline или корпоративной вики — она находится там же, где и вся остальная информация о сервисе.

Плагины: экосистема

Одна из причин успеха Backstage — плагинная архитектура. Ядро предоставляет каталог, шаблоны и TechDocs, всё остальное идёт через плагины. На 2025 год в экосистеме более 230 плагинов: интеграции с GitHub Actions, Argo CD, Grafana, Prometheus, PagerDuty, Trivy, Terraform, AWS, GCP. Связка Grafana + Prometheus даёт полное покрытие мониторинга: дашборды Grafana отображают метрики сервиса прямо на его странице в каталоге, алерты Prometheus видны в том же контексте. Trivy проверяет контейнеры, файловые системы и IaC-конфигурации на уязвимости, результаты подтягиваются в Backstage через плагин. Если нужной интеграции нет, Backstage предоставляет SDK для написания собственных плагинов на TypeScript и React.

Spotify также предлагает Spotify for Backstage — коммерческую версию с дополнительными плагинами, хостингом и поддержкой для enterprise-заказчиков.

Trade-offs: о чём молчат на конференциях

У Backstage есть серьёзные ограничения, о которых стоит знать до старта внедрения.

Порог входа высокий. Backstage — фреймворк, а не готовый продукт. На выходе получается набор строительных блоков, из которых собирается портал. Для первоначальной настройки и кастомизации нужны React-разработчики, для поддержки — выделенная платформенная команда. По отчёту TechTarget, даже сам Spotify продолжает дорабатывать Backstage.

Операционная нагрузка. Backstage нужно где-то хостить, обновлять, мониторить. Обновления ядра выходят часто, миграция между версиями требует работы. Плагины могут ломаться при обновлении ядра.

Плагины разного качества. Из 230+ плагинов часть поддерживается активно, часть заброшена. Перед тем как полагаться на плагин, стоит проверить дату последнего коммита и количество открытых issues.

Каталог требует дисциплины. Если команды не поддерживают catalog-info.yaml в актуальном состоянии, каталог превращается в устаревший справочник. Нужны автоматические проверки и скорекарды, которые отслеживают полноту и актуальность данных.

Когда Backstage — правильный выбор

Backstage хорош для организаций с 10+ инженерными командами, которые готовы инвестировать в платформенную команду из двух-трёх человек для настройки и поддержки портала. Если есть React-компетенции, экосистема из десятков сервисов и нарастающая проблема с discoverability — Backstage решает эти задачи лучше других инструментов. Если команд три и сервисов десять, лучше посмотреть на SaaS-альтернативы вроде Port в сравнении платформ или стартовать с вики и скриптов.