Backstage — управление микросервисным ландшафтом без хаоса

Представьте: в вашей компании уже не десятки, а сотни микросервисов. Новый разработчик приходит в команду и первую неделю тратит не на код, а на поиски. «Где лежит этот API?», «Как запустить этот сервис локально?», «Кому писать, если он падает?». Каждая команда изобретает свои велосипеды для документации, а общие инструменты превращаются в разрозненную коллекцию закладок в браузере.

Но проблема не только в онбординге. По мере роста компании растет «когнитивная нагрузка». Разработчик вынужден держать в голове десятки ссылок на CI/CD, дашборды, баг-трекеры и Wiki — вместо написания кода он переключается между контекстами.

Как фронтенд-инженер, я часто сталкивался с этим сам. Вместо того чтобы писать код, начинаешь расследование: «Как мне запустить этот бэкенд локально?», «Почему в документации три версии API?», «Кто владелец этого сервиса?» — ответы теряются в чатах, а время уходит в никуда. Знакомая ситуация? Уверен, что да.

Именно поэтому, когда я впервые увидел Backstage, сразу понял — «вот оно!». Backstage — это open-source платформа для создания внутреннего портала разработчика, изначально созданная в Spotify и переданная в CNCF (Cloud Native Computing Foundation). Open-source версия доступна с 2020 года, и за это время платформа успела доказать свою зрелость в тысячах компаний.

Это не просто очередная админка, а единая операционная система для вашей инфраструктуры, которая делает работу с ресурсами простой и предсказуемой. Давайте разберемся, как она работает и почему я считаю, что Backstage — это инструмент, который стоит рассмотреть каждой растущей инженерной команде.

Почему Backstage — это больше, чем просто внутренний портал

На первый взгляд может показаться, что проблема «много сервисов и нет порядка» решается обычной Wiki-страницей или таблицей в Confluence. Но практика показывает: статическая документация устаревает быстрее, чем ее успевают обновлять, а ссылки разлетаются по чатам и теряются.

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

Вот лишь несколько задач, которые Backstage решает прямо «из коробки»:

• Поиск и обнаружение. Вместо вопроса в общий чат «Кто автор этого сервиса?» разработчик открывает каталог, видит владельца, ссылку на репозиторий, документацию и текущий статус сборки — всё в одном месте.

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

• Снижение порога входа. Новый разработчик перестает тратить первую неделю на «разбор полетов». Он заходит в портал, видит, какие сервисы есть, как они связаны, и может локально запустить нужный через готовую документацию.

• Управление жизненным циклом. Backstage помогает отслеживать устаревшие версии библиотек, сервисы без владельца или те, которые давно не деплоились. Это превращает поддержку экосистемы из реактивной в проактивную.

Именно эти возможности делают Backstage не просто «еще одной админкой», а единой точкой входа для всей инженерной деятельности. Теперь давайте разберем, на каких трех принципах строится эта платформа.

Три кита Backstage

Backstage организует порядок через три ключевые функции:

1. Каталог компонентов (Software Catalog): Сердце платформы. Это автоматически обновляемый реестр всех ваших сервисов, библиотек, сайтов и ресурсов. В отличие от гугл-таблицы, каталог строится на метаданных, которые хранятся прямо в репозитории с кодом — например, в файле catalog-info.yaml (это своего рода «паспорт» сервиса: имя, владелец, окружение). Чтобы узнать, кто отвечает за сервис, где найти его API и какая версия актуальна, — достаточно открыть карточку сервиса в каталоге.

2. Документация как код (TechDocs). Техническая документация живёт рядом с кодом в Markdown. Для тех, кто знаком с подходом «документация как код» — ничего неожиданного. А если нет, то суть проста: в отличие от Wiki (Confluence), где документы быстро устаревают, здесь документация обновляется вместе с кодом в том же репозитории. Backstage забирает файлы оттуда и отображает в чистом интерфейсе. Документация всегда актуальна, потому что она — часть процесса разработки, а не отдельная задача.

3. Шаблонизация (Software Templates): Это то, ради чего, на мой взгляд, стоит внедрять Backstage. Как фронтенд-инженер, я много раз сталкивался с тем, что в разных проектах используется разный стек: где-то Webpack, где-то Vite, где-то свои кастомные сборки. Новый разработчик тратит дни на то, чтобы просто понять, «как тут принято писать код». Шаблоны Backstage позволяют стандартизировать технический стек фронтенда (и не только) — и именно это заинтересовало меня больше всего. Под капотом шаблона можно зафиксировать утверждённый набор инструментов, линтеров, конфигов и даже структуру папок, например если используется что-то типа FSD (о котором я какое-то время назад рассказывал на FrontendConf). Создание нового сервиса превращается в заполнение пары полей и нажатие одной кнопки.

