Networking: CapEx, OpEx, and… In-App Purchases?

From a cost perspective, the networking dialogue is dominated by CapEx. Acquisition costs for new networking gear have historically been tied to hardware, and despite the relatively recent rise of bare metal switching, networking hardware remains a high-stakes business. But SDN is changing this dynamic in potentially significant ways.

The first point to clarify when talking about CapEx is that CapEx does not necessarily mean hardware (at least not the way that most people mean). While there is a strict financial definition for CapEx, in the networking industry it has become shorthand for Procurement Costs. Because networking solutions have been predominantly monetized through hardware, we associate procurement costs with hardware, but this is changing.

The fact that the ’S’ in SDN stands for software is reason enough for people to look beyond the chassis. But the reality is that while vendors have monetized the hardware, the value has been increasingly moving to the software side for more than a decade. So long as everyone was selling hardware, it didn’t really matter that much whether the cost was tied to the hardware or the software, so we have been a little bit lazy collectively in determining a deliberate pricing mix.

More recently, however, there have been additional solutions that are offered entirely through software. With virtual networking devices, for example, there is no physical hardware (unless you count the servers and the network that connects the servers). A common sales tactic for these types of solutions is to point out how expensive physical solutions are. Why pay for all that sheet metal when you can get the same functionality in a virtual form factor? Of course, you are not really paying for the sheet metal; your check also pays for the software and all the features that go into that sheet metal. But the argument is pretty compelling.

The point here is that the only thing that really matters is how much you pay for the whole solution. Whether the price is affixed to hardware or software is an accounting detail – important for some people, but not really the most important thing for the majority of buyers. Rather than calling it CapEx, we ought to be referring more broadly to procurement or acquisition costs. All in, Solution A costs X dollars to bring in house, and Solution B costs Y dollars.

This would certainly simplify the conversation some. But even then, it isn’t all about procurement costs anymore either.

Depending on the solution, the procurement costs account for roughly one-third of the total cost of ownership. The remaining two-thirds of the cost is ongoing operating expense (power, cooling, space, management, support, and so on). The models here for most solutions start to get pretty squishy. While we can fairly formulaically determine things like power, space, and support, when it comes to estimating the cost of managing a device, the models are so dependent on uncontrollable things that they border on useless. And even when the models are sound, most companies have not sufficiently instrumented their network operations to really know what they are spending.

But just because it is difficult to model OpEx does not mean that network teams should ignore it.

If there is one thing that the gaming industry has taught us, it is that there are all kinds of creative ways to separate someone from their money. In the early days of video games, 100% of the cost was procurement cost. After you bought the install media, you had paid everything you were ever going to pay. Before long, some of the more popular games figured out that they could lower initial costs (make the barrier to entry lower) and then charge for ongoing use through subscriptions.

As the networking world adjusts the pricing mix – associating more of the cost with the software – we should expect that charge models will mirror what we have seen on the consumer side. It is not a big stretch (and in fact already happening) to see massive up-front hardware costs replaced with more palatable hardware pricing combined with either higher software or potentially support costs. This has the dual benefit of making it easier for customers to select a vendor, and creating annuities for said vendor.

But the evolution of game pricing models did not end with subscriptions.

For anyone who has gotten sucked into the hell that is Candy Crush, you are already well aware of in-app purchases. The initial game is free, but if you want to get a special advantage or unlock a level, you can make an in-app purchase. They have cleverly priced the in-app purchases to feel like you are hardly spending anything. It’s less than a dollar. I should just go ahead and get that spotted donut thingy! Of course, by the time you add up all those just a dollar moments, you end up paying far more than you ever would have up front.

The magic of this type of pricing is that most of this is not really known up front. When you first get Candy Crush, you don’t really think you are going to buy the special extras. And Candy Crush doesn’t tell you that the levels get progressively harder to the point that they are nigh impossible without a little extra help.

Before you write this off as not applicable to networking, consider a few points.

First, despite the huge open source push, there are still a lot of companies pursuing commercial grade versions of the otherwise free software. Sure, you might buy into the open source controller, but if you need the networking version of the spotted donut thing, what do you do? This is essentially the networking equivalent of the in-app purchase. Call it the in-arch purchase. Once you buy into a particular architecture, the switching costs are prohibitively high. If you have to pay more for the commercial software, can you really say no?

Second, some of the tiered pricing models that are taking root make it more difficult to accurately model ongoing license costs. If you are not thinking about how the costs will scale with the number of ports, users, VMs, or whatever, you might find out down the road that your solution is contributing more ongoing costs than anticipated. For example, buying one VM from Amazon might seem easy enough, but what if you need thousands? It doesn’t stay cheap forever.

Maybe the in-arch costs are just extra features or capabilities. Or ongoing support and services. Whatever the source, these types of costs contribute to the ongoing operating expenses. And because the primary purchasing criterion is CapEx (procurement costs), burying some of these costs a little later in the product lifecycle and making them a bit smaller in magnitude (but larger in volume) will be attractive.

The punch line here is that we are on the cusp of a change in monetization strategies. You might think that pricing and costs will be transparent, but has the networking community given us a real reason to believe that to date? If you think so, consider this: why do buyers celebrate 50% discounts? It’s because pricing is ridiculously obfuscated in this industry. Until we all start expecting more, I just don’t know why this would change.

Along those lines, my colleague Bill Koss posted some facts about Plexxi costs. In the interest of transparency, it’s worth taking a look here.

Read more:

• CapEx, OpEx, and Scale