Scalr
Scalr
March 3, 2023

Don't Build a Service Catalog

By
Ryan Fee

Service catalogs are great, right? They give you an easy button, help you standardize, and allow for all users to deploy infrastructure regardless of their technical capabilities. I love easy buttons, I love standardization, but I do not love the crutch that is a service catalog.

I have had too many calls where prospects say they are in the middle of a transformation, they are moving to Terraform, but, by the way, do you have a service catalog? It’s kind of an oxymoron when you think about. If you’re in the middle of a transformation and asking for a service catalog, then you’re likely transforming 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 others 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 take 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.

Note: While this blog references Terraform, everything mentioned in here also applies to OpenTofu. New to OpenTofu? It is a fork of Terraform 1.5.7 as a result of the license change from MPL to BUSL by HashiCorp. OpenTofu is an open-source alternative to Terraform that is governed by the Linux Foundation. All features available in Terraform 1.5.7 or earlier are also available in OpenTofu. Find out the history of OpenTofu here.

Start using the OpenTofu & Terraform platform of the future.

A screenshot of the modules page in the Scalr Platform