DEV Community: Jian Reis

Backstage Adoption: The Day 2 Problem

Jian Reis — Thu, 06 Feb 2025 14:13:46 +0000

Deploying Backstage is an huge milestone for any engineering team. Whether you’ve set it up to improve service discoverability, streamline onboarding with templates, or enhance governance, the possibilities it unlocks are transformative. But here’s the hard truth: deploying Backstage is just the beginning. What comes next - the Day 2 experience - is where the real work begins.

Day 2 with Backstage is about moving beyond the initial setup and figuring out how to turn Backstage into a tool your developers use as part of their daily or weekly workflows, and in time, come to rely on. Many teams start with specific use cases like service discoverability or software governance, but these don’t always translate neatly into widespread adoption. That’s because solving a single pain point doesn’t necessarily create long-term habits. To make Backstage stick, you need a strategic approach that aligns its features with your developers’ daily workflows. So, let’s explore why Backstage adoption often stalls, and how to set your organization up for sustained success.

Build it and they will might come

It’s easy to assume that once Backstage is deployed, adoption will naturally follow. After all, it solves critical pain points: creating a unified service catalog, automating repetitive tasks with templates, and introducing governance tools to improve software quality. But in practice, adoption requires much more than simply solving these problems. It requires building habits, demonstrating value, and integrating Backstage into the fabric of your engineering culture.

Strategy: treat Backstage like a product

The key to overcoming adoption challenges is to treat Backstage like a product, not just a one-off project. This mindset is at the heart of successful adoption and ensures that Backstage evolves over time to meet the needs of its users. Treating it as a product means committing to continuous improvement, guided by user feedback and measurable outcomes. That does mean that if you’re a platform engineer, you may need to put on a product manager hat, thinking strategically about what your users need, prioritizing features, and continuously communicating the value of Backstage to developers and leadership alike. This means balancing the technical work with a clear focus on solving problems and delivering value internally, which may represent a big change.

It needn’t be overwhelming though - start by engaging your most important internal users - your developers. Communicate with them to understand their workflows, pain points, and priorities. Backstage adoption is a collaborative effort, and the more involved your developers feel in shaping its direction, the more likely they are to embrace it. Use tangible metrics to track success, such as catalog completeness, daily active users, or ROI from key features like templates (engineering time saved for each template run, for instance). These metrics not only highlight areas for improvement but also help demonstrate value to leadership, ensuring sustained investment.

The ‘treat it like a product’ approach to a developer portal such as Backstage is really well articulated by Adam Rogal, who leads Developer Productivity and Platform at DoorDash. In the podcast episode “Bootstrapping a Developer Portal,” Rogal shares how his team built their developer portal, DevConsole, with a clear focus on delivering immediate value to their engineering customers. By engaging engineers early and iterating based on their feedback, the platform team ensured that DevConsole directly addressed real pain points. This approach not only drove higher adoption but also built trust with their internal users.

Rogal also underscores the importance of creating a community - not just of users but of contributors. By empowering teams to actively participate in shaping the portal, DoorDash fostered a culture of collaboration and continuous improvement. This communal effort allowed the portal to evolve alongside the organization’s needs, ensuring its long-term relevance and success.

By adopting this product mindset and prioritizing user engagement, platform teams can transform Backstage into an indispensable tool that enhances productivity and aligns with organizational goals. The experience at DoorDash serves as a powerful example of how this approach can drive both adoption and satisfaction.

Tactics for sustaining adoption

While adopting a product mindset gives you the strategic foundation for long-term Backstage success, tactics offer some actionable focus areas on a day-to-day basis. Let’s explore some key tactics to help drive and sustain adoption.

Automate catalog completeness

A rich and accurate catalog is the foundation of Backstage, but manually maintaining it is time-consuming. The best approach is automation. By using integrations with GitHub or AWS, you can automatically populate the catalog with metadata from your repositories or clusters. In our experience, organizations with the highest levels of catalog completeness (90% or more) have all made extensive use of automations such as templates and scripts, and entity autodiscovery and ingestion to reduce the manual effort involved.

Leverage templates for early wins

Templates are one of the easiest ways to showcase the value of Backstage. They can automate repetitive tasks, like setting up a new microservice or creating a CI/CD pipeline, saving developers significant time and ensuring software governance and best practice is baked in. The ROI here is often immediate and measurable - reducing a process from months to minutes is something both developers and leadership can get behind.

Measure and communicate value

Metrics are your best friend when it comes to adoption. Track data like catalog completeness, template usage (and time saved), and daily active users to understand what’s working and what needs improvement. Share these metrics with leadership to demonstrate the impact of Backstage and justify further investment.

Make adoption a cultural effort

Adoption isn’t just a technical challenge - it’s a cultural one. Evangelism plays a crucial role here. Host “lunch and learns,” demos, or office hours to show developers how Backstage can make their lives easier. Engage other engineering teams and create internal champions who can advocate for the platform within those teams. Adoption grows when developers see Backstage as part of their workflow, not an extra step.

Invest in custom plugins

While Backstage’s open-source plugins are a great starting point, one of Backstage’s biggest selling points is its near limitless extensibility through custom plugins. These plugins can address your organization’s unique workflows and challenges, creating a toolset that developers can’t find elsewhere.

Plan for Day 2 from Day 1

The real value of Backstage lies not in its deployment but in its adoption. To unlock this value, you need to approach Backstage as a product - gathering feedback, iterating on features, and aligning its capabilities with your organization’s goals. Adoption doesn’t happen overnight, but with a strategic mindset and sustained effort, Backstage can become an indispensable tool for your engineering teams.

