Построение современного development platform с Backstage

Почему developer portal — это не development platform, и как спроектировать важнейший слой под ним

Ключевые выводы

• Backstage решил задачу портала, а не платформы. Портал организует каталоги, документацию и шаблоны. Платформа отвечает за развертывания, среды, политики и операции во время выполнения. Backstage предполагает, что слой исполнения уже существует ниже.
• Точечные интеграции становятся нагрузкой для сопровождения. Во многих организациях образуется «грязная середина», где Backstage напрямую связан с CI/CD, GitOps, Kubernetes и средствами observability через хрупкую и трудноразвиваемую кастомную связку.
• Абстракции — это интерфейс между разработчиками и инфраструктурой. Разработчики работают с компонентами, endpoint и зависимостями. Platform engineers работают со средами, пайплайнами и типами компонентов. Платформа компилирует всё это в ресурсы Kubernetes.
• Контрольная плоскость закрывает разрыв. Она стоит между порталом и runtime, превращает абстракции в инфраструктуру, последовательно применяет политики, устраняет drift и возвращает состояние runtime обратно в портал.
• Хорошие абстракции открывают продвинутые возможности. Единый observability, автоматические guardrails и AI agents, которые могут понимать вашу платформу и действовать в ней. Всё это становится возможным, когда есть четкие концепции и control plane, понимающий обе стороны.

…

Начните с Backstage

Если вы строите internal developer platform, Backstage почти наверняка будет частью архитектуры. Он решил проблему обнаружения и стал стандартным выбором для developer portals.

До Backstage разработчики ходили по вики, таблицам и полагались на tribal knowledge, чтобы понять, кто владеет сервисом или как поднять новый. Backstage привнес структуру: единый каталог, экосистему плагинов и golden-path шаблоны, которые действительно прижились.

Backstage — проект Cloud Native Computing Foundation (CNCF) с одной из самых активных сообществ разработчиков в экосистеме. Когда организации оценивают developer portal, Backstage становится отправной точкой.

Но многие команды после внедрения обнаруживают одно и то же: Backstage дает портал, а не платформу. Портал организует информацию. Платформа отвечает за исполнение: развертывания, среды, политики, observability и runtime operations.

Backstage предполагает, что execution layer существует под ним. Именно там и сосредоточена основная сложность — и об этом статья.

Что такое development platform на самом деле

Development platform, или internal developer platform, — это self-service framework, который вы строите, чтобы разработчики могли самостоятельно создавать, разворачивать и управлять приложениями.

У большинства организаций уже есть органически выросшая версия этого:

• Разработчик коммитит код
• CI pipeline собирает и отправляет образы в registry
• Пайплайн обновляет GitOps-репозиторий с Helm charts или Kubernetes manifests
• Argo CD или Flux синхронизируют эти манифесты с кластерами

Возможно, такой поток уже работает у вас сегодня. Вопрос в том, является ли он пайплайном, сшитым скриптами и tribal knowledge, или платформой с последовательными абстракциями и self-service возможностями.

Что обычно происходит после внедрения Backstage

Как добавить Backstage в такую схему? Обычно разработчики ведут файлы сущностей Backstage, в первую очередь component и API entities, рядом с исходным кодом. Затем вы настраиваете встроенный entity provider в Backstage, чтобы он сканировал репозитории и заполнял каталог. В итоге у вас появляется портал со всеми системами, компонентами, API и другими ресурсами. Пока всё хорошо.

Но как только разработчики начинают пользоваться порталом, на вас обрушивается стабильный поток запросов на доработки:

• «Я вижу свой компонент в каталоге, но он вообще запущен?» Вы настраиваете Kubernetes plugin и связываете компоненты с соответствующими манифестами. Теперь разработчики видят состояние pod, статус deployment и число replica.
• «Мне нужны логи, метрики и traces, связанные с моим компонентом». Вы интегрируете стек observability или заставляете разработчиков переключаться в Grafana, Datadog или в тот инструмент, который у вас используется. В любом случае появляется еще одна связка.
• «Можно создавать новые компоненты отсюда?» Вы строите шаблоны Backstage, которые генерируют репозитории с нужной структурой, сущностями Backstage, Helm charts и CI pipeline, кодируя лучшие практики вашей организации. Теперь вы поддерживаете golden paths в шаблонах отдельно от runtime-конфигурации, которая реально их обеспечивает.

Каждый запрос разумен и выполним, но в сумме они накапливаются.

«Грязная середина»

