Taking false cloud comfort from multi-tenancy

One-for-all or many-for-some? How a vendor implements multi-tenancy makes a big difference to the effectiveness, competitiveness and market appeal of a cloud application or resource.
Written by Phil Wainewright, Contributor

With new players and products coming to the cloud every day, it's more important than ever to be clear about what exactly buyers should be looking for when evaluating cloud offerings. Perhaps the biggest cause of confusion and misunderstanding is the use of the term 'multi-tenancy'. It's a core ingredient of cloud and has been rightly emphasized by cloud platform vendors as a key differentiator from other forms of hosted computing such as application service provision (ASP). The emphasis has been so strongly expressed that many people have inferred that multi-tenancy is synonymous with cloud computing. Unfortunately, it's not quite as simple as that. There are a number of different ways of implementing multi-tenancy, and not all of them deliver the full benefits of the cloud model.

The key point about how Salesforce.com, Amazon, Facebook or any other 'true' cloud platform works is that everyone shares it — which both requires and transcends multi-tenancy. Indeed, it's almost superfluous to mention multi-tenancy except to emphasize the differentiation from conventional software. In the cloud, it's simply not viable to provision a truly elastic, continuously updated resource as an on-demand service without making it multi-tenant. But, as I've written many times in the past, that's still not the whole story. At its heart, cloud computing is all about being connected. In that context, multi-tenancy is just one of four defining characteristics of cloud.

The bottom line is that you can have multi-tenancy but still not be 'true' cloud. How the multi-tenancy is both architected and implemented each impact how well the service performs in a cloud context. To use a recipe metaphor, there are several different flavors of multi-tenancy, and it can be served in a variety of settings. Here's a short rundown of the most common architectures and implementations you'll find in use today.

One shared resource for all

This is the classic implementation model used by all the cloud leaders. All clients use the same, unique, shared operational resource, which is presented to them either as a web application or as an API (preferably both). How the underlying infrastructure is architected behind that interface can vary enormously, as I discussed in some detail a while back.

In most examples, these services are powered by multiple instances sitting behind the single interface, simply because running an elastic resource at scale means distributing the computing across dozens, hundreds or (preferably) thousands of replicated, interchangeable instances. For an application provider like Salesforce.com, the instances can be very big clusters with many services around them. Other providers replicate a larger number of much smaller instances. In a large-scale implementation, the replication can happen at many levels. Google not only runs its services across thousands of replicated commodity servers, its infrastructure even replicates entire data centers.

The key point about what happens behind the scenes of a single shared cloud service — whether it's Amazon EC2 computing, a platform such as Heroku, a service like Google Maps or a complete application like NetSuite — is that the client doesn't have to know or care how many instances are running behind the interface, so long as it performs to expectations. There may even be occasions where some of the components within that shared resource become single-tenant instances if the load balancing works better that way, but the client won't notice any difference.

For an application provider (to a much greater extent than an infrastructure or platform provider), that behind-the-scenes control gives enormous flexibility to pool resources at every layer of the compute stack to produce maximum economy, performance and functionality. Because the resource pooling is so comprehensive, application providers can use multi-tenancy to deliver competitive services from relatively small instances of dozens or hundreds of servers rather than the thousands that are needed to provide an economic cloud infrastructure-as-a-service offering. Many of course get even greater economies by running their applications either partly or wholly on public cloud platforms rather than have the headache of operating their own servers or burst capacity.

Page 2: Multiple shared instances for some »

«  Page 1: One shared resource for all

Multiple shared instances for some

This is the implementation model preferred by many conventional packaged application vendors, especially those with a longstanding ecosystem of partners — step forward Microsoft as a prime example, although it is SAP's plans for Business One that has prompted debate on the topic this past week among current and former Enterprise Irregulars. The model is also seen in licensed and open-source platform-as-a-service offerings such as VMWare's Cloud Foundry, and plays an important role in Oracle's approach to delivering its own SaaS portfolio.

In this model, the software is architected for multi-tenancy, but is separately implemented many times over, either in separate 'pods' within the vendor's own data center, or by individual third-party providers, such as hosting companies, solution providers, developers and some enterprises. It's quite legitimate to describe each of these implementations as multi-tenant if they are serving multiple customers, even though there's a fundamental weakness compared to the 'one for all' model mentioned above.

Ecosystem players like this 'many for some' model because they feel more in control of their own destiny hosting their own instances than when the cloud service is provided direct from the vendor. The weakness lies in the slow and cumbersome innovation cycle that results from having to test and distribute the software every time there's a patch or a new release. It's poles apart from the devops model beloved of cloud afficianados.

Compared to 'one-for-all' cloud applications and platforms, the 'many for some' model adds huge extra test-and-development costs and time-to-market lags that result in a highly uncompetitive business model. But since many conventional ISVs and their partners have nothing better to offer in the cloud, it remains hugely popular as an alternative to traditional on-premise solutions and is much less disruptive to existing channel business models than the 'one-for-all' model.

For channel players serving niche markets this type of multi-tenancy may serve them well for the next few years, so long as there's no viable 'one-for-all' cloud alternative their customers can turn to. Many ISVs will get to market faster if they build on packaged PaaS solutions rather than architecting their own platform from the ground up. But those choices are merely deferring the disruption of moving to a 'one-for-all' model to a later date. For ISVs in particular, I would argue that the best way to stay in control of your own destiny in the cloud is to follow the example of companies like Zynga — build on someone else's public cloud to get started, and once you've grown big enough to justify it you can migrate to your own servers later on.

Private shared instances for a few

The final take on multi-tenancy is to implement a private shared instance to serve a closed community of clients — perhaps as a way of lowering the speed, cost and governance overhead of serving a set of applications to departments and subsidiaries in a large enterprise, or to serve participants in an extranet of suppliers, dealers or customers. This type of multi-tenancy has a direct lineage from timesharing mainframe resources and it's more prevalent than you might think, especially if you include customer-facing enterprise applications such as online banking, parcel tracking or supply chain management. The trouble with this 'private-for-few' model is that the lack of diversity in the user base will dilute the economies of operation that more public providers gain from better demand pooling, as well as sharing the higher costs and slower innovation of the 'many for some' model.

Market demand from channel partners and enterprise customers for 'many for some' and 'private for few' implementations pretty much compels conventional software vendors to add multi-tenant packages to their product ranges. Most are glad to do so, since it feels like a gradual, non-disruptive move into the cloud. That would be fine if cloud were simply a deployment option, as many in the industry insist it is — and of course if a vendor offers multi-tenancy as an option, that reinforces the perception. But the 'one-for-all' model of multi-tenancy moves cloud offerings onto an entirely different plane where the pace of innovation, breadth of interconnectivity and acceleration of economies of scale are radically increased. Satisfying market demand for other, less disruptive forms of multi-tenancy risks creating a false sense of security and undermines the re-education process the vendors will have to get into as they try to reposition around cloud and get everyone in their organisations and ecosystems up to speed with what cloud is really all about.

Editorial standards