So, as you set up Backstage, don’t just think about the first deployment. Think about what comes next - the Day 2 experience. Plan for it, invest in it, and you’ll set your organization up for long-term success.

What to think about when you’re thinking about an IDP

Jian Reis — Mon, 27 Jan 2025 16:17:51 +0000

Thinking about implementing an Internal Developer Portal (IDP)? You're in good company - Gartner believes 80% of of platform engineering teams will use IDPs by 2026. There’s a growing sense that every forward-looking technology organization should “have an IDP,” but without a clear rationale as to the "why", this mindset risks building something that (at best) is broad and shallow but that fails to address the real issues slowing your teams down. If you focus on too many things at once, you could end up with a platform that may look impressive but doesn’t actually help people do their jobs.

Instead, a successful IDP emerges when you carefully pinpoint and address the actual challenges developers face. Is discoverability a major and constant headache, with engineers spending hours trying to figure out who owns which service, or whether a certain piece of functionality already exists somewhere else? Are operations teams buried in tickets because developers need help every time they want a new environment or test database spun up? Do your devs waste time hopping between half a dozen interfaces to track deployments, check logs, and find documentation?

These are the signals to tune into when you’re thinking about building an IDP. Aligning your IDP closely with well-understood problems ensures every feature is both purposeful and valued. Equally important, it sets the stage for adoption. Developers and team leads won’t embrace a platform just because it’s there—they’ll embrace it if it truly solves their everyday pain points. By narrowing your focus to the challenges that matter, you can go deep on solutions that genuinely improve how your team works, rather than going wide and hoping something sticks.

Focus on the Three Big Challenges

1. Discoverability

The Challenge:

Have you ever seen teams re-implement a piece of functionality simply because they didn’t know it already existed somewhere else? Or maybe someone spends half a day sifting through old wikis, outdated Confluence pages, and random Slack threads looking for an API endpoint. That’s poor discoverability in action. It’s not just about knowing what services exist, but also understanding who owns them, what their dependencies are, and where the latest documentation or runbooks can be found. When this information is hard to find, it leads to frustration, wasted time, and sometimes unnecessary duplication of effort.

What to Prioritize and Implement:

A Service Catalog that brings together all your services, their owners, docs, performance data, and runbooks in one easily searchable location. Using something like Backstage, you create a living directory of what your organization offers internally, so developers spend less time hunting and more time building.

Measuring Impact and ROI:

Track how often teams ask questions like, “Do we have a service that does X?” or “Who’s responsible for Service Y?” If these inquiries drop significantly, you’ve hit a milestone. Similarly, if your onboarding times shrink—new hires who previously took weeks to understand the landscape now feel comfortable in days—that’s your IDP delivering tangible value.

2. Self-Service

The Challenge:

Ever see a feature get stuck in limbo because the developer can’t get the right environment spun up? Or watch an ops team drown under a pile of infrastructure requests that never seem to end? Without self-service capabilities, your velocity takes a hit. Developers have to wait on someone else’s schedule to get a test database or a staging cluster. By the time the resource is ready, the developer may have lost context or moved on to something else. Multiply that by all the teams and projects in flight, and it’s a huge drag on efficiency.

What to Prioritize and Implement:

Template-driven provisioning and a*automated pipelines* that let developers handle common requests themselves. Pre-approved templates can ensure that every provisioned environment adheres to best practices and security standards, so you’re not just removing a bottleneck—you’re also improving consistency and reliability.

Measuring Impact and ROI:

Start by noting how long it currently takes to get a new environment—maybe it’s three days. After introducing templates, see if you’ve brought that down to a few hours or less. Fewer infrastructure-related tickets and faster environment turnarounds mean your teams can maintain their momentum, delivering features and fixes quicker than before (never mind the increase in developer productivity).

3. Developer Experience (DX)

The Challenge:

Picture a developer’s daily routine: they log into one tool for CI/CD pipelines, another for metrics, another for logs, and a separate browser tab for documentation. This constant context-switching slows them down and increases cognitive load. Over time, this fragmented experience can lead to frustration and reduced morale. It’s not that your teams don’t have the tools—they might have too many, scattered across different interfaces with inconsistent user experiences and integration points.

What to Prioritize and Implement:

An IDP such as Backstage that has all the necessary plugins and integrations properly configured and working becomes a Single Pane of Glass that consolidates these critical elements. By giving developers one place to view logs, metrics, deployments, code reviews, and documentation, you’re streamlining their workflow and cutting down on wasted mental effort. Having an IDP that pulls in data and functionality from multiple sources, presenting it in a coherent, intuitive manner is a surefire way to improve developer experience for your internal engineering teams.

Measuring Impact and ROI:

Survey your developers before and after implementation. Ask how easy it is to find information, how often they switch tools, and how smoothly they can move from coding to testing to deploying. You can also keep an eye on DORA metrics—if the team starts shipping more frequently or fixing issues faster, your integrated interface may be part of the reason why.

Tying It All Together

These three challenges—discoverability, self-service, and DX—often feed into one another. Better discoverability saves teams from reinventing the wheel, reducing the complexity of what you need to maintain. Self-service capabilities speed up delivery, easing the workload on ops and freeing developers to move quickly. Improved DX lowers friction, streamlines daily workflows, and keeps developers happier and more productive. Together, these improvements create a virtuous cycle that helps your engineering organization move faster and build more resilient services.

