Over a million developers have joined DZone.

Is an SDN App Store viable?

DZone's Guide to

Is an SDN App Store viable?

Free Resource

When it comes to API frameworks, there seems to be a Field-of-Dreams-esque view that If you build it, they will come. And as our industry dives headfirst into SDN waters, there will be people who advocate the proliferation of developer programs under the premise that networking needs an App Store. The question these people need to be asking is whether an SDN App Store is actually a strategically viable end state.

Before I get into whether the networking industry can support an app store, I need to outline the strategy behind these developer programs. All developer programs are embarking on what is typically called a platform strategy. The general idea is that if you create a platform and people build on that platform, you can essentially build your business around a virtuous circle. More people build applications, and so the platform is more useful, which draws more people who then create a larger business draw for would-be app developers, and the cycle continues.

Now when you think about platforms, chances are that you will immediately gravitate towards the technical definition. You might have thought about iPhone or Linux first, or maybe your mind went straight to some SDN instantiation, like OpenDaylight. But the best example of a platform strategy that I can think of is Barbie.

Barbie dolls have dominated children’s toys for decades. Because they are such a popular doll, if you make clothing that goes with that doll, you can sell to anyone who owns a Barbie doll. The potential marketplace is huge. And the fact that there are so many Barbie accessories makes the dolls more valuable. The same doll can be used to play on the beach, in the snow, or just relaxing at home with Ken and a bottle of vino. As a result, both the doll and the accessories can command huge prices, and they have stood up well over the decades despite an onslaught of newer toy options.

In this example, Barbie is the platform on top of which a lucrative accessory business was created. Barbie was really just a vehicle to drive longer-lasting accessory sales. A single doll might force a family into 10 or 20 outfits. If Mattel had needed to, they would have given these dolls away free of charge, because they knew that the follow-on accessories were going to drive their revenue. And once people own the accessories, changing to a new platform is near impossible because of the switching costs.

This is precisely why every couple of years, people bring up the platform model as a way of driving the business. Apple’s obvious success with their App Store becomes the poster child for these new efforts. The question, though, is what is required for this concept to succeed in networking?

To some extent, this appears to be a chicken-and-egg problem. The apps draw the people, but the people draw the app developers. So which is more important?

Without a doubt, you need the installed base before you can get the apps. There are basically three reasons developers write an app: because they can, because they want to see people use their stuff, and because they can make money. The first class of developer is rare, and the types of apps that are created simply because they are possible offer only basic functionality. These are examples of what could be done, but they are rarely the type of killer apps that drive an entire market towards adoption. The other two drivers require a sufficiently large installed base for developers to have a path to success.

With the iPhone, the installed base quickly numbered in the millions. Any app developer had a huge marketplace to sell to. So what does the install base look like in networking?

To answer that question, you have to first define what the platform is. If the application is going to be deployed on a device-by-device basis (think some monitoring agent), then the install base is the number of devices over which the application will ultimately run. However, if the application is going to be deployed across entire networks (as with any service provisioning efforts), then the install base is not the number of devices but the number of networks. You essentially need to convert entire networks over, which drops dramatically the number of potential customers.

Imagine this: there is a massive network operated by a single company. The network has 1 million routers and switches deployed in support of 10s of millions of servers (think of this as the Skynet network that exists sometime off in a pre-apocalyptic future). If you want to sell your service app to Skynet, the fact that there are a million devices in the network doesn’t change the number of customers in your target market. Sure, it means that if you win, that win could be huge. But it doesn’t give you a bunch of options to sell to.

The market dynamics here more closely approximate the luxury goods market than they do any mass consumer market. There is a lot of money to be made on a per-deal basis selling million-dollar watches. But the number of people who buy those is relatively small. This is why there are only a few true luxury brands. If there was a ton of money to be made in those super-high-end markets, you would see more competition there. But there isn’t, and consequently you don’t.

The implication here is that anyone who wants to open a networking app store doesn’t have the install base that she might first imagine. And without that install base, the question that people need to answer is: how will an average app developer make money? Because if he doesn’t make money, the fact that you built it will not make him come.

Even with small markets though, there can be lucrative businesses, so maybe the size of the install base is not completely debilitating. But you still need to identify the apps that will sell across whatever install base there is. The challenge here is that there are not a bunch of killer apps that people are just waiting around for. And where these killer apps are identified, they tend to apply only to niche markets. And in these niche markets, the requirements are quite specific and typically somewhat onerous, which makes it harder to develop those apps. The result is hurdle after hurdle with very limited financial upside for the developer.

And finally, even if a few of these apps turn out to be killer apps, you have to account for increased competition in the space. For instance, if you are building your app to run on HP’s installed gear, if you make a metric ton of money, what is to stop HP from entering that market and using their sales guys to peddle a competing product?

I don’t want to suggest that applications are not important. But I do want to underscore that the mere existence of APIs and some quoted number of installed Ethernet ports do not make a platform strategy immediately viable.

Now, since it is the holiday season, every post should end with hope. So is there any hope for an SDN app store?

As things stand presently, no. But as the control space continues to evolve, I think there will be a couple of opportunities. If the SDN world is defined mostly by the battle lines drawn around the various Point of Control efforts (OpenDaylight, NSX, and so on), then how that plays out will have material impacts on the viability of an app store. Most markets support a duopoly. In this case, you would expect OpenDaylight and NSX to take the lion’s share of opportunity, and then the handful of other efforts would fight over the scraps (Big Switch, NEC, PLUMgrid, Midokura, whoever).

This means that any app store ambitions would need to target OpenDaylight or NSX. Of these, OpenDaylight would appear to have the most cross-vendor support. If I were an SDN app developer and my goal was to sell a lot of apps (not just be acquired), it means that I would bet first on OpenDaylight. Every bet after that would face increasingly stiff odds.

Of course, sometimes the long shots pay off. So I guess there is still some hope for some of the app store efforts out there after all.


Published at DZone with permission of Mike Bushong, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}