3 Reasons Not to Use Backstage

#1. The Scale Factor: Why Size Dictates Suitability

In my dialogues with platform teams from organizations of various sizes, a recurring theme is the relevance of an Internal Developer Portal like Backstage to their specific scale. Backstage shines in large-scale operations typical of corporations with hundreds of engineers, where managing a diverse and sprawling tech landscape is a challenge. However, for smaller teams, the scenario is markedly different.

In organizations with fewer engineers, the complexity and breadth of a tool like Backstage can be more of a pain than a help. Smaller teams typically require agility and simplicity, which can be better addressed by more streamlined platforms focused on delivering a self-service experience. This is where Internal Developer Platforms (like Qovery) can provide a more fitting solution. It’s tailored to offer an exceptional developer experience without the overhead of managing a complex array of features that larger teams demand. When engineering teams grow, combining an Internal Developer Platform with an Internal Developer Portal is relevant to cover the full spectrum of needs.

Read more about Internal Developer Portals vs. Internal Developer Platforms

#2. Frontend Expertise: A Barrier for Many Teams

Throughout my discussions, I've noticed a significant hurdle in adopting Backstage: the need for substantial frontend development skills, particularly in React. This requirement poses a considerable challenge for many platform teams, whose strengths often lie in backend development, infrastructure, or DevOps.

"The idea of backstage is super cool, but for me, as a DevOps engineer, the fact that I need to write a lot of React code instead of github workflows and terraform files made to leave the project." - Reddit User

Creating and maintaining custom plugins in Backstage requires not only React expertise but also a deep understanding of its architecture. This can divert platform engineers from their core responsibilities and create a steep learning curve. In my experience, platforms that can abstract these complexities, allowing engineers to focus on their strengths, are often more beneficial for teams without dedicated frontend resources.

#3. The Long-Term Commitment: Setup and Maintenance Considerations

Another critical aspect, often overlooked in the initial excitement of adopting a new platform, is the long-term commitment required for setup and maintenance. Implementing Backstage is not a one-off task but a continuous journey of updates, customization, and maintenance.

"At scale, Backstage is not an "other duties as assigned" sort of tool to own. It will require dedicated resources as it grows. That's usually the biggest thing people overlook, based on conversations I've had." - Reddit User from r/DevOps community

For smaller teams or organizations with constrained resources, this ongoing investment can be a significant burden. It's essential to weigh the long-term costs and efforts against the immediate benefits. In many cases, I've seen teams benefit more from simpler, more manageable solutions that focus on core development workflows, avoiding the resource-intensive nature of comprehensive platforms like Backstage.

#Conclusion

While Backstage offers a robust solution for large organizations with complex needs, it's not a one-size-fits-all tool. My interactions with various platform engineering teams have highlighted the importance of considering factors like organization size, technical skill sets, and the long-term investment required. For many, a more streamlined and focused platform like Qovery (Internal Developer Platform), which emphasizes ease of use and efficiency, may offer a more practical and beneficial approach.