With that as a baseline, your IDP can really step up and take things a step further. For example, Roadie’s Tech Insights can add another layer of value to your IDP by providing a data-driven, real-time view into the overall health and quality of your services. Rather than relying on anecdotal evidence or gut feelings, Tech Insights surfaces concrete metrics—like compliance scores, dependency health, and adherence to security best practices—within the same platform your developers already use. This makes it easier for engineering leaders to identify hot spots, measure improvement over time, and align investments with areas of greatest need.

Ultimately, you don’t implement an IDP just to say you have one. You implement it because you’ve identified specific, costly problems and want to solve them. Start by pinpointing the real issues—where are you losing time, where are developers frustrated, where are processes too complex or opaque? Then map each problem to a targeted solution—like a service catalog, a set of ready-made provisioning templates, or an integrated interface—and track the results. By focusing on the areas that matter most, you ensure that your platform isn’t broad and shallow, but narrow and deep—truly making a difference where your teams need it most.

Get the “why” and the “what” clear first. From there, your IDP will have real purpose, real value, and real staying power within your organization. It’ll be something people rely on, not just another system they’re forced to use.

Backstage Alternatives

Jian Reis — Fri, 24 Jan 2025 10:39:42 +0000

Alternatives to Backstage

Backstage isn’t the right choice for every company, and not every engineering organization needs Backstage. That might sound strange coming from a company that builds on Backstage, but it’s the truth. As powerful as Backstage is for solving developer experience challenges at scale, it’s not the right tool for every organization, at least not right away, and in some cases, not at all.

Whether you're a startup trying to find product-market fit or a team with a simple and modern tech stack, there are times when Backstage may feel like more than you need. Here, we’ll explore three scenarios where Backstage may not be the right fit and what to consider instead.

1. You’re Too Small to Need an IDP

Backstage - and Internal Developer Portals (IDPs) in general - shine when teams grow large enough that communication and coordination start to break down. For small teams, however, these challenges simply don’t exist yet.

The Dunbar Number Effect

Robin Dunbar theorized that humans can only maintain stable relationships with about 150 people - hence Dunbar’s Number. In a work context, smaller teams (especially those under 50 people) tend to operate with high levels of trust, shared knowledge, and informal ownership. Everyone knows everyone, everyone knows who owns what, documentation lives in people’s heads, and service discovery isn’t a pain point.

The Breakpoints of Growth

As team size crosses critical thresholds, however, these dynamics start to shift:

At ~50 engineers: Service sprawl becomes harder to manage. Informal ownership systems start to break down, and tribal knowledge becomes a bottleneck for onboarding. There’s more teams, and their workflow and focus becomes more specialized.
At ~100 engineers: Onboarding slows dramatically as new hires can no longer rely on organic knowledge-sharing. Tools and microservices proliferate, making visibility into ownership and service health challenging.
Beyond 150 engineers: Services are difficult to find, ownership is opaque, and communication breakdowns occur without any sort of tooling. Standardization and discoverability becomes a top priority.

Backstage Alternatives for Small Teams

For smaller teams, you don’t need anything fancy to manage documentation and discoverability. Tools like GitHub Wiki or README.md files in your repositories work perfectly for keeping track of processes and service details. If you need a bit more structure, a simple Google Sheet or Airtable can act as a lightweight service catalog, where you can track service names, owners, and key details. These low-effort, low-cost solutions fit well into existing workflows and are more than enough until your team grows and things start to get a bit more complex.

For teams below these thresholds, investing in an IDP might feel like over-engineering. But as you approach these tipping points, the need for a platform like Backstage becomes abundantly clear.

2. You Prioritize Convenience Over Customization

One of Backstage’s greatest strengths is its extensibility. It’s designed to adapt to the unique needs of engineering teams, but that flexibility does come at a cost: it requires upfront investment and ongoing maintenance.

When Convenience Takes Priority

If you prioritize ease of use and simplicity over extensibility, Backstage might feel like too much effort. You might prefer an out-of-the-box solution that:

Is turnkey and ready to go with minimal setup.
Doesn’t require significant customization to meet your needs.
Offers technical support as part of the package.

The trade-off here is that these out-of the box solutions typically tie you to a pre-defined, closed-source roadmap of a proprietary solution, but that may not be a problem if your first priority is ease of use.

Simpler Backstage Alternatives

If convenience and simplicity is your current priority, there are Backstage alternatives like Port or Cortex, which offer off-the-shelf convenience and often a lighter lift for implementation. However, this comes with some considerable trade-offs:

Closed-source limitations: You’re locked into the vendor’s roadmap and have very limited ability to extend the platform.
Reduced adaptability: These tools might not evolve with your team’s unique needs as you grow.

The question to ask yourself is: Do you need something flexible enough to grow with you, or are you content with a tool that works for now, even if it’s less adaptable and extensible in the long term?

3. Your Tech Stack Isn’t Complex Enough to Need Backstage

Backstage thrives in environments with sprawling tech stacks, multiple tools, and complex pipelines. If your stack is modern, unified, and relatively simple, you might not yet feel the pain points that Backstage is designed to address.

A Clean Slate vs. Spaghetti Code

Clean, modern stacks: If your stack is built on Kubernetes with a single CI/CD pipeline and minimal microservices, you might not feel a need for Backstage’s service catalog or tech documentation features.
No legacy systems: Backstage shines in environments with years of accumulated tech debt - spaghetti code, undocumented services, and disconnected tools. If your stack is new and clean, those pain points might not exist.

Backstage Alternatives for Simple Stacks

