I have some experience running tekton on the same data plane cluster, wouldn’t recommend that to anyone. the builds are fast and deploys are instant, but i think that’s not it. plus, tekton is super young and rapidly growing, i.e breaking and changing. and the terminology is odd and confusing

when you say gitops and control plane, I think I understand what you mean. part of the infra is usually handled by control plane, e.g cluster routing, services, ingress, but the deployments are often time directly injected into data plane. I don’t like the idea of wrapping your runtime releases into terraform or helm charts, because releases are simple and fast, often time it’s a single deployment manifest where the only diff is a container image version

@Alex Pulver here we go, AWS always rocking with the naming. 😃 ‘application plane’ is what I was missing

looking at the article, application plane feels like the same thing as data plane. just in a different context

For example, tenant provisioning functionality can be thought of as part of SaaS Control Plane, but be deployed in the same cluster as SaaS Application Plane apps

And sometimes the functionality of both planes can be deployed in the same environment

whether it’s provisioning a new deployment for the tenant or just creating a record for your backend system to start serving the tenant

So the application plane is not an agent, but rather the core business functionality of the SaaS offering. Tenants interact with both though

For example, registration service (sign-up) is part of SaaS control plane. The functionality that customers but the SaaS offering for is in the SaaS application plane

@Rauan Mayemir What I have in mind is pretty similar to the image @Alex Pulver shared. Each tenant is a separate Kubernetes namespace and each with the their own Helm chart(s) and associated repo.

@Leo Gomes as for repos, I’d suggest to consider reliability (blast radius) and operational excellence (delivery velocity). Organizing application components into their own repositories and pipelines will reduce blast radius and increase delivery velocity. It does require a strong automation culture and tooling. Taking this approach, we should be aware that application contains non-compute resources as well (e.g. databases, datastores, caches). In this approach, each application manages whatever is need for the tenant. Let’s take these Product and Order apps as an example. They can use different isolation models. Product app can store tenant data in the same database. Order app can store data (due to whatever constraints) in database-per-tenant model. Hence, their deployment process will be different, and how they manage tenancy will be different.

Product app could use a single namespace in compute for its needs and perform runtime access scoping to database. Order app could create namespace per tenant and perform isolation at deployment time.

@Alex Pulver, @Ram I went through most of the material, thank you! I think that AWS' documents & presentations formalizes and summarizes a lot of ideas around what a modern SaaS application is. What I didn't find was a detailed description of how one would go about implementing the control-plane itself. This is where I believe @Ram's article kicks-in and describes the challenges and requirements for the control-plane. I have also read in detail the Snowflake's paper on their control-plane. I'd be interested in any further material you may suggest in particular on building a control-plane that would be Kubernetes-specific. Snowflake manages it's own VMs, which I believe makes sense in their case, but I'd interested more in the challenges of a control-plane that manages a fleet of k8s clusters / namespaces.

@Leo Gomes I wrote down in a bit more detail the alignment between SaaS control plane/SaaS application plane and Service control plane/Service data plane in https://softwhat.com/aligning-saas-and-service-planes-definitions/. Hope it can further clarify what I wrote above, and I would be glad to have any feedback 🙂