I’m going to touch upon critical challenges one would run into while building SaaS solution for public cloud and some design options for each. In this post you may notice references to various Azure components, but  these challenges and design is applicable to any public cloud provider.

1. First and foremost –  Get your “Tenancy Model” right.

There are 4 architecture options for tenancy. If the solution has different Azure roles (web, worker),  you can apply these patterns to each role individually and mix and match across the roles.

  • Multi-Tenant, Multi-Instance  –  All tenants share the resources of instance(s). Tenant isolation and partition needs to be designed into the product to comply with any regulatory requirements of your vertical.  Instances are scaled out for redundancy and performance.  This is widely used model and we recommend our customers as well. This perhaps hard one to implement, but if done right,  it gives you better scalability and  simplifies the maintenance. (More on this in future posts)
  • Multi-Tenant, Single-Instance  – All tenants share the same resources,  Single instance service all tenants. You can perhaps start with this and then scale out to multi-instance as needed.  You may want to compare scale up vs scale out const differences, Difference can be sizable. Tenant isolation and data partition design would be same as above.
  • Single-Tenant, Multi-Instance  – Each tenant gets dedicated  set of instances. Scale out with more instances. Though its not advisable, Each tenant can potentially be running on different versions of code.
  • Single-Tenant, Single-Instance  – Each tenant would be running on dedicated instance.

2. App Customization and Extensibility:

  • Design should account foramount of control that you are willing to give to tenants. Branding (typically styles and logo) is something that we see organizations like to customize in SaaS.  Extensibility can be as deep as :
    • Each tenant extending dataset by adding custom data elements
    • Customizing the business processes
    • Letting tenant create custom code module and upload to SaaS.
    • Above mentioned extensibility takes sound upfront design of the SaaS solution. Heavy use of dependency injection patterns. Salesforce did pretty good job when it comes to extensibility.

3. Provisioning for trails and new subscribers:

  • On-boarding new subscriber in multi-tenancy architecture would be relatively cheaper than in single-tenant design. Provisioning in multi-tenancy may require any where from creating a new database entry for the org to setting up a new database for better data isolation.
  • Where as in Single-Tenant design – You may need setup azure account for the customer, spin up new instances (web/worker and Sql databases)

4. App updates:

  • A multi-tenant application that has a single code base makes it easy to roll out application updates to all your subscribers at the same time. This approach means that you have only a single LOGICAL instance to update, that reduces the maintenance effort.  In addition, you know that all your subscribers are using the latest version of the software, which makes the support job easier. Azure update domains would come in rescue by enable you to roll out your updates across multiple instances without stopping the application. Caution though, different app instances would be running under different version simultaneously during the upgrade window, that is something to consider in solution design.

5. Third-Party components:

  • If there are any third party plug-ins in the solution, they need to support tenancy model of your application.

6. Financial Considerations:  Two charge models – Pay Per Use OR fixed monthly fee.

  • Pay Per Use:
    • Cost calculation would be trickier for multi-tenancy. You need to build logic to meter each tenant resource usage and apply your profit markup to it.
    • For single-tenancy – Create azure account for each tenant and azure tracks the resource consumption  per each service (Storage,  transactions , processing) for that account.  However , it comes with some fixed costs , for example paying 24×7 compute instance or Azure SQL Db instance, might be too expensive for small tenants.
  • Fixed fee:
    • Fixed costs would allow subscribers to predict the bill at the end of the month. But that would be hard for you as provider to predict how much utilization is going to be, hence profit margin can vary significantly (could be negative in some cases).

Wrapping up –  Multi-Tenant SaaS application design certainly requires diligence,  Will cover other aspects of SaaS application design future posts.


Surya Penmetsa

Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *