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."
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.
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.
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.