& cplSiteName &

OpenStack Doesn't Come for Free

Caroline Chappell
5/11/2015
50%
50%

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.

(3)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
cnwedit
100%
0%
cnwedit,
User Rank: Light Beer
5/12/2015 | 8:55:56 AM
Great assessment
This is an excellent explanation of a complex situation. Thanks, Caroline. I think it makes sense going forward to be very specific when we talk about OpenStack and what people mean when they say they are incorporating it. Obviously, all OpenStack isn't created equal.
Dredgie
50%
50%
Dredgie,
User Rank: Light Sabre
5/11/2015 | 9:12:57 PM
No Free Beer
> To coin the old FOSS phrase, courtesy of Richard Stallman, it's free as in free speech, not as in free beer. 'Libre'!
Ray@LR
50%
50%
[email protected],
User Rank: Blogger
5/11/2015 | 5:00:25 PM
The usual battle: Purists vs pragmatists?
Caroline

This reminds me of so many previous debates/instances, where there is a 'purist' view of how thuings should be done in an ideal world and a pragmatists view, which takes into consideration things like timescales and resources.

Do you get a sense that there are more people still on the 'purist/idealist' side of the fence?
More Blogs from Heavy Lifting Analyst Notes
The latest release from The Linux Foundation's Acumos AI Project offers some interesting incremental improvements.
What role will CSPs play as the Internet evolves to support new consumer applications?
NaaS growth stems from the belief that by leveraging the programmability of the cloud, CSPs can create customizable VNF-based services for anybody who requires a full scope of services and does not want to deploy their own infrastructure.
The telco distributed cloud model is gaining support among service providers, even ahead of extensive 5G rollouts.
To gain a realistic understanding of operators' views and plans for transport, Heavy Reading launched its first-ever 5G Transport Market Leadership Study with support from Ericsson, Fujitsu, Juniper and VIAVI Solutions.
Featured Video
Flash Poll
Upcoming Live Events
September 17-19, 2019, Dallas, Texas
October 1-2, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
December 3, 2019, New York, New York
December 3-5, 2019, Vienna, Austria
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events
Partner Perspectives - content from our sponsors
Ryan Ding From Huawei: Industries + 5G, Enabling New Growth
By Ryan Ding, Executive Director of the Board, Huawei Technologies
Adaptive MIMO in the Era of 6GHz Wi-Fi
By James C. Chen, Quantenna
All Partner Perspectives