Don’t Build a Service Catalog
Service catalogs are great, right? They give you an easy button, help you standardize, and allow all users to deploy infrastructure regardless of their technical capabilities. I love easy buttons, and 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 it. 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, and 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 allows 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 from which users can deploy. The difference is that the design of these solutions takes into account the developer's 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.
