Part 1: The Evolution to Software as a Service
Suppose you are developing software with a target audience of different unrelated organizations. Your software will fulfill a business need shared across the organizations, but there is nothing tying them together other than that shared need. How would you approach this opportunity?
A common traditional approach would be to build it as a software product, or package, that must be deployed separately for each customer organization. This is a very intuitive and easy-to-grasp approach. In the world of custom solution deployment, however, this may be complicated. Often you need skilled technicians to set-up and configure the software to work with the organization's existing infrastructure and systems, as well as to monitor and maintain the software.
Figure 1: Deployment per organization approach. I use the term tenant to denote the organization that is making use of the software, though in this model this is a misnomer, I find the term helpful in the context of the rest of the post.
Each organization that uses the software will need dedicated hardware and personnel resources. Scalability will be limited to the capacity of the infrastructure on which it is deployed and cannot be easily managed.
Finally, there is the problem of how to manage software updates. When we have to plug that security hole we found, do we just put the patch on a website somewhere and the organizations are responsible for applying updates? If we are hosting the installation on behalf of all our customer organizations, are we going to spend the man-hours to sequentially apply the update to each separate deployment? Or, perhaps best of all, do we have the budget to spend the engineering hours to make the deployments self-update?
In response to many of the limitations of the multi-instance application you can turn to a multi-tenant application. This is an application that is installed once, and has the capabilities to "host" a multitude of customer organizations, or tenants. As you bring on new customers to the system you (or they) don't need to go through a deployment process. Hardware may not need to be purchased or reallocated to the task of running the application each time a customer is added. Software updates automatically apply to all tenants simultaneously.
Figure 2: Single deployment approach. One instance is able to handle multiple tenants. Each tenant has a logical "instance" to maintain its independence.
Because each tenant is an independent customer organization they must each maintain separate data, authorization accounts, etc. These aspects must be designed and engineered in the development process. Therefore, initial development costs are likely to be higher, but the mid to long-term benefits should more than make up for it.
The limitation, as you might guess, is scalability. If each tenant is housed by a single application, what happens as the tenants grow in size or number? Generally, this model only supports vertical scalability; meaning you have to keep getting bigger and bigger hardware. You'll argue that with a web farm you get horizontal scaling, but for the sake of my argument, that farm just becomes your vertical slice since it is all backed by finite infrastructure capacity. The web farm as a whole has to grow to satisfy peak capacity of all tenants.
Because of the capacity limits imposed by infrastructure, on-boarding a tenant is usually something that has to be managed carefully.
Software as a Service Applications
There are a couple interpretations of what Software as a Service (SaaS) is. For me, at least in the context of this post, it is an application that can readily and easily be consumed by any entity who so desires, without impacting other consumers. Much of the "secret sauce" that makes an application meet the "readily and easily" criteria is given to us via cloud platforms like Windows Azure. Simply by hosting your multi-tenant application in Windows Azure you start to get a great many benefits. For instance, all requests that come into your application are routed through a load balancer. This enables the single application deployment to be run on multiple virtual machine instances; giving you instant and infinite scalability.
Figure 3: Multi-tenant application + Windows Azure = SaaS.
Imagine your application was happy serving the first 3 tenants on just 1 running instance (although, Windows Azure requires at least 2 to get the SLA, for obvious failover reasons) and you want to bring on a fourth. This fourth tenant represents a large customer that requires the combined capacity of the first three. With Windows Azure, this change requires a mere configuration change.
But there are other offerings in the Windows Azure stack that allow you to deliver a true SaaS solution. The Windows Azure Management API enables for robust automated tenant provisioning processes. Virtual machine instances can be turned on and off dynamically to match volume, deployments can be updated using rolling update strategies that guarantee application availability, and resources such as isolated storage accounts can be created as part of a tenant on-boarding process.