As of its Cactus release (April 2011), the OpenStack Open Source Cloud infrastructure project had three main subprojects: OpenStack Compute (code-named Nova) for provisioning and managing large networks of virtual machines, OpenStack Object Storage (code-named Swift) for creating redundant, scalable object storage, and OpenStack Image Service (code-named Glance) for providing discovery, registration, and delivery services for virtual disk images. Over the last few months an additional sub-project codenamed Quantum has emerged which deals explicitly with networking and has participation from networking giants Intel and Cisco as well as from Citrix. It’s a mechanism for defining network topologies aimed at providing Layer-2 network connectivity for VM instances running in clouds based on the OpenStack cloud fabric. It is designed to be extensible to allow higher-level services (VPN, QoS, etc) to be built on top, and to cleanly handle the “edge of network” problem (i.e., the binding of the cloud into the internet).
Existing Cloud users may be thinking “I don’t need to care about this, AWS just sorts it out for me”. The thinking behind Quantum is that given the Amazon Outage, the “Cloud provider knows best” approach to networking is no longer tenable. The network layer should be of concern to the enterprise both in Private and Public cloud environments, it should be possible for developers to specify a network topology in a straightforward manner (preferably graphically), it should be possible to plug specialized software and hardware services into the cloud and for the enterprise developers to make use of those services, and there should be an open market of software plugins and physical devices providing those services from multiple vendors. A slightly more cynical view is that without this layer, there is nowhere in the cloud for Cisco to innovate – or more specifically there is no way for Cisco’s innovations to be leveraged by end-customers, leading to a commoditization of the networking layer and a long-term value decline.
We are not, however, cynical about Quantum. It’s essentially the networking industry saying – “hey we can contribute something here by innovating on an open platform”, and it’s not just Cisco, there were actually four pre-existing initiatives in this area: NetworkService (Citrix/Rackspace/Nicira), NetworkServicePOC (NTT/Midokura), NetworkContainers (Cisco), and NaaS Core Design (Intel). The four fledgeling projects got together a couple of weeks ago and put together a single unified plan for an API set and a timetable to deliver something in prototype form by the next OpenStack release (Diabolo) in September 2011.
Quantum goes in very low in the stack, it’s at level 2 and it speaks to the hypervisor network stack via a plug-in agent. See the above diagram (from Citrix). It doesn’t sit in a Virtual Machine. Quantum is thus lower in the stack than the pre-existing OpenStack projects, which already do provision some networking, but in a less configurable way, so the existing projects (notably Nova) will have to be refactored to use Quantum. At this stage Quantum is not mature enough to form the base for Nova, but in the medium term (after Diabolo) it will likely be refactored to provision networking that way. There is already an initiative looking at this.
Quantum is designed to be completely independent of the other OpenStack projects, and accessible via its own REST API. There is one area around authentication where it may in the short term have a dependency on another emerging OpenStack project, but in the long term there is no real need for this. Edward’s recent post on vMware Virtual SCSI APIs (which are different APIs but at roughly the same level in the stack) indicates that closed-source vendors often struggle to provide access to APIs at this level, but it is after all Cisco we are talking about and the Quantum architecture leaves open the tantalizing possibility of Cisco shoehorning Quantum in underneath vCloud through the VCE partnership between the two companies.
We’ve talked at length about OpenStack governance, and it is worth noting that there is no way that this initiative would have come about under the non-permissive single-vendor GPL-style commercialization model of vendors like Eucalyptus, because the vendors involved would have had to have assigned the IPR to Eucalyptus who would then have licensed it back to them under GPL. Cisco would never do that. Now that Cisco is going with OpenStack, Eucalyptus won’t have the leverage (or the resources) to provide equivalent functionality itself. However, it could leverage the standalone Quantum layer underneath the Eucalyptus implementation – a hybrid open source cloud.