В итоге у вас получается платформа, скрепленная точечными соединениями. Любая новая возможность требует новой связки. Любое обновление рискует что-то сломать. Вы тратите больше времени на сопровождение интеграций, чем на создание функций.

Вы бы никогда не спроектировали production system с таким количеством точечных зависимостей. Почему это должно быть приемлемо для вашей платформы?

Относитесь к платформе как к продукту, но и как к системе

Органически выросшие системы помогают стартовать, но как только вы делаете Backstage своим порталом, вам нужен продуктовый подход. Начните с developer experience, поймите их боли, а затем спроектируйте систему, которая последовательно их решает.

Но платформа — это еще и система. Подходите к ней так же, как к любой production system, которую строите. Вы бы не проектировали back-end service, не думая о separation of concerns, понятных интерфейсах и extensibility.

Здесь применимы те же принципы:

• Separation of concerns: не смешивайте абстракции для разработчиков с реализацией инфраструктуры. Держите их отдельно, чтобы развивать каждую независимо.
• Clear interfaces: определите явные абстракции. Разработчики и platform engineers должны взаимодействовать с четко заданными концепциями, а не с деталями реализации, разбросанными по Helm charts и CI scripts.
• Extensibility: требования меняются. Если каждая новая возможность требует кастомной связки, вы будете больше времени тратить на сопровождение, чем на улучшения. Проектируйте с расчетом на расширение с самого начала.

Разница между набором интеграций и платформой — в архитектуре. Если системный дизайн верный, новые возможности добавляются чисто. Если нет, каждый запрос на функцию превращается в обременительное сопровождение.

Отсутствующий слой под Backstage

Переход от органически выросшего пайплайна к действенной development platform — большой скачок. У вас, вероятно, уже есть работающие CI/CD pipeline, кластер Kubernetes, где выполняются workloads, и каталог Backstage, описывающий существующие сущности.

Вопросы такие:

• Как превратить информационный портал в портал с платформой внутри?
• Как связать то, что описано в каталоге, с тем, что реально запущено?
• Как обеспечить golden paths не только на этапе первичной генерации?
• Как спроектировать платформу, которая будет развиваться вместе с потребностями организации?

Не хватает связующего слоя между Backstage и runtime — слоя, который делает портал операционным, а не просто информационным. Посмотрим на ключевые архитектурные элементы, которые стоит учесть при проектировании этого слоя и всей платформы.

Начните с абстракций

Одна из главных целей development platform — снизить cognitive load. Платформа должна встречать разработчиков там, где они находятся, и говорить на их языке, а не на языке Kubernetes.

У каждой организации свой словарь, но system model Backstage — хорошая отправная точка. Он не покрывает вообще всё, но его можно расширять custom entities. Главное, чтобы разработчики работали с высокоуровневыми концепциями, а платформа компилировала их в ресурсы Kubernetes. Разработчики абстрагированы от деталей реализации, но при этом могут видеть, что происходит внизу.

Это не просто статические абстракции; у них есть и связанная runtime semantics. Следующая диаграмма показывает runtime-представления этих концепций.

В workload cluster project становится границей изоляции для всех своих компонентов. Платформа переводит это в namespaces Kubernetes и network policies, которые не просто описывают границу, а реально ее enforce’ят.

Visibility endpoint определяет, какие endpoint могут общаться друг с другом. Endpoint уровня project получает network policies, блокирующие трафик извне проекта. Endpoint уровня organization доступен для внутреннего трафика, но остается за internal gateway. Внешний endpoint маршрутизируется через public gateway с соответствующей аутентификацией. Разработчики объявляют visibility; платформа генерирует политики.

Dependencies работают так же. Когда компонент объявляет зависимость от endpoint, платформа подставляет URL и другие environment variables, необходимые для подключения. Она настраивает network policies в обе стороны — egress от вызывающего endpoint и ingress к целевому endpoint. Без объявленной зависимости egress по умолчанию блокируется. Граф зависимостей, показанный выше, отражает фактический разрешенный поток трафика, а не просто задуманные связи.

Нужны и platform abstractions

Абстракции для разработчиков помогают разработчикам. Абстракции платформы помогают вам.

Пока разработчики работают с components, endpoints и dependencies, вам нужен другой словарь, чтобы проектировать и эксплуатировать саму платформу. Эти абстракции позволяют вам и вашей команде определять стандарты, применять политики и создавать структуру без написания низкоуровневых конфигураций под каждый сценарий.

Эти абстракции отделяют заботы платформы от забот приложения. Разработчикам не нужно знать, на каком кластере работает их код и как связаны среды. Они разворачивают в «staging» или «prod», а вы определяете, что эти термины означают.

