IDP vs. Self-Service Portal: A Platform Engineering Showdown
In 2007, the world was introduced to DevOps. This approach involves bringing together development and operations teams to speed up deployments and improve efficiency and collaboration in the software development lifecycle. It is credited with being twice as fast as a traditional approach.
Yet, according to the most recent State of DevSecOps 2023 report, only 9% of companies use DevOps exclusively, and just 20% use it for more than half of developments. Why is uptake so low when the benefits are so clear? The report also reveals that 80% of organizations have struggled with DevOps adoption in the past five years.
Improving the developer experience (DevX) has been identified as key to driving uptake. A positive developer experience will boost productivity. DevX impacts how efficiently developers write, test and deploy code. Developers are likelier to adopt and advocate for tools and technologies that offer a seamless and intuitive experience.
The focus, however, has evolved from creating better conditions for developers to making processes more intuitive and engaging. To achieve this goal, we have seen the birth of platform engineering and the creation of internal developer platforms (IDPs) that offer curated tooling and services — CI/CD pipelines, containerization, monitoring tools and so on — to enable developer self-service.
So far, it’s been helpful for the developers. But what about the other less technical stakeholders within an organization who are also involved in consuming IT infrastructure? The solution architects, opts, DevOps, FinOps, security teams and network teams all contribute to the business but aren’t dedicated developers.
While the Gartner definition of platform engineering focuses heavily on DevX, it’s just one piece of the puzzle. A truly impactful platform isn’t just for developers; it’s for a much wider variety of teams.
Self-Service Portals
It’s easy to get lost in the sea of IT acronyms at the best of times, and the platform engineering ecosystem is the same, particularly given that these two options seem to promise similar things but deliver quite differently. For many organizations, choosing or building an IDP might be what they think is required to save their developers from repetitive work while looking for a self-service portal (SSP) to streamline automation.
Used correctly, an SSP can become the beating heart of an organization’s digital transformation journey. They provide the governance capabilities to define roles, a service catalog to enhance efficiency, and automation that takes care of manual tasks while reducing human error for all the teams within an organization that are consuming IT infrastructure but, critically, are not dedicated developers.
Serving as a bridge between teams, users like project managers, QA testers and even business stakeholders can all benefit from having access to helpful governance and automation tools through an SSP. These tools empower “non-developers” to keep track of projects, identify bottlenecks and gain insights into the development process without needing deep technical expertise.
SSPs also encourage collaboration, which should be baked into every corner of the portal. Shared repositories allow users who would normally be reliant on the technical skills of a dedicated developer to store code with automated version control in order to keep everything running smoothly, as well as code reviews to ensure everyone is on the same page.
This seamless work across platforms for a far more comprehensive range of users is beneficial, so what’s the problem?
The Russian Doll Effect
First, it’s about identifying a need. For many organizations, acquiring or building an IDP that will fix operations overhead and enable developer self-service sounds like a straightforward decision, but there is some confusion around identifying what an IDP actually is and how to obtain one.
Backstage, the Spotify open source platform, has been making big waves in the platform engineering space by offering a plug-in system that makes an IDP extremely customizable and collaborative. The reality, however, is somewhat different, and this DIY approach can make the whole process even more confusing.
This is where a holistic view is helpful to enable development oversight. This provides all users with a stake in the game — managers, CFOs and even sustainability officers — with the ability to zoom out of the day-to-day software development tasks and look at the bigger picture.
By providing a user-friendly interface to define and deploy cloud resources, an SSP frees up the time and effort required to set up complex infrastructure configurations. Centralizing resources provides oversight while also enabling guardrails to be established to protect against “shadow IT” being deployed. This not only helps identify resources that aren’t being used to save money but also helps make cloud practices more eco-friendly by removing unnecessary resources.
This is the main difference between an SSP and an IDP, and understanding which capabilities an organization needs is critical for ensuring a smooth platform engineering journey. Like a Russian doll, an IDP is a layer on top of an SSP that offers tools to streamline the entire software development lifecycle. The SSP is about functionality and automation for everyone involved.
The big doll is the engineering platform — the tricky bit that explains why a platform engineering journey takes roughly three years. This comprehensive solution transcends the boundaries of SSPs and IDPs. The engineering platform is an overarching concept that spans many functionalities, including resource management, ecosystem collaboration and plug-in integration. Designed to cater to individuals of all skill levels, it offers a user-friendly interface and customizable features to suit diverse needs and workflows.
The relationship between all three layers is like a puzzle where every small detail matters, even if it seems insignificant at first glance. As mentioned initially, DevOps has come a long way since 2007. But thanks to the recent advent of platform engineering as well as IDPs that are all neatly accessible via an SSP, we now have the potential to accelerate improvements in the discipline, and create frictionless self-service environments that open up development to the broader workforce.
