The economics of multi-tenancy and its effect on the overall service offering…

One of the key design decisions for Cloud Computing implementers is multi-tenancy.  The idea is to abstract a pool of sharable resources (i.e. server, database) at the right layer, and to the right degree to optimize the number of tenants served by the resource.   Obviously, this needs to be done in balance to the particular service offered, the context in which the service is used, and challenges in terms of ongoing Cloud infrastructure/platform operation and maintenance, Terms of Service, etc…
Multi-tenancy has broad impact on the overall service offering from architecture and operation to financial management.  For service providers (including private Clouds implemented by shared services in many large organizations), it bears direct financial impact with regards to level of asset utilization and return-on-assets [i.e. total revenue from all tenants / (assets costs + asset operation & maintenance)].  It  also effects software licensing costs, resources required for ongoing service operation and configuration management, support, etc…
There is a spectrum of multi-tenancy:

At the server level, the unit of deployment is Virtual Machine (VM).  Each tenant is offered a VM to provide isolation and protection from other tenants.  So, a key question in this shared tenancy model is VM density.  How many VMs can be carved out on a physical server resource?  Other key considerations involve service provider's average cost of a VM (i.e. power, cooling, hardware and software costs, ongoing support and maintenance, etc)…
At the next level, there is platform as a service.  Examples of that would include Google App Engine (GAE) or Force.com.   On these platforms, unit of deployment is an application.  As an example, on GAE, tenants are provisioned their own application server (Jetty) running on Google’s infrastructure.   Similarly, on Force.com, each developer is provisioned a Resin app server in the to prevent tenants from stepping on each other…
At the top, a single code-base application is shared by multiple tenants.  A well-known example would be SalesForce.com.  Depending on the service implementation and tenancy model, as new tenants are provisioned, different levels of resource sharing may occur…  [Please have a look at the following MSDN article on Multi-Tenant Data Architecture.]
At each level, the following issues should be continually considered:

• Tenancy Density: How many tenants can be instantiated on a physical unit of deployment?  
• Cost / Tenant:  What is the average cost / tenant?  The cost includes everything from infrastructure costs (i.e. facilities, power, cooling, Telco provider) to hardware components including server, storage, network to software licensing costs, service maintenance and support…
• Service Design: Does the tenancy model enhance the service for the target customers?  For example, many organizations are looking at the Cloud to simplify their IT by offloading infrastructure operation and maintenance costs to Cloud service providers.  In the lower level, organizations are still required to staff for operation, monitoring, and support of their applications on the Cloud infrastructure…
• etc…

So, the design decisions and technology selections around multi-tenancy should not be approached casually, as it has fundamental impact on the service, its profitability, as well as operation and maintenance.