Open Source MANO Needs a Reality Check
Open source initiatives are supposed to bring communities together, to foster cooperation and to provide useful tools for all. In the telco cloud world there are some worrying signs that the opposite is happening.
First of all there is the general confusion about who is doing what and why -- this was highlighted by Deutsche Telekom's Axel Clauberg last week in a public forum, while in private many industry executives are unhappy at the plethora of industry groups, including open source developments, that spring up around the latest hot trends (edge computing being one of the latest). (See DT's Clauberg Sounds Warning on Profusion of Industry Groups.)
Do we need more groups, more initiatives focusing on topics already under scrutiny and in development? There's an unhealthy whiff of API land-grab behind some initiatives.
There's also the resource crunch. Large telcos and vendors have the cash and headcount to join initiatives and have staff involved in technical committees and even contributing code. Smaller companies do not -- they are, by default, sidelined.
And then there are the schisms that are breeding discontent. The prime example here is the uncomfortable friction between the two main open source MANO (management and orchestration) initiatives, The Linux Foundation's Open Network Automation Platform (ONAP) and ETSI's Open Source MANO Community (OSM) .
ONAP has a lot of big-name support: Not only is it underpinned by some of the biggest and most influential operators in the world -- AT&T, China Mobile, China Telecom, China Unicom -- but it has major international operators urging the rest of the operator community to rally around ONAP specifications and adopt them as a new sort of standard. (See Orange Issues Telco Cloud Rallying Cry and Vodafone's Heeran: Defining the Telco Cloud.)
It also has hefty support from the vendor community. (See NFV Orchestrator Vendors Flock to ONAP.)
But it is also burdened by unhelpful hype that, ironically, does a disservice to its supporters and its prospective selection as an initiative that could deliver some helpful de facto standards.
For some of its flag-wavers, ONAP is already "the winner" -- the MANO system that will dominate telco cloud deployments in the future. But despite claims that it is "deployment-ready" just because of a number of enhancements have been made, some APIs developed and a couple of modules shoe-horned by integrators into a carrier deployment, it's very clearly a long way from offering up code that could be productized/hardened/industrialized. (See ONAP Says Its Beijing Release Is Market-Ready, Bell Canada Reaches Milestone in Network 3.0 Vision With (ONAP) & Hook-Up With Amdocs and Bell Canada Pioneers Production ONAP.)
That lack of maturity has become apparent during the past few weeks.
At the recent Open Networking Summit in Amsterdam, a session titled "Industrializing ONAP" highlighted the complexity of ONAP in its current form, revealed that poor documentation was making it hard for developers to figure out exactly how the software might be evolved and used (a common theme during recent weeks) and showed that industry experts with experience of turning open source code into usable software products that could be supported were struggling to see how ONAP would ever be more than a collection of integration exercises -- that point was made by a representative in the audience from Red Hat, one of the most experienced companies when it comes to developing software products based on open source code.
At the same event, an impressive all-female panel discussed ONAP's progress. While much praise was heaped on ONAP, Helen Chen, a principal architect in the Global Technical Service business unit at Huawei and Project Technical lead of the ONAP Integration project, struck a great balance between being positive and pragmatic. She described ONAP as a "huge code base … a fat baby" that comprises a lot of code needing work (modules need to be decoupled, for example), and noted that there was still a lot of work to be done on automating test processes. As for a continuous release cycle, rather than the current cyclical release cycle, Chen noted this was "a dream," but one that is "years away."
Other panelists, including Lingli Deng, senior project manager at China Mobile, and Catherine Lefèvre, assistant vice president, Network & Shared Services, at AT&T, noted that progress is being made in terms of deployments and trials -- China Mobile is particularly bullish about its merits. But there was also admission that the work to date had been very focused on garnering support for the initiative and ensuring that releases were hitting deadlines, as well as accelerating delivery times, and an understanding from Deng that many CSPs not as large and involved as the big Tier 1s might "struggle to understand how it applies" to them.
But there was still a sense that this was the glossy version of events and that Chen might have highlighted more of the challenge side of the equation than was expected.
So what's next? Another ONAP update is due soon (in November, dubbed Dublin) but that will only cover up some of the cracks.
But you know what -- that's OK! No one actually expects an open source development comprising millions of lines of code to be made useful in a blink of an eye, or even a few months. Iterative progress and a very clear indication of the state of documentation, exactly which modules might be ready to be either used by an operator's team or considered for "industrialization" by a vendor and even highlighting areas where more community activity would all be useful and not at all damaging: Promoting ONAP as "ready to deploy" currently invites suspicion, because that suggests 100% readiness and that's very far from reality.
OSM: A gritty alternative?
Then there's OSM. Support for that initiative is not as broad, especially in terms of major operator support -- Telefónica, BT and Sprint have been its leading carrier supporters, though the likes of SK Telecom, KT Corp. and Portugal Telecom are also listed as participants -- and it, too, is a way of delivering production-ready code, though it is currently preparing its fifth release in November: That one of the companies involved in taking OSM to market, Whitestack, told Light Reading that autoscaling (essential for any MANO software) is to be introduced with that version suggests there is still some way to go.
But it's a more compact development (it doesn't have millions of lines of code to unravel) and appears to have taken some positive strategic decisions, especially related to the separation of the Information Model (IM) from the other elements, something that OSM's supporters highlight frequently. (See Telefónica: OSM Paves the Way for Network Slicing and Telefonica's Elizondo: OSM Offers Best Information Model for Service Orchestration.)
This is also highlighted in a blog by EnterpriseWeb CEO Dave Duggal, who has aligned his company with the OSM camp while still highlighting some of its shortcomings.
Despite the apparent long uphill task ahead, there is talk from the OSM camp of a deployment by its lead operator sponsor, Telefónica , during 2019, though exactly what that means is unclear.
In the meantime, the OSM crew is feeling the heat from ONAP's marketing offensive -- so much so that an OSM workshop in The Hague began with a slide suggesting that ONAP is glossy and attractive but akin to science fiction, like the Starship Enterprise, whereas OSM is gritty, unglamorous, born of sweat and tears but real and set to make a real world impact, like a moon landing. The analogy raised some laughs but such a comparison could come back to kick the OSM team in the cojones and also alienate those that are trying to make a real-world decision about which initiative is best suited to its resources and goals. The sparring between the camps is irritating some carriers, as evidenced by comments from a STC executive on this LinkedIn post.
That there are still two open source MANO developments seems non-sensical to those who expect ONAP and OSM to converge. But on whose terms? A meeting of minds seems highly unlikely. Sheer weight of support seems more likely to reveal a dominant platform.
But it's interesting that some operators are looking at plucking the best of breed from each camp, though this would necessitate the kind of integration work that many operators want to avoid.
Of course the ultimate test will be if either open source MANO actually works in an economically viable way and within workable timeframes. Right now, more proprietary vendor MANO developments will be starting to look more attractive to operators that just need something that works and which they can trust. Currently, as the circus act gets bigger and louder, the gap between the reality and the actual progress appears to be getting wider and that can only be dispiriting and frustrating for the folks at the coalface, trying to produce working code, and bad for the operators and developers trying to make sense of where open source MANO can fit into their plans.
The open source community has a lot to offer the telecom sector and could reshape the way the industry develops -- there is actually a collective will for it to work: The companies with capex budgets are willing supporters. But such developments will be judged by the processes, the openness (that should be a slam dunk, right?), the real-world applicability (currently limited) and the willingness to provide hype-free updates that the developer and operator community (whether "members" or not) can trust. Because once trust is lost, it's hard to get back.
— Ray Le Maistre, Editor-in-Chief, Light Reading