Back to the future
In my last post, I talked about how the time sharing model for enterprise apps was displaced by user owned data centers and on premise deployments of enterprise software. In the late nineties, a plethora of companies tried to reinvigorate the timeshare model, using the Internet as a cheaper network backbone.
These companies, collectively called Application Service Providers (ASP), used a variety of different approaches to deliver enterprise software over the web. They ranged from:
- Using remote terminal software from Citrix to allow people to log in remotely to standard implementations of traditional enterprise applications (Oracle, SAP, etc.) that the ASP hosted at their data center,
- Building custom web front ends that integrated with traditional enterprise applications that the ASP hosted at their data center,
- Writing new single tenant (see the definition of multi-tenant later on) web-based implementations of enterprise applications that they hosted for the customer.
While this model—in its various forms—had some success, it was still difficult to build a viable business model because each new customer required the ASP vendor to buy software licenses, dedicate hardware to a single customer (you could share storage but sharing servers was difficult – remember VMs hadn’t come into their own yet) and maintain each customer installation individually. Since the LAMP stack was still in its infancy, after you bought the hardware and storage you still had to spend a pile of cash on software licenses for operating systems and databases.
ASP + Multi-tenancy = Software As A Service (SaaS)
Saleforce.com pioneered a new architectural model called multi-tenancy and coined the term Software as a Service (SaaS). In simple terms, multi-tenancy means that all of the customers of a data center share a common pool of software and hardware. Advanced software techniques are used to keep one customer from viewing another customer’s data and to try and ensure that no one customer monopolizes the shared resources in a way that causes other customers to have a bad user experience. This is a very hard problem to solve. Multi-tenancy software has to replicate the multi-tasking features that a modern operating system brings to individual servers but without direct access to the hardware and it must do this across multiple distributed resources (servers, storage, databases, etc.).
The multi-tenant architecture dramatically improved SaaS vendor margins and their price competitiveness over traditional ASP vendors and timesharing solutions in two ways:
- Less hardware and software needed to support the pool. Servers and software licenses can be shared over many users instead of just one, leading to huge savings. These savings allow a SaaS vendor to be price competitive, or even cheaper, than an in-house solution.
- Easier maintainability. Since all customers are running the same software, it becomes much easier to maintain. Instead of rolling out a bug fix to a 1,000 separate machines/ERP installations, you simply fix it once and all thousand customers benefit from a minimal effort on the SaaS vendors part. The downside for customers is that SaaS software follows Henry Ford’s famous Model T customization model: “You can have any color you want as long as it is black.” A multi-tenancy model, by definition, limits the amount of customization available to any single customer.
These gains, in combination with the fact that an ASP model is a natural fit for the very predictable and profitable subscription based pricing model has bought the industry full circle to its original business model, timesharing. Back to the future indeed!
I know I promised in my last post to talk about what’s coming after the multi-tenant architecture but this post is getting long. So I will cover post multi-tenancy architectures and deployment models, including our approach at PatternBuilders, in my next post.