Almost every definition of cloud, amongst the myriad definitions that exist, include the notion of multi-tenancy, a.k.a. the ability to isolate customer-specific traffic, data, and configuration of resources using the same software and interfaces. In the case of SaaS (Software as a Service) multi-tenancy is almost always achieved via a database and configuration, with isolation provided at the application layer. This form of multi-tenancy is the easiest to implement and is a well-understood model of isolation.

In the case of IaaS (Infrastructure as a Service) this level of isolation is primarily achieved through server virtualization and configuration, but generally does not yet extend throughout the datacenter to resources other than compute or storage. This means the network components do not easily support the notion of multi-tenancy. This is because the infrastructure itself is only somewhat multi-tenant capable, with varying degrees of isolation and provisioning of resources possible. load balancing solutions, for example, support multi-tenancy inherently through virtualization of applications, i.e. Virtual IP Addresses or Virtual Servers, but that multi-tenancy does not go as “deep” as some might like or require. This model does support configuration-based multi-tenancy because each Virtual Server can have its own load balancing profiles and peculiar configuration, but generally speaking it does not support the assignment of CPU and memory resources at the Virtual Server layer.

One of the ways to “get around this” is believed to be the virtualization of the solution as part of the hardware solution. In other words, the hardware solution acts more like a physical server that can be partitioned via internal, virtualized instances of the solution*. That’s a lot harder than it sounds to implement for the vendor given constraints on custom hardware integration and adds a lot of overhead that can negatively impact the performance of the device. Also problematic is scalability, as this approach inherently limits the number of customers that can be supported on a single device. If you’re only supporting ten customers this isn’t a problem, but if you’re supporting ten thousand customers, this model would require many, many more hardware devices to implement. Taking this approach would drastically slow down the provisioning process, too, and impact the “on-demand” nature of the offering due to acquisition time in the event that all available resources have already been provisioned.

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

-- NIST Cloud Computing Definition v15

And yet for IaaS to truly succeed the infrastructure must support multi-tenancy, lest customers be left with only compute and storage resources on-demand without the benefit of network and application delivery network (load balancing, caching, web application firewall, acceleration, protocol security) components to assist in realizing a complete on-demand application architecture.

What is left as an option, then, is to implement multi-tenancy architecturally, by combining the physical and virtualized networking components in a way that is scalable, secure, and fits into the provider’s data center.

An architectural approach leverages existing networking components to provide shared services to all customers. Such services include virtual server layer failover, global application delivery, network and protocol security, and fault-tolerance. But to provide the customer-specific – application-specific, really – configuration and isolation required of a multi-tenant system the architecture includes virtual network appliance (VNA) versions of the networking components that can be provisioned on-demand and are specific to each customer.

This architecture ensures providers are able to easily scale the customer-specific networking services by taking advantage of the hardware components’ inherent scaling mechanisms while affording customers control over their application delivery configuration. Providers keep their costs to implement lower because they need fewer hardware components as a foundational technology in their data center while ensuring metering and billing of application delivery components at the customer level is easily achieved, often via the same “instance-based” model that is used today for server costing.

Customers need not be concerned that an excessively complex configuration from another customer will negatively impact the performance of their application because the application/customer-specific configuration resides on the VNA, not the shared hardware. All customers can benefit from a shared configuration on the hardware platform that provides non-specific security functions such as protocol and network-layer security, but application-specific security can reside with the application, alleviating concerns that “someone else’s” configuration will incur latency and delays on their application because of the use of layer 7 security inspections (often inaccurately called “deep packet inspection”).

An architecture in which VNAs are leveraged to provide multi-tenancy also assists in maintaining mobility (portability) of the application because the VNA can be packaged with the application and moved more easily across cloud control boundaries.

In a “private” cloud implementation this architecture is just as valuable, allowing for better accounting of costs associated with individual projects, departments, or sub-organizations while providing a stable, reliable core network for the entire organization. This model better allows organizations to take advantage of the flexibility of network-side scripting to address specific application issues, such as the discovery of a new vulnerability. Customers can implement network-side scripting solutions to specific security or application issues and deploy them as part of the VNA tier until such time as the issue is addressed, whether through patching or development or upgrade of the application. It affords organizations the time to address the vulnerabilities and issues without concern that the application will be compromised. When the issue is addressed, the VNA can easily be decommissioned without disruption.

Multi-tenancy is an important aspect of cloud computing that certainly should be supported across the entire network and application delivery network infrastructure. While this certainly can be achieved by the internal virtualization of hardware components (and has in the past) such a model may not be appropriate (i.e. cost-effective) for large-scale providers seeking to serve thousands of customers. A combination of hardware and virtual network components architected in such a way as to ensure reliability and availability while also securing the flexibility and isolation of configuration and data customers demand is what is needed. Architectural multi-tenancy is likely the best option for achieving all the desired goals without sacrificing any of the benefits of either the hardware or virtual model.

* This is the route that Nauticus Networks took in their ill-fated virtual switch albeit without the benefit of modern virtualization technology