Skip to main content

Kratix Ep 11: Full IDP Integration with Backstage

Rachmat Hidayat
Author
Rachmat Hidayat
Learn & sharing insights on TypeScript, Go, Kubernetes, DevOps, DevSecOps, SRE, Platform Engineering, AI/ML Engineering, and MLOps.
kratix - This article is part of a series.
Part 11: This Article
We have built a massively scalable backend using Kratix, ArgoCD, Vault, and Crossplane. However, forcing developers to write YAML and run kubectl apply is still intimidating for many product teams. To achieve true self-service, we need a beautiful Web UI. Let’s integrate Kratix with Spotify’s Backstage.

1. Why Backstage?
#

Backstage is an open-source framework for building developer portals, originally created by Spotify. It serves as a centralized catalog for all software components, documentation, and infrastructure.

By marrying Backstage (The Frontend) with Kratix (The Backend), we create the ultimate Internal Developer Platform:

  • Developers browse the Backstage Software Catalog to find available Kratix Promises (like Redis, Postgres, Kafka).
  • Developers click a button in Backstage to request a database.
  • Backstage generates the Kratix Claim YAML and commits it to Git.
  • Kratix detects the new Claim, runs the Pipeline, and orchestrates the deployment.

2. Integrating Backstage Software Templates
#

Backstage uses a feature called Software Templates to scaffold new projects or request infrastructure. We will create a Template that allows E-Commerce developers to request our Kratix Redis database via a web form.

In your Backstage repository, create a new template definition file redis-template.yaml:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: kratix-redis-database
  title: Provision Redis Database
  description: Request a highly available Redis database via Kratix
  tags: ['database', 'redis', 'kratix']
spec:
  owner: platform-engineering
  type: service

  # 1. The Web Form (Parameters)
  parameters:
    - title: Database Details
      required:
        - name
        - size
        - environment
      properties:
        name:
          title: Database Name
          type: string
          description: Unique name for your database
        size:
          title: Size
          type: string
          enum: ['small', 'medium', 'large']
        environment:
          title: Environment
          type: string
          enum: ['dev', 'staging', 'production']

  # 2. The Execution Steps
  steps:
    # Use the 'fetch:template' action to generate the Kratix Claim YAML
    - id: generate-yaml
      name: Generate Kratix Claim
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          size: ${{ parameters.size }}
          environment: ${{ parameters.environment }}

    # Commit the generated YAML to the Developer's Git Repository
    - id: publish
      name: Publish to Git
      action: publish:github
      input:
        allowedHosts: ['github.com']
        description: This is a Kratix Claim generated by Backstage
        repoUrl: github.com?repo=ecommerce-infrastructure&owner=acmecorp

3. The Skeleton YAML
#

Notice the url: ./skeleton in the template above. We must provide the raw Kratix Claim YAML with placeholder variables that Backstage will fill in.

Create a folder named skeleton next to your template file, and inside it, create redis-claim.yaml:

apiVersion: marketplace.acmecorp.com/v1alpha1
kind: Redis
metadata:
  name: ${{ values.name }}
  namespace: team-ecommerce
spec:
  size: ${{ values.size }}
  environment: ${{ values.environment }}

4. The Complete User Journey
#

Now, let’s look at the day in the life of an E-Commerce developer:

  1. They log into the Backstage Web Portal.
  2. They navigate to the “Create” section and select the “Provision Redis Database” template.
  3. A beautiful web form appears. They type ecom-session-cache, select large, and choose production.
  4. They click “Create”.
  5. Backstage takes those inputs, injects them into the Skeleton YAML, and opens a Pull Request on the ecommerce-infrastructure Git repository.
  6. The developer (or their manager) approves the PR.
  7. A GitOps agent (like ArgoCD or Flux) syncing that repository applies the YAML to the Platform Cluster.
  8. Kratix wakes up, detects the new Claim, and executes the Pipeline (as we learned in Episodes 1-10).

The developer successfully provisioned complex, multi-cluster infrastructure without ever touching a terminal, writing a line of YAML, or understanding Kubernetes.


Conclusion & Next Steps
#

You have built the holy grail of Platform Engineering. You have a frontend (Backstage) that provides exceptional Developer Experience, and a backend (Kratix, GitOps, Crossplane) that provides unbreakable security, scalability, and state management.

In the final episode, Episode 12: Production Reference Architecture, we will review the entire system diagram from end-to-end, providing a downloadable reference architecture that you can present to your CTO.

kratix - This article is part of a series.
Part 11: This Article