Backstage is designed for scale. If you’re not experiencing rapid growth or dealing with legacy complexity, simpler tools like GitHub Wiki/Confluence for documentation and an internal wiki or a Google Sheet for your service catalog might suffice for now. However, it’s worth planning ahead:

As your team grows, even a clean stack can become difficult to manage.
Early adopters of IDPs often avoid the scaling pains that hit later-stage teams.

Backstage may not be for you today, but as your team and stack evolve, you might revisit its benefits down the line.

When is Backstage Right for You?

The decision to adopt Backstage depends on your team’s size, priorities, and tech stack. For small teams with simple needs, or for organizations that value convenience over customization, Backstage might feel like overkill. But as you grow—crossing those critical thresholds of 50, 100, or 150 engineers—or face challenges of service sprawl, tribal knowledge, and legacy complexity, an Internal Developer Portal like Backstage can be transformative.

If you’re wondering whether Backstage is the right fit for your team we’d love to help you.

Backstage: How much does it really cost?

Jian Reis — Thu, 23 Jan 2025 10:38:23 +0000

As software engineering teams and their products grow in size and complexity, delivering a good developer experience becomes a strategic priority for engineering leaders. Internal Developer Portals (IDPs) are a force multiplier for developer experience, improving service discoverability, reducing cognitive frustration and mental load, and ultimately boosting productivity and efficiency. This is why Gartner predicts that 80% of platform engineering teams will use these portals by 2026.

Backstage, an open-source project initially developed by Spotify and donated to the CNCF, is a popular choice for implementing an IDP precisely because it’s open-source, and therefore appears to have a low cost to implement. Compared to proprietary IDPs, which have monthly usage costs which are predictable but add up over time, Backstage allows teams to start independently and for very little or no cost (or so the thinking goes). In reality, the Total Cost of Ownership (TCO) of implementing Backstage can be surprisingly high, along with the effort to do so.

Breaking Down the Backstage TCO

Why? What about implementing an open-source solution like Backstage is so expensive? The first and most important thing to realize is that Backstage is not actually an IDP; it is a framework for building an IDP. This distinction is far from semantic and is critical to understand right from the start - Backstage requires substantial development and customization to become a functional IDP. It is not an out-of-the-box ready product and understanding the lift required to set up and run a Backstage IDP is critical for evaluating the total investment required.

1. Backstage Initial Setup Costs

Even just setting up an initial Backstage IDP involves considerable work that organizations often underestimate.

An Entirely Do-It-Yourself Approach

Backstage is often picked because of its flexibility and extensibility. This flexibility is one of its core strengths, but it also means you need to do everything yourself - very little of what you might consider an essential IDP feature works out of the box. Organizations need to allocate significant developer resources to installing and configuring Backstage, as well as setting up plugins and integrations. Getting an MVP instance of Backstage working from scratch can take days or even weeks, involving tasks like configuring core services, setting up entity providers, integrating authentication systems, and customizing plugins.

Skill Requirements

Backstage is typically managed by platform or DevOps teams. However, Backstage itself is built using TypeScript, with a NodeJS backend and a React frontend. This requires skills in TypeScript, HTML, CSS, and frontend development - skills not always necessarily available within platform teams. Developing or sourcing these skills is essential for successfully setting up, customizing, and ultimately extending Backstage into a fully functional IDP.

2. Ongoing Operational Costs

Once the initial version of a Backstage IDP is up and running, there are significant operational costs involved in keeping the portal running. These include tasks such as security patching, managing version updates, integration maintenance, monitoring system health, and the inevitable and unenviable task of providing support and troubleshooting bugs.

Maintenance and Upgrades

Backstage requires regular updates and patches to keep up with changes in its ecosystem. Teams need to allocate resources for system health monitoring, applying bug fixes, and handling version updates. Maintenance can become particularly challenging due to the frequent updates driven by community contributions. For instance, many organizations found the new Backstage backend upgrade complex and time-consuming to manage. Without careful planning and dedicated resource allocation, keeping the portal secure and fully functional becomes a constant challenge.

Support and Troubleshooting

Unlike commercial software, Backstage doesn’t come with dedicated support. Organizations must allocate internal resources or outsource support services, both of which add substantial costs. For even mid-size engineering organizations, maintaining a Backstage instance often requires at least one full-time support engineer - this grows quickly as organizations scale. With 1,600 engineers for instance, Spotify had a full-time team of four engineers working on their IDP.

Bug Fixes and Custom Plugin Development

Bugs are an inevitable part of any software, and Backstage is no exception. Because Backstage is open-source, teams often need to rely on community contributions, which can sometimes delay fixes compared to commercial support. Fixing bugs in an open-source environment involves a combination of tracking down issues internally and hoping for quick community fixes - both of which can lead to delays. However, because much of the real functionality for Backstage comes from a variety of plugins which are managed by different teams, levels of responsiveness and support vary substantially from plugin to plugin. Moreover, teams often need to develop custom plugins to meet specific requirements that aren't available out of the box. This adds another layer of ongoing development costs, requiring dedicated engineering time to build, test, and maintain these plugins.

3. Long-Term and Hidden Costs

Beyond the initial setup and ongoing operational costs, there are long-term and less visible costs that organizations need to consider.

Long Time to Value

Backstage can take time to deliver value, as it often requires extensive customization and collaboration to build out a robust software catalog. Achieving high levels of catalog completeness involves significant coordination across multiple teams, which can delay tangible benefits and extend the timeline for realizing productivity gains. Many adopters struggle with driving catalog adoption, with some reporting challenges in achieving high levels of completeness even after extended periods. Adoption challenges can result in delayed value realization, undermining the original productivity and efficiency goals.

