r3tam blog

Backstage и Internal Developer Portals в 2026: создание IDP с нуля

9 мин. чтения

Backstage и Internal Developer Portals в 2026: создание IDP с нуля

Введение

Разработчик приходит в новую команду. Ему нужно развернуть микросервис, настроить CI/CD, подключить мониторинг, получить доступ к БД и — оформить документацию. Вместо того чтобы написать код, он проводит три дня за чтением вики-страниц, конфигурированием YAML-файлов и поиском того, кто владеет нужным кластером Kubernetes. Знакомая ситуация?

По данным Gartner за 2026 год, более 80% организаций, занимающихся разработкой ПО, уже имеют выделенные платформенные команды, а 75% предоставляют разработчикам порталы самообслуживания. Платформенная инженерия (Platform Engineering) перестала быть экспериментом — это стандарт индустрии. В центре этого стандарта лежит Internal Developer Platform (IDP), а главным инструментом для её построения стал Backstage — open-source фреймворк, созданный Spotify и переданный CNCF.

В этой статье мы разберём, что такое IDP, почему Backstage стал де-факто стандартом, как его внедрить и какие альтернативы существуют на рынке в 2026 году.

Что такое Internal Developer Platform

Internal Developer Platform (IDP) — это слой самообслуживания, который абстрагирует сложность инфраструктуры и тулчейна, сохраняя за разработчиками контроль и гибкость. В отличие от традиционного подхода, где разработчик открывает тикет в Ops и ждёт, IDP позволяет получить ресурс или развернуть сервис через понятный интерфейс за минуты.

Ключевые компоненты IDP

Современная Internal Developer Platform включает несколько взаимосвязанных слоёв:

  • Портал разработчика — интерфейс, через который разработчики обнаруживают сервисы, запрашивают ресурсы и управляют приложениями. Каталог сервисов, шаблоны и документация — всё в одном месте.
  • Слой абстракции инфраструктуры — бэкенд, который транслирует запросы разработчика в конфигурации облачных API, Kubernetes и CI/CD-пайплайнов.
  • Golden Paths — предварительно сконфигурированные, «золотые» пути, которые проводят разработчика через лучшие практики без необходимости изучать каждый инструмент отдельно.
  • Безопасность и комплаенс — автоматические проверки, гарантирующие, что каждый развёрнутый сервис соответствует политикам организации.

IDP vs традиционный DevOps

Эволюция от DevOps к Platform Engineering — это не замена одного подхода другим, а его закономерное развитие. Если в классической модели «You build it, you run it» каждый разработчик должен был разбираться в Kubernetes, Terraform, Prometheus и десятке других инструментов, то IDP берёт эту когнитивную нагрузку на себя. Разработчик продолжает отвечать за свой код, но инфраструктурные вопросы решает платформа.

| Аспект | Традиционный DevOps | Platform Engineering |

|--------|-------------------|---------------------|

| Доступ к инфраструктуре | Ad-hoc, через тикеты | Самообслуживание через портал |

| Стандартизация | Индивидуальная настройка команд | Golden Paths и шаблоны |

| Безопасность | Ручные ревью | Автоматические guardrails |

| Онбординг | Вики и «спроси коллегу» | Централизованная документация |

| Скорость | Зависит от команды | Предсказуема через платформу |

Backstage: архитектура и ключевые возможности

Backstage — это open-source фреймворк для построения Internal Developer Portal, созданный Spotify и принятый CNCF в статусе инкубирующего проекта. По данным Spotify, более 2 600 компаний уже используют Backstage в своих организациях. В 2026 году экосистема насчитывает более 244 активных плагинов, а само решение стало стандартом де-факто для построения порталов разработчика.

Архитектура

Backstage построен на модульной архитектуре, где каждый функциональный блок — это плагин. Ядро фреймворка состоит из:

  • Frontend-приложения на React, которое обеспечивает пользовательский интерфейс.
  • Backend-сервисов (techdocs-backend, catalog, scaffolder), реализующих бизнес-логику.
  • Базы данных (PostgreSQL) для хранения метаданных.
  • Системы аутентификации, интегрируемой с корпоративным IdP.

Каждый плагин регистрируется на своём URL и может как предоставлять собственный UI, так и расширять существующие возможности через Utility APIs.

Software Catalog

Каталог сервисов — это сердце Backstage. Каждый компонент описывается YAML-файлом, который хранится вместе с кодом в репозитории:

# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Сервис обработки платежей
  tags:
    - go
    - microservice
  annotations:
    github.com/project-slug: myorg/payment-service
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout

Каталог автоматически отслеживает владельцев, зависимости, жизненный цикл и статус каждого сервиса. Это устраняет проблему «сервисов-призраков», о которых никто ничего не знает.

