This article first appeared in Wireless Week on March 13, 2017
Last month, the Linux Foundation announced the fusion of its two flagship open networking projects. Open-O (launched a year ago at Mobile World Congress by China Mobile and Huawei) will join with open source ECOMP (Enhanced Control, Orchestration, Management and Policy, led by AT&T) to form the ONAP (Open Network Automation Platform) project. Here’s why ONAP is a game changer not just for NFV, but also for the next iteration of hyperscale cloud.
NFV is Too Big to Go It Alone
The biggest “a-ha” moment in the ONAP announcement is the reality that NFV is such a major undertaking—technically and operationally—that even powerhouses like AT&T and China Mobile understand they can’t go it alone. Working together also means that open source is the collaboration platform for the future, as it’s the only way to drive standardization in fragmented industries.
Users and Vendors, Working Together
A major lesson we learned from the OpenStack community is the importance of users—in this case, carriers—that are committed to deploying the technology hand in hand with vendors, all working together in the same community. It took OpenStack a while to reach maturity, and bringing the operational view into the community has really sped up the roadmap process. Put another way, when big consumers of the technology started working side by side with developers in the community, large strides toward operational maturity followed.
Standardization Comes to MANO
In 2016, as NFV was taking flight, a diversity of MANO (management and organization) initiatives was hindering the climb to altitude. Fragmentation from semi-competitive projects like OSM (Open Source MANO), OPEN-O, OpenBaton, and OPNFV (Open Platform for NFV) was a source of risk for carriers. With the formation of ONAP, one community now represents more than 30 percent of subscribers worldwide. This center of gravity will drive standardization toward ONAP.
Similar to the way that OpenStack forced a consolidation among open cloud initiatives (CloudStack and Eucalyptus), I expect the same thing to happen with other open source initiatives around NFV. ONAP will force consolidation, and smaller initiatives will see value in collaborating with a standard-setting project.
TOSCA (Topology and Orchestration Specification for Cloud Applications) has been used in Open-O and will likely become the standard for ONAP as well, alongside the acceptance that TOSCA/YANG (Yet Another Next Generation) should be integrated as complementary technologies and not as competing standards. This may become the biggest step toward a common modeling language.
Simplified VNF Onboarding
VNF onboarding remains a top priority for our Cloudify open source project, and it’s a major reason Gigaspaces was founding member of ONAP. No platform is ever complete without a thriving marketplace of cloud-native applications that can easily be onboarded to the orchestration platform. Without an ecosystem and marketplace, such initiatives will struggle for relevancy.
What ONAP Can Learn From OpenStack
OpenStack’s early progress was stymied by consensus-led decision-making, which slows everything down. Of course, the market keeps moving, and so the community—and the software—get left behind.
The OpenStack community saw this issue and has largely addressed it, but the lesson teaches us something important that can be applied at ONAP: agreeing on a common modeling language is going to be key to moving forward faster. Similarly, creating a looser governance structure in the model of OpenStack’s Big Tent model will drive competition and innovation. Importantly, it will force contributors to be measured by adoption, not by control over a certain piece of the stack. “Game of Thrones” tactics have no place in open source.
Allowing room for competition will keep ONAP from becoming yet another “Linux” that needs to have a single implementation for every piece in the stack. Competition reduces the risks of land grabs in which everyone tries to influence the project by owning a piece of it. This leads to the creation of unnecessary projects simply to justify the desire to contribute and be part of the game. This in turn leads to greater complexity, and eventually lack of adoption.
A community driven by big players risks losing the developer's voice. As we've seen in OpenStack, the developers are the key to driving simplicity and alignment with DevOps processes and tools. A challenge for the ONAP community is to create a structure that includes developer voices in architectural decision making by reducing barriers to external contribution and enabling a simple way for other open source projects to integrate and support ONAP without forcing them to become part of ONAP. These could include monitoring frameworks, policy engines, container integration, and cloud-native VNFs.
OpenStack has taught us that allowing competition will drive faster innovation and encourage contribution through competition, building better implementations of the same core components rather than spreading the effort thinly across many different projects.
ONAP: It’s the Code, Stupid
NFV standardization simply has to be driven from the code. Having an open community with companies focused on innovating—churning out code together—and taking these practices back to the standard bodies like TOSCA and ETSI/NFV to build a unified NFV model and architecture is the means we’ll use to drive NFV adoption and network innovation, to the benefit of everyone who uses global networks to solve problems and drive commerce.
Recent Comments