Larry Lang, CEO, PLUMgridBut change is upon us. Newer, web-based workloads run in hypervisor environments other than ESXi, with bare metal and container deployments gaining ground as well. Agile, private-cloud environments like OpenStack are providing API-level access to compute, storage and networking resources, and the networking requirements are very different between these two worldviews.
"Getting the networking solution right enables them to build and deploy applications and iterate them faster without excessive re-engineering to the network"
Periodically, application developers embracing agile and DevOps need to access data running in their legacy VMware environments. Think Oracle, SAP and the like which store data for application developers as they build apps in OpenStack environment.
In this new world where VMware is one data center architecture among several, it’s critical that networking catch up. A single, virtual networking domain to span each hypervisor, which connects legacy to new way of app developing, bare metal and container scenario in the IT portfolio is needed. A single virtual networking domain for such heterogeneous environments would not only tie these disparate pieces together for control and data plane processes, but would help IT utilize existing environments more efficiently as application developer needs become more diverse, not less.
Let’s take a closer look at the core issue.
As businesses are deploying and using multiple hypervisors to run different workloads for their applications, single-domain virtual networking, which provides a path to the future cloud technologies of OpenStack and is also a bridge to legacy VMware environment is must -have with minimal network downtime or disruption. Several open source and commercial solutions are lining up to deliver this. The idea is to give app devs the capability to manage applications through a single virtual networking domain, across a multiple hypervisor environment and scale as the application portfolio changes. The typical environment looks like below.
So, why all the hypervisors? There are three main reasons:
1. Different departments have different needs
Multi-hypervisor environments evolved from pragmatism. Different business units needed to run different applications that required different hypervisors. For example, some databases run on ESXi while the corresponding web servers run on KVM. This usually requires separate networking solutions, often hardware centric, for each hypervisor environment.
2. The non-stop purchase cycle and tribal knowledge
Once you get started on a specific hypervisor, it’s hard to stop. Businesses may want to leverage the stability and maturity of their existing ESXi infrastructure for a production environment. This is entirely understandable. IT leadership is reluctant to lose an existing competency with a chosen hypervisor once they’re in production with it. After all, no one wants to consider changing the hypervisor for apps tied to mission-critical processes unless there’s a compelling reason.
On the other hand, these same businesses might be open to a green field deployment of a new hypervisor—such as KVM in OpenStack—for the feature testing phase of an application lifecycle. Such scenarios force businesses to deal with separate networking domains tied to each hypervisor at different stages of the application lifecycle. This, in turn, further spawns unnecessary risk and complexity in networking domains.
3. Fear of lock-in
Choosing one hypervisor for deployment across a range of workloads necessarily leads to lock-in of some form, whether that’s vendor lock-in or commitment to a specific open source project. By extension, this usually leads to sub-optimal network performance or unnecessary network customization. Such network and hypervisor tie-in increases licensing and support costs, which may not be needed for the planning and development phase of the application lifecycle.
Moving towards a single virtual networking domain
With the networking complexities associated with multi-hypervisor environments, a solution that creates and manages a single networking domain for each application is a big advantage. This eliminates the need for network reconfiguration or policy setting changes as applications move from the development to the deployment phases.
To state it more directly, a single, virtual networking domain delivers three advantages for enterprise IT:
1. Homogenized virtual network environment for app deployment and extensibility
2. Leverage technology improvements in each hypervisor
3. Maintain cost leverage with hypervisor vendors without disrupting the network layer
There are several open source and proprietary software solutions that are working toward this goal. Multi-hypervisor environments will continue to be the norm, not the exception, so companies looking for a scalable, secure, zero downtime virtual networking platform have options they should consider. Getting the networking solution right enables them to build and deploy applications and iterate them faster without excessive re-engineering to the network.
