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 1 / 2   >   >>
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. 

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 | 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.


brooks7 5/2/2017 | 10:39:21 AM
Re: A long reply By the way, by your definition I like the Telecom App store idea.  I want to throw out some thoughts about some boundaries around the services....

1 - Services have to save end customers money.  There are occasions where services can add to customer revenues, but that means a study of the niche and then being able to develop services aligned with that niche.  Not impossible, but I would think - second pass.

2 - Bandwidth Services and Transmission Services have to be ancillary to the problem solved.  The competition is IT services connected over by MPLS, the Internet, or a Hybrid of both.  Those services will be developed quickly and deployed ubitiquitously.  If you tie your special network to the service, you are likely to serve only a small minority. 

3 - Consider an Ecosystem play as the answer.  Instead of trying to compete with these IT services, consider instead a way of making them easier to develop and deploy or more secure or easier to access.  Revenue would come from increased network usage not higher value of a bit per second.

4 - Operational considerations at the customer should drive approaches.  IT folks are hard to hire and are expensive.  How can you reduce the need for end customers to hire more folks?  Be a partner and not a vendor.

5 - Speed is of the essence.  In today's world, switching costs are high and are avoided as a general rule.  That means that new applications are a land grab game right up front.  So unless you are considering a "Levi Strauss" model (see item 3), you need to be first or near first to market.  If you are not the value has been sucked out by the time you get there.


PS - Telecom equipment vendors...read #5...it is the way that Service Providers have been buying for over 10 years.  You either win up front or you don't win.  Quit throwing good money after failed product lines with the old Product Management/Marketing Hockey Sticks (We are at the inflection point right now!).

Steve Saunders 5/2/2017 | 4:40:15 PM
Re: A long reply "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. "


This is the exact problem Cisco is wrestling with with its software licensing right now, yes. 
tojofay 5/2/2017 | 6:54:26 PM
Re: A long reply some are leading the way: https://www.infinera.com/eurofiber-scales-service-offerings-with-end-to-end-infinera-network/
tpohara 5/3/2017 | 12:06:12 PM
Excellent Article I could not agree more with your article. We spent years re-engineering our core product(s) to address this very concept within the industry. 
Mgagnon1956 5/3/2017 | 3:10:41 PM
Telecom App Store - Its all about the Business Applications Steve,

Great perspective on a vexxing challenge for Telco's. The idea of a Telco app store is timely.

What the Telco app store needs are business applications linked specific network virtualization enablers. Why one NFV service versus another? What underlying business benefit is dervied from linking Business App "A" to NFV Service "B" or "C". Does it matter and why? 

At Nubo Software our platform allows Enterprises to de-couple mobile apps, data and security from a physical mobile device and shift them to a virtualized mobile device running on a Telco Cloud. Virtualized apps such as Office 365, Outlook, SFDC & others are streamed back to physical devices over Telco connectivty fabrics that would benefit enourmously from NFV services to power a specific Qos user experience for the app. 

"Zero" data is transmitted to or resides on the device making the mobile session perfectly secure. NFV services allow high performance bandwidth & latency to be "dialed up" on demand allowing an amazing virtualized app experiences at Telco Cloud scale! 

We think mobile app virtualization (MAV) coupled with NFV services and MEC/5G, offer Telco's a tremendous opportunity to render business apps and NFV services from the same Telco app store. 

Your thoughts?



danielcawrey 5/4/2017 | 11:49:36 AM
Re: Excellent Article Interesting read. As a technologist I do find virtualization interesting. However, I can see how constantly talking about it and its implementations can get old. The real business benefits of this are really what the conversation should be about these days. 
RMersh 5/5/2017 | 3:36:43 PM
Standards, Interop, OS, migration and the business end of NFV So where do I start.....

First, I do appreciate the thought that has gone into both of the articles you have posted on the relationship between OS and standards, and what operators should focus on to make a success of NFV and SDN. You have made a number of good points, although I think some issues are missing and some points are made a little aggressively. The problems you identify are fair game, but we do need to think hard on what can make a difference in the resolving them.

So, on the issues you identify, I agree that:

- virtualization is not yet delivering on it's promise

- open source development has not been successfully married to the best practices of standards

- interoperability should be a key consideration in virtualized products and services

- the introduction of virtualization is slower than some commentators predicted

- there has been too much hype and not enough reality

- standardised APIs are critical 

- virtualized solutions may be over-engineered

- operators are really looking for new services / revenues

- operators want an open market place for virtualized products

You were a little harsh on some actors in the industry. As I'm from the standards world, you may be surprised that I want to defend our colleagues in the OS community. They are not as 'flaky' as you insinuate, we were really quite inspired about how quickly and how concrete they have been in developing solutions, ones that show how we could develop standards at the Broadband Forum in completely new ways. OS is distruptive because it is producing more than just powerpoint presentations.

Some points I expected you to make though, were absent. For the broadband community, we are keenly aware of issues like co-existence between traditional networks and programmable / virtualized functions, migration paths and best practice, the requirements of the smaller operators (who are critical to the market place) and potential regulatory questions.

I think you are right to emphasize the benefits of standards - industry consensus (market development), promoting conformance, 'safe harbor' and the discipline of the standards process. What is needed though, to gain the advantage of NFV and SDN, is to use the output of OS projects and the commercial software of the vendors in a standardised framework where you can prove new services, test them and develop best practice for deployment. We just announced a new initiative for Open Broadband on exactly this:https://www.broadband-forum.org/news/download/pressreleeases/2017/PR07_BBF_China_SDNFV_FINAL.pdf

Lastly, you are right to emphasize APIs, where some of your predictions / indications may already be happening.

Some providers who are already engaged at the BBF have contributed an industry level Telemetry API for application and cloud portals that basically form a migration path using legacy and cloud telemetry models.This came to the BBF so as to ensure the Residential Gateway specifications will follow through, and support an operator consensus on what the industry "managed resource model" will be.

I wish I could be at BCE to take up your offer to discuss this further, but unfortunately I am double booked.

Page 1 / 2   >   >>
Sign In