The Differences Between a Service Catalog, Internal Developer Platform, and PaaS

Often teams in this position start thinking about or using Kubernetes or consider using infrastructure as code and look for a solution to solve internal deployment and discovery problems.

Primarily large or fast-growing companies start looking for solutions and are faced with the question of building their own vs. buying. Even if you do extensive research, it's not easy to distinguish similar-sounding solutions. These include a platform as a service, a service catalog, or an internal developer platform, and they can, on the surface, sound similar. This post looks at some of these options to highlight the similarities, differences, and when or why you might want to use one.

Platform as a Service

One of the most established options, a platform as a service (PaaS), is a comprehensive solution for a cloud-based development and deployment workflow and provides everything a team might need from development tools down to a data center. PaaS is designed to support the complete (primarily) web application lifecycle from building to testing, deploying, managing, and updating. In contrast to infrastructure as a service (IaaS), where you still manage data, runtimes, and middleware yourself.

With PaaS, you only need to manage your applications and data. With the convenience of having pretty much everything managed for you comes the biggest negative, a lack of control over features and functionality coupled with vendor lock-in. Depending on the PaaS you choose, you may reduce some of the work needed from operations but likely also hit limitations that could frustrate the progress of development teams. Building and running modern large-scale and bandwidth applications with many PaaS providers became increasingly expensive.

In a now well-known tweet, Kelsey Hightower pointed out that most people looking for a PaaS want all the conveniences it offers, but to build it themselves.

And finally, Kubernetes liberated many software companies by giving them a lot of the tools needed to create partial versions of a PaaS, and many providers struggled to keep up. Many PaaS providers switched to offering Kubernetes instead as it became a popular standard for larger teams.

Service Catalogs

A service or software catalog aims to create what is often referred to as a developer “portal”. Portals such as backstage.io give teams an overview of the applications, services, websites, libraries, and more they manage and run. They provide details on ownership of the services, metadata, and links to important interaction points for the services, such as source repositories, support tooling, and observability metrics. They help you create a single location to find disparate sources of documentation such as readmes and API reference, hopefully closing common knowledge gaps.

A service catalog gives increased visibility of resources and who is responsible for them, preventing duplicated effort and reducing countless “where can I find x?” questions. But the limiting factor of service catalogs is the lack of ability to trigger any services or deployments. It’s a great source of information but doesn’t let you do much directly. A service catalog gives more of an overview of what has already happened, and generally, it happened elsewhere.

A service catalog is primarily for the benefit of engineers and engineering managers but doesn’t necessarily solve the issue of speeding up collaboration between Ops and engineering teams, as they are still potentially the gatekeepers for all environment management and deployments.

Internal Developer Platform

As Infrastructure as Code (IaC) tools and practices grew in popularity and use, they promised to make creating and managing infrastructure follow similar processes as code. However, instead, they got more complex and more abstract, often involving dozens of tools or scripts. IaC has its place, but Ops teams can quickly lose control of developers' actions, and there is an increased risk of security and performance issues.

This is why many large engineering teams started a shift back to a form of centralizing Ops responsibilities, but this time into a platform team. To begin with, Ops teams configure Internal Developer Platforms (IDPs), and developers use them as a layer on top of the technology and tooling an engineering team already has in place. Ops teams specify the resources that start with an environment or request. They set templates for application configurations and govern permissions with Role-Based Action Control (RBAC). 

This helps teams automate recurring tasks such as spinning up environments and resources and makes enforcing standards easier. Developer teams gain autonomy by changing configurations (that they have permission for), deploying, spinning up fully provisioned environments, and roll back of core and ancillary infrastructure.

Compared to a service catalog, the view of an IDP is reversed. It’s generally the place to trigger events rather than view their output. Whether from a git workflow, a CLI tool, UI, or API call, an IDP takes code, orchestrates infrastructure, and deploys into a fresh environment based on the configuration defined by an Ops team.

The main function of an IDP is to allow developers to spin up services and environments for testing code changes, with all the infrastructure they need including external resources such as databases or DNS resolvers.

Choose What Works for You

Typically a PaaS can suit teams starting out or at the initial stages of scaling their applications. But if that application meets success, they are likely to hit the limitations of a PaaS quickly.

A service catalog is a great source of information, and even introducing one early can help reduce information silos at a later stage, however, you still need another solution for deploying and running applications.

An IDP needs investment to create but pays off in the long run by giving dev and ops teams the freedom and assertions they need to feel productive and comfortable. An IDP is not something small or new teams need, but much like with a service catalog, there is no harm in thinking in terms of a platform from the outset.