Friday, October 14, 2011

Why We need Multi-tenancy?

This is an expert from my paper,  "A Multi-tenant Architecture for Business Process Execution" that was presented at  9th International Conference on Web Services (ICWS), 2011 with some changes to give context. 

This is related to Sumedha's blog and Larry Elision's comment on Multi-tenancy (MT). Also similar ideas were presented in my talk at WSO2 Con Multi-tenancy: Winning formula for a PaaS.  

What is Multi-tenancy? 

The idea is that the same server instance can support multiple tenants. In other words, it gives the illusion to each user that he has his own server/App while actually, the server is shared among many. MT enables hosting organizations to mix and match heavily used and lightly used tenants together, thus enabling them to run the overall infrastructure with much less resources. 

It is best compared to an apartment complex, where the owner of each apartment (tenant) thinks it is his own home, while the apartment complex shares resources like real state, plumbing, ventilation, security etc. Idea is to provide isolation while achieving maximum sharing. 

Why Multi-tenancy? 

1. Each VM runs its own OS etc., while with MT, the sharing happens at much higher level than VMs, thus enabling better resource sharing. 
2. Supporting Pay as you go within a Cloud platform. 

Let me explain this in bit more detail. Cloud platforms, SaaS, PaaS have “pay-as-you-go” model as a key assumption. That is users can ask for resources and use them only when he needs them and should be able to release resources when he does not. If this assumption holds, applications while not being used should cost the user almost nothing. Therefore, to support pay-as-you-go model, the both SaaS or PaaS middleware should be able to support applications owned by many users (we will call them tenants) within the same server while allocating resources on demand. 

It is possible to do this through IaaS where one can run a VM per each user. However, often many of the applications and users are not active (in use). For example, if a hosting provider has 10,000 tenants and if only few hundred are in use at a given time, then running a VM for each is a waste. Since booting up a VM often takes time and does not complete fast enough to serve the first request, keeping VMs in disk and booting VMs on demand is often not practical.

With MT, the cloud provider can handle this by allocating tenants to servers based on the projected load (e.g. cloud provider can give different classes of QOS). He should place many rarely used tenants in the same server using MT, thus reducing the cost. 

However, there may be other way to implement pay-as-you-go, and I would love to hear about them. 

On final note, implementing MT is not easy by any means, and it take some thinking and hard work. Main challenges are data isolation, execution isolation, and performance isolation. I will talk about them more in a later blog. Mean while, following papers talks about how WSO2 implemented some of them. 

  1. A. Azeez and S. Perera et al., WSO2 Stratos: An Industrial Stack to Support Cloud Computing, IT: Methods and Applications of Informatics and Information Technology Journal, the special Issue on Cloud Computing, 2011.
  2. Milinda Pathirage, Srinath Perera, Sanjiva Weerawarana, Indika Kumara, A Multi-tenant Architecture for Business Process Execution, 9th International Conference on Web Services (ICWS), 2011 
  3. Paul Fremantle, Srinath Perera, Afkham Azeez, Sameera Jayasoma, Sumedha Rubasinghe, Ruwan Linton, Sanjiva Weerawarana, and Samisa Abeysinghe. Carbon: towards a server building framework for SOA platform. In Proceedings of the 5th International Workshop on Middleware for Service Oriented Computing (MW4SOC '10). ACM, New York, NY, USA, 7-12. DOI=10.1145/1890912.1890914, 2010
  4. Afkham Azeez, Srinath Perera, Dimuthu Gamage, Ruwan Linton, Prabath Siriwardana, Dimuthu Leelaratne, Sanjiva Weerawarana, Paul Fremantle, Multi-Tenant SOA Middleware for Cloud Computing 3rd International Conference on Cloud Computing, Florida, 2010

No comments: