Cloud Computing has enabled developers to build scalable & fault tolerant applications at a much faster rate and deploy these applications at lower costs on a pay per use basis.
We discussed about the key architectural considerations for developing applications for Cloud in an earlier post by Veeraj.
In this post we will be discussing the best practices and architectural considerations about developing a SaaS application. For understanding what is SaaS and the opportunities it presents, please read the earlier blog on SaaS.
While developing Software as a Service application, the development team needs to consider the following factors to ensure a quality product and a viable business.
Self Service & Personalization:
A SaaS application has to be self-serviced, anyone should be able to register and start using a SaaS application without any help from the admin or technical person. Details about setup and usage of the application should be made available to the user on the application itself.
It should also have high level of personalization. The customer should be able to make changes to the look and feel of the applications as per their requirements. Even end-users for a particular tenant should be able to update certain aspects of the application look and feel.
Multi-tenancy
Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Multi-tenant architecture allows developers to leverage common infrastructure and code base to expand their services making it easy and economical to maintain the application.
Integration
A SaaS application has to have integration capabilities with other applications. There should be a standard set of APIs made available to integrate with other SaaS and on premise applications.
Operational Performance
The application should be always available and highly scalable with good performance.It should be able to serve to tenants of any size. As the application will be accessed over the internet, it has to have good performance for rendering, data querying and transactions.
Security & Compliance
For a SaaS application the responsibility of the application and hardware security lies with the developer. Developer should ensure that the data of multiple tenants on the shared infrastructure is virtually segregated and is accessible by people who are intended to access it. Security is a major concern for organizations to adapt to SaaS applications.
In this blog we will talk about design and architectural considerations for these factors.
Multi-tenancy is the key to successful SaaS
By definition, subscription for the application over the internet is sufficient enough for an application to be defined as SaaS, but this does not differentiate it from any ASP application. To differentiate a SaaS application in practical terms it must be a multi-tenant application.
A SaaS application has to be a multi-tenant application to be successful. Multi-tenancy helps leverage the efficiencies of underlying infrastructure and application code, by sharing it across multiple customers. Sharing of resources enables efficient usage of the resources and reduces costs of operations.
Levels of Multi-tenancy
The sharing of resources for multi-tenancy happens at various layers of the system architecture. These layers can be broadly identified as,
- Infrastructure Layer
- Database Layer
- Application Layer
Based on the layers shared, there are four types of multi-tenancy models which can be used to architect your SaaS application.
Isolated Tenancy: This is the basic level of tenancy very none of the layer is shared among the tenants. Each tenant has their own infrastructure, database and application. The infrastructure is physically isolated.
Infrastructure Tenancy: In Infrastructure tenancy the underlying infrastructure for the application is shared across tenants.The database and application layers are separate for the tenants.
Application Tenancy: Application tenancy model will have the application code and infrastructure shared by each tenant. The database is still separate for each tenant.
Shared Tenancy: In shared tenancy model, infrastructure, database and application are shared among all the tenants. Each unique tenant in the database will be identified by a unique tenant id.
Design Considerations
To segregate multiple tenants in multi-tenant environment, each tenant has to be identified uniquely. This is done by defining unique tenant ids for each tenant at the application layer and the database layer, depending on the level of multi-tenancy.
Tenant ids along with user ids are used to identify the user accessing the application, and restrict users to access only the data which they are supposed to access.
For shared tenancy, you can design the application to have separate schema for each tenant or the same schema for all the tenants. This choice would mainly depend on the database you select. For example, you can have multiple schema in Oracle and MS SQL Server databases, but if you are using MySQL database, there is no concept of schema.
The table below gives an overview of what considerations are required while developing an application with each of the models.
Tenancy Model Considerations
Selection of the tenancy model will depend on the type of SaaS application, the skill sets of the developer, complexity, SLAs, Time to market etc.
Here is a brief comparison to help you make a decision to select the tenancy model.
Tenancy Model Comparison
Security Considerations
Security of data is probably the only major constraint which discourages a lot of customers to move on to SaaS applications. Security of the application and the data residing in the application should be of the highest priority for a SaaS developer.
It is possible to provide security in SaaS applications by virtually isolating the data using tenant ids within the database. Developer should ensure that the data accessed by the end user should be restricted only to that tenant.
Some of the security patterns to keep in mind would be:
Trusted Database Connections: Applications should connect to the database only using the application’s own process identity and not by individual user identities. This means that you should use the root or super admin user for the database instead of the individual schema users.
Access Control Lists: Grant proper access controls to various tenant users. User access should be restricted to a particular tenant (Authentication) and to particular modules depending (Authorization) on their access rights. Authentication and Authorization are important as tenant administrators have full access to create and grant access to users for their tenants.
Tenant Data Encryption: The tenant data should be encrypted while stored in the database. Encryption is especially important when applications store high-value data or when multiple tenants share the same set of database tables.
Restricted APIs: SaaS applications need to talk to various other applications to exchange data or for reporting purposes. Developers need to ensure that APIs have limited data manipulation capabilities and access only the required data.
Scalability Considerations
In traditional applications, usually the number of users accessing the application is restricted, but for a SaaS application the number of users accessing the system could be virtually unlimited and hence the application has to be inherently scalable.
Scalability has to be achieved for both Application as well as Database.
Application Scalability
Application scalability can be achieved by either scaling up (moving application to a larger & more powerful server) or by scaling out (adding additional identical servers to handle the load). For a SaaS application hosted on Cloud, we can easily scale out the application. Some of the points to consider while scaling out the application are:
Design stateless applications. Statelessness means that each transaction can be handled by one instance as well as any other. Statelessness can be achieved by storing the session data on the client’s side or in a distributed store that is accessible to any application instance which is scaled out. Stateless applications ensure that the user doesn’t lose the session in case of addition of new servers or failure of existing servers.
Pool resources like threads, network and database connections. This helps in maximizing the resource usage and enables predictable resource usage.
Asynchronous I/O. This allows application to perform other tasks while it waits for input and output to complete.
Database Scalability
For an internet scale SaaS application, database size will keep on increasing with addition of new users and increasing transactions. Increase in data will impact the database performance with higher querying and transaction times resulting in poor user experience.
Some pointers to ensure optimal database performance are:
Data Partitioning. Partition the data into smaller segregated chunks to improve querying and transactional efficiencies. Developers and architects need to develop a partitioning strategy by careful analyzing the usage patterns of the application. The developer needs to put in place dynamic re-partitioning strategies to ensure minimal intervention for the ever increasing data.
Read Only Copies. Keep read only copies of databases. Redirect the reporting and query requests to these read only databases to balance the load on the transactional database.
Monitoring
Software application consumers are used to having the application on their own premises, and the internal IT team is usually responsible for monitoring and maintaining the application. With SaaS applications the developer has the responsibility of monitoring and maintaining the application.
For SaaS ISVs to be competitive in the market, it is necessary to provide availability SLAs in excess of 99.9%. SLAs make it a legal binding for the developers to adhere to them or face penalties in case of non-adherence. Frequent downtimes can surely be a company killer in case of SaaS vendors.
Apart from downtimes, the application should also be monitored for performance issues; slow performance delivers poor user experience. Developers should define performance baselines and monitor the application performance against these benchmarks to identify potential performance issues.
Monitoring tools and processes need to be put in place to ensure high availability of the applications.Developer needs to figure out all the single point of failures and continuously monitor these potential weak links for failures.
Monitoring tools have to be backed up by proper processes to ensure that any downtime is handled promptly.
Conclusion
SaaS applications provide a whole new world of opportunities, but careful considerations have to be made to ensure that the application is architected and designed properly for it to be secure, scalable, easy to use and make the most of the economies of scale.A well-built SaaS application can provide a win-win solution for both the developer and the customer.
If you are a start-up or an ISV looking to develop a SaaS product, please get in touch with us at sales@139.59.4.14. Blazeclan has extensive experience in building massively scalable and easy to use SaaS applications.
