Over a million developers have joined DZone.

Cognitive Dissonance: CapEx, OpEx, SDN, DevOps, and White Box

DZone's Guide to

Cognitive Dissonance: CapEx, OpEx, SDN, DevOps, and White Box

· DevOps Zone ·
Free Resource

DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.

contradictionThere is an interesting industry-wide cognitive dissonance that is occurring. We are talking about SDN and touting its automation and orchestration capabilities. We frequently introduce DevOps into the discussion as we talk about making meaningful progress towards long-term operational expense (OpEx) improvements. Leaders everywhere are espousing the benefits of a highly orchestrated, software-defined infrastructure. Controllers will give us a single point to administer the network. APIs will have us relying on code more than keystrokes, driving down the manual aspects of operations. All of this will lead to a total cost of ownership (TCO) utopia.

And in the same breath, we talk merchant silicon, price-per-port, and the rise of white box switching.

Why is it that our industry dialogue seems so confused?

The reason we have a fractured, seemingly Jeckyll-and-Hyde industry discussion is that we actually have two competing dynamics that are at play. While most leaders understand that the long-term cost driver is OpEx, there are near-term requirements that must be met. Every year, networks are asked to support more traffic being driven by more users accessing more applications from more endpoints. 

The rate of growth might vary from network to network, but the requisite new capacity that has to be added every year can usually be calculated. CIOs or VPs of Networking should be able to stand up and declare every year "We need X amount of additional capacity to meet next year's demand!" The challenge is that the rate of capacity growth is exceeding the rate of budgetary growth. 

This creates a situation where each year more capacity has to be built into the network than the new budget can accommodate. So long as industry dynamics (merchant silicon, increased competition, and so on) are driving the price-per-usable-capacity down fast enough to offset the capacity increases, the system stays in a state of equilibrium. But when the demand exceeds the cost decreases, you end up in a tough spot.

This is why despite the fact that OpEx is a bigger contributor to cost over the entire life of a device, IDC reports that CapEx makes up just under two-thirds of the purchase criteria. While we would love to plan over a longer time horizon, we are simply unable to because our immediate needs require us to be so CapEx focused just to keep up.

This should be terrifying to folks. The rate of price declines will at some point asymptotically approach some small number that will assuredly be lower than the rate of new capacity required. When that happens, how do you keep up with new transport requirements?

The answer is ugly: you don't. 

Fundamentally, this means two things. First, network architectures will likely have to undergo some fundamental changes. Networks will need to evolve to architectures that require fewer devices, and customers will need to get much higher utilization out of their existing capacity. Deploying gobs of new capacity with low utilization is self-defeating. It is both capital intensive and it actually increases operating costs as the number of devices climbs. Servers have already gone through that transition. Networks will need to follow suit. The difference is that compute utilization is a nominally easier thing to both measure and improve.

Second, network operators will need to extract their OpEx savings earlier than they probably expect to help provide some headroom on the equipment side. The problem with attacking OpEx is that it is never a good time to do it. "The economy sucks. We don't have the resources to tackle a nice-to-have project like automation this year. We can do it when things improve." Or "The economy is booming. We barely have enough resources to keep up with new demand. We can't handle the automation stuff right now." 

So failing some Grand Networking Bargain, the best that most networks can do is pin their hopes on falling capital costs. It is the one thing that is immediately in sight. This is what makes white box switching so attractive. The idea that you can solve the immediate CapEx problems is extremely enticing. And for those networks who have given up even paying lip service to the long-term operational burden, this represents the best possible outcome.

But building out the same networks we have today doesn't change the long-term operational cost curve. It simply addresses the current-year problem of adding affordable capacity. We are playing a game of Networking Jenga here. We pull some CapEx costs out of the underlying network, and we place additional operational cost back on top. We can keep building this tower up and up and up, but at some point, the whole thing collapses under the operational load. 

And there is no quick fix when that happens. 

Conscientious IT leaders need to recognize this. The pain points that have driven SDN, network virtualization, and NFV to the top of our industry hit list are the same ones that ultimately mandate that we pay more than lip service to OpEx. Buyers need to start weighing in their OpEx plans as they make capital purchases. And vendors need to recognize that there is a current-year problem about adding capacity that has to be addressed. Without both of these things happening coincidentally, we will continue to talk out of both sides of our collective mouths.

Read the 4-part DevOps testing eBook to learn how to detect problems earlier in your DevOps testing processes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}