Why Is OpenStack Neutron Struggling?
From its humble beginnings in 2010 as an odd mash-up of the Rackspace Swift object storage project and the NASA Nova cloud, OpenStack has rapidly grown in complexity and sophistication.
Although there have been some notable recent detractors, for the most part hundreds of successful public and private implementations have demonstrated OpenStack’s component federation approach to cloud architecture has the needed flexibility and robustness. With all these successes, why is Neutron, the networking component, struggling to find its connections?
Cloud network architectures are challenging to design, build, and maintain. They have to work securely and reliably at multiple levels of the stack—properly separating the underlying infrastructure networks from the customer facing virtual machine networks and workloads.
Few designers are aware of just how different the traffic patterns are from traditional data center networks. For example, unlike traditional data center architectures, there are far more packets traveling across the infrastructure (east/west traffic) as the virtual machines communicate with storage and other workloads than packets traveling in and out of the data center (north/south traffic).
Adding to the complexity is the increased ratio of virtual machines to physical servers. Often the management issues related to workload and virtual machine traffic far exceed the underlying infrastructure traffic. Abstracting the network layers away from the network hardware by using software defined networking (SDN) is one solution to these many thorny problems.
Neutron, the OpenStack SDN component, was pulled out of Nova into its own separate project in the Folsom release. There was growing community recognition that cloud networking needed its own separate track to address the numerous requirements and constituencies. Even though SDN is still very much an emerging technology, the thought was that clouds need highly abstracted networks.
Conceptually, Neutron addresses the cloud network complexities by providing network abstractions at the component layers. The idea is that the higher network layers (four through seven) would be used by developers to build their applications through an API. Since developers are typically interested in the network functions, workload connectivity, and policies, not how they actually work, the architecture is simple and application centric.
On the other hand, network engineers are focused on networking primitives and access to the underlying hardware, so they want a network-centric, device-oriented, and topology-aware view. Theoretically, new use cases will uncover new user types as Neutron develops.
Sadly, from the November 2013 Summit Neutron sessions, not all is well with the project. Some fundamental Neutron pain points include:
- Can Neutron create a low-level standard API that supports all network vendors?
- Should Neutron provide different abstractions depending on user type?
- Can or should an SDN work without a controller?
- Can the management layer abstract low-level details when interacting with external elements?
So far, the major backers and contributors have been network hardware vendors such as Cisco, Juniper, and Arista. There were some data center engineers in the sessions, but the heavyweight network engineers from the Telcos—the folks who really do have a deep understanding of how to build networks at scale—were completely missing. Will the project stay on track without their valuable insights? Stay tuned.
