The SCP Toolkit comprises a number of Kubernetes native components which support the management, lifecycle, discoverability and connectivity of Service Resources (databases, message queues, DNS records, etc.) on Kubernetes. These components are:

  1. Service Offering
  2. Service API Replication
  3. Service Resource Replication
  4. Service Resource Claims (coming soon!)

Each component has value independent of the others, however the most powerful and valuable use cases can be unlocked by combining them together in unique and interesting ways. For some examples of the sorts of things you can do with the toolkit, please refer to the use guide.


Application teams need supporting Service Resources (e.g. databases, message queues, DNS records, etc.) to develop and run their applications. They do not want the burden of having to run these services themselves, so often organizations provide ticketing systems that allow Application teams to make manual requests for new Service Resources to be created and managed for them. This process often takes weeks. In the cloud, Application Teams have self-service access to create new managed databases and can be provisioned with a simple API call, for example RDS. The SCP Toolkit aims to provide a set of modular tools that can be used to provide the same self-service experience of the cloud for Service Resources running on Tanzu.

We also believe Application and Service infrastructure should be separated, and we have observed customers doing this with TAS. A few examples of the benefits of this segmentation of infrastructure are:

  • Dedicated cluster requirements for workload or service clusters. For example, Service clusters may need access to SSDs.
  • Different cluster lifecycle management. Upgrades to Service clusters may occur more cautiously.
  • Unique Compliance requirements. As data is stored on a Service cluster it may have different compliance needs.
  • Separation of permissions and access. Application teams can only access the clusters where their applications are running.

One way to address these needs in the kubernetes multi-cluster world is to split clusters into Application Workload clusters and Service clusters, then allow application teams to consume the Service Resource APIs from their Application Workload cluster, with reconciliation of resources occurring on Services clusters.

check-circle-line exclamation-circle-line close-line
Scroll to top icon