Platform Tips #20: Why Backstage is So Complex? Is There An Alternative?

In less than 6 months, I’ve chatted with hundreds of Platform Engineering teams, and I was stumbled by the number of them that were literally disappointed by Backstage.

Hey Folks 👋,

I'm Romaric, CEO of Qovery, and this is my 19th Platform Tips post.

This week, we have to chat about Backstage. The reference open-source Internal Developer Portal (or Dev Portal) that was created by Spotify (donated to CNCF). In less than 6 months, I’ve chatted with hundreds of Platform Engineering teams, and I was stumbled by the number of them that were literally disappointed by Backstage 😬. The main reason is - how much effort is required to maintain it. Today, I want to explain the story behind Backstage and why it’s so complex. I’ll also share my thoughts on what could be a simpler alternative.

Origins and Intent

Backstage was conceived by Spotify to address the complexities inherent in managing a vast and diverse type of service. As Spotify's engineering teams navigated the challenges of scaling their operations, the need for a unified system that could offer a holistic view of their software ecosystem became clear. Backstage was their solution: a developer portal that aimed to organize services, documentation, and data with the goal of enhancing developer efficiency and productivity.

Spotify's platform engineering teams, known for their multidisciplinary approach within squad-based structures, include individuals proficient in React — a key skill given that developing Backstage plugins requires knowledge of this library. This composition reflects the platform's advanced technical foundation, geared towards teams with a broad range of technical skills, including front-end development capabilities.

The Complexity

Despite its innovative design, feedback from hundreds of platform engineering teams reveals a consistent theme: Backstage's complexity poses a significant barrier. Many teams seek a self-service catalog that is straightforward to configure and provides seamless access for developers. Instead, they encounter a platform that, while powerful, demands a considerable investment in time and resources to tailor to their specific needs. Of course, Spotify is flexible enough to provide a high degree of customization. But is it really necessary?

/* src/plugin.ts */
import { createPlugin, createRouteRef } from '@backstage/core-plugin-api';
import ExampleComponent from './components/ExampleComponent';

// Create a plugin instance and export this from your plugin package
export const examplePlugin = createPlugin({
  id: 'example',
  routes: {
    root: rootRouteRef, // This is where the route ref should be exported for usage in the app
  },
});

// This creates a routable extension, which are typically full pages of content.
// Each extension should also be exported from your plugin package.
export const ExamplePage = examplePlugin.provide(
  createRoutableExtension({
    name: 'ExamplePage',
    // The component needs to be lazy-loaded. It's what will actually be rendered in the end.
    component: () =>
      import('./components/ExampleComponent').then(m => m.ExampleComponent),
    // This binds the extension to this route ref, which allows for routing within and across plugin extensions
    mountPoint: rootRouteRef,
  }),
);

One concrete example of this complexity is the necessity to develop custom plugins using React and Typescript (example above). For teams without front-end development expertise, this requirement can stall the adoption of Backstage or necessitate additional training or hiring, complicating what should be a straightforward process.

Toward a New Approach

It becomes clear that there is a pressing need for a new approach to developer portals — one that prioritizes ease of configuration, maintenance, and operation without the prerequisite of React development skills. The goal would be to offer platform engineering teams a solution that aligns with their fundamental requirement: a self-service portal that is intuitive, easy to manage, and adaptable to the evolving needs of developers and the organization.

I’ll stop teasing here - since I’ll publish next week a post on a new open-source alternative to Backstage that I’m working on 🤗.

Conclusion

The journey of Backstage, from its inception at Spotify to its current status as a tool explored by platform engineering teams worldwide, offers valuable insights into the balance between functionality and usability. As we look ahead, the goal is to build upon these insights and propose an open-source alternative that addresses the core needs of platform engineering teams. This new approach will seek to simplify the developer portal experience, making it accessible to teams regardless of their expertise in front-end development, and ultimately fostering a more efficient and productive software development ecosystem.

—

Let's revolutionize Platform Engineering by putting developers first. Subscribe now to join me on this exciting journey!

---