The telecom industry has spent decades wandering in a technology desert. The trek isn't over by any stretch -- but at least the destination is now clearly marked.
Journey's end is a place we are calling The Autonomous Network. Right now, it's pretty much a mythical gleaming city on a hill. But the road to that city is now under construction, and it's just a matter of time before this truly massive project is completed. That time will be marked in years, which means there's a lot of hard work ahead.
Figuring out the endgame is not so much an "aha!" moment as a "duh!" moment. It starts with the latest industry buzzword: automation. Automation isn't actually a new concept at all -- it's been a part of just about every communications innovation since the advent of the rotary phone. But we are now at the point where all the bits and pieces of automation will start coming together to form one great superstructure.
The immediate goal of automation is to create "autonomous processes" -- in which the network does what it needs to do without human intervention. That's been an aspiration of telecom architects and solution providers for literally decades.
But now, the vast array of related technology ingredients that are essential to make automation possible -- virtualization, AI, machine learning, telemetry, robotics, analytics, et al -- are all reaching various degrees of maturity (though, just like people, some are a lot more grown up than others). And as these discrete elements of automation come together, the path to The Autonomous Network is taking shape. Carriers are now contemplating building networks that could run themselves for days or even weeks at a time, without any human interaction whatsoever.
When we talk about The Autonomous Network in this context, we are talking about communications processes in their entirety -- not just the connections but also the services, applications, underlying processes and everything else that is part of the giant virtual machine that powers the global economy.
For carriers and CSPs still grappling with the problem of getting NFV to work, the thought of tackling automation, with all of its science-fiction-like components, probably looks like a job too far. Making sure they can reap the benefits of automation (staff reductions; better performance; greater reliability) without falling into the same traps that have plagued NFV and other great leaps forward (vendor lock-ins, over-complicated open source non-standards, hard-to-prove business cases) requires our industry to take a long hard look at the mistakes that continue to make virtualization such a painful experience for carriers, and to learn from them.
It's complicated
Let's get one thing clear up front: Automation is really f***ing complicated. In fact, the word "automation" is a generic catch-all for all the separate elements that need to be in place to get to The Autonomous Network, and each step in the process will be more complicated than the previous one. Step 1 is the automation of specific management functions (generally sitting in the carriers' existing, clunky IT infrastructure). Step 2 is the automation of the updates of those processes, so they don't have to be handled manually (automating the automation, basically). Beyond that, service providers will want to make the scripts more intelligent by adding AI and machine learning to not only automate the processes but to improve their efficiency, "automagically," over time.
For carriers, most of whom are still operating in super manual mode, using thousands of human admins and operators, this stuff is pretty much pie in the sky right now.
Next page: Who you gonna call?
Who you gonna call?
So the big question for service providers is: Who can they trust to design and help build their autonomous network? Options range from traditional to mold-breaking.
At the "trad" end of the scale they can go with one of the incumbent vendors (Huawei Technologies Co. Ltd. , Nokia Corp. (NYSE: NOK), Ericsson AB (Nasdaq: ERIC), etc.), which in turn are competing head-on with the incumbent OSS vendors ( Amdocs Ltd. (NYSE: DOX), Oracle Corp. (Nasdaq: ORCL), Netcracker Technology Corp. -- all of which have their own NFV and multi-domain orchestration platforms) and the heavy-duty IT vendors ( Hewlett Packard Enterprise , IBM Corp. (NYSE: IBM), Dell Technologies (Nasdaq: DELL)).
"Each type of company brings its own strengths to the party, and some of them play in more than one camp, notably Ericsson, which is strong in network operating software, as a network equipment provider and as an integrator," comments James Crawshaw, analyst at Heavy Reading, who recently published a report on this market called Intent-Based Networking, Automating Next-Generation Networks.
On the more disruptive end of the scale, carriers can opt to use code from one of the new carrier-driven industry organizations, such as ONAP or OSM; do it themselves using an automation programming framework and a lot of hard work; or go with one of the new and disruptive "God code" middleware solutions now entering the fray (more on these later).
Whichever path they take, for service providers this is a decision fraught with much more anxiety today than it was four or five years ago when they were considering suppliers for NFV.
Back then, service providers were optimistic that deploying software-based virtualization (SDN and NFV) would buy them two benefits: cost savings, plus a way to escape from being locked into one vendor's end-to-end communications portfolio. At the same time, those same service providers were also predisposed to continue to work with the incumbent vendors they knew and trusted.
For the incumbent vendors, this situation presented a serious quandary. How could they continue to lock in their biggest customers while also showing that they were fully committed to the bold new, open and interoperable world of software-based virtualization? Their answer, basically, was to slap some open source lipstick on a proprietary pig, by continuing to sell their own technology while also joining a slew of open source virtualization organizations. This effectively sent their service provider customers (and analysts and the media, who all fell for this line) the strong impression -- not guarantee, mind -- that their products would seamlessly interwork with products from other open source supporters.
Today, of course, we know that "support" for open source code doesn't mean that a vendor's products will interoperate with anyone else's, at all. Mostly they won't, without a lot of hard systems integration and/or lab work. Now add in the fact that the incumbents' early NFV products were mostly hard to implement (buggy, overly complicated, expensive to get running) and the result, four years on, is a lot of very big incumbent equipment companies with a lot of very frustrated carrier customers.
Next page: Making sense of the vendor marketectures
Making sense of the vendor marketectures
This isn't stopping the incumbents from again charging ahead with announcing strategies for the next big thing, automation. Juniper Networks Inc. (NYSE: JNPR)'s automation solution goes by the rather excellent name of "The Self-Driving Network" (points, Juniper marketing types!) and it's published a wealth of detailed technical resources to explain its automation position (see this, this and this. Oh, and this.)
Cisco Systems Inc. (Nasdaq: CSCO), on the other hand, has gone with the dreadful "The Network. Intuitive." This must have sounded brilliant over gluten-free muffins during that Ogilvy pitch, but it's a tagline only millennials could love. (Note to Cisco: We telecom industry types tend to be older and greyer. Extra gluten.)
And what if. We all started using. This. Punctuation. How annoying. Would that. Be?
At the heart of Cisco's automation strategy is a software platform called the DNA Center ("another muffin?" "Don’t mind if I do.").
And that's about all we know about it (at press time Cisco still hadn't briefed me). It's not clear where the code in DNA Center comes from (maybe from its Tail-F acquisition?). Currently the DNA Center is designed for use in enterprise networks only. (We don't know when a version for telecom networks will arrive, which rather enforces the view that Cisco is deprioritizing the service provider market over the enterprise right now.) And I haven't even been able to discover what "DNA" stands for (surely not deoxyribonucleic acid. Maybe "Do Not Ask"?).
"The first iteration is basically a Catalyst upgrade, albeit a fancy one," comments Craig Matsumoto, Editor in Chief of Light Reading.
Reversing the supply chain
So going with the incumbents (Cisco, Huawei, Juniper, Ericsson and Nokia; or Adtran Inc. (Nasdaq: ADTN), ADVA Optical Networking , Ciena Corp. (NYSE: CIEN), if the network being automated is optical) is one option. But vendor missteps with virtualization have prompted an unprecedented occurrence in the communications industry, as the world's largest service providers -- including AT&T Inc. (NYSE: T), BT , China Mobile Communications Corp. , China Telecom USA , Deutsche Telekom AG (NYSE: DT), SK Telecom (Nasdaq: SKM) and Telefónica -- have given up on waiting for the incumbent vendors to deliver state of the art solutions, and are instead turning the traditional telecoms order on its head by developing virtualization and automation technology themselves.
Further, they are also collaborating (shocker!) with their service provider competitors via industry groups to improve their code and assure interoperability. The two most obvious examples of this inversion of the comms industry supply chain are ONAP, an initiative created by the merger of AT&T's ECOMP platform with the Chinese operators Open Orchestrator Project (OPEN-O) -- and OSM, whose members include major players such as BT, Telefonica, Telenor Group (Nasdaq: TELN) and Sprint Corp. (NYSE: S)
By getting different carriers (and vendors) to agree on a common code base and APIs, both ONAP and OSM are hoping to solve one of the telecom industry's great imponderables: the inability to carry sophisticated traffic, automation and security policies across the boundaries between different carriers' networks. (Interestingly, a lot of people in our industry assume this is possible today; the reality is that without an awful lot of work the vast majority of the services world is still stuck in 20th century "best effort" mode.) The challenge faced by these organizations is the sheer scale of the code base involved. ECOMP alone has about 8.5 million lines of code. That software needs to be integrated with the one from OPEN-O, and then kept updated; a systems integration challenge on an unprecedented scale.
"Anyone who brags about writing 8 million lines of code in 2017 is a complete idiot. The whole world seeks to be distributed, modular and resilient. Coding monoliths is for dunderheads," says Dave Duggal, managing director of Enterprise Web, which makes an alternative solution for orchestration and automation.
The Linux Foundation, which runs the ONAP group responsible for doing that, is playing down the difficulty, and says that arguments over which code prevails will be quickly resolved. But after the shambolic free-for-all that was the open source community's attempt to "help" with NFV does anyone really believe that? ("We shall. See," as Cisco would say).
Next page: Forking integration
Forking integration
Systems integration provides another option for carriers looking to enable automation, but here again they face a fork in the road. On the one hand, they can pay a professional service organization, a.k.a. system integrator, to do it. Accenture , Amdocs Ltd. (NYSE: DOX) and Deloitte Development LLC are all aggressively soliciting for this work, and Amdocs is the lead integrator now helping virtualize/automate AT&T's network -- a kingmaker account if ever there was one.
On the other hand, service providers can DIY the integration work in house, using one of several third-party automation frameworks, most of which come with cutesy/ridiculous names -- such as Chef, Puppet, Juju, JP McWongbonkle and SaltStack. (Note: I may have made one of these up.)
For most service providers that's probably too much project for them to handle right now (though Juniper says that as a rule, service providers are more inclined to handle the system integration challenge in house than its enterprise customers).
God Code
The automation market also includes some new and potentially highly disruptive alternative solutions. Companies including EnterpriseWeb, RIFT.io and UBiqube sell comms middleware, which is essentially the software equivalent of the hardware God Boxes of the early 21st century, sitting like a glowing ball of software light in the middle of the network, wrapped in APIs, handling both the interfaces to existing services and networks and the job of automating and orchestrating them.
By internalizing the "hard stuff" and presenting a ubiquitous island of code around which the rest of the carrier's network and its services can pivot, these "God Code" solutions present obvious advantages over the other automation alternatives on offer today. In fact, they sound pretty great.
But keep in mind that automation doesn't exist in isolation, and neither do the products that vendors are selling to enable them. It's not just that automation is interleaved with orchestration. In fact, OSS/BSS, orchestration, automation are all on a "capability continuum" -- one that increases in complexity and value the further that you travel along it. In other words, service providers looking to automate their networks face a vastly complicated, almost superhuman challenge. Just having an amazingly clever software solution may not be enough to lure carriers away from their traditional; suppliers, who, in the case of Ericsson, have been proving that they can solve their customers' knotty comms problems for a century and a half.
Next page: Here come the newbies
Here come the newbies
Gaining the trust of Tier 1 carriers is a challenge that is also faced by a slew of other new and relatively new privately held startups and semi-established companies -- each of which have entered the automation space with specialist solutions that address one piece of the autonomous network puzzle.
Intent-Based Networking (IBN) & Orchestration
AI & Analytics
Robotic Process Automation (RPA)
(Source: "Intent-Based Networking, Automating Next-Generation Networks," James Crawshaw, Analyst, Heavy Reading)
Tower of babble
One more thing: With so many new companies and new approaches vying for attention, a critical step in the journey to autonomous networks is making sure that everyone speaks the same language. All of us in the industry (media, analysts, carriers, vendors, standards bodies and integrators) need to agree a common lexicon or syntax to describe the autonomous network and all of its component parts. This is exactly what we failed to do four years ago when we started work on NFV -- and it's one of the primary reasons why virtualization ended up being such a ball of hair.
Not-for-profit industry organization the New IP Agency (NIA) is helping to overcome the language challenge by creating an industry initiative to create the industry's first comprehensive hierarchical taxonomy of next-generation communications -- a unique and exhaustive blueprint that will simplify and accelerate the design, construction and monetization of virtualized, autonomous networks.
Phase 1 of the project started this week, and will wrap up on November 1, when NIA will share the results at a conference in London. Ultimately, NIA says its goal is to upstream the Next-Gen Taxonomy to relevant industry standards organizations for ratification.
So, fellow telecom industry colleagues, take heart -- we now know where all this is leading. Sure, not all of us will be around to see the grand opening of that gleaming autonomous network city on the hill (though our children will). But we can take comfort in knowing that the pain we go through today will make for a better world tomorrow. Or something like that.
— Stephen Saunders, Founder, Light Reading
Note: I'll be hosting discussions of all of the automation issues covered in this article at four (4!) upcoming Light Reading events:
Automation & the New Carrier Network Workshop (November 2, 2017, London, UK)
2020Vision (December 5-7, 2017, Prague, Czech Republic)
The Autonomous Network, Calif., 20 to 21 March 2018
If you want to contribute to the dialog at any of these events, please shoot me a line at [email protected]
Further reading:
For anyone with a serious interest in comms automation, I can't recommend Heavy Reading's latest report strongly enough. Titled "Intent-Based Networking, Automating Next-Generation Networks," it's written by Heavy Reading Analyst James Cranshaw, and carriers and CSPs won't find a better primer on the fundamental issues they face.