Представьте: в вашей компании уже не десятки, а сотни микросервисов. Новый разработчик приходит в команду и первую неделю тратит не на код, а на поиски. «Где лежит этот 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 организует порядок через три ключевые функции:
Каталог компонентов (Software Catalog): Сердце платформы. Это автоматически обновляемый реестр всех ваших сервисов, библиотек, сайтов и ресурсов. В отличие от гугл-таблицы, каталог строится на метаданных, которые хранятся прямо в репозитории с кодом — например, в файле
catalog-info.yaml(это своего рода «паспорт» сервиса: имя, владелец, окружение). Чтобы узнать, кто отвечает за сервис, где найти его API и какая версия актуальна, — достаточно открыть карточку сервиса в каталоге.Документация как код (TechDocs). Техническая документация живёт рядом с кодом в Markdown. Для тех, кто знаком с подходом «документация как код» — ничего неожиданного. А если нет, то суть проста: в отличие от Wiki (Confluence), где документы быстро устаревают, здесь документация обновляется вместе с кодом в том же репозитории. Backstage забирает файлы оттуда и отображает в чистом интерфейсе. Документация всегда актуальна, потому что она — часть процесса разработки, а не отдельная задача.
Шаблонизация (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 выполняет последовательность действий, описанных в шаблоне:
fetch:template — скачивает «скелет» сервиса (с правильной структурой папок, линтерами, тестами и Dockerfile) и подставляет туда имя, введенное пользователем.
publish:gitlab — создает новый репозиторий и пушит туда код.
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 — прозрачность, контроль над масштабом и уверенность, что инженерная культура не рассыплется при росте.