Together, We Can Build the Telecom 'App Store'

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

<<   <   Page 2 / 2
brooks7 5/1/2017 | 5:31:36 PM
Re: A long reply Steve,

The problem with the telecom world is that the vendors are doing what the telcos say....even if it is bad for them.  Its okay with Huawei, because they are in the business of driving everyone else out of business.  But what I want to know is NOT if they are all in.  I expect that.  What I want to know how they are planning to raise prices with virtualization.  And if not raise prices, how they are expecting to raise profits.  That is the question that they need to be asking in the executive suite.  The telcos are peferctly happy for the vendors to price themselves out of existence...until they do anyway.  I am completely good if they say, we are terminating all of our Hardware Engineers tomorrow.  That is one way to raise profitability, but I hope you see where I am heading.


Steve Saunders 5/1/2017 | 2:09:42 PM
Re: A long reply Thanks Seven - 

Re: the vital groups. Yes, i agree. nothing happens without the vendors. We did actually roster ubiquitous support from all the NFVi incumbents for NIA last year, which surprised me (perhaps i shouldn't admit i was surprised?!?!)

Huawei, ADVA, Cisco, ZTE, Ericsson, Nokia - all in for the plan. Service providers have been harder to corale, but they are coming in now. 

My concept of a telecom app sote shouldn't be taken too literally, you know. It's more of a metaphor for interoperabile and viable commerical virtualized services! 

As always, thanks for the smart feedback... 





brooks7 5/1/2017 | 10:40:27 AM
A long reply Apologies in advance, but your article posted so clearly why this is not working and I thought it deserved a thoughful and complete reply.

First: your commentary on why service providers are interested in Virtualization:
 - They want to reduce costs
 - They want to participate in new services

Those objectives are orthangonal to each other.  You can do one or the other or both and they don't provide momentum to the other.  I think this is the single biggest problem.  The whole standardization/specification cycle is about cost reduction by the introduction of multiple vendors who will price their products to drive themselves out of business to win at a large Service Provider.  The new services occur in an environment that moves so fast that the standardization will not work for them.  It takes too long to create this environment and this environment gets bypassed by fast movers.  Today's world is a perfect example of this.  IT service providers build products in Data Centers and using off-the-shelf choices.  By doing so, they have made Service Providers a Business Commodity.  The number of SPs that bring bandwidth to DCs is staggering.  By doing this, the IT SPs have made the network inside the DC very cheap and very fast and the connectivity choices many.  This move is being done and accelerated without participation by the SPs.  In fact, the participation that they did have has been largely sold off.

Second:  Your notion of a common API and essentially the demphasis on Open Source

Open Source is completely misunderstood.  When you are building a new IT service (like when I ran a SaaS operation) we looked at what OS we would use as part of the product.  The goal was to eliminate a number of software developers to get the product to market.  Why write when you can download?  Service Providers have been Systems Integrators.  OS does not work that way.  You need to provide the linkage between the pieces of OS UNLESS one project was designed to work with another exclusively.  There is no incentive for anyone to make an Open Source product that they pay people to write and then deliver to a telco for free - UNLESS there is consulting available.  I think you should instead look at loosely coupled packages that are connected through standard IP technology for what you are trying to do here.  This idea that a set of JSON objects or XML files are going to be completely plug standard and move instantaneously to meet the new services demands is just not viable.  The question you should ask yourselves is:  How many brand new services can be introduced per day by a SP?

Third:  A new app store

There are 2 falacies here.  First, that there is something special about a SP that lends itself to hosting an App Store.  Application authors want as wide a distribution as possible.  This means working to the lowest common denominator of connectivity.  Specialness is directly opposed to that.  If the SP is not special, than Google Play Store and iTunes will always defeat a SP.  The SP will be the Windows store equivalent (for mobile devices anyway) a complete afterthought.  Second, that any consumer of the app store will choose it first.  Why?  What will be compelling to make users move away from their existing choice of 3 app stores to choose one of the 100 new ones that will be created.

Fourth:  The wrong place to look

Sorry but you are looking in the wrong place and talking to the wrong people.  If virtualization is going to succeed than it needs to work for 2 groups:  Customers and Vendors.  What problems are you solving for the Customer that are not being solved today?  How are vendors going to make more profit by working with Service Providers virtualizing?  I think those are the key groups.  Talking to Service Providers about these is an utter waste of time.  What they have said (and I am about to paraphraze your article) is they want to make all the money off of Angry Birds while spending nothing and taking no risk.  Well, good luck with that. 

<<   <   Page 2 / 2
Sign In