There's a chokepoint in the process of automating the virtualized data center. Sure it's quick and easy to spin up a virtual machine, and once running, you can even re-allocate memory, CPU, and storage from the management console. But when it comes to assigning or re-assigning network bandwidth, good luck.
Networks can be virtualized, but most are not. Network infrastructure springs from hardware design concepts that predate the concept of virtualization. Even the "virtual" local area network must be defined in hardware, when it should be set in software.
In many cases, switches, routers, and controllers depend on their embedded spanning tree algorithms. Spanning tree is an arithmetical determination of the most efficient path for a message to follow in a given network and results in a hierarchy of devices. After the mapping is implemented, not a lot more can be done. Spanning tree is built in and each device knows its place in the map. That leaves the network calcified in place, unyielding to momentary demands and resistant to taking on an assignment of different characteristics.
As sleeping virtual machines come to life, or reach peaks of operation during the workday, it would be nice to be able to allocate and reallocate their network resources, based on where the traffic is. For that matter, when a new virtual machine is spun up in three minutes, it would be great to get its network allocation at the same time instead of waiting three days for a network engineer to rig its network services. Why can't automated policies be applied to the VM's networking, like those for CPU, memory, and storage? Those policies are already in place and ready to be implemented at the moment of a VM's creation. Why is networking a holdout?
The reason is there are still barriers to treating networking as a programmable or software-defined resource. The virtualization phase that has swept through the data center is still washing up on networking concepts expressed as devices hard-wired together. What's needed is to free the network from the underlying hardware. It should be a more malleable entity that can be shaped and reshaped as needed. Part of the purpose for lifting the network definition above the hardware is to escape the limitations of the spanning tree algorithm, so useful in its day, now outmoded by virtualization.
Escape from spanning tree can be done if your network vendor supplies virtualization management atop its hardware devices, but then you must use one vendor's equipment exclusively. Most enterprise networks are a mix, making virtualization harder to implement. So what's really needed is a separation of the switching control plane, currently the spanning tree algorithm's fiefdom, from its direct link to the hardware. By allowing a new set of policies or flexible algorithms to run the hardware, we can adapt the network to the world of virtualization.
One way to do so is to adopt a much more flexible approach to network algorithms called OpenFlow, from a research project at Stanford. The difference between spanning tree and OpenFlow is summed up in a statement by Guido Appenzeller, CEO of the startup Big Switch Networks and a director of the Clean Slate research project on network redesign at Stanford: "I don't want to configure my network. I want to program my network," he said in an interview. Appenzeller said he's just echoing a statement he heard from James Hamilton, distinguished engineer at Amazon Web Services. There is an awareness of how applications have been separated by virtualization from the hardware and a widespread wish that something similar would happen with networks.
"Networking needs a VMware," said Kyle Forster, a co-founder of Big Switch and vice president of sales and marketing. Big Switch was created to fill that ambition--founded to take advantage of the OpenFlow protocol that came out of Stanford's Clean State project in 2008 and backed with $11 million in venture capital, for starters.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
