Ideas About Service Provisioning with Claim

[csviri]

Some thoughts on Primaza Claims, just brainstorming a little bit:

First of all if I understand correctly it is not in the scope now that Primaza provisions service but something like that might be in the scope in the future. IMO that is a big win (or killing feature :) ), first of all it would solve the problem of a service catalog, and handling such provisioning.

Now the problem is Kubernetes is designed already for such thing, like Custom Resources and Operators are kinda already for provisioning custom services using the Kubernetes API. So listing (if one has rights) of CRDs alreay gives you an idea what are the capabilities of the platform / cluster.

There are multiple problems to solve, first of all platform engineers / teams solves a lot offerings of a service, installing operators and stuff. On the other hand we have tools like OLM that is already automating installation of an Operator / Service offering. However we don't want to install all the operators in a cluster, since there might be hundreds, probably most of them is won't be used. BUT we want to give a possibility for teams to discover services and/or claim for one that is not necessarily installed yet (basically service catalog). Thus we could say to the users (with an API / website) , look here are the possible services that can run on the cluster, if you claim for one service, we install the operator for you (OLM) - this will install also the CRD - if not installed yet.

Here comes the hard part, how to configure the requested service, thus how to create the Custom Resource (CR) after the Custom Resource Defintion (CRD) is there on the cluster (installed by Primaza and/or OLM).

One way is to just create a default CR for the team in their namespace, and let the team fine tune it. So update the CR with team specific configuration. - Problem is that this not plays well with GitOps, so then this needs to be saved into a git repo,
( but next time for example a DEV cluster is provisioned, we are won't be able to apply it, only after CRD is present. Will work however nice in a non dynamic / prod environment)

So this is kind of a problem now I think with kubernetes, the set Services which are offerings of a platform, could be managed much more dynamically then it is now. In other words dynamically installing operators.

Handling Secrets and and access of the service what primaza now solves is also a problem, that is tightly related to this. And might make sense to cover both these problems with one solution

On the other hand in a smaller companies these service offerings are well tailored and needs SRE to run, so from organisational perspective this is a challenge too

But if we thinking to building a generic solution, like a cluster/platform that already out of the box offers a huge list of services (datastores, queues, etc) probably this is a way to go, making easy to claim a new service on the platform, that is zero effort to install and run.

Of course platform engineers are still needed to make is sure it runs, and put other bits and pieces together.