SAN JOSE, Calif. – Cisco Systems stands at a strategic juncture. I believe it may have hit its peak, and if it does not change direction it could see a slow decline from its leadership in communications.
I see Cisco pinched between two trends—software-defined networking (SDN) and the Internet of Things (IoT). I believe it currently has the wrong long-term strategy for both.
On one side are all the hungry forces of SDN. The Googles and other data center giants along with Cisco’s core enterprise and carrier customers long for a path to simpler, less costly networking.
These customers are allied with some of Cisco’s competitors who want to disrupt the networking giant. Together these vendors and users are pushing for a virtualized comms layer controlled by open C-language programs runs on mainstream x86 servers. They are like a rebel hoard with a thousand spears trying to bring down the mighty castle Cisco has built out of its ASICs and IOS software.
Cisco has defensively erected its ONE initiative. The idea is to embrace SDN at a rudimentary level but continue to deliver value-added features through ASICs and IOS, only accessible through its proprietary APIs.
It’s a reasonable strategy for an incumbent. Ericsson has adopted a similar position.
Long term, I think it’s a losing game. Ultimately free Linux overwhelms $70-a-copy Microsoft Windows. Simpler, good enough technology wins out over value-added proprietary bits.
Hewlett-Packard appears to be with the SDN crowd, and it should be. If the market moves toward managing comms through its servers, it wins. If proprietary features on switches and routers maintain a hold, it can play there too.
I think in the end the game goes to the company that is the first and best to embrace the openness of the SDN vision. Cisco is not poised to be that vendor.
I agree with this statement - "Let's make sure we know what we need before we launch a major buildout that will need to be redone many times before it's suitable for the intended purpose", mentioned by JeffL_2; The issue is how do we go about it. So many vendors leap into the market with proprietary technology or methodologies (ala CISCO and EIGRP) and then try to make it the standard, instead of using patience with the standards committees like the IETF and JEDEC and waiting for the markets and the standards to mature. And why do they do this? Security. We all admit we enjoy having jobs. It is trust in ourselves that insures that we eat, but it is trust in others that insures our survival. Also, I believe it's a false assertion to claim we can only endorse either SDN or ASICs implement methodologies -when Reconfigurable Hardware has only just recently emerged. But it may require us to hand over significant authorization power to others -the free market (ie unemployment!). Which brings me back to our circular dilemma which we refuse to face: our fear of job/career security. There is a diamond within reach, but we refuse to let go of the sand.
The problem I see is we're only talking about IoT as a "market" rather than having a more meaningful definition that would shed some light on what our primary concerns ought to be. For example to the extent that it will be used for control instead of just monitoring, security will tend to get a lot more focus, otherwise any "script kiddy" with a Raspberry Pi could bring havoc to the system. Ironically at least on the "big iron" switches it frequently takes something on the order of a DDOS attack to mess things up, if on the other hand you're dealing with a significantly narrower bandwidth it takes a much LESS structured attack to create significant problems! Remember even on the systems we use now the "dumb router" that was necessitated by early IP address limitations became the "firewall" we now rely on to help address our security shortcomings, it would be preferable if we didn't have to suffer through that all over again. If we have to proliferate crypto strategies throughout IoT then the minimum MIPS requirement per node goes up substantially. Let's make sure we know what we need before we launch a major buildout that will need to be redone many times before it's suitable for the intended purpose.
Sorry, but I think this topic of SDNs, much like IoT and "cloud computing," is mostly trade press/marketing buzzword hype. It gets taken way too literally, like something brand new, when in fact it's "more of the same." By which I mean literally MORE, of what we've known for decades.
Routers and layer 3 switches are becially identical devices, as far as their function goes, and as far as how they operate within Internet Protocol routed networks. The difference is only in how they are built. In order to allow faster speeds, what the hype calls "layer 3 switches" do most of their routing functions in hardware.
If you want to adjust the way these devices operate in real time, for instance changing the routing priorities of different queues, then you have to allow for these functions to be done in software. Also if you want to adjust the remote monitoring of minute aspects of each device, that too will drive you to a more software-oriented router. Obviously, the larger a network is, the more you may want to monitor and adjust these devices remotely. Everyone has known this for years and years.
So it becomes a balancing act. To think that Cisco and any other router vendor aren't fully aware of these tradeoffs is naive. And same as always, the device makers will introduce proprietary solutions, in their otherwise commodity products, to solve specific customer requirements in particularly clever ways. While at the same time, also offering the standards-based solutions that the marketing hype encourages the corporate buyers to ask for.
In a few short years from now, we'll look back at today's buzzwords du jour and we'll see that in fact, things progressed along a predictable and continuous line, without any obviously jarring change in direction.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.