The modern Service Catalog
If you find yourself cringing at the term Service Catalog because of bad experiences with certain vendors, don't panic. The modern Service Catalog is an entirely different beast. Here are the key ideas:
Defined as code
The Service Catalog must be defined as code, using the tools mentioned in the previous section, such as Terraform, CloudFormation, Docker, Kubernetes, etc. Your team must have access to this code so you can customize it and evolve it as much as necessary.
Designed for use directly in production
Many of the Service Catalogs that you find in the wild seem to be full of code that's great for a "5 minute demo"—something that looks great in a sales presentation—but isn't actually useful for real-world production use cases. The sort of Service Catalog we're talking about here should be explicitly built to be used directly in production.
Designed to meet your company's requirements
In order to be able to use your Service Catalog in production, it should be written specifically to meet your company's requirements out-of-the-box (the ones you defined in the pre-requisites).
Here's the key idea: as you'll see in the next section on CI / CD, you'll set up your cloud accounts so that only way to deploy anything into those accounts is to use the Service Catalog, which means the code in the Service Catalog is how you enforce all your requirements around security, compliance, scalability, and so on!
Tested to meet your company's requirements
As described in the previous section, one of the big advantages of using code is that you can validate it. Your Service Catalog should have tests built in that systematically validate the code meets your company's requirements. This includes:
- Code review: You should enforce that code cannot be merged to your
mainbranch unless it has been reviewed by at least 1 (or more) people who are not authors of that code.
- Static analysis: For infrastructure code, you can run tools such as
- Policy enforcement: You can run tools such as Open Policy Agent (OPA) to test that your code meets various compliance and regulatory requirements.
For a concrete example of a Service Catalog for AWS, see the Gruntwork Service Catalog.