It is so crucial for ISVs not to fall behind in the market. They always have to be ready to release a new version of their products to keep their time to market value. If they cannot automate their provisioning processes, they'll be slower than their competitors. Automated provisioning also reduces the risk of having a faulty release and under-utilised resources.
Loads on applications can vary a lot by time. On specific dates/times, loads on applications can peak. In traditional approaches, ISVs have to keep resources ready before those load waves arrive, which creates considerable cost and increases the complexity of managing those resources. Also, it is always hard to manage the resources as the business grows.
Isolation Between Tenants
Security is the most important aspect when we consider customer privacy with compliance. ISVs have many customers, and the isolation between customers should be handled carefully. Any leaks between tenants can be a big issue, and there must be thick borders between tenants.
Single Tenancy vs Multi-Tenancy
In the early stages, ISVs can run multi-tenancy supported applications to be able to be on the market sooner. This is fine when they don't have many customers. Still, by the time when they start having more customers, their applications have to be modernized and isolated with different environments which makes them single tenancy supported multi-customer environments. Running a multi-tenancy environment can be easy and cheaper at first, but it creates vast complexity, which slows down the application development, release cycles and time to market, with higher maintenance costs and efforts.
Technology develops every single day. That creates an excellent opportunity for ISVs to keep their costs low. With growing businesses of ISVs, their needs for resources increase. Without an efficient and robust technology implementation, it is almost impossible to keep the costs low. After some time, there is a risk for the business to start to be non-profitable. For many ISVs, more customers mean more cost, yet it doesn't have to be that way!
Cost/SLO for Various Membership Tiers
Providing different price/membership tiers for their customers is essential for the ISVs. Providing this also helps them manage their resources and keep their costs low. Modernizing the infrastructure and application helps a lot in decreasing the complexity; this decrease contributes to cost optimisation and work efficiency. With the modernization, the application efficiency boosts and that makes happier customers with better performance and lower costs which makes ISVs a better vendor.
Typical membership tiers for ISVs
Kloia’s Approach to Help ISVs
Kloia believes that every ISV needs a customised modernization plan. That’s why kloia customised approaches to help single and multi-tenant ISVs;
For single-tenant architectures, our approach is to modernize the application for decoupling the software and dockerizing the application(s) so we can benefit from using kubernetes. After that, we help ISVs isolate tenants.
We offer ISVs different isolation choices based on their needs;
Account-based isolation is probably the highest-priced package that a customer may buy/subscribe. As we’ve assumed above, let’s consider this as a Platinum/Gold Package.
In this approach, we automatically create a different AWS account for each tenant. By doing this, we can create the highest security, performance, and isolation.
If the ISV would not want to deal with different AWS accounts for each platinum/gold customer, then we suggest isolating tenants over VPC. This isolation method is the second preferred isolation approach after account-based isolation.
3. Subnet-Based Isolation
If ISVs do not need the isolation level of VPC for platinum/gold customers, our next suggestion would be subnet-based isolation. This is where we create different subnets and EKS clusters for different customers.
4. Node-Based Isolation
Node-based isolation could be used for cheaper service levels, where having one of the isolations above could be very expensive. That’s why we suggest having a node-based isolation per tenant.
5. Namespace-Based Isolation
For free/lower-tier packages, we assume ISV would rather spending the minimum amount of money, which is why we’ve created namespace-based isolation for them. With this option, there will be one VPC and one cluster. Nodes will be shared among all customers. The isolation will be done on kubernetes namespace level.
Reference Model Architecture for Single-Tenant SaaS Architecture
Here you can find our sample reference model for a single-tenant SaaS architecture. Let’s say a new customer subscribes to a SaaS account from the ISV. When they place the order or complete the subscription, everything will be done automatically within minutes using terraform. Based on the package customer subscribed, all necessary actions will be taken by terraform scripts and all necessary notifications will be sent to the customer and internal team.
For the ISV’s that would prefer managing multi-tenants on a single infrastructure, we help them with the transition to this architecture.
Some transition approaches are;