If IT isn't shared, it isn't cloud...

Recently I was asked: Is multitenancy a fundamental of cloud computing or SaaS or both? I think that depends on how loosely defined multinenancy is in your dictionary.

In computing, the term multitenancy describes a shared approach to resources. I think that in a very loose definition both cloud computing, and of course SaaS, involve resource sharing. But not all types of multitenancy are the same with respect to their approach to resource sharing.

Gartner offers up six models of multitenancy: shared-nothing; shared-hardware; shared-processing; shared-database; shared-everything and custom multitenancy.

The shared-nothing approach is the least multitenant in nature and users may have nothing more in common than a shared URL, billing system, support line or duplicated executable files. This stretches the definition of multitenancy so far as to be essentially out of bounds, in my view, and is most likely adhered to only by those seeking to follow on the bandwagon effect of SaaS and the cloud. Think of IBM WebSphere or Oracle Application Server running on Amazon EC2.


The shared-hardware approach to multi-tenancy isn’t very interesting to software types like me. In this model, the tenants share a common pool of hardware usually through virtualization. But each tenant has its own dedicated software stack (application platform, middleware, applications, databases, etc.) It should be no surprise that this is the approach taken with Microsoft Azure .NET because they want to maximize software sales and licenses and the easiest way to do that is to require multiple instances.

What Gartner calls shared-database multitenancy is about a single database for all tenants. Tenants do not share each other’s data (and can not see it), but it is stored inside the same database. However, a separate instance inside an application container is used to process the application.

Only when Gartner starts to speak about shared-processing multitenancy will some cloud advocates start to nod their heads. In this model, a multi-threaded application platform brokers each tenant’s use of the processor but each tenant will likely have a unique database instance. Gartner says: ". Most process execution resources are shared, allowing fine-grained elasticity. The application platform has multitenancy features responsible for tenant isolation and for targeting all data exchanges to the correct DBMS instances. " Gartner mentions the uniPaaS application platform as the example of this model.

In the shared-everything model of multitenancy both processor and database multitenancy is present. As Gartner suggests, this provides maximum theoretical elasticity. However, several factors such as the efficiency and design of the database gateway and the operational integrity and bi-directional scalability of the processing engine can inhibit optimal processing performance in shared-everything multitenancy approaches such as Force.com. Other downsides include public exposure of non-specific tenant metadata (statisitics about overall use of the application or platform can become known to competitors) as well as issues related to the lock-in of application code on a completely proprietary cloud platform or SaaS application.

Finally, Gartner would identify custom multitenancy as a sort of manually programmed multitenant architecture. Clearly the programming overhead is massive in such approaches and one worries about the capability of an organization to sufficiently test such an approach in a manner that can assure operational integrity and reliability.

Choosing the right level of multitenancy is an important decision. But it is not the only decision in choosing a cloud-enabled application platform. One must also consider the client environment and the challenges of developing both the server side and the client side of an application. So to answer the question we started with, yes, both cloud computing and SaaS require some model of multitenancy. If it isn't shared, it isn't cloud. Nobody owns the whole damn sky.

One-To-Many Application Platform: Is Cloud Computing In Need of New Infrastructure?

An Architectural View of One-to-Many

uniPaaS is emerging as the industry’s first one-to-many application platform. We are all familiar with the one-to-many data relationship as the workhorse of relational databases. As David Remsen states: “When deciding upon how to best split data into tables we often ask "What are the logical units of the data?" In other words, what is best represented by a single row of data. It is often convenient to think of physical representations when applicable. For example, what types of information can we associate with a patient that only appears once. A person usually has one name and social security number so these can be safely placed in a table. We might add date of birth. [On the other hand] a person can have many tests. They might only have one but they might also have fifty. Thus one person might have many tests and this is represented by a One-To-Many relationship…”

A one-to-many data relationship exists when one record from one data source is related to several records from another data source; a single country in a Country data source will be linked to many entries within a City data source. This much is clear and well known to developers and users alike.

So what is a one-to-many application platform? A one-to-many application platform is an application platform designed to optimize the delivery of many applications, each of which may have many implementations. And of course, each implementation may have many users.

In the past, client-server applications tended to be bound by notions of physical location and ownership. My company owns an application server in Chicago and any of the local area network clients can use it. Using the medical record analogy above, this situation is a bit like building a doctor’s office inside of every one of your company offices just in case someone gets sick. Shouldn’t you send them to a clinic where the needs of many in the community can be served? Why monopolize the skills and equipment of a doctor for only one or two patients per day?

Even with the introduction of wide area networks, VPNs, the Internet, and the like, we still got hung up with the concept of ownership. My company bought a software license and only our people can use our software on our server, but yes they can sit anywhere on the web when they do it. Now granted, this was very liberating. Physical space dissolved when using software applications. Networking, T3, WiFi and a host of other technologies have conquered the notion of space separating us from use of computer applications.

So along comes the idea of Software-as-a-Service (SaaS) to break down another barrier. Through a concept known as multi-tenancy, the ownership barrier is broken down. Many different implementations of the same software application can exist within the same database. Each tenant’s data is firewalled from the others so that ACME Corp has no idea that ABC Corp is even using the same application. In this instance the physical servers and the software are not installed on the client computers. Only a web browser or client runtime engine need be installed, but the real application runs remotely on someone else’s physical servers. One-to-many computing is better served when the client side is capable of Rich Internet Applications (RIA).

Gradually and then all of a sudden, SaaS became a popular trend as successes like Salesforce.com bedazzled customers and Wall Street investors. The SaaS story sounded somewhat familiar to people who had been promoting hosted computing services. As the notion of grid computing sort of floundered for want of a customer base, the industry searched for a new hype cycle and found it in the notion of cloud computing. Cloud computing sort of combines the SaaS idea of Software-as-a-true-service with Software-as-a-do-it-yourself-service. Our application on your hosting server fits some people’s notions of what cloud computing is all about.

Thinking back to our medical records analogy in the beginning to explain one-to-many data relationships. SaaS is a bit like having access to a doctor’s office. You can go there and see one doctor or maybe a few, but you are pretty much limited by the skills of the doctor and the equipment in the office. Seeing a doctor is great, unless you need the services of a hospital.

A one-to-many application platform doesn’t just serve one customer and it isn’t limited to a single software supplier either. A true one-to-many application platform is independent of the underlying physical computing architecture and capable of sustaining n-applications across n-implementations with n-users. So while the application platform is unitary, it can not be bound to a single physical CPU or server in order to support its many applications, implementations and users. The architecture must be capable of application partitioning across multiple physical servers and data storage servers.