Welcome!

Java Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Adrian Bridgwater, Sharon Barkai

Related Topics: Virtualization, Java, Linux, Cloud Expo, SDN Journal, IoT Expo

Virtualization: Blog Feed Post

Network Virtualization: Instances versus Tenants

Technology shifts are creating a lot of chaos, including the way we use words

Technology shifts are creating a lot of chaos, including the way we use words. Cloud. SDN. Multi-tenant. Instances. They're all inter-related and seem to have different meanings depending on who's trying to sell you what today.

That's more than a tad bit disconcerting, because you know what you mean when you say "multi-tenant" but other people (trying to sell you stuff) may have a different definition. And that means when you ask about it and they say yes, you may not be getting what you expected - and that's not good for either end of the transaction.

So let's talk network virtualization today, particularly with respect to the difference between "instances" and "tenants."

Instance
An instance, made a common part of technology's growing vernacular, stems from the need to separate the physical from the virtual, a la server virtualization. Because "server" is used to describe about fifty different things - all in the realm of technology - it became necessary to distinguish between an application "server" and an application "instance" to avoid confusion. Thus, an instance is often shorthand for virtual machine or virtual instance and essentially describes a container of functionality.

For example, if I refer to an "instance" of BIG-IP I mean a virtual machine in which the BIG-IP platform is running. Note that this says nothing about the underlying hardware, which could be COTS or cloud or purpose-built hardware. That's because one of the characteristics of virtualization is abstraction, and its benefits are generally derived from the fact that it decouples the "solution" from the underlying resource provider (the hardware).

Now, that's an instance. Confusion generally comes in when we start adding multi-tenancy to the discussion which, of course, is a requirement for modern architectures and deployment environments.

Multi-tenancy
The basic principles of multi-tenancy are similar to that of an apartment complex. Multiple tenants, all with their own isolated "living space" cohabitate within the same physical space. This enables the tenants to share the cost of the infrastructure (the physical structure) and thus lower the overall costs of living.

In technological terms, the same concept applies. We want to allow multiple tenants (applications) to share the cost of the infrastructure and thus lower the overcall costs of delivery (all the services you have to have to make sure the application is secure, reliable and available).

Multi-tenancy in infrastructure enables multiple tenants to cohabitate while being assured they can manage their own space in an isolated, secure fashion. The way this is achieved is to segment each instance into isolated domains, usually on a per-application basis.

Depending on specific architectural, regulatory or business requirements, a single instance can be treated as equal to a single tenant. But more often than not a single instance is segmented into multiple tenant domains to enable greater sharing of costs.

tenancy-versus-instances

The end result should be the more tenants, the lower the costs*.

The reason this is important is because applications require greater diversity in network policies with respect to performance, availability and access. The days of applying the same set of network policies to web application A and B are pretty much over. The coming of the Internet of Things is going to force highly differentiated policies to be put in place on a per-application basis. That means that infrastructure needs to provide multi-tenant instances able to go far beyond the simple "tenant = instance" assumption that is frequently made when discussing network virtualization because the number of applications that will be rising to support new business models and take advantage of opportunities is only going to increase in the next few years.

So be careful with your words as you start to lay the network foundation you're going to need to succeed in the coming years. Make sure you know exactly what the person on the other side of the table means when they say "multi-tenant instance" and make sure it will be able to support the way in which you're going to need to deliver all those new applications.

* Assuming the business model associated can achieve the economies scale required by modern architectures. Many cannot.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.