Opportunity Cost of Developer Time

Implementing and maintaining Backstage requires a considerable allocation of developer hours - hours that could otherwise be spent on core business initiatives. The opportunity cost of dedicating skilled engineers to Backstage rather than focusing on product velocity is often substantial, as tasks like feature enhancements, infrastructure improvement and optimization and bug resolution for customer-facing products may be impacted. This trade-off can ultimately impact a company’s ability to deliver product improvements and address customer needs quickly.

Advanced Functionality Requires In-House Development

Much of the more advanced functionality that large organizations desire - such as cloud cost insights, Tech Insights, Role-Based Access Control (RBAC), or other compliance tools - needs to be developed in-house when using Backstage. These features aren't included out of the box, and the existing Backstage solutions are still in their early stages. For example, the current Backstage RBAC implementation lacks advanced permission granularity, which many enterprises require. As a result, additional engineering investment is often needed to design, implement, and maintain these features. These added costs can be significant, particularly when dealing with complex use cases or compliance requirements.

The Backstage Reality Check

The truth is that building a fully functional IDP using Backstage is a bigger lift than many organizations anticipate. Gartner’s Innovation Insight for Internal Developer Portals report indicates that standing up a Backstage instance is a substantial undertaking, which is something many organizations only realize once they start experimenting with Backstage themselves.

While there are plenty of compelling examples of organizations who have implemented incredible Backstage portals, such as Zalando, American Airlines, and Trendyol, companies looking to create a robust platform like should expect to dedicate two to five engineers for several years. For example, Zalando's core team working on their Backstage-based solution consisted of three engineers and an engineering manager, actively developing since 2020. The cost of maintaining this team over four years easily exceeds $4 million, with broader team contributions pushing the total investment higher.

Successfully deploying Backstage requires more than technical expertise; it demands a product mindset, as well as skills in project management and developer relations. Top Backstage adopters treat the portal like a product, viewing their internal engineers as customers. This product-focused approach encourages continuous improvement and sustained engagement, ensuring that the IDP evolves to meet the needs of its users. Driving adoption involves actively promoting the tool, onboarding teams, and fostering consistent engagement - activities that are essential for success but may require different approaches and skills compared to traditional platform engineering roles. Many leading adopters have embraced this product-oriented mindset by actively gathering feedback, iterating on features, and promoting internal usage. In cases where these skills are not available internally, organizations may need to consider external partners to help drive adoption and success.

The Roadie Alternative: A Better Way to Backstage

Granted, Backstage offers an incredibly flexible framework for building an internal developer portal, but the complexities and costs of implementing and maintaining it can be daunting. This is where Roadie comes in - a managed Backstage solution that significantly reduces the setup, customization, and maintenance burden.

Roadie was born out of the desire to reduce the complexity and effort required to set up and manage a Backstage portal. For example, Paddle, a technology company, transitioned from self-hosted Backstage to Roadie to alleviate the maintenance burden and complexity involved in managing their IDP. By leveraging Roadie’s managed setup, Paddle was able to cut down their management time and cost significantly, enabling their teams to focus on higher-value projects rather than the ongoing operational overhead of Backstage.

With Roadie, organizations get a fully managed solution that eliminates the need for dedicated engineering teams to spend months configuring, maintaining, and supporting their Backstage instance. Roadie provides a streamlined way to enjoy the benefits of an internal developer portal without the ongoing overhead of maintenance, allowing engineering teams to focus on building features that drive business value.

1. Accelerated Setup

Roadie handles the configuration and customization of Backstage, cutting setup time from weeks or months to hours or days. With pre-configured integrations including SCM tools like GitHub and GitLab, authentication and identity providers such as Okta, and documentation solutions like TechDocs, onboarding becomes streamlined and efficient. Roadie's solution engineering team ensures you start gaining value from your internal developer portal almost immediately. For more details, see the full list of pre-configured integrations Roadie provides.

2. Ongoing Support and Best Practices

Self-hosting Backstage means managing ongoing bugs, updates, and configurations, which can become a time-consuming challenge for internal teams. Roadie offers a fully-managed service throughout the entire lifecycle ensuring that your platform is always running smoothly on the latest stable releases for Backstage and plugins with no action required from you.

Beyond troubleshooting, Roadie provides support via Slack or MS Teams for any technical challenges that might arise. Roadie’s partnership extends to a full Customer Success engagement, and takes a hands-on approach to helping increase catalog completeness and improve overall platform adoption. This active engagement reduces the operational burden and also empowers teams to continuously derive value from their Backstage instance with minimal friction.

3. Managed Hosting and Maintenance

Roadie manages all infrastructure, ensuring uptime, security, and compliance without effort from your team. Complexities like load balancing, service health monitoring, and scaling are handled by Roadie, leveraging our extensive expertise in delivering highly scalable and performant Backstage instances. This helps organizations realize significant savings and operational efficiencies. Regular updates are applied seamlessly, keeping your portal current without risky manual interventions.

4. Cost Efficiency

The TCO for self-hosting Backstage can reach millions of dollars over several years. Roadie, by contrast, offers a per-seat pricing model, designed to support growth over time. Only engineers actively contributing to your SCM incur costs, which means that as your usage scales, costs remain directly tied to active contributors. Meanwhile, roles like product managers or leadership can access the portal for free, providing visibility without increasing costs. This flexible pricing model ensures that expenses grow in alignment with your organization's real needs and usage patterns.

5. Focus on Developer Productivity

