The weather was perfect at the Ritz Carlton in Half Moon Bay, California, as the Linux Foundation (LF) was putting on a wonderful Open Source Leadership Summit (OSLS). The “who’s who” of open source roamed the hallways and there was substantive discussion around open source initiatives.
At the same time, social media lit up over the dichotomy between the swanky, ritzy environment filled with CEOs and open source heavyweights and developers in the trenches that weren’t able to be at the event. I’m not going to get into whether the LF is being ostentatious and wasteful with an event that brings open source developers together with business leaders who are attracted to, and in some cases desire a conference location like the Ritz. It’s a balance between attracting businesses that provide funding while staying true to the roots of open source and supporting key developers. There’s a lot to say about that and is perhaps best saved for another day. In the meantime, my conversations there with the community helped solidify some thoughts I’ve been having about the Open Network Automation Platform (ONAP) project under LF Networking.
As a quick recap, ONAP was formed under the Linux Foundation when AT&T’s in-house orchestration platform – that was in the process of being open-sourced – was combined with the LF’s own orchestration efforts, Open-O. Seeded by Chinese efforts from China Mobile and Huawei, Open-O was announced in November 2016. Open-O subsequently gathered support from the wider community, including VMware who joined in January of 2017. Right after, in February of that year, ONAP was announced with AT&T donating its ECOMP codebase of about 8.5 million lines of code. LF then indicated an intent to merge the Open-O project with ECOMP under the new ONAP umbrella. At launch, a veritable set of well-known companies supported it, and the Open Networking Summit (ONS) conference in 2017 was pretty much all ONAP, all the time.
Fast forward two years to 2019, and my expectation for ONS 2019 is that ONAP will still be a star in that show but will be joined by new LF Edge initiatives. When ONAP launched there were expectations set that the re-architecture would be a faster process than has been realized. The hard work to get ONAP architecture rationalized and easily deployable continues.
In the meantime, the environment has changed, there has been a drive toward container-based architecture that favors microservices. And the industry has realized that orchestration is likely a multi-tiered problem with cross-domain or multi-domain services orchestration combined with domain-specific orchestration. ETSI’s NFV framework has to now morph and adapt to this new reality.
Meanwhile, in my conversations with LF service providers and telco vendors, I’ve heard feedback on ONAP that runs the gamut: from “ONAP is production-deployable today,” to “ONAP is too AT&T-centric and has to be heavily adapted for different carriers,” to “ONAP is too heavyweight and massive to be useful.” Likewise, I’m hearing that “ONAP is both cloud- and container-ready” and at the same time, “it’s too complicated, not microservices-based, and needs to be rearchitected.” It feels like ONAP is caught, like "Schrödinger’s cat," in a situation where multiple realities exist, and where all can be simultaneously true.
Parsing through all the confusion, there’s a middle path that I believe characterizes the situation at hand:
1. ONAP has value because it captures the different modules and models required to provide orchestration services in a real-world large telecommunications company.
2. Further, many of the components and service capabilities provided by each of those components serves a useful purpose and is necessary in today’s telcos – though it’s open to debate as to whether these components will be fit for next-gen telco services.
3. ONAP, in the form of ECOMP, is proven because it is running in production in AT&T and in other telcos; though other telcos have each chosen a subset of ONAP components appropriate for their needs. And there are likely many telcos in the world for which ONAP is just not a fit today.
4. There is still significant work to be done to make ONAP easily deployable, and even more to truly make ONAP a streamlined microservices-based, container-optimized orchestration platform.
5. Not all the capabilities in ONAP today will be needed for future telecommunication services, and a large part of the 8 million-plus lines of code might not exist in their original form two to three years down the line as the modules and code get re-factored to be optimized for cloud-native deployments.
6. Probably one of the biggest values of ONAP is that it has momentum across both carriers and networking equipment providers, and provides a vehicle in which next-gen telco orchestration can be discussed, debated, and moved forward.
That last point is probably the most critical for ONAP’s success. One might view ONAP as "stone soup," with ECOMP being the stone that started the brew – with apologies to ECOMP as it likely provides more value than a stone. Contributions from other telcos and networking providers will improve the overall quality and taste of the soup, and ONAP will get re-architected and improved to fit future telco needs. ONAP is essentially a unifying banner under which telco orchestration open source efforts can occur.
At the same time, there are others in the industry who don’t see value in being tied to what they view as a “legacy” approach and want to start from a cleaner, cloud-native slate. They prefer beginning with the end-state of a microservices, container- or functions-based architecture and working backwards for a leaner approach to the problem. Taking a page from the cloud service providers playbook could be better than starting with a traditional telco approach. It remains to be seen which wins, though it’s unclear to me what winning means. We’ll likely see multiple approaches deployed – it’s horses for courses after all.
To wrap up, I realize I’ve used both Schrödingers cat and stone soup metaphors to characterize ONAP but let’s assume that both are appropriate in describing the reality – yes, ONAP is both Schrödingers cat and stone soup. And to expand on the Schrödinger’s cat metaphor, I’m not sure we should open the box with ONAP inside today and peer in too deeply lest we don’t like what we find. Rather, let’s give it time and see how reality plays out. In due time perhaps the cat will emerge alive from the box – or not.
Photo source: Harry Frees (Library of Congress).