With the increasing trend in on-demand consumption, SaaS business model has now become the de-facto standard for delivering software products. This has also led to the increase in engineering complexities of building a multi tenant SaaS product.

What challenges are you facing right now?

The above picture captures the top concerns of most of the SaaS engineering team, particularly during their early growth stages of the product. Most of these factors are not a big concern in on premise environments as it caters to a single customer and hence, the demand for non-functional requirements (ex: load, concurrency, etc.) is not going to be extremely high. Moreover it is delivered from within the same network and hence, the threat of security attack is not high and integration can be simple as the (connecting) solutions are also going to be available together within the same network.

Engineering your SaaS product

SaaS model not only demands the business functionality to be addressed correctly but also deliver in such a way that it can be highly scalable, secure, extendable and also easy to configure and integrate. Following are some of the best practices that should be followed in engineering your SaaS product.

Scalability:

It’s extremely important for a SaaS product to be designed in a way that each layer can independently scale in a seamless manner. For example, your SaaS product may expose APIs for consumption. It’s possible that the API calls could be more than the web requests, hence, API layer should be independently scaled (preferably auto-scaled) to meet unpredictable loads.

Database Scaling:

In today’s cloud infrastructure scenario, scaling at the web and application layers is extremely easy particularly with technologies like java, .NET, which inherently supports scaling. However, scaling the database layer is the most difficult task, which can be simplified by adopting Data Sharding as a principle right from the architecture. Data sharding is basically partitioning your data in some logical groups, where each group can be individually scaled out. For example, you can have one group (sharding) to hold all US customer’s data, and one group to hold all UK customer’s data and one group to hold the remaining customer’s data. Data Sharding also allows you to totally move these groups to different physical (database) servers so that they can be processed more efficiently without any bottlenecks. The good thing is, even when your US customers grow heavily you can further split the group as US-East, US-Central and US-West. This way you can achieve unlimited scalability with zero engineering effort.

Multi Tenancy:

Multi tenancy can have a great impact on the scalability and the profitability aspects of your SaaS business. A well layered multi tenant architecture can provide economies of scale, by considerably reducing the hardware/infrastructure cost. At the same time, it allows you to maintain a single code base, which is easier to maintain.

SaaS Configurability:

SaaS Configurability is a biggest challenge and roadblock for moving to multi tenancy. Often architects are challenged with conflicting requirements, which forces them to a path of custom code development. This can be mitigated by having a configurable design across the various layers in the product. For example, the following areas should be made configurable and extendable – UI, Authentication, Fields, Database sharding, role/privileges, auditing, etc.

Building a multi tenant SaaS product is tough and requires well experienced technical architects with the balanced knowledge of application architecture and infrastructure architecture in order to leverage the cloud services to meet the demands of SaaS non-functional requirements.