What Happened to the Service Catalog?

Service catalog and the problem of managing dependencies in Kubernetes

• Developers using Kubernetes often need to manage dependencies like databases and message queues
• Manually provisioning and managing these dependencies is not scalable
• Service catalog was an attempt to solve this problem by providing a single source of truth for all infrastructure and application dependencies
• Service catalog was built on top of the open service broker API, which allows for decoupling between service providers and consumers
• One issue with service catalog was its complexity and lack of adoption

Developers often struggle with managing dependencies in Kubernetes, leading to manual and inefficient processes. Service catalog aimed to solve this problem, but faced challenges with complexity and lack of adoption.

Imagine you provide a hosted cloud service - for example, a SaaS metrics platform or a managed database. Your customers use Kubernetes and you want to let them easily consume your service in their Kubernetes workloads. Today, you would build an operator or perhaps a Crossplane provider. But not so long ago there was a Kubernetes project specifically for this use-case: the Service Catalog. The Service Catalog worked with the Open Service Broker API to allow management of hosted services via Kubernetes resources. It provided a standardized, vendor-neutral way to manage and connect to external services from Kubernetes workloads. It never really took off. Operators won the day, and the Service Catalog project was shut down in 2022. This talk explores both the limitations and the advantages of the Service Catalog model. We'll compare and contrast the Service Catalog with operators and Crossplane, and explore where each approach could learn lessons from the others. With that context in mind, we'll think about the future. Kubernetes users will continue to consume cloud services in their applications; what's the best way to facilitate that?