This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Evaluating OpenStack for your cloud services environment: Read more in this section
- A skeptical look at OpenStack architecture
- What can OpenStack Quantum do for cloud providers?
- Martin Casado on OpenStack Quantum and cloud networking
Explore other sections in this guide:
- 2. - Two open source cloud initiatives, lots of decisions
- 3. - How cloud providers are using OpenStack
With the Folsom release of OpenStack, networking pros now have OpenStack Quantum, an industry-standard, open application programming interface for cloud networking orchestration. Using the OpenStack Quantum API, software and hardware companies can create solutions to solve the problems of network operations in cloud computing and highly virtualized data centers. In this Q&A, Martin Casado, Nicira co-founder and influential OpenStack figure, discusses the impact Quantum will have on cloud networking and network orchestration.
What is the significance of Quantum in the Folsom release?
Martin Casado: Quantum is really just a vendor-neutral, industry-standard interface. The implications are significant, because if you build the cloud and you use Quantum, you've decoupled the operations and orchestration from the actual mechanics of the networking side.
When OpenStack was created, there was an industry-standard interface for compute called 'Nova,' [and interfaces for storage], but networking wasn't a first-class citizen. Networking was hardcoded in a piece of Nova. Quantum makes the networking subsystem a pluggable, modular, standard interface that's treated as a first-class citizen. Now [cloud operators and customers] can run any number of virtual networking solutions … and know it will slot in and work within the greater OpenStack environment.
Why was it important to break networking out of Nova into its own API?
Casado: I think it's pretty clear that … the cloud movement is still in the early period and these technologies are evolving very quickly. You want them to be able to evolve independently. Different groups are focused on different aspects of infrastructure. There are many guys focusing on compute, there are teams that are working on storage, and the same thing with networking. If you couple these together, they would all have to evolve in lockstep, which would slow it down. [That would] also increase the number of dependencies between systems, which would mean [the different] groups would have to work on both of them to evolve it. This will allow us to innovate and evolve the networking space independently of the other areas of infrastructure.
In the past, networks have never had an operational interface that was industry standard. Most networking lock-in has happened at the operation interface -- the CLI [command line interface]. They are all vendor-proprietary, vendor-specific. You've got guys trained to these CLIs, so it's very difficult to move, even between different products from the same vendor, let alone from different vendors. Something like OpenStack makes this movement possible.
Does OpenStack Quantum pull you out of the CLI for cloud operations?
Casado: That's right. Quantum is an API that will do the operations for the network in the cloud. And if the cloud is using Quantum, it is doing programmatic provisioning of the network. That is decoupled from the specific CLI or specific vendor API. Networking has never had something like that.
[But we can't] confuse … an industry-standard API with the functionality that's being implemented. Any company can implement the functionality. We've got a dog in the race, and there will be many other companies that do it as well. Quantum is just providing the abstraction layer to allow this to evolve separately.
Quantum is a set of APIs that goes across the data center that the cloud management stack talks to when it wants to provision a new virtual network for a tenant. [These are] very high-level APIs, not low-level switch management APIs.
What change must take place below that OpenStack Quantum abstraction?
Casado: Quantum allows you to create virtual networks in an industry-independent way, attach those virtual networks to things like virtual machines or high-level services, and orchestrate the configuration of those high-level services.
More on OpenStack and networking
OpenStack networking: Why should we care?
Midokura network virtualization: Layer 2-7 services, OpenStack
Cisco SDN response: Programmable networks, not OpenFlow
There many ways to implement this. You could implement this in a proprietary fabric manner. You could do it as a thin software layer that works on any type of hardware, which is what Nicira does. Or you could do a combination of the two, where you have software that integrates with hardware.
The point of Quantum is to allow that market and that ecosystem to evolve and to optimize, based on what the customer needs from the network layer. I think we'll see a bunch of solutions come out. You'll certainly see solutions of the type that Nicira does. You'll see special hardware, and you're going to see integrated solutions.
At first these solutions are just going to provide basic virtual networking, but I think you'll see them evolve to consume [Layer] 4-7 services, and maybe even management, billing and security and a lot of other things that we typically ascribe to the network but aren't directly [L2 and L3] virtual networking.
How does it enable choice when a company chooses one network virtualization approach and then three months later decides it's not the right fit? What if they've bought into one of these network fabrics?
Casado: The reality is a lot more complicated than this kind of simple, high-level idea of choice. The idea of choice is that the cloud management system will orchestrate the infrastructure, and the interface to the networking piece is vendor-neutral. In reality, there are a lot of other touchpoints. If they buy a proprietary fabric and they manage it through Quantum, they can replace the fabric with another solution, but it would require them to buy new hardware and figure out how to deal with that hardware in places that Quantum doesn't.
But one thing they don't have to do, which they do have to do today, is change any scripts. You wouldn't have to change your operational model. It should just slot in under the Quantum API.
Is changing those scripts and operational models really a major burden?
Casado: Yes, absolutely. I don't have any direct research, but having had hundreds of direct customer visits, a lot of the stickiness of networking gear and solutions is that they are all against vendor-proprietary APIs. And this is not just a script issue. It's an operations issue; it's an education issue. In many cases, you have to retrain a workforce if you start swapping these things now.
Today it's very disruptive to go from one version to another version of the same product. And so, Quantum isolates you both between vendors but also within the same vendor as you go up the product line.
What's next for OpenStack Quantum? How will networking evolve in future releases?
Casado: My personal hope is to get to a point where it's actually stable and not touch it. If people start programming to Quantum in order to have some stability and we keep changing it, then we've just moved the problem to another place. That said, we have a lot of work before we get there. Right now we've been focusing on L2 and L3, but you'll see the orchestration of higher-level services, L4 through L7.
What will moving up the stack to Layers 4 through 7 enable?
Casado: When you go to L4 through L7, you get all the basic benefits of virtualization for L4 through L7 services: the ability to provision quickly, to have different configurations for different tenants. A lot of these things will move to software and VMs [virtual machines], so you're not tied to an appliance. That will be step one, and that will happen over the next couple of years.
In step two, you can start changing the paradigm. You can start leveraging this new environment to create new types of services. If you're in the cloud and you have a hypervisor at the edge, you actually have a lot more visibility than you ever had before. In the hypervisor, you can see the guest operating system; you can figure out what users are there, what apps are being used, what docs are being used. So, there's no reason why you can't pass this information to the firewall so that you are making rules over things like users and you're not guessing from traffic.
In part two of this interview with Nicira co-founder Martin Casado, read how VMware will use Nicira technology to create independent network virtualization that is hypervisor-agnostic.
Let us know what you think about the story; email: Shamus McGillicuddy, News Director.