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

COMMENTS Add Comment
Page 1 / 2   >   >>
Solution63465 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?



kq4ym 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.
Tomasz Stepniak 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. 
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.

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



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. 
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/
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. 
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!).

Page 1 / 2   >   >>
Sign In