Any B2B software’s cloud native journey starts with containerizing the software stack. Then the software needs to be packaged to run on Kubernetes for its distribution to the end users. The most common packaging methods are building an Helm chart or a Kubernetes Operator. These packaging methods enable ISVs to list their software on any of the public marketplaces e.g. AWS marketplace or Google cloud marketplace. The ultimate goal still for any B2B software vendor is to build a SaaS offering as it significantly simplifies consumption of their software for the end users and allows the software vendor to capture more market opportunity.
Let us explore what it means to deliver a SaaS for a Kubernetes application. SaaS delivery demands that the provider of the software will manage the running instance of the software and also the underlying infrastructure, while the customer just consumes it. To put it in the context of Kubernetes, let us take an example of a database provider. If this database is just packaged as an Helm chart / Kubernetes Operator, the end customer will have to set up a Kubernetes cluster, deploy this Helm chart or an Operator on it and then manage all this environment in order to use the database. In contrast, if there is a SaaS offering for this database, the end customer directly uses the database without having to worry about the management of the database software or the Kubernetes environment.
Now let us explore how to build a SaaS for a B2B software packaged for Kubernetes. There are primarily 3 key aspects to consider:
- Multi-tenancy:
Majority of the B2B SaaS offerings create a separate instance of the application stack per customer. When delivering it on Kubernetes, you need to figure out the best architecture to do this with your isolation requirements. You could dedicate a separate Kubernetes cluster per instance or use namespaces within the same Kubernetes cluster. One of the most common patterns is to dedicate a separate cluster per customer and use the namespace based separation if the same customer is looking to provision multiple instances of your application.
- Usage based metering and billing:
This is about being able to meter the usage based on predetermined metrics and bill the customers based on that. These metrics could be consumption of underlying resources like CPU, memory, storage, network traffic or they could be application specific ones like number of requests made. Prometheus being the most prevalent metrics tracking system with Kubernetes, you need a way to use it across multiple instances / tenants of your SaaS to be able to track the metrics for all the customers and bill accordingly.
- Role based access to providers and consumers:
When delivering your SaaS on Kubernetes, the access to the cluster needs to be managed for two separate personas — providers and consumers. Providers are the software vendors delivering and managing their SaaS. Consumers are the end customers using the software. Consumers may or may not need direct access to the cluster but they need a simple way to provision the software. Providers need more privileged access to the environment to be able to monitor or troubleshoot their software. In order to achieve the provisioning and management of such environments at scale, there needs to be APIs to manage these role specific access to the clusters.
While designing SaaS or managed services for your B2B software, you need to consider all these aspects. At CloudARK, we have been helping a number of organizations building SaaS for their software on Kubernetes using KubePlus SaaS Manager. Check out our website to learn more about how KubePlus addresses the above aspects to give you a turn-key solution for building your SaaS.
Additional resources:
- Register for our upcoming webinar to learn more about delivering your Kubernetes application as-a-serve.
- Sign up for our free demo to see KubePlus SaaS Manager in action with your Kubernetes application.
