When to use ClassClaim vs ResourceClaim

With the introduction of ClassClaim, there are now two ways of requesting access to a Service Resource: ClassClaim and ResourceClaim. This section explains the similarities and differences between the two APIs and when usage of one is preferable over the other. It is advisable to work with ClassClaims where possible as they are easier to create and are more portable across multiple clusters.

Similarities

• Both APIs express the need for access to a Service Resource.
• Both APIs adhere to the ProvisionedService duck type. In order words, they both have the field .status.binding.name in their API. This means that they both can be targeted via a ServiceBinding and therefore both can be fed into Cartographer’s Workload API.
• Both APIs rely on a ResourceClaimPolicy in order to achieve cross-namespace claiming.
• Both APIs ensure mutual exclusivity of claims on Service Resources. That is to say that that a ClassClaim or a ResourceClaim will never result in claiming the same Service Resource as another ClassClaim or ResourceClaim.

ResourceClaim

A ResourceClaim targets a specific resource in the Kubernetes cluster. To target that resource, the ResourceClaim needs the name, namespace, kind, and API version of the resource.

The specificity of the ResourceClaim means it is most useful when:

• There’s need to be a strong guarantee which Service Resource the application workload will be utilising. For example, if the application needs to connect to exact same database instance as it promotes through development, test, and production environments.
• This is a experimental or demo environment so creating the ClusterInstanceClass and ClassClaim would be superfluous effort.

If neither of the above are true, then it is recommended to look at the ClassClaim API instead.

ClassClaim

A ClassClaim targets a ClusterInstanceClass in the Kubernetes cluster. To target that class, the ClassClaim just needs its name. The ClusterInstanceClass can represent any set of service instances and therefore each time you create a new ClassClaim, you could claim any of the service instances represented by that ClusterInstanceClass. Once a ClassClaim has claimed a service instance, then it will never look for another. This is true even if the ClassClaim’s spec is updated or the ClusterInstanceClass is updated. Therefore the ClassClaim is performing a point-in-time lookup at its creation, utilising the ClusterInstanceClass for that lookup.

The loose coupling between the ClassClaim and the Service Resources means that ClassClaims are great in situations where:

• Different Service Resources need to be injected into the application workload at different points in its promotion from development to production environments.
• The ClassClaim (perhaps along with a Workload referencing it) need to be promoted from one environment to the next without changing their specification.