by Rahul Jain, Fiberlink

With the increasing popularity and penetration of the cloud, SaaS (Software as a Service) is rapidly becoming the preferred software delivery model for organizations across the world – software buyers as well as vendors. With SaaS, software is hosted by the vendor (service provider) in the cloud and accessed by the users over the Internet using a thin client e.g. a web-browser. There are many business benefits of adopting SaaS. For the customer, it means reduced cost of ownership, fast deployment, no maintenance headaches, and a smaller learning curve leading to a higher adoption rate in the user community. For the vendor, it means reduced cost of customer acquisitions, faster sales cycles, more upsell opportunities and an easier rollout of new features.

From an engineering perspective also, SaaS is a great way to build and deliver software. It is a perfect fit for software delivery teams that have adopted an agile development model. As the software is centrally hosted, you can:

1. Deliver new features to your customers faster
2. Receive user feedback and implement changes in real time
3. Fix production issues quickly

Also, you need not worry about any environment dependencies, different software versions, their
upgrades, etc.

So, excited about building a SaaS product? OK, let’s see what you must know for building SaaS software. The following are the key architecture/design tenets of a SaaS product:

Multi-tenancy:

Multi-tenancy is the ability to serve different customers from a shared hardware or software instance. It gives you economics of scale by catering to a growing customer base without any significant increase in your resources. From a software design perspective, multi-tenancy influences all aspects of software including database model, application logic, user interface, etc.

At the database level, multi-tenancy can be achieved either by storing data for each customer in a separate schema or by partitioning the customer data by adding a customer qualifier field to all entities (i.e., Customer ID should be part of all tables as a primary key field). The second approach is straightforward and can be implemented very easily. It may suffice for systems that do not have a large volume of data. However, for systems that deal with large data volume it is best to store each customer’s data in a schema of its own. In both cases, you must spend some time building data access frameworks to hide the underlying data partitioning scheme from developers. This not only makes your developers’ lives easier but also helps you to migrate from one scheme to another when the need arises.

Scalability:

Well, scalability is important for any software system worth its salt. However, it becomes extremely important for a SaaS system because any performance impact directly affects all your customers. If one of your customers starts uploading large volumes of data, it should not start impacting other customers. Database multi-tenancy discussed above takes care of scalability from the database operations side. To ensure that your application servers are scalable, you must ensure that your applications are cluster enabled and you can add cluster nodes as your data volumes grow. It is best to make all your application services stateless so that you do not need to worry about session persistence/replication, etc.

Another design principle to follow, while designing scalable systems, is modularizing your services. This not only makes your system more fault-tolerant but also allows you to scale the different components based on the number of requests each component receives. Another important tool you should exploit is cache. In a SaaS system there is a lot of data that is common across customers (e.g. country codes). Such meta data can be cached and be made accessible across the system. This will avoid unnecessary database operations and boost system performance.

Security:

As the data for all customers is stored in the same data-store, it is very important to ensure that one customer’s data is not accessible by another. This means deploying several levels of defenses. For instance:

• At the database level, you must encrypt all confidential data – preferably by using a unique key for each customer.
• At the network level, you must ensure that all the communication happens on a secured channel (e.g., HTTPS should be used for all requests from the browser to application server).
• At the application level, you must ensure that all the workflows authorize the user before granting access to any data. Authorization must be performed on the server side for each request rather than depending on the client for it. Also, ensure that your website conforms to security best practices.

Customizability:

If you have been in the enterprise application space for more than a few months, you would know that no two customers are the same. Each customer has different requirements for data modeling, UI workflows, integration with legacy systems, etc. As a SaaS system developer, you should realize this early and ensure that the system provides customization capability for all important elements, e.g., the UI look and feel, data interchange formats, definition of entities and business logic, as well. When designing your data model, think how your users can extend it. When designing your business logic, think how the user can alter it. It is a good practice to model business logic as a template that can be changed by your users. When designing your UI look and feel, think of different themes, logos, icons, etc. Customization becomes very important if your business model involves partners to resell your solution; they’ll probably want to rebrand your solution and customize the workflows.

As a pioneer in the SaaS space, MaaS360 has used these and some other design principles and has ensured that our applications are secure, scalable and customizable. We’ll discuss these concepts in detail in the coming posts. Meanwhile, please share about your experiences of building/using SaaS solutions in the comments section.