For cloud automation, think flat networks and Ethernet fabric

The goal of the cloud—whether public or private—is to make business services immediately available to anyone, anywhere, anytime. To do that cost-effectively, cloud automation—or the provisioning and deprovisioning of servers, storage, networking and applications on demand—is crucial. For networking, cloud automation will mean the move to Ethernet fabrics and potentially open network software.

Cloud computing is a different economic model and a different 'technology destination' that depends on greater flexibility by standardising and simplifying. "You can't innovate until you've optimised and automated," said analyst Jonathan Steel, founder and CEO of The Bathwick Group.

Cloud networks require going flat and using Ethernet fabrics

Networking vendors argue that an important part of that simplification and optimisation is to make the network as flat as possible, for example, by collapsing it to a single Layer 2 tier in the data centre, plus another tier for aggregation. This is generally done using Ethernet network fabrics that borrow the almost peer-to-peer concept of the storage area network (SAN) fabric.

"The cloud requires a dramatic change in the way of looking at the data centre," said Renaud Larsen, chief cloud architect for Juniper Networks. "First, you want to collapse the network to a single tier; then the problem is how to manage that single tier. You need a unified Layer 2 hook to the system management layer."

For most vendors, this means the move toward automated network management. Some examples are Juniper with its QFabric architecture, which lets network administrators manage the networking infrastructure as a single switch with a single view of the fabric; Cisco with its FabricPath technology for scalable and flexible networks; and Force10 Networks with its Open Cloud Networking initiative, which uses standards to add interoperability, thereby easing the task of automating workload allocation within the data centre network.

Simon Pamplin, UK and Ireland systems engineering manager at Brocade, said that "providers are all heading towards massive hyper-environments, so they have to simplify and automate the management because they can't afford to manage it otherwise."

More on cloud networks
Cloud computing network primer
Inter-networking data centres for the cloud
Cloud computing networks: Architecture goes flat
"It plays into Ethernet fabrics—large, flat Layer 2 networks with the same ease of management and self-healing capabilities as SANs that are designed to make cloud infrastructures easier," Pamplin said. "Storage networks are just large clouds, and the cloud concept is very similar to storage virtualisation." In this model, he said that each device on a Brocade-based cloud would have a virtualised ID, decoupled from the infrastructure.

In cloud networks, it's not about switches, but open management systems

"When people want to build a cloud, the next question isn't what switches to use, it's what cloud management system," said Doug Gourlay, VP of marketing at cloud networking specialist Arista Networks. "The cloud is an operating model, not a topology. It's a model predicated on services, and on automated provisioning through programmatic interfaces."

Where the vendors differ is in just how much their automation tools and interfaces depend upon their hardware, and in particular on their proprietary switch operating systems. Cisco, for instance, describes FabricPath as "a set of capabilities within the NX-OS software" that runs its Nexus 7000 switches.

But that's why networking is the laggard when it comes to auto provisioning within the data centre, said Jeff Baher, senior director of product marketing at Force10 Networks. "There is a significantly larger open infrastructure on computing and storage [than on networking]," he said, arguing that most network gear lacks the control-level interoperability that has evolved in other areas of IT.

"In networking there's a similar number of vendors, and the forwarding plane works so boxes can communicate, but once you start to peel back the layers, for example on Juniper or Cisco, there is a lot of optimisation, which tends to imply a degree of lock-in. It's a control plane issue, rather than the forwarding plane—the control plane is what glues the open network together." Baher added, "There is nothing up our sleeve. Our boxes are boxes, and our control plane is 100% standard. Nothing prevents a customer from adding other equipment."

Ken Duda, Arista's VP of software engineering, said that the issue is not just building a standards-based infrastructure—although that is important—but the ability to then reprogram and reconfigure it instantly. "Our entire EOS command interpreter is written in Python, so you can modify it on the fly," he explained. "Our router is fundamentally a big Unix server, so you can change the routing if its neighbour goes down, or dynamically modify a VLAN in response to a virtual machine migration."

For those with long memories, this approach will ring bells because the very first routers were simply PCs with two network cards and some routing software. As seems to be increasingly the case with IT, what goes around comes around.