Once perceived as the weak link in the cloud-security chain, multi-tenancy has evolved to become not only the foundation of the efficiencies the cloud is noted for, but also the key to keeping your organization’s valuable applications and data secure. By sharing a single codebase, cloud apps and data can be patched and updated much faster than is possible when they reside in your company’s internal networks.
Multi-tenancy is a cornerstone of cloud computing. It is the key to the cloud’s elastic scalability and other cost efficiencies. But when it comes to multi-tenancy’s data-management benefits, on-demand scalability is the tip of the iceberg. In particular, organizations of all sizes are coming to appreciate the enhanced security of the multi-tenant architecture, particularly when compared to the increasing difficulty of securing in-house data centers.
Ironically, security was often cited as a weakness of multi-tenancy in the early days of cloud computing. It didn’t take long for that perception to do a 180. As Forbes’ Tom Groenfeldt reports in a December 1, 2015, article, IT departments tend to overestimate their ability to secure their in-house networks.
Groenfeldt cites a recent report that found in-house breaches can take weeks or months to discover and patch, whereas cloud services have up-to-date tools and qualified staff to detect and correct security vulnerabilities before they can be exploited. In fact, near-constant security auditing is often a requirement for cloud services to earn the certification their infrastructures require, according to Groenfeldt.
Multi-tenancy is also a feature that distinguishes cloud services from the data-hosting offerings of third parties that merely move the customer’s apps and databases from a server in their data center to an identical server at the service provider’s site. This practice is referred to as “cloud washing” by DataInformed’s Bil Harmer in a November 30, 2015, article. Harmer states that multi-tenancy is a fundamental aspect the three major cloud categories: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
All three major cloud categories rely on multi-tenancy to deliver the elastic scalability that is the cornerstone of cloud-service efficiency. Source: Forrester Research
Harmer identifies three must-have features of true multi-tenancy:
When a vendor simply runs its legacy software in multiple virtual machines, it is merely hosting those isolated apps, not delivering cloud applications, according to Harmer. If the vendor claims to be offering a multi-tenant environment for such hosted apps, it is cloud washing. Not that there’s anything wrong with app-hosting services. It’s just not appropriate to market such products as cloud-based.
The primary difference is that when you need more capacity in a hosted service, the vendor will issue a Statement of Work (SoW) that states explicitly what resources you are contracting for: hardware, installation, maintenance, licensing, and support. By contrast, a cloud service scales capacity on demand, and because all tenants share a single codebase, everyone benefits automatically when that codebase is patched or upgraded, without requiring any renegotiation.
Back in 2011, Oracle CEO Larry Ellison told the Oracle Open World conference that his company’s “cloud” solution was more secure than that of rival Salesforce.com because Oracle’s service did not use multi-tenancy, while Salesforce.com’s offering did. As Forrester Research’s James Staten and John R. Rymer point out in the definitive whitepaper Understanding Cloud’s Multitenancy (pdf), Ellison was wrong on two counts:
Tenant autonomy is achieved by isolating tenants at three points in the cloud architecture:
The two principal methods used by cloud services to ensure tenant autonomy in multi-tenant architectures are the dedicated resource model and the metadata map model. Source: Forrester Research
The primary difference between the two models is that the former provides each customer with a fixed set of logical resources that are clearly defined, packaged, priced, and allocated; while the latter “hides” all processor, storage, and network resources behind metadata and keeps the metadata separate from the data and resources. The dedicated resource approach is more akin to traditional enterprise infrastructure management, while the metadata map model assigns objects to each tenant for all operational tasks as if they were organized into a container.
In reality, cloud services are likely to use a mix of these two approaches: the dedicated resource model for apps that were written originally for on-premises, single-tenant environments; and the metadata map model for apps and services designed with multi-tenancy in mind from the get-go. The Morpheus cloud application management platform supports both models in public, private, and hybrid cloud environments via its out-of-the-box integration with Amazon Web Services (AWS) and Openstack. Morpheus offers a single management console that lets you track servers, storage, and utilization in the cloud configuration of your choice.
