Don't Build a Service Catalog

Service catalogs are great, right? They give you an easy button, they help you standardize, and they let anyone deploy infrastructure no matter their technical skill. I love easy buttons and I love standardization. What I don't love is the crutch that a service catalog becomes.

I've had too many calls where a prospect tells me they're in the middle of a transformation. They're moving to Terraform. And then, by the way, do you have a service catalog? It's a bit of an oxymoron. If you're in the middle of a transformation and asking for a service catalog, you're probably transforming right back to legacy IT.

Years ago at Scalr we had a "template registry" feature (the name doesn't even make sense..) that had nice big icons, descriptions, the shopping cart experience…. It was great! You would click a few buttons, Terraform runs in the background, and users would get information about their resources. It was great until we showed it to a few of our advanced customers and they instantly asked us to remove it.

Why you ask?

A transformation is a transformation. Just because you have Terraform on the backend being managed by a few people doesn't mean you have transformed. Those few engineers will end up being the bottleneck one day.

Self service doesn't mean a self service catalog. Self service means you enabled your teams to work autonomously because of the implementation of controls:

• Having isolated environments in which your development teams can operate independently without having to worry about stepping on each other's toes.
• Creating and enforcing OPA policies to ensure the teams are complying with standards.
• Generating reports to understand how your Terraform modules, providers, and other objects are being used.
• Getting the right data to the right place to make sure your DevOps team is working efficiently.
• Allowing teams to use existing workflows, but having the end result being Terraform executing in a remote backend.
• Having an extensive IAM model to allow them to do their job in a secure fashion.

The goal should be self service enablement, not a self service catalog.

That being said, I know it's hard to find good DevOps engineers and not everyone is ready to be an expert in Terraform. That's why the popular backstage.io exists. That's why, at Scalr, we created a module registry in which users can deploy from. The difference is that the design of these solutions takes into account the developer experience. Just because someone can't write the Terraform code, doesn't mean they shouldn't understand the fundamentals, process, and standards that are adhered to in the organization.

This is a very different approach from a traditional service catalog, a shim on top of an API, or the entry point from an ITSM tool. Presenting the fundamentals and the process to your users will help accelerate the transition.