Software Templates (Scaffolder)

Шаблоны — это killer feature Backstage. Разработчик заполняет форму в UI, и Backstage автоматически создаёт репозиторий с настроенным CI/CD, Dockerfile, манифестами Kubernetes и конфигурацией мониторинга. Время на создание нового микросервиса сокращается с дней до минут.

Spotify называет это «Golden Paths»: правильный способ разработки становится самым простым. Не нужно помнить, какой шаблон для GitHub Actions использовать — Backstage сам его подставит.

TechDocs

TechDocs реализует подход «docs-as-code»: документация пишется в Markdown, хранится вместе с кодом в репозитории и автоматически публикуется в портале. Интеграция с MkDocs генерирует статические HTML-файлы, которые кешируются в облачном хранилище (S3, GCS, Azure Blob). Больше никаких устаревших wiki-страниц.

Плагины

Экосистема плагинов Backstage покрывает практически все потребности современной разработки:

  • Инфраструктура: Kubernetes, AWS, GCP, Azure
  • CI/CD: GitHub Actions, GitLab CI, Jenkins, Tekton
  • Observability: Grafana, Prometheus, Datadog
  • Безопасность: Snyk, SonarQube, зависимые сканеры
  • Инциденты: PagerDuty, Opsgenie
  • Управление затратами: облачные бюджеты, FinOps-дашборды

Сценарии внедрения Backstage

Open Source: полный контроль

Классический сценарий — самостоятельное развёртывание Backstage. Вы получаете полный контроль над кодом, данными и инфраструктурой. Однако это требует выделенной команды: как минимум два инженера, которые будут поддерживать экземпляр Backstage, обновлять его и разрабатывать внутренние плагины.

Плюсы: безлимитная кастомизация, отсутствие вендор-лока, полный контроль над данными.

Минусы: высокий порог входа, затраты на поддержку, время до первого value — от 3 до 6 месяцев.

Spotify Portal: Backstage as a Service

В 2024 году Spotify запустила коммерческий продукт — Spotify Portal. Это Backstage «из коробки»: облачное托管 с no-code настройкой, автоматическими обновлениями и встроенными плагинами (Soundcheck для проверки качества, AI-ассистент, RBAC).

Плюсы: мгновенный старт, минимальные операции, встроенные enterprise-функции.

Минусы: ограниченная кастомизация, зависимость от вендора, стоимость при масштабировании.

Roadie: Managed Backstage

Roadie — третья опция: managed-хостинг Backstage от стороннего провайдера. Вы получаете тот же open-source Backstage, но без необходимости управлять инфраструктурой. Roadie берёт на себя обновления, бэкапы и мониторинг.

Пошаговое руководство по запуску Backstage

Шаг 1. Установка

npx @backstage/create-app@latest --name my-company-portal
cd my-company-portal
yarn dev

Эта команда создаёт полноценный Backstage-проект с предустановленным Software Catalog и базовыми плагинами.

Шаг 2. Настройка аутентификации

Backstage поддерживает GitHub OAuth, GitLab, Google, OIDC и SAML. Конфигурация задаётся в app-config.yaml:

auth:
  environment: production
  providers:
    github:
      development:
        clientId: ${AUTH_GITHUB_CLIENT_ID}
        clientSecret: ${AUTH_GITHUB_CLIENT_SECRET}

Шаг 3. Наполнение каталога

Backstage автоматически сканирует репозитории GitHub/GitLab и регистрирует сервисы, в которых найден catalog-info.yaml. Достаточно добавить файл в корень репозитория — и сервис появится в каталоге.

Шаг 4. Интеграция плагинов

Плагины устанавливаются через Yarn:

yarn add --cwd packages/app @backstage/plugin-kubernetes
yarn add --cwd packages/backend @backstage/plugin-kubernetes-backend

После добавления в конфигурацию плагин появляется в боковом меню портала.

Шаг 5. Создание шаблонов

Шаблоны описываются YAML с указанием шагов: какой репозиторий создать, какие файлы сгенерировать, какой CI/CD настроить. Шаблоны хранятся в том же Git-репозитории, что и код Backstage.

Альтернативы Backstage

Backstage — не единственное решение на рынке. В 2026 году сформировались три основных подхода:

Port — SaaS-платформа

Port — коммерческий SaaS, который предлагает готовый портал разработчика «из коробки». В отличие от Backstage, не требует написания кода для интеграций — всё настраивается через UI или API. Гибкая модель данных, встроенные scorecards и workflow-автоматизация делают Port привлекательным для организаций, которые хотят получить результат за дни, а не месяцы.

