& cplSiteName &

Together, We Can Build the Telecom 'App Store'

Steve Saunders
5/1/2017
100%
0%

Next-gen virtualization technology is complicated. Really complicated. But what service providers need are simple solutions to their business challenges. As an industry, how can we reconcile this dichotomy? The answer is to borrow a page out of the consumer comms market by building a "telecom app store" that extracts the promise of NFV from its complexity.

This concept provides the answer to the problems I raised in my column on Light Reading a couple of weeks ago. You can read that piece here, but the snapshot is that, as an industry, we've gotten ourselves into a proper pickle by staking our hopes and aspirations on a technology (virtualization) without developing it using the best practices that have kept telecoms from running off the rails for the last 150 years (you know, stuff like standards, certification and interoperability).

The good news -- other than that there is a solution, obviously -- is that this is something that we can implement this year (2017). One of the reasons virtualization has become such an albatross for service providers is that the technology is so arcane. Yet, as an industry, we've allowed it to become way more complicated than it needed to be by inviting an army of open source nerds to help us develop NFV and SDN. That genius move basically spawned a giant rolling hairball of technology acronyms, draft specifications, committees, subcommittees (not to mention "committers") and personal and corporate agendas, the net product of which is basically indecipherable and practically unusable for anyone who doesn't get a huge boner from spending their every waking minute helping to crowdsource comms code for comms code's sake.

I've spent much of the last year ignoring the fantastically dull minutiae of virtualization technology itself and instead talking to real people -- a.k.a. "service providers" -- everywhere from Saudi Arabia to Swindon to find out what business outcome they need virtualization to deliver in order to build commercially viable 21st century businesses (answer: not acronyms). Universally, service providers say they want networks that are less expensive to own and run. But what's yet more important to them is what runs over those networks: the digital applications and services. Because that's where they see their "net new" revenue growth coming from. And most service providers don't want to write, de-bug and deploy those applications and services themselves.

What they really want is to carry on doing what they know how to do best -- building ultra-reliable, very high-speed, predictable networks, while picking and choosing "best-in-class" products from an extensive ecosystem of third-party applications and service developers. Preferably by downloading the ones they need from a reliable online marketplace, knowing that the products they choose will work over the network they own.

In other words, service providers want an app store for telecom services.

Right now, this telecom app store doesn't exist in any shape or form. Intel and HPE have both had a crack at creating something of this sort and, frankly, the less said about those efforts the better (you can see HPE's here).

So why doesn't the telecom app store exist yet? The problem is that there are no universally accepted industry standards for NFV, which means there's no agreed way for companies to develop new services and applications, turn them into VNFs and get them to run on NFV infrastructure (NFVi) from other vendors. Worse, service providers that want to buy VNFs from multiple different vendors can't tell if they will work on the NFVi that they have installed in their network without a bunch of extra work. (Months of work! For every new service they want to deploy! In a lab! Which they have to pay for!) Looking at the current byzantine state of virtualization technology you could be forgiven for thinking it will be years and years before the concept of a telecom app store could become a reality.

Not so!

By hacking my way through the Gordian knot of code complexity that the open source community and vendor organizations have tied around NFV, I discovered last year that hidden deep inside the taxonomy there is a single code ganglion that holds the key to unlocking the entire NFV ecosystem. Specifically, the API that sits within MANO and provides the jump-off point or interface between NFVi and VNF services and applications.

If we can get the entire industry to agree to use the same API, we will in one stroke enable interoperability between NFV solutions from different vendors -- thus making possible a virtualization "free market technology economy" -- one that is embodied in the telecom app store (or, more likely, "stores," since once the seal is broken on interoperability I expect to see a flood of companies jump in to provide these market places).

But how do we make this dream a reality in an industry where the traditional overseers of technology -- standards bodies -- have abdicated their role to the Linux fanboys?

For the last year I have been working with the New IP Agency (NIA) to gather support for such an API, and at Light Reading's Big Communications Event this month in Austin we will be sitting down with all of the leading companies in the telecom industry to formally kick off the process of defining the API that will allow North-South interoperability between NFVi and VNF service and applications.

From a technology perspective, our intention is to avoid reinventing the wheel; instead we plan to re-purpose one or more of the many specs already developed in the industry as the basis for our final specification. And, since the NIA is not a standards body, whatever specification we agree on will subsequently be up-streamed to the appropriate body for standardization.

Defining the API is only the start. Once we have agreed on a specification we will then use it as the basis of certification testing that will be conducted by multiple independent labs around the world.

One of the cool parts about our plan is that the NIA will dictate how much labs are permitted to charge for certification, in much the same way that the Department of Motor Vehicles sets the maximum price that garages can charge for a vehicle inspection. This prevents anyone from taking advantage of the certification process in the way that the MEF did with its Carrier Ethernet certification.

This is a vital and historic mission that we are undertaking, and we're looking to get as many individuals and companies involved in our work as possible. The NIA has an NFV demo taking place live in the middle of the show floor, so if you are going to that event please feel free to drop in on us (the show floor is open 12:30 p.m. until 6:30 p.m. on Tuesday, May 16 and 12:20 p.m. until 2:15 p.m. on Wednesday, May 17).

Or, just shoot me an email and I will happily bring you into the tent on what we are planning to do and when.

— Stephen Saunders, Founder and CEO, Light Reading

(13)  | 
Comment  | 
Print  | 
Oldest First  |  Newest First  |  Threaded View        ADD A COMMENT
<<   <   Page 2 / 2
Tomasz Stepniak
50%
50%
Tomasz Stepniak,
User Rank: Light Beer
5/7/2017 | 12:32:06 PM
Long way to go...
I can see three major risks:

1. Security

2. Security

3. Vendor push back as the vendor-lock is very convenient to reduce all operational risks. 
kq4ym
50%
50%
kq4ym,
User Rank: Light Sabre
5/13/2017 | 2:19:46 PM
Re: Excellent Article
As noted, "standards, certification and interoperability" are the keys to making it all work. And it will be interesting to watch as APIs are developed and especially to see how the standardization of certification fees may work out to get a level playing field here too.
Solution63465
100%
0%
Solution63465,
User Rank: Lightning
5/19/2017 | 4:24:02 PM
Metaphors
I really liked the article and whatever points were being made-

Except for one- Is is necessary to use the term "boner" in the writing?

Perhaps there are some readers who cannot relate to that experience.

Way to alienate approx 50% of the working population...no?

March on SYS-STEMMERS!

 

 
<<   <   Page 2 / 2
More Blogs from From the Founder
After almost two decades at Light Reading, it's time for a different optical adventure.
John Chambers is still as passionate about business and innovation as he ever was at Cisco, finds Steve Saunders.
Light Reading founder Steve Saunders talks with VMware's Shekar Ayyar, who explains why cloud architectures are becoming more distributed, what that means for workloads, and why telcos can still be significant cloud services players.
Light Reading's recent Automation Everywhere conference provided invaluable guidance and insights for network operators figuring out their automation strategies.
Ngena's global 'network of networks' solves a problem that the telecom vendors promised us would never exist. That doesn't mean its new service isn't a really good idea.
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