Backstage: от Spotify до CNCF

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

В 2016 году у Spotify работало больше 200 инженерных команд, и каждая из них выбирала инструменты на своё усмотрение — это было частью знаменитой модели автономных «скводов». Свобода выбора давала скорость на старте, но создала проблему, которую внутри Spotify называли 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, Google Docs или Notion — она находится там же, где и вся остальная информация о сервисе.

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

Одна из причин успеха Backstage — плагинная архитектура. Ядро проекта предоставляет каталог, шаблоны и TechDocs, а всё остальное — плагины. На 2025 год в экосистеме более 230 плагинов: интеграции с GitHub Actions, Argo CD, Datadog, Grafana, PagerDuty, Snyk, Terraform, AWS, GCP. Если вашей интеграции нет — 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 в сравнении платформ или начните с wiki и скриптов.