Когда выбирать: нужна быстрая отдача, нет выделенной платформенной команды, приоритет — time-to-market над кастомизацией.

Cortex — платформа качества инженерии

Cortex фокусируется на метриках качества, scorecards и операционной видимости. Если Backstage — это витрина сервисов, то Cortex — это система управления качеством. Она показывает CTO и VP of Engineering, какие сервисы соответствуют стандартам, а какие требуют внимания.

Когда выбирать: главный приоритет — operational excellence и compliance.

Сравнение

| Характеристика | Backstage | Port | Cortex |

|---------------|-----------|------|--------|

| Модель | Open-source (CNCF) | SaaS | SaaS |

| Каталог | YAML-определения | Гибкая модель данных | Авто-обнаружение |

| Шаблоны | Scaffolder | Self-service actions | Scaffolder |

| Scorecards | Через плагины | Встроенные | Встроенные, мощные |

| Кастомизация | Неограниченная | Через конфигурацию | Через конфигурацию |

| Затраты на старт | Free + инженеры | Per-user | Per-user |

Практические рекомендации

Начинайте с малого

Самая частая ошибка — попытаться внедрить Backstage сразу на всю организацию с сотней плагинов. Spotify начинал с семи человек в команде. Выберите одну команду-пилота, решите её конкретную проблему (например, «не можем найти, кто владеет сервисом») и расширяйтесь постепенно.

Автономия команд

Backstage спроектирован так, чтобы команды сохраняли владение своими плагинами и данными. Используйте Code Owners — каждая команда отвечает за свой раздел портала. Это масштабирует платформу без роста центральной команды.

Измеряйте adoption

Внедрение IDP — это не технический, а культурный проект. Измеряйте:

  • Процент сервисов, зарегистрированных в каталоге
  • Количество заявок на инфраструктуру через портал (снижение тикетов)
  • Время онбординга новых разработчиков
  • Developer Satisfaction Score (DevEx)

Безопасность с первого дня

Интегрируйте проверки безопасности в Golden Paths. Каждый новый сервис автоматически проверяется на уязвимости зависимостей, соответствие политикам секретности и корректность конфигурации сети.

Заключение

Internal Developer Portals на базе Backstage — это не просто тренд, а необходимый инструмент для организаций, которые хотят масштабировать разработку, не теряя в скорости и качестве. В 2026 году платформенная инженерия стала мейнстримом, и Backstage — главный инструмент для её реализации.

Начинать можно с малого: Software Catalog для видимости сервисов, шаблоны для новых проектов, TechDocs для документации. Постепенно платформа обрастает плагинами и интеграциями, превращая хаос микросервисной архитектуры в управляемую экосистему.

Выбор между Backstage Open Source, Spotify Portal или коммерческой альтернативой вроде Port или Cortex зависит от размера команды, потребностей в кастомизации и бюджета. Но общая логика неизменна: платформа должна делать правильный путь разработки самым простым.

FAQ

Что такое Golden Paths в контексте IDP?

Golden Paths — это предварительно сконфигурированные, одобренные пути разработки, которые делают правильный подход самым простым. Например, шаблон для нового микросервиса включает настройку репозитория, CI/CD, Kubernetes-манифестов и мониторинга. Разработчик получает готовую основу и пишет только бизнес-логику.

Сколько стоит внедрение Backstage?

Backstage как open-source проект бесплатен. Затраты складываются из инфраструктуры (сервер, PostgreSQL), времени платформенной команды (рекомендуется минимум два инженера) и расходов на интеграции. Spotify Portal продаётся по подписке, Roadie — managed-хостинг с помесячной оплатой.

Backstage или Port: что выбрать?

Если у вас есть платформенная команда и потребность в глубокой кастомизации — выбирайте Backstage. Если нужно запустить портал за неделю без кода — выбирайте Port. Гибридный подход (Port для быстрого старта, Backstage для масштабирования) также распространён.

Нужен ли Kubernetes для Backstage?

Нет, Kubernetes не обязателен. Backstage — это Node.js-приложение, которое можно запустить где угодно: на виртуальной машине, в Docker или в Kubernetes. Однако в продакшене рекомендуется использовать Kubernetes для масштабирования и управления.

Как Backstage интегрируется с существующими инструментами?

Через плагины. На сегодняшний день доступно более 244 open-source плагинов для интеграции с GitHub, GitLab, Jenkins, ArgoCD, Datadog, PagerDuty, AWS, GCP, Azure и сотнями других инструментов. При необходимости можно написать собственный плагин на TypeScript.

Хотите углубиться в тему? Прочитайте нашу статью о Platform Engineering в 2026, а также ознакомьтесь с официальной документацией Backstage на backstage.io.