Как это устроено изнутри? Коротко о главном

Чтобы дальше было понятнее, расскажу, как Backstage работает «под капотом» — ничего сложного, только самое важное.

Backstage написан на TypeScript и состоит из двух основных частей: frontend (React) и backend (Node.js). Но главная фишка — это плагинная архитектура. Всё, что вы видите в интерфейсе, — это плагины. Сам Core — это просто каркас, который:

• Управляет авторизацией

• Хранит сущности в каталоге

• Предоставляет API для плагинов

Плагины живут в своих песочницах, не зависят друг от друга и подключаются к Core через унифицированный API. Это значит, что вы можете:

• Добавлять плагины по мере необходимости (никакого «монолита»)

• Писать свои плагины под специфические задачи

• Использовать community-плагины без страха что-то сломать

Магия создания сервиса по шаблону

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

Вместо того чтобы копировать файлы из старого проекта и гадать, какие версии библиотек ставить, разработчик заходит в Backstage, выбирает шаблон, заполняет пару полей и нажимает «Create». По сути — создание сервиса в несколько кликов, но по ощущениям — как один.

Допустим, мы выбираем создание frontend-приложения на React. Backstage запускает многошаговый мастер:

Разработчик заполняет простую форму: в моём упрощенном примере указываем только название сервиса и системы, в рамках которой он будет существовать. Остальные настройки зашиты в файле yaml конфигурации шаблона.

Все эти поля настраиваются с помощью JSON Schema. Можно сделать поля обязательными, добавить выпадающие списки или даже целые динамические разделы, которые появляются в зависимости от выбора пользователя.

После нажатия кнопки «Create» запускается магия. Backstage выполняет последовательность действий, описанных в шаблоне:

1. fetch:template — скачивает «скелет» сервиса (с правильной структурой папок, линтерами, тестами и Dockerfile) и подставляет туда имя, введенное пользователем.

2. publish:gitlab — создает новый репозиторий и пушит туда код.

3. catalog:register — регистрирует новый сервис в каталоге Backstage, добавив ссылку на его catalog-info.yaml.

Когда всё готово, разработчик получает ссылки на новый репозиторий и карточку сервиса в каталоге.

Вот как выглядит карточка сервиса после регистрации (вкладка Overview).

Кроме неё, доступны и другие вкладки:

• CI/CD — статус сборок и пайплайнов

• API — описание и спецификации API сервиса

• Docs — документация TechDocs

• Dependencies — внешние зависимости сервиса

• Relations — связи с другими сущностями (компонентами, системами)

• Links — полезные ссылки (репозиторий, дашборды, чаты)

• Subcomponents — вложенные компоненты, если сервис состоит из нескольких частей

Весь процесс занимает пару минут. Новый сервис уже создан с соблюдением всех стандартов, задокументирован и готов к работе. Разработчик даже не открывал браузер за пределами Backstage.

Экосистема и плагины

Backstage живет за счет плагинов. Существуют плагины для интеграции с Jenkins, GitHub Actions, Jira и сотнями других инструментов. Глядя на карточку сервиса в каталоге, инженер сразу видит статус CI/CD сборки, ошибки в логах и того, кто сегодня на дежурстве.

Экосистема плагинов заслуживает отдельного разговора — здесь я привёл лишь самые популярные примеры.

И это еще не все

Backstage — большая платформа, и в одной статье сложно рассказать обо всём подробно. Если вы решите присмотреться к нему ближе, вот несколько важных аспектов, которые мы не затронули:

• Разграничение прав (Permission Framework). Кто может создавать шаблоны, редактировать каталог, удалять сервисы? Backstage поддерживает гибкие политики доступа на основе ролей (RBAC) или правил (например, через Open Policy Agent).

• Связи между системами. Каталог умеет хранить не только компоненты, но и их отношения: какой сервис зависит от какой базы данных, какое API использует, в составе какой системы находится. Это позволяет строить граф зависимостей.

• Поиск и индексация. Backstage имеет встроенный поиск по всем сущностям, документации и даже техническим заметкам. Можно подключать собственные индексы (Elasticsearch, PostgreSQL).

• Бэкенд-плагины. Плагины бывают не только фронтенд-визуальные, но и бэкендовые — они могут добавлять свои API, интеграции или обработчики событий.

• Кастомизация внешнего вида. Интерфейс Backstage можно адаптировать под бренд компании: логотипы, цвета, темы, свои виджеты на главной странице.

Резюме

Backstage превращает взаимодействие с инфраструктурой из череды догадок в предсказуемый интерфейс.

Для разработчика — возвращённое время и фокус на коде.

Для команды — быстрый онбординг и меньше хаоса.

Для архитектора, техлида и CTO — прозрачность, контроль над масштабом и уверенность, что инженерная культура не рассыплется при росте.