The primary goal of a platform team is to empower their engineering organization to be more efficient and productive. Setting up an Internal Developer Portal is just one part of that mission - it’s not the sole objective. By partnering with Roadie, platform teams can offload the heavy lifting of setup, customization, and ongoing maintenance of the IDP, freeing them to focus on other high-priority initiatives that drive strategic value and innovation. Roadie's managed solution allows platform teams to provide a powerful developer portal without getting bogged down in operational overhead.

Conclusion

When organizations begin their journey with Backstage, most envision something more than just a basic software catalog. While setting up a minimal catalog with a few essential plugins might be achievable relatively quickly with Backstage, it is unlikely to meet the long-term needs of engineering teams. The true goal for most organizations involves a comprehensive internal developer portal that acts as the central nervous system for their engineering organization.

A well-functioning IDP using Backstage then typically includes a high level of catalog completeness, advanced role-based access control for secure and granular access, integrated compliance tools for governance, custom metrics dashboards to monitor DORA metrics, and automated workflows that streamline developer tasks from idea to production.

It’s about empowering engineering teams with visibility, efficiency, and the tools they need—all in one place. Achieving this state involves building custom plugins, extending Backstage’s existing capabilities, integrating with multiple internal systems, and making sure the platform evolves as organizational needs change. That’s where the real costs start adding up—both in developer time and operational complexity.

The difference between a minimal setup and this goal-state is significant in terms of the total cost and time investment required. Most organizations underestimate the journey required to go from a basic setup to an advanced, fully integrated platform that drives genuine developer productivity. Roadie offers a managed Backstage solution that takes on this journey for you, making the goal-state a reachable reality without the ongoing drain on your team’s time or budget.

Backstage and Cost Insights: shifting cloud costs left

Jian Reis — Wed, 16 Oct 2024 07:31:48 +0000

Cloud computing - the double-edged sword

Managing cloud costs is fast becoming a strategic priority. While cloud service providers (CSPs) like Google Cloud, Microsoft Azure, and Amazon Web Services offer incredible flexibility and scalability, they can quickly lead to ballooning costs if left unchecked. We’ve all seen the cloud billing horror stories, but even for companies that have a good grip on their cloud costs, it’s easy to get into a situation where cost growth begins to outstrip associated revenue growth.

Such a position can undermine profitability, growth, and operational flexibility, ultimately putting the organization on an unsustainable trajectory. Beyond simple expense, runaway costs can mask inefficiencies in architecture, resource allocation, and service usage, creating a vicious cycle of wasted consumption. Left unmanaged, this can undermine even the most successful products, ultimately affecting their long term viability.

A notable case in point is Spotify, who encountered this scenario early on which forced the company to rethink its approach to managing cloud costs. Spotify realized that to get a handle on this, they needed to empower their engineers - the people closest to the actual cloud usage - to own the costs and be responsible for optimizing them. Rather than a top-down approach mandating a cost reduction, Spotify opted to make the engineers themselves responsible for their own cloud costs, an excellent example of the phenomenon of shifting cloud costs left.

Shifting cost awareness left: a cultural change

Shifting cost awareness left is a concept in effective cloud cost management that is gaining traction. Essentially a form of embedding cost considerations earlier in the engineering process, not as an afterthought for finance teams, that’s exactly what Spotify did, according to James Governor at RedMonk: “Spotify engineering teams are used to having a lot of autonomy, so the company couldn’t just introduce new cost guardrails as a top down concern. Therefore the Cost team tried to foster a culture where optimization would be fun.”

Shifting cost awareness left isn’t just about giving engineers tools, it’s a cultural shift where engineers take ownership of the financial impact of their work and are invested in cost optimization. When engineers are empowered with real-time cost insights, they become agents of change. Instead of waiting for an end-of-month cloud bill to identify costly inefficiencies, engineers can make informed decisions in real-time. This shifts cost management left from a reactive process driven by finance to a proactive, engineering-led initiative.

There’s a philosophical value here that goes beyond dollars and cents. By making cost awareness a core part of the development lifecycle, companies can drive a sense of ownership and even healthy competition among teams. Engineers begin to actively look for ways to optimize their cloud usage, often competing with each other to drive down costs. This culture of cost ownership not only saves money but also leads to better architecture and more efficient systems overall.

According to Janisa Anandamohan, Spotify Senior Product Manager, Cost Engineering:

We know engineers are natural optimizers when it comes to reliability, security, performance, et cetera. And now we’re telling them, hey, add costs into the mix. And they were super excited about that. We had many teams that were just able to tweak their services and data pipelines and to make them more efficient. And we know efficiency doesn’t just help cost, but helps reliability and performance as well. So we were getting double, triple wins along the way.

Spotify’s solution: Cost Insights

Spotify’s approach to shifting managing cloud costs left took the form of a cost optimization and visualization plugin called Cost Insights, on their own internal version of Backstage. The concept is simple: provide engineers with the tools to visualize and manage the costs associated with the services they build, all within the internal platform they are already using - their internal developer portal. By tying cloud costs to specific entities in the Backstage catalog, teams are empowered to take control of their spending and optimize resources more effectively.

This approach worked well for Spotify, partly due to their internal engineering culture, but mostly as a result of the significant engineering effort invested into getting Cost Insights integrated into their developer platform. While they have since open-sourced a pared-down version of the Cost Insights plugin back to the community, most organizations attempting to replicate their success will find it challenging, even when using their plugin. This is largely because of the technical complexity required, and because the current Spotify Cost Insights plugin, like many of the other aspects of the Backstage framework, is far from an out-of-the-box solution.

Just how much work would it take an engineering team, even working with the open-sourced Cost Insights plugin to implement a working solution? It’s a significant lift; here’s what they’d have to do:

Cloud billing integration: Set up a mechanism such as an API to pull cost data. This involves not only access configuration but also understanding the data schema of your cloud provider, which can be complex and time-consuming.
Backend development: Develop a backend to fetch, process, and store the billing data. This step requires designing a database schema that can handle potentially large amounts of data efficiently and setting up a server to run this service.
Cost Insights API implementation: Implement the API endpoints required by the Cost Insights plugin. This includes endpoints for fetching cost data, projecting future costs based on current trends, and breaking down costs by services, projects, or departments.
Frontend integration: Integrate the Cost Insights plugin into your Backstage instance. This may involve customizing the plugin to fit into your organization’s Backstage environment and ensuring it interacts correctly with your newly developed backend.
Testing and validation: Thoroughly test the plugin with real data to ensure accuracy. Validate the cost projections and insights with your finance team to ensure they align with actual expenditures.
Maintenance and updates: Continuously update the backend and frontend as cloud providers change their APIs or pricing models, and as new features or fixes become available in the Cost Insights plugin.

For a small team of three to four engineers, this could take anything from several months to a year to fully implement. This is a big lift for most organizations, which means that for many, this complexity keeps the solution remains out of reach. While the concept of cost transparency and shifting cost awareness left resonates, the time and effort required to implement and maintain a working Cost Insights tool deters widespread adoption.

As if it wasn’t hard enough, all of the work above assumes an organization is using only a single CSP in their stack. In reality, any organization that is using multiple CSPs (say, AWS and GCP) faces a thorny additional hurdle: the lack of data homogenization and normalization from CSPs. Each CSP often presents cost data in a different format, making it extremely challenging for organizations to consolidate and interpret this data in a unified manner if they’re using multiple CSPs.

Fortunately, the recent introduction of the FOCUS (FinOps Open Cost and Usage Specification) standard has changed the landscape for the better. Developed as a collaborative effort by the FinOps Foundation, the FOCUS standard aims to normalize the cost and usage data across different CSPs, providing a common format that makes it easier for organizations to integrate and analyze their cloud spending. This standardization is a crucial enabler, simplifying the data integration process and reducing the overhead associated with translating disparate data formats.

Introducing: Roadie’s Cost Insights Plugin

The adoption of the FOCUS standard significantly simplifies the integration of cost data across various cloud platforms. However, the complexity and effort of setting up Cost Insights is still high - which is where we at Roadie saw an opportunity to help. We recognized that the idea of empowering engineers to manage cloud costs was spot on, but the solution needed to be simpler, more accessible, and ready to use out of the box. As such, we’re in the process of refining and enhancing the existing Cost Insights plugin, making it significantly easier to deploy and use right out of the box.

Our enhanced Cost Insights plugin builds on Spotify’s version, but aims to reduces the setup friction, allowing engineering teams to access powerful cloud cost insights immediately - no custom backend development required. This streamlined approach means engineers can spend more time optimizing their services and less time managing the infrastructure for cost tracking.

With Roadie’s plugin, teams can quickly see which services are driving up their cloud costs, how those costs have trended over time, and what actions can be taken to reduce unnecessary spending. The key here is not just providing data but making it accessible and actionable, so engineers can immediately use it to make decisions.

Roadie’s Cost Insights plugin takes full advantage of the FOCUS standard, ensuring that the data we present is both accurate and comparable across providers. By eliminating discrepancies in how cost data is reported, the plugin enables engineers to gain a clear understanding of their cloud usage without needing to reconcile different data formats.

The ability to assign costs to specific entities within a Backstage catalog is what we’re most excited by. In traditional cloud billing tools, costs are often presented at a very high level, making it hard to drill down and see what’s truly driving the expenses. By associating costs with individual services and the teams responsible for them, the plugin makes cloud costs real and relatable for developers. When a team sees exactly how much their service is costing, they can no longer ignore it or avoid responsibility - it becomes part of their job to optimize those costs.

The Roadie Cost Insights dashboard displaying cloud cost by product

How it works

Our Cost Insights plugin, currently in internal beta, integrates seamlessly with a Roadie-managed Backstage instance to provide teams with an out-of-the-box solution for tracking and managing cloud costs. Key features include:

Easy setup: No complicated setup required - simply connect to your cloud service provider to Roadie Cost Insights via your cloud administration settings or via a secure broker, and allow the Roadie Cost Insights compatibility layer to take care of all the data modeling and translation.
Project and group-based cost tracking: Track cloud costs at the entity, team, or product level, and drill down into specific projects or groups for more detailed insights.
Trend visualization: View cloud cost trends over time, breaking down data by dimensions like products, services, and regions to identify patterns and anomalies.
FOCUS standard integration: The plugin leverages customer-provided FOCUS data, ensuring consistency and like-for-like comparability across cloud providers.
Actionable insights: Dashboards help engineers take ownership of their services, and immediate action by optimizing those services or reducing over-provisioned resources.

For example, a team might notice that the costs of a particular product are rising faster than expected. With Roadie’s plugin, they can drill down into the cost breakdowns, identify high-cost services, and take corrective action - such as optimizing resource allocations or reducing usage.

Roadie Cost Insights also supports multiple regions, meaning a DevOps team managing multiple cloud services in different regions could use Roadie’s Cost Insights to track cloud costs by region. For instance, they could spot that their compute resources in one region are significantly more expensive compared to others. Using the plugin’s trend visualization and breakdown capabilities, the team can identify the services or instances driving up the cost and adjust their architecture to either reduce or move resources to more cost-effective regions.

Roadie Cost Insights Architecture - note that the user configuration overhead is limited to installing the Cost Insights client on the cloud service provider infrastructure (or the use of a broker client) while Roadie takes care of all the backend setup.

The future of Roadie’s Cost Insights Plugin

We believe that by simplifying cost management and putting it directly in the hands of engineers, companies can not only save money but also drive innovation, efficiency, and alignment across their teams.

Cloud cost management is no longer just a financial issue—it’s an engineering one. By providing real-time insights into cloud spending and shifting cost awareness left, Roadie’s Cost Insights plugin helps companies empower their engineering teams to take ownership of their cloud usage. This leads to smarter decisions, lower costs, and more efficient systems.

While Cost Insights is still currently in an internal beta, if you’re interested in learning more or becoming an early design partner, get in touch with us today. We’d love to work together to bring the future of cloud cost management to your team.

Title image by Brian Penny from Pixabay

Adopting Backstage - Documentation and Support

Jian Reis — Thu, 03 Oct 2024 11:02:51 +0000

This is the first in a series of posts aimed at helping organizations to adopt Backstage.

Making Backstage Easier for New Users

Imagine opening Backstage for the first time, searching for a service, and finding... nothing. How do you even search properly? You’d need to understand concepts like entity kinds, types, and ownership.

And if you can't find the entity, how do you add it? This requires knowing your organization’s ingestion patterns: Do you need a YAML file in the code repo? Or do you manually input the URL into the import flow? Without internal support or clear, beginner-friendly getting started documentation, this process can feel like a maze.

Backstage isn't always intuitive, especially for new users without internal support or clear documentation. Most available open source documentation is aimed at implementers, not end users. It’s often generic, overwhelming, and assumes you’re using GitHub as your SCM system. So, what can you do to make Backstage easier for your team?

How to Simplify Backstage for Your End Users

Invest in User-Friendly Documentation

For Backstage to succeed in your organization, internal getting started documentation to help users use Backstage is a must. This documentation should be front and center for new users, which might mean putting it in an existing documentation platform even if your goal is to eventually move all docs into Backstage’s TechDocs. You can use the Homepage plugin to highlight certain top level info for new users including a preview card for your getting started docs in TechDocs.

Your getting started docs should open with a clear intro to what Backstage is and how it helps. Include simple examples of its core features, remembering that many new users won’t even know what an internal developer portal is meant to do.

As well as have a intro page in your internal documentation explaining it you could also publish a blog post introducing IDPs to your engineers.
i.e. Sample content for an intro to IDPs and Backstage

### Internal Developer Portals
An Internal Developer Portal (IDP) is an application which is designed to give our developers easy access to information and commonly used workflows. Its goal is to reduce context switching and toil for developers by providing a “single pane of glass” that helps to improve productivity, reduce duplication of effort, and foster a more cohesive and efficient development environment.

An IDP is a place to find information about the software we build and use, the teams who build that software, and the API specs, code repositories and documentation associated with that software. It also typically provides self-service automation scripts for common tasks like creating applications or making changes to infrastructure, and scorecards to help ensure that software is adhering to best practices.

### What is Backstage
Backstage is an open-source platform for building developer portals. It was originally created by Spotify to manage and streamline their complex microservices architecture and was released for public use in 2020. 

**Key features of Backstage include**:
- Software Catalog: A centralized listing of all services, providing an overview and allowing easy management and discovery.
- Software Templates: Streamlined processes for setting up new projects and services with pre-defined templates.
- Plugins: Backstage is extensible with plugins to integrate with various tools and services used in AstraZeneca.
- TechDocs: A documentation site generator that converts Markdown files into a browsable documentation site.

Backstage aims to improve developer productivity and collaboration by providing a single, cohesive interface for all development-related activities.

Identify key user journeys and craft your getting started content around them:

Why would a software engineer or product manager initially visit Backstage?
What are they trying to accomplish?
What problems could Backstage help with?

Talk to teams who are just onboarding or align these journeys with company-wide initiatives. If, for example, you see the Scaffolder as a high-value feature, start with docs explaining how to use it and how to modify templates.

You could create these docs in TechDocs and link them from wherever engineers currently go for org-level documentation or just create them in existing documentation systems like Confluence.

Ensure they are searchable by including the right keywords in titles and descriptions, whether hosted in Backstage or elsewhere.

Lastly, publicise these docs as much as you can - get a few blog posts out on any internal news distribution channels, ping organization wide channels with the link and a short teaser description (we’ll be writing a more detailed post about internal marketing very soon with a bunch of resources for you to use).

Create a Dedicated Support Channel

Establish a clear support channel—like a Slack or Teams group—where users can ask Backstage-related questions. This not only helps with adoption but also builds a community where knowledge is shared and best practices emerge.

Pin relevant internal and external docs in these channels to avoid repeated questions. Support channels are also a great place to identify gaps in your documentation, allowing you to improve onboarding and make it as self-service as possible.

You could even nominate Backstage champions—advocates within your organization who can help answer questions and lighten the load on your Platform Engineering/DevOps teams.

At Roadie, support channels with our customers have been essential to successful Backstage rollouts. While documentation is the first line of defense, having a place for follow-up questions is key to encouraging usage and reducing friction for busy engineers.

By streamlining these two areas—user-friendly getting started documentation and a dedicated support channel—you’ll make engaging with Backstage a smoother experience for your team and boost adoption.