One of the more interesting questions confronting anyone who works at a box company, like I do, is what causes a vendor to get disrupted?
There are a lot of business reasons, and technical reasons covered in a wide variety of sources…
My pet theory is the following:
A box vendor produces a box that has to be deployed as a box because of what it does. For example, to switch you need a box that can sit between three physical cables and make decisions about where to forward the packets.
Deploying a box is a pain in the ass. Replacing a box is hard.
And the problem is that once you, as a customer, deploy a box, you realize that you need the box to do more stuff.
And the vendor starts adding software features into the box to meet that need.
And at some point in time, the box vendor believes that the value is the software and not the box. And they are partly right, except that the only reason the customer is buying the software from the box vendor is because they must buy the box.
And the box over time becomes an increasingly complex software system that can do more and more and more and more.
And software engineers hate complexity. And where there is complexity there is opportunity to build something simpler. And competition tries to break into the market by making a simpler box.
The problem with the simpler box is that if the set of the things a customer needs to do is A, and you can do A/2 – you’re simpler and incomplete. Inevitably you will become as complex as the original box.
What causes the disruption is when the customer no longer needs to deploy the box.
To pick an example that I can talk about, many vendors in the storage industry used spinning rust disk drives to store data. When customers decided that they no longer wanted to use spinning rust to store data, vendors like Nimble and Pure started to win in the market because they stored data in flash.
Nimble and Pure certainly didn’t have the feature set of their competitors – how could they. The reason they won deals was because the decision criteria for the customer wasn’t software it was the desire to store the data differently on a different kind of physical media – flash. The combination of a customer desire to store the data differently coupled with a simpler box made it possible for Nimble and Pure to win in the market place.
To put it differently Pure may, for all I know, have A/5 of the features of the competition, but if the first order decision is that you want to store data on flash in an external array, then that is irrelevant because you’re not comparing Pure to a spinning rust array, but Pure to another flash array. And there Pure has an advantage.
The networking industry has stubbornly resisted disruption for years. And part of the reason is that the physical box hasn’t really changed over time. Parts of the industry have changed, and overall the same leaders are still winning.
However, there is a possibility of a disruption in the networking industry, in particular, in the modern cloud data center.
The reason being that for the first time in a long time, the fundamental network stack may be re-wired in a very unique way.
In an earlier post, I discussed thee Network Database. In a traditional network, every network element has to be a full fledged participant in the Network Database.
And like traditional applications that have to interact with a database to do anything interesting, network services must also interact with the Network Database to do anything interesting.
And it turns out that building an application that uses the Network Database is hard, unless your application fits into that model and … well … runs on the network element.
Companies like to whine that network vendors are slow, maybe they are – or maybe the problem they are trying to solve in the way they are trying to solve it is just hard and takes time. Having worked with folks in this industry, I am convinced of the hardness thesis rather than the laziness thesis.
SDN – has the potential – to disrupt the model of software applications being built as distributed services running on multiple network elements. For one reason: it actually makes building network applications easier because it aligns with how the vast majority of programmers think. Building applications out of distributed protocols is hard. Building applications on a centralized database is easy. And there are claims that well you’ll need multiple databases to scale, and it turns out that too is easy – after all that’s what the web guys have been doing for years.
And that creates an interesting disruption in the network stack. That is different than flash and disk drives but potentially as massive.
The value of the software stack that the traditional vendors have built over time begins to diminish as more services get built using a different model. One argument is that it will take time for the new services to be as complete as the old model. And that is true. If you believe, however that the new programming model is more efficient and expands the pool of programmers by a step function, then the gap may be closed significantly faster.
Having said all of that, I am reminded of a saying:
Avec des si et des mais, on mettrait Pari does une bouteille.
The Network Box vendors are making their strategic play as well, and the industry will change and we will most likely still see the same players on top ….
Dali Kilani (@dadicool) says
Nice post! I too believe in a massive disruption in the networking world. The killer use cases for SDN have not been identified/packaged properly to make people pick the “inferior on the surface” SDN-based solution (according tt standard measures) because it offers something traditional architectures can not (similar to the Flash vs spinning disk argument). most of the debate so far centered around tech components (openflow as a protocol, openflow controllers, merchant silicon and HALs, open-source network element OS, NFV, etc) and not enough on solving customer problems.
I want a network that’s ;
– resilient (one of the things that traditional distributed architecture did well)
– fast
– observable (very hard to put a TAP point into an arbitrary point in the network in a distributed architecture)
– agile (the lack of being the main thing customers grump about today)
– Service-oriented Not packet-oriented
and for good measure, the exact saying is :
Avec des si et des mais, on mettrait Paris dans une bouteille.
Cheers
Dali
kostadis roussos says
I should write a post on the killer app. It’s actually pretty obvious to me – when you’re building a multi-tier application configuration of a private network is a key problem so people just have massively shared networks for no good reason.
Also when you need to build an application with specific network requirements it’s impossible to do that without involving the network administrator or network team and get better utilization out of the network.
I don’t think anyone gets disrupted per-se, but the nature of the market will change.
As for the whole saying, far be it for me to question a French speaking native but the INTERNET 🙂 gave me the quote… Damn you ANGLOPHONE INTERNET!