There are compelling reasons why OpenStack is rapidly becoming the clear favorite of all possible candidates for the Virtualized Infrastructure Manager (VIM) in the NFV Management and Orchestration (MANO) stack.
The VIM is the API-driven orchestration layer responsible for manipulating and managing virtual compute, storage and networking resources so that they provide appropriate execution environments for different virtual network functions (VNFs).
OpenStack has tremendous momentum behind it as the fastest-growing open source project in history. It now involves thousands of developers keen to create an open source alternative to commercial programmable infrastructure managers, such as AWS and VMware. Enterprises (including telcos) are equally keen to benefit from the powerhouse of innovation the initiative represents. OpenStack has been designed so that it can easily be extended with new features, including those needed to support NFV and, in many cases, operators with NFV pilot projects can draw on existing OpenStack skills and supporters on the IT side of their organizations.
Yet market misunderstanding of open source software in general, and OpenStack in particular, threatens to slow NFV adoption. Organizations often think that open source software is "free"; however, while open source "community edition" code can be freely downloaded, there will always be a cost involved in implementing and maintaining it. Users pay either for in-house expertise to do this or for a vendor implementation that guarantees a reliable, supported code base.
OpenStack is an impressive piece of open source software engineering that is becoming more stable and mature with every release. However, it is highly complex, adds thousands of lines of code every six months, and requires users to understand the implications of different deployment choices. It cannot be installed and used without investment, since it is more a collection of generic tools than an operationally ready and tested, integrated solution. OpenStack needs to be hardened for production use in any environment, let alone in a carrier-grade scenario. Operators delaying NFV projects until OpenStack can really be implemented off the shelf for free are likely to find that they miss the boat entirely.
As an IT project, OpenStack also needs significant feature extension to support the demands of NFV. VNFs are very different from IT applications -- a fact that is still under-appreciated by the IT community used to running cookie-cutter, discrete workloads that can cope with the oversubscription of infrastructure resources in data centers.
VNFs, by contrast, may have very specific infrastructure requirements, such as no resource sharing, or access to specific acceleration functions, or large amounts of memory to ensure predictable performance. They have stringent high-availability needs and they may be distributed across NFV infrastructure (NFVI) locations, which means that WAN connectivity becomes part of the virtual network resources that need to be orchestrated.
At the moment, "vanilla" OpenStack distributions do not provide all the bells and whistles needed to manage VNF demands on the NFVI. Nor does OpenStack address the upper layers of the NFV MANO -- the VNF Manager or NFV Orchestration functions, such as the management of physically distributed infrastructure resources across the WAN or the deployment of complex VNFs such as the virtual Evolved Packet Core, which consists of several component VNFs (that the ETSI NFV Industry Specification Group confusingly refers to as "network services").
The OpenStack project is beginning to tackle NFV extensions at the VIM level, such as the ability to support a wider range of server topologies and access to specific features within servers needed to boost performance. The OPNFV initiative also aims to champion NFV-specific requirements through the OpenStack upstream process.
However, this will take time, especially as some NFV extensions will be seen as esoteric by the broader OpenStack community, which typically prioritizes additional functionality when it has demonstrable applicability to a wide range of users.
So for the foreseeable future, operators that want both to steam ahead with NFV for competitive reasons and to benefit from open source innovation will need to use vendor-integrated OpenStack implementations with vendor-proprietary extensions in the areas where NFV support is currently missing. Again, those who prefer to delay until OpenStack contains all the features required for NFV will be waiting a long time.
However, while the idea of vendor-proprietary extensions in the context of OpenStack appears to run counter to the spirit of the ETSI NFV ISG (an initiative that has as a key goal the breaking of vendor lock-in), it's not as bad as it sounds. We are in a very early market for NFV. If it is to progress, the industry needs to come up with solutions in advance of standards -- even open source "standards," which move faster than conventional standards bodies, but still relatively slowly in market terms.
It's also worth remembering that open source works differently than conventional software development. In the latter case, vendors develop a standard product that their customers then tailor to their specific requirements, so the software ends up becoming less standard over time, and more expensive to maintain. Open source software implementations may require proprietary competitive differentiation around the edges, but as long as the vendor quickly adopts evolved versions of the software and contributes functionality back to the community through the upstream process, the software becomes more standard over time -- a more future-proof approach.
Finally, the real value of OpenStack lies in its APIs, rather than in the trunk code that implements its function. As long as vendors don't break OpenStack APIs, operators can swap in another vendor's implementation of OpenStack underneath and all northbound systems remain unaffected. Where NFV is concerned, the stability, performance and level of support that an OpenStack implementation delivers really matters.
These capabilities don't come for free, but they do allow operators to take advantage of NFV sooner rather than later and all the signs are that vendor competition on implementation will be fierce -- a healthy situation for customers. Leading operators say that the benefits of early NFV adoption outweigh the small discomfort of not having a completely open source, NFV-ready VIM at this stage of the market's development.
— Caroline Chappell, Principal Analyst, Cloud & NFV, Heavy Reading
This blog is sponsored by Alcatel-Lucent.