Cloud, open source, and new network models: Part 1
OpenStack's Quantum project is the latest evidence of how cloud computing is changing network architectures forever. What is the cloud network model, and how will it improve cloud operations?
What is the network's role in cloud computing? What are the best practices for defining and delivering network architectures to meet the needs of a variety of cloud workloads? Is there a standard model for networking in the cloud?
Last week's OpenStack developer summit in Boston was, by all accounts, a demonstration of the strength and determination of its still young open-source community. Nowhere was this more evident than in the standing-room-only sessions about the Quantum network services project.
I should be clear that though I worked on Quantum planning through Cisco's OpenStack program, I did not personally contribute code to the project. All opinions expressed here are mine, and not necessarily my employer's.
Why is Quantum important in the context of cloud networking? Because, I believe, it represents the model that makes the most sense in cloud infrastructure services today--a model that's increasingly become known as "virtual networking."
In this context, virtual networking refers to a new set of abstractions representing OSI Model Layer 2 concepts, like network segments and interfaces, and Layer 3 concepts, like gateways and subnets, while removing the user from any interaction with actual switches or routers. In fact, there are no direct representations of either switches or routers in most cloud networks.
The diagram below comes from my "Cloud and the Future of Networked Systems" talk, most recently given at Virtual Cloud Connect in late September:
Here's what's interesting about the way cloud networking is shaking out:
From the perspective of application developers, the network is getting "big, flat, and dumb", with less complexity directly exposed to the application. The network provides connectivity, and--as far as the application knows--all services are explicitly delivered by virtual devices or online "cloud services."
There may be multiple network segments connected together (as in a three-tier Web architecture), but in general the basic network segment abstractions are simply used for connectivity of servers, storage, and supporting services.
From the service provider's perspective, that abstraction is delivered on a physical infrastructure with varying degrees of intelligence and automation that greatly expands the deployment and operations options that the application owner has for that abstraction. Want cross-data-center networks? The real infrastructure can make that happen without the application having to "program" the network abstraction to do so.
Using an electric utility analogy (which, but it works in this case), the L2 abstraction is like the standard voltage, current, and outlet specifications that all utilities must deliver to the home. It's a commodity mechanism, with no real differentiation within a given utility market.
The underlying physical systems capabilities (at the "real" L2 and L3), however, are much like the power generation and transmission market today. A highly competitive market, electric utility infrastructure differentiates on such traits as efficiency, cost, and "greenness." We all benefit from the rush to innovate in this market, despite the fact that the output is exactly the same from each option.
Is abstraction really becoming a standard model for cloud? Well, I would say there is still a lot of diversity in the specifics of implementation--both with respect to the abstraction and the underlying physical networking--but there is plenty of evidence that most clouds have embraced the overall concept. It's just hard to see most of the time, as network provisioning is usually implicit within some other service, like a compute service such as Amazon Web Services's EC2, or a platform service, such as Google App Engine.
Remember, public cloud services are multitenant, so they must find a way to share physical networking resources among many independent service consumers. The best way to address this is with some level of virtualization of network concepts--more than just VLANs (though VLANs are often used as a way to map abstractions to physical networks).
Most services give you a sense of controlling network ingress and egress to individual VMs or (in the case of platform services) applications. Amazon's Security Zones are an example of that. A few, such as GoGrid and Amazon's Virtual Private Cloud (pictured at the top of this post), give you a subnet level abstraction.
In part 2 of this series, I'll explain how Quantum explicitly addresses this model, and the next steps that Quantum faces in expanding the applicability of its abstractions to real world scenarios. In the meantime, if you use cloud services, look closely at how networking is handled as a part of those services.
You'll see evidence of a new network model in the making.