Learn Backstage - History, Background & Why You Need Backstage

#Introduction

In episode 0, you prepared the basic skills and tools you need: Node.js 20+, Yarn 4, Docker, Git, and more. Episode 1 takes a pause from tooling to understand why Backstage exists. A technology doesn't emerge from a vacuum — it's born from the way organizations evolve how they build and run software. Understanding this historical context will make Backstage's architectural decisions in later episodes feel perfectly reasonable.

#The Evolution of Platform Engineering

#The DevOps Era (1990s - 2010s)

In the DevOps era, engineering teams began blending development and operations. Release processes that once waited for a monthly schedule gradually became automated pipelines with more frequent commits, builds, and deploys. CI/CD tooling appeared, and a culture of collaboration between developers and operators became a core value. Still, software at this time was dominated by monoliths — one large application deployed as a whole.

#The Microservices Explosion

Problems started to surface when monoliths were broken up into many small services. Each service could be deployed, scaled, and developed independently. The number of services skyrocketed: from dozens to hundreds and even thousands. This condition is called the microservices explosion. Every team had its own repositories, pipelines, and ways of working. At this point, the technical challenge shifted from "how to write code" to "how to find the code that already exists".

Another side effect of this explosion was a need for new tooling: service discovery, observability, and API version management became burdens that never existed before. Teams began to realize that building a service was just the beginning — managing it at scale was the real challenge.

#The Discoverability Problem and Cognitive Overload

When services number in the thousands, engineers start hitting two big problems:

• Discoverability — engineers don't know which services already exist, who owns them, where their documentation is, or how to integrate with them.
• Cognitive overload — information is scattered across many repositories, wikis, chats, and documents that are out of sync. Connecting a new service means navigating a sea of conflicting information.

The impact: time meant for writing features is consumed by searching for information and waiting for answers from the platform team. At a certain point, the bottleneck is no longer how fast you can write code, but how fast you can find and understand what already exists.

#The Birth of Platform Engineering and IDPs

Out of these problems was born the discipline of Platform Engineering — the practice of building a layer of internal tooling and services that lets engineers self-serve. Its core concept is the golden path: a proven route for common tasks such as creating a new service, deploying, and managing infrastructure. This layer is known as the Internal Developer Platform (IDP), and Backstage is one of the most well-known IDP implementations.

A summary of the evolution:

#The Origins of Backstage

Backstage's journey from an internal tool to an industry standard rests on three major milestones: its birth at Spotify, its open-sourcing, and broad community adoption. Each is explained below.

#Built by Spotify (2016/2017)

Backstage was born out of Spotify's internal needs. The music company ran thousands of internal services managed by hundreds of engineering teams. The problem was exactly what we've described: engineers couldn't find the relevant services, documentation was scattered, and onboarding a new service felt like a major undertaking. Spotify began building Backstage around 2016/2017 as an internal catalog and control plane for all those services.

#Open Source and Donation to CNCF (2020)

In 2020, Spotify made a pivotal decision: it open-sourced Backstage and then donated it to the Cloud Native Computing Foundation (CNCF) with an incubating status. From then on, Backstage was developed together with the community rather than by a single company. This kind of governance model ensures Backstage stays neutral and unbound to any particular vendor's interests. The incubating status also signals that the project is considered healthy and fit for use, with clear governance under CNCF's umbrella.

#The De Facto Developer Portal Standard

The combination of features, plugin ecosystem, and community support made Backstage grow rapidly. Many large companies adopted it and made it the de facto standard for developer portals. Today, Backstage is the natural starting point when an organization wants to build its own IDP without starting from scratch.

#The Problems Backstage Solves

Backstage was built to directly answer the problems that surfaced throughout the evolution above:

Imagine a catalog-info.yaml describing every service — a single file that acts as the source of truth for a service's name, type, and owner:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
spec:
  type: service
  owner: team-checkout

You'll create and manage files like this in depth in episode 4. For now, catalog-info.yaml is a concrete example of the "single software catalog" that is Backstage's answer to the discoverability problem.

#Backstage vs Traditional Approaches

Before Backstage, many organizations tried to solve discoverability in conventional ways — and the results always fell short:

Backstage closes this gap by making code the source: catalog-info.yaml lives in the same repository as the code, so the catalog stays in sync with reality. There's no manual process for updating entries — changes in the repository are reflected in the portal directly. This is what makes Backstage different from a mere document or spreadsheet: its truth is maintained by the Git workflow engineering teams already use every day.

#Conclusion

In this episode 1, you understood the context around Backstage's birth: the evolution from the DevOps era, the microservices explosion, discoverability problems and cognitive overload, up to the emergence of platform engineering and IDPs. You also learned Backstage's origins at Spotify, its journey to becoming an incubating CNCF project, and why it became the de facto developer portal standard.

The key takeaways:

• Backstage was born from a real problem — thousands of services that were hard to find and understand.
• An IDP is the answer to toil — self-service replaces a queue of tickets.
• Backstage is neutral — governed by CNCF, not tied to any particular vendor.
• A single catalog is the heart of the solution — all information is centralized in one place.

In the next episode, episode 2, we get more technical: core concepts and the main Backstage architecture — the monorepo structure, core primitives like the Software Catalog and Scaffolder, and the modern frontend and backend systems.