The Hidden Costs of ‘Free’ Internal Developer Portals

You’ve heard about the significant benefits that internal developer portals offer. IDPs can help your engineering teams increase velocity and reliability as well as boost the developer experience by organizing all the essential information about your applications, services, environments, clouds and team in one self-serve place.

IDPs also enable your engineering leaders to measure and manage initiatives to improve compliance with architectural and operational standards, security and regulatory demands. They even serve as a central resource catalog for your operations team so they no longer need to traverse multiple clouds, accounts and availability zones via clunky cloud consoles to find basic resource information.

Now you’re probably wondering: Which type of internal developer portal should we implement? Should we try a specialist vendor or use a free solution like Spotify’s Backstage open source project?

Those are fair questions. Why pay for a dev tool if you can deploy a free alternative? As we’ll illustrate below, the free-IDP approach costs way more than you think.

The Two Types of ‘Free’ IDPs

1. The Open Source Model (Spotify’s Backstage)

The most common free IDP on the market is Backstage.io, a platform developed by Spotify to help with its own engineering initiatives and was later made available to the open source community and before it was eventually accepted into the Cloud Native Computing Foundation.

Although Backstage is technically free, in the sense that you won’t pay a vendor for seats or licenses to use the tool, you need to understand that it will generate substantial costs, both in an absolute sense and relative to your alternatives. A few examples:

Your Team’s Time

Backstage requires a substantial internal engineering investment to set up and maintain the project.

Difficult to Set up

Installation: Despite being a CNCF offering, Backstage doesn’t ship prebuilt Docker containers. The installation requires Node.js and Yarn and, depending on your existing tech stack, likely requires additional personnel to build the IDP and keep it running.

Backstage is a code-based product that requires a lot of customization via editing both source and YAML files. There’s no single-click, or even multiple-click, installation procedure. You’ll almost assuredly need a sizable dedicated team to maintain the system and to keep the application up to date.

Data Integration: Further, to unlock value from a catalog like Backstage, you have to get the right information into it. This happens via plugins, which are written by third parties. As a result, the quality of material varies among plugins, and it’s entirely up to you to view the plugin’s GitHub repository and decide whether it’s worth installing.

For instance, the Backstage Kubernetes plugin supports native K8s and provides helpful details about status, errors, proximity to autoscaling limits and container restarts. But there is no plugin for Azure Kubernetes Service (AKS) or Amazon Elastic Kubernetes Service (EKS), and the Google Kubernetes Engine (GKE) plugin is limited to usage and cost monitoring.

Additionally, plugins have different depths of implementation. For example, some will enable search and others won’t, and you won’t know until you read the code to see exactly what you’re getting with respect to the depth of a plugin’s capabilities. The documentation will likely be scant, if it exists at all.

Configuring plugins to bring data into Backstage adds an additional layer of work for your team. Each plugin requires configuration versus single-click integration offered by leading specialist vendors. Where Backstage does have plugins for a few cloud resources, the number is extremely limited, and you must configure a plugin per cloud service versus a single-click integration for all of your cloud resources. (AWS Lambda and AWS Proton each require their own plugins with separate configurations, whereas one-click AWS integration covers dozens of cloud resource types.)

Configuring search: For almost every enterprise, the core value proposition of a solution like Backstage includes enabling users to discover services and other assets via a simple search in the UI. Backstage offers a search module, but you must have the time, staff and money to put in the effort to use it. The project focuses all the use cases on searching for entities, and none covers the relationships between them, which is a hint about Backstage’s limitations.

Maintenance Costs

Maintaining an open source solution like Backstage will require an ongoing commitment of your team’s time and resources — time and resources your company will be diverting from improving your products and delivering value to your customers.

A CloudSmith article points out that organizations managing their own Backstage platforms in-house might spend as much as 30% of their time upgrading their Backstage instance.

Backstage also lacks a solution for data integrity. As such, when data in an enterprise’s toolchain changes, catalog entries in Backstage become stale until a service owner independently recognizes that drift has occurred and manually updates their YAML files.

Opportunity Cost of Missing Features

Backstage’s general lack of infrastructure awareness and its syndicated approach to gathering and displaying data harms more than just search capabilities. It also limits the platform’s ability to support critical use cases, such as a resource catalog, and to provide useful analytics. Backstage lacks the comprehensiveness of the catalog contents and flexible analytics that its paid competitors have.

Backstage does offer insights, but you’re locked into its pre-canned Tech Health and Cost tools, and the data they report is limited to what plugin developers decide to offer.

Many of these limitations come from Backstage’s architecture. It acts as an abstraction layer over your existing services and tools. It reads YAML files and feeds describing your infrastructure, but it has few querying and reporting capabilities. It simply displays a syndicated feed that describes your assets.

This severely limits Backstage’s ability to enable users to answer questions and build useful analytics, and it even limits the utility of the core catalog in some cases. (Imagine if you don’t have a time series database to easily observe change history when troubleshooting.)

As a result, your organization will likely fail to capture the business value available in alternative solutions. You should carefully assess the business value associated with analytics and scorecard scenarios around reliability measures, architectural compliance, remediating security vulnerabilities, controlling cloud costs and other supported scenarios versus what you can accomplish in Backstage out of the box. Your organization could lose out on a material return on investment due to Backstage’s limitations versus what leading specialist vendors can offer.

Bottom line:

Organizations that adopt the Backstage project may forgo material value they could otherwise create through available alternatives. The unfavorable ROI versus paid alternatives manifests in three areas:

• Costs from your fully loaded internal labor investment in supporting Backstage in excess of the cost of a special vendor solution.
• The opportunity costs of your internal team’s time (the business value they could have created by focusing on customers versus building an internal tool).
• The opportunity costs of scenarios that unlock meaningful business value, which your company could realize with specialist solutions but not with Backstage.

A side note about Backstage hosting providers: Hosted Backstage can partially alleviate certain internal costs (and opportunity costs); however, you should still consider the incremental business value from resource catalog, analytics, scorecards, search and other important scenarios available with specialist vendors.

Further, Backstage hosting providers can have limited resources, so they may not be willing to apply updates right away and/or may ration support resources via prearranged commitments. So instead of keeping your costs as low as possible, you may be presented with a minimum. Beware of nontransparent pricing!

Our recommendation: Don’t take our word for any of this. Do your own research. Find an engineering leader at an enterprise using Backtage.io, and if possible, another whose company has migrated from Backstage to a best-of-breed IDP. Let them tell you about the true costs of the free model and the benefits of using a purpose-built tool. Then use an evaluation framework like the one below to understand where your highest return on investment lies for your scarce internal resources.

‍

2. The Bundleware Model (a Free Add-On for a Tool You’re Paying for)

Bundled offering is another free internal developer portal that was recently introduced. It’s when software vendors sell tools in adjacent markets and offer their own proprietary IDP in the bundle.

With a bundled IDP, the costs could be even more significant because these tools may lack even more of the critical features you’d expect from your developer portal.

Costs of Missed Functionality

Bundled developer portals thrown in to sweeten the deal of a SaaS company’s core product are, by definition, built and supported by companies that don’t specialize in IDPs. That means these products may lack key functionality today and won’t face the same pressure to innovate moving forward.

Examples of potentially missing features:

• Scorecards and analytics
• Microservice catalog only vs. a universal catalog that is environment- and resource-aware
• Lack of breadth and depth for supported toolchain integrations
• Limited support for key scenarios for application engineers, DevOps, engineering managers and architects

You should quantify the business value of important feature gaps to ensure you and your stakeholders understand the business value per engineer you’ll trade for obtaining a free tool. Forgone value includes the value the missing feature would have created for your enterprise as well as the direct and opportunity costs of any partial solutions.

Yes, it was “free,” but this vendor’s bundled IDP is clearly not serving its enterprise customer well in this example.

Money-saving tip: Negotiate a discount with your bundleware vendor’s product.

Specialist IDP vendors generally offer transparent pricing. The cost of a specialist vendor solution that meets your organization’s needs effectively represents the perceived cost your bundleware vendor wants you to credit them with offsetting by adopting their solution and allowing them to otherwise maintain pricing for their core product.

Turn the tables on the vendor by requesting a discount on their core product equivalent to the cost of a specialist vendor’s internal developer portal. By doing so, you will accomplish three valuable objectives:

• You get a purpose-built IDP tool that will add value to your operations and deliver all of your desired ROI.
• You save money on your bundleware’s core product.
• You avoid the tempting trap to deploy a free but inferior — and potentially costly, as we’ve demonstrated here — bundled IDP that will fail to deliver the value you’re hoping for.

Bottom line: You are likely to generate a superior return on investment by selecting the best-in-class tool and negotiating a discount with a bundleware provider.

So there’s your two-pronged strategy for success: Invest in a leading, purpose-built IDP, and then leverage your bundleware vendor’s claims about their IDP’s value to extract more favorable terms for their core software solution.