Отсутствующий слой — это control plane

Control plane — это место, где абстракции становятся реальностью. Он находится между порталом и вашими workload clusters и переводит намерение разработчика в конфигурацию инфраструктуры.

Его можно рассматривать как компилятор, который таргетирует кластеры Kubernetes, преобразуя более высокоуровневые абстракции в то, что понимают Kubernetes и его базовые фреймворки. Он также может применять общие для платформы правила в процессе этой компиляции. Ограничения по ресурсам, требования безопасности и прочее могут enforce’иться последовательно, а не просто быть задокументированы и оставлены на удачу.

Но компиляция — только половина работы. Control plane также непрерывно reconciles. Он отслеживает drift между объявленным и фактическим состоянием. Когда они расходятся, он исправляет расхождение. Ваши абстракции остаются source of truth; control plane обеспечивает их соблюдение со временем.

Программируемость — не опция

Один из ключевых аспектов этого control plane — programmability. Если вы хотите, чтобы платформа развивалась, control plane должен быть extensible. У разных команд разные требования. Появляются новые возможности. Нельзя предусмотреть всё заранее.

Это означает возможность настраивать, как абстракции компилируются в манифесты Kubernetes. Но extensibility без guardrails опасна. Нужна programmability, которая сохраняет ваши invariants. Цель — ограниченная гибкость: достаточно открытая для развития, но достаточно структурированная, чтобы оставаться цельной.

Наблюдаемые абстракции делают портал полезным

Control plane также агрегирует runtime state и связывает его с вашими абстракциями. Именно это делает портал полезным. Без этого разработчикам приходится собирать информацию из разных инструментов: Kubernetes dashboard для состояния pod, Argo CD для состояния deployment, Grafana для метрик, Jaeger для traces. Каждый инструмент знает лишь часть истории; ни один не показывает полную картину.

Когда control plane агрегирует состояние, портал рассказывает связанную историю. Когда разработчик открывает страницу компонента в Backstage, он видит:

• Развернутые среды и их статус
• Текущее число replica и потребление ресурсов
• Недавние развертывания и кто их запустил
• Логи, метрики и traces, привязанные к этому компоненту в каждой среде
• Зависимости и их состояние

Никакого переключения контекста. Никакого ручного восстановления, какой pod относится к какому сервису и в каком кластере он живет. Абстракция — это якорь, а все остальное к ней прикрепляется.

Это работает только потому, что control plane понимает обе стороны. Он компилировал абстракции в Kubernetes, поэтому знает, как вернуть runtime data обратно. Информация течет в обе стороны. Вниз — намерение разработчика проходит через control plane и становится запущенными workloads. Вверх — runtime state возвращается через control plane и появляется в портале.

Именно это делает портал action-oriented. Он не просто показывает информацию; он связан с системой, которая может действовать.

Data plane: сохраняйте простоту

Data plane — это место, где реально выполняются ваши workloads. В большинстве случаев это один или несколько кластеров Kubernetes. Data plane ничего не знает о ваших абстракциях. Он понимает примитивы Kubernetes, такие как pods, deployments, services и ingresses. Задача control plane — компилировать ваши более высокоуровневые концепции в эти примитивы и применять их.

Data plane делает одну вещь: запускает то, что ему говорит запускать control plane. Интеллект живет в control plane; исполнение происходит в data plane.

Где в платформе находится AI

AI сейчас участвует в каждом разговоре о платформах, но архитектурный вопрос в том, где он действительно должен находиться.

Созданные вами абстракции и control plane формируют основу. У вас есть четкие концепции вроде components, endpoints и dependencies. У вас есть runtime state, агрегированное и связанное с этими концепциями. У вас есть связанный взгляд на систему. AI agents вполне могут этим воспользоваться.

Agents как пользователи платформы

AI agents должны уметь взаимодействовать с платформой как полноправные участники. Для этого нужно открывать capabilities платформы через интерфейсы, которые могут использовать агенты, например Model Context Protocol (MCP) servers, APIs с понятной семантикой, удобные CLIs и skills, привязанные к операциям платформы.

Такие возможности платформы позволяют агентам создавать компоненты, запускать сборки и развертывания, запрашивать статус среды и рассуждать о зависимостях. Они помогают и вам, и вашим разработчикам работать продуктивнее.

Agents как возможности платформы

Вы также можете встроить агентов внутрь платформы, чтобы помочь командам в повседневной работе. Вот несколько примеров таких агентов:

• SRE agents: анализируют логи, метрики и traces, чтобы выделить вероятные root cause. Вместо того чтобы копаться в дашбордах, разработчики получают корреляцию сигналов и подсказку, куда смотреть.
• FinOps agents: помогают командам понимать и оптимизировать стоимость ресурсов по средам и компонентам.
• Architect agents: помогают с архитектурными решениями, например анализом зависимостей, планированием capacity и оценкой влияния миграций.

Эти агенты работают потому, что у них есть доступ к единому представлению control plane. Они видят абстракции, runtime state и данные observability в одном месте — ту же связанную историю, которую разработчики видят в портале.

Паттерн сохраняется: хорошие абстракции упрощают всё, включая AI.

OpenChoreo как референсная реализация

OpenChoreo — open-source development platform для Kubernetes. Недавно его приняли в CNCF как sandbox project. OpenChoreo реализует архитектуру, описанную в этой статье: абстракции для разработчиков, поддержанные control plane, портал на базе Backstage, интегрированные CI/CD и GitOps, а также observability, связанная с вашими абстракциями.

Если вы строите такую архитектуру самостоятельно, OpenChoreo стоит изучить как референс, даже если вы не будете внедрять его напрямую. Проект показывает, как эти элементы сочетаются: как абстракции компилируются в ресурсы Kubernetes, как runtime state возвращается в портал и как guardrails enforce’ятся во время компиляции.

OpenChoreo можно использовать как полноценную платформу или установить его плагины Backstage в существующий портал и взять только слой control plane. В любом случае важны лежащие в основе паттерны. Архитектура — это идея. OpenChoreo — один из способов ее реализации.

Полезная ментальная модель: multi-plane architecture

OpenChoreo разделяет обязанности на пять плоскостей:

1. Experience plane: место, где разработчики, platform engineers и SRE взаимодействуют с платформой через портал на базе Backstage, CLI, GitOps или AI agents.
2. Control plane: мозг, который переводит высокоуровневые абстракции (components, APIs, environments, pipelines) в манифесты Kubernetes. Он программируем через component types и traits, поэтому его можно расширять без форков и без написания низкоуровневых controllers. Он непрерывно reconciles runtime state обратно в эти абстракции.
3. Data plane: место, где работают workloads. Он enforce’ит семантику ваших абстракций, например project isolation, traffic policies и security boundaries. Это не просто конфигурации; платформа гарантирует их.
4. Observability plane: возвращает метрики, логи и traces через те же абстракции, которые разработчики уже понимают, без необходимости что-либо переводить.
5. Workflow plane (optional): по умолчанию отвечает за сборки с использованием Cloud Native Buildpacks и Argo Workflows.

Эти плоскости работают вместе, но остаются отдельными сущностями. Их можно проектировать независимо, развивать с разной скоростью и раскладывать по разным топологиям: один кластер с namespace isolation для dev/test, полностью разнесенные multi-cluster конфигурации для production или гибридные топологии, где плоскости вроде Control и CI размещаются рядом ради экономии.

AI и OpenChoreo

OpenChoreo строится так, чтобы считать AI agents полноправными участниками. В OpenChoreo 1.0 внешние агенты могут взаимодействовать с платформой через MCP servers, agent skills или CLI, чтобы генерировать и редактировать конфигурации компонентов, рассуждать о релизах и средах и делать многое другое. Встроенный SRE Agent — первый пример этого подхода. Он анализирует логи, метрики и traces из ваших развертываний и использует LLM, чтобы выделять вероятные root cause и практические инсайты.

От портала к платформе

Backstage решил задачу портала. Он дал единый интерфейс для каталогов, документации и golden paths. Но портал — это не платформа. Между тем, что видят разработчики, и тем, что реально работает, есть разрыв, и именно там вы застреваете. Его начинают заполнять точечными интеграциями, custom plugins и скриптами, которые сами становятся обременением для сопровождения.

Рабочий паттерн такой: portal, control plane, data plane:

• Портал, который дает разработчикам готовый доступ к каталогам, документации и шаблонам.
• Control plane, который компилирует абстракции платформы, устраняет drift и агрегирует runtime state.
• Data plane, который запускает workloads и обеспечивает гарантии.

Независимо от того, строите ли вы это сами или берете что-то вроде OpenChoreo, архитектура важнее инструментов. Правильно выстроите слои — и новые возможности будут вставать естественно. Ошибетесь — и каждый запрос на функцию превратится в отдельный проект.

Backstage дает вам входную дверь. Настоящая платформа начинается за ней.

Материал — перевод статьи с английского.

Оригинал: Building a state-of-the-art development platform with Backstage