Commercial Internal Developer Portals (IDPs) are a valuable investment for teams that want to move quickly toward addressing initiatives surrounding software ownership, production readiness, and improving developer experience. But there's a common misconception that all commercial internal developer portals (IDPs) carry an inherent risk of “vendor lock-in” vs open-source alternatives like Backstage.
While it’s true many SaaS providers use proprietary components, which rightfully may leave users feeling a bit uneasy about where they build, this isn’t true of every option in the market today.
In this article, we’ll share what to look for in prospective vendors to ensure you can move critical business logic if and when you need to without facing exorbitant switching costs, and what additional traits you should look for to future-proof your IDP investment.
Risks of IDP lock-in
An IDP serves as a central hub for engineering teams to track, record, and improve tools and processes used to build high-quality software.
Vendor lock-in refers to a situation where a customer becomes heavily dependent on a particular vendor's products or services, making it difficult or costly to switch to alternative solutions.
Because an IDP is at the center of a healthy engineering organization, vendor lock-in can be especially detrimental if you’re stuck with an IDP solution that ultimately isn’t meeting your team's needs.
As the engineering community identifies new metrics and methods for promoting developer productivity, your IDP should also be incorporating those strategies. If an IDP doesn’t evolve overtime or provide the core functionality your team needs, you may find yourself unable to streamline the developer experience or increase visibility for all stakeholders—core tenets of an effective ICP.
How to ensure your IDP is scalable and portable
By definition, staying clear of vendor lock-in means you’ll have the freedom of portability. You’ll have more leverage to negotiate your current IDP contract, get the most out of your existing vendor, or easily migrate if needed.
There’s a few core areas to consider when selecting an IDP provider that won’t lock you in.
Portable business logic
Question to ask: Is the catalog tracked in a proprietary format?
Why it matters: A red flag for any SaaS product, including an IDP, is when your data gets stored in a proprietary format that the vendor dictates. This is problematic for multiple reasons.
For starters, it makes it painful or even completely unviable to ever change IDPs. Migrating all your data may be prohibitively time consuming and the risk of data loss could outweigh the potential upside of switching. You end up trapped.
Not only that, but you risk not retaining ownership of what should be your own data. For many enterprises, this would be a dealbreaker for security and privacy reasons.
How Cortex addresses this: Cortex is the only IDP that uses YAML to track services. YAML is a universal, popular programming language that is designed to be easy to read and understand.
Beyond that, you'll find that Cortex YAML files are also a valid OpenAPI format, the most widely used API description language. We extended the OpenAPI spec with Cortex-specific tags to ensure that we were reusing common formats that are already adopted in the industry.
Chances are, your engineering team is already using OpenAPI in different parts of your systems to help describe APIs and other components. Since Cortex YAML files are in a common format that is widely adopted in the industry, if ever you decide to move your IDP away from Cortex, leveraging Cortex YAML files is straightforward.
Standard framework for infrastructure automation
Question to ask: Is ownership of the different components in the IDP driven through GitOps?
Why it matters: Ensuring that your IDP uses GitOps to systemize the different pieces that go into the IDP is another way to help avoid vendor lock-in.
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation (source: GitLab).
Managing functionality through GitOps helps you keep track of all the different use cases for your IDP, and then gives you ownership to manage it in Git.
How Cortex addresses this: We already talked about how Cortex uses YAML and OpenAPI to track services, but Cortex is the only IDP that also lets you power all the functionality inside the IDP directly through GitOps and YAML.
For example, while you can create Scorecards directly in the Cortex UI, you can also create them using YAML, and you can then manage them directly through Git. The format and data around Scorecards stays in your code base and is version controlled for the future.
Data storage and self-hosting options
Question to ask: What mechanisms are in place to ensure that I own all of my own data and minimize risk?
Why it matters: Retaining ownership over your data is critically important.
You also want to be able to leverage all existing data, so you want to make sure that the IDP can bring in custom data from internal systems. Related to those integrations, it's also important to check what kinds of data are actually being stored and tracked within the IDP. You want to ensure that sensitive data is not actually being stored unnecessarily which could expose you to increased risk in the case of a breach.
How Cortex addresses this: With Cortex, you can easily connect to custom data from internal systems. We made the explicit decision to not track any personal data of our users or store any of the actual data we're pulling from your integrations. This has allowed us to gain the trust of countless enterprise security teams.
We also believe that it’s important for organizations to always have the option to go on prem if your security requirements change in the future. Cortex offers an on-prem version which allows customers with more stringent requirements to host everything in their own air gap systems.
Extensibility and scalability
Question to ask: What does the plugin ecosystem look like?
Why it matters: A good sign when choosing an IDP is if they value extensibility. If your IDP already has an ecosystem for plugins, it shows they’re committed to empowering their users to mix and match external services with the core IDP features.
Plugins extend the power of your IDP for long-term scalability, thus reducing the likelihood that you’ll ever be in a situation where you need to migrate your IDP. And in the event that you need to make a switch, a vast plugin ecosystem can aid in the migration.
How Cortex addresses this: At Cortex, we’re the only commercial IDP that offers a plugin framework. With 50+ plugins, you can bring data from anywhere to extend your IDP experience. Cortex plugins let you build apps that can be embedded in the Cortex UI and fed from any data source. And, if ever you decide to migrate to or from Cortex, you can sync your data using any of our out-of-the-box integrations, or plug-in framework to connect to any homegrown tool.
API-first approach
Question to ask: Is the IDP ‘API-first’ so I can easily export my data?
Why it matters: Having APIs to export data is a must-have for any IDP. Without a standard set of APIs for every feature, it becomes much harder to build automation to pull the data that is being managed.
In the event that you do want to move off the IDP, it is challenging to migrate without being able to actually pull the data and reuse it, especially if you're not using something like GitOps.
How Cortex addresses this: Cortex takes an API-first approach. Customers have access to all of the data across any of our product functionality. For example, we’ve seen customers pull scorecard data to do further analysis, or send data to other systems for data visualization. With Cortex, you always have 100% access to all of the data, easy to export at any time—no matter if you’re exporting data to leverage in new and exciting ways, or migrating your IDP.
Cortex: The most flexible and scalable IDP
At Cortex, we’re very cognizant of the risks of vendor lock-in. We believe deeply in the importance of a competitive landscape to push the entire industry forward, and we also know firsthand that engineering teams are better off when they choose tools they actually want; not tools they’re stuck with.
And, we’ve built a platform that is not just open, but also extremely flexible so you don’t need to worry about outgrowing it.
The considerations in selecting an IDP that doesn’t lock you in, like Cortex’s portable business logic and infrastructure framework, doesn’t just create the option of portability; it also makes it simple to get started with Cortex in the first place. For instance, if you’ve already started building your IDP using Backstage, we have a plugin to streamline the migration to Cortex.
To learn more, request a demo today.
