- Treating applications in enterprise data centers as tenants allows those applications to be agile, without impacting other applications.
- Multi-tenancy is not always supported well in networking products, and ineffective support means workarounds and increased complexity which are anathema to well-run IT.
When looking at network services such as application delivery controllers (ADC), firewalls, content filters, WAN optimization appliances, physical and virtual switches – anything that processes application traffic – you want to examine the multi-tenancy features that are available to ensure they provide adequate isolation from other applications and the configurations can be easily, seamlessly moved from one appliance to another.
Multi-tenancy is often considered a service provider requirement because providers serve many customers that need to be isolated from each other. Enterprises benefit from multi-tenancy even though there is one customer with one administrative domain. In fact, multi-tenancy in an enterprise historically has had little value with traditional IT data centers, but the requirements change when moving to a highly automated data center or private cloud.
Many enterprise applications are still written in a rigid fashion and do not respond well to changes, such as changing an IP address that could be deeply embedded in an application in multiple places or adding and removing components dynamically. The rigid nature of enterprise applications is at odds with the dynamic nature of private clouds and is the primary reason why we have a growing number of protocols and methods such as network overlays or packet encapsulation which allow the network to change underneath applications without those applications being aware of the change. You can move a server from rack 1 to rack 30 and the networking – viewed from the application – remains the same regardless of what is happening in the physical network.
When you bundle up the networks, services, and servers that make up an application into a logical unit and isolate it like a tenant, then you simplify operations management because you do not have to worry about conflicting configurations in your network. For example, if you acquire a company or consolidate data centers which have overlapping IP address ranges, you do not have to renumber networks as long as the applications are isolated from each other. In the rare cases where two services on overlapping networks many need to communicate, you can use address translation or proxies to resolve the conflict.
Similarly, if you want to move an application from one data center to another, you do not have to worry about the networking configuration at the destination, because the network the application tenant uses does not change and the physical network has no idea what is happening in the tenant network. You can even stretch networks across the data center or to public clouds provided your overlay/encapsulation technology is supported by the public cloud provider.
For example, ADC products such as A10’s Thunder, Brocade’s ADX, and Citrix’s NetScaler support multi-tenancy by isolating applications. Automation and orchestration features simplify activities such as moving services around a data center and scaling the services up or down without impacting adjacent application tenants.
Start thinking of applications as tenants and make sure your products support multi-tenancy. Doing so will prepare your applications for the dynamic orchestration that is coming your way. Lack of solid multi-tenancy support only adds problems.