Switch to Break Away From Vertical Integration?
June 20, 2011
We have discussed similar subject in my earlier post, Network Issues in Data Centers. Let’s take a little different angle to look at the problem this time.
A little bit background. Vertical integration is the degree to which a firm owns its downstream suppliers and its upstream buyers. The switching products and technology has been vertically-integrated for decades. Networking incumbents, like Cisco and Juniper, have been designing their own ASICs, embedded systems, protocols, and tightly integrate these in-house components into their products.
Even though most of these products claim to be “interoperable” and “standard compliant”, the administrators have been advised to stay with single vendor solution for compatiblity reasons in the day-to-day operation. This vertical integration strategy, while provided certain level of warranty over product and service quality, put network users in many disadvantages. For example,
- Lock-in leads to unreasonable pricing – have anyone ever compared the price of a Cisco-certified SFP+ transceiver to any market leader’s products?
- Slow innovation – how many network technology research papers evolve into a real product in the past 10 years?
- Slow response to customer’s problem and requests – ever try to ask Cisco to add something simple, say an agent to report certain unusual events?
Switch users, especially data centers, have been questioning whether vertical integration still makes sense in the past several years. Visionaries, such as James Hamilton of Amazon, have been advocating to break away from vertical and build a new programming model where we can enable innovation in network industry and avoid the lock-in from single vendor.
The same requests have been raised in many other occasions. For example, one of the Open Compute workgroups discussed the possibility of bringing open architecture to data center networks that facilitate the Open Compute platforms. In several Open Network Foundation (ONF) discussions, we have heard similar comments that commoditized switching platforms are facilitating the demand of Software Defined Network (SDN).
So, why do people think it is time to break away from vertically integrated network solution? Obviously, Moore’s law has played a critical role behind the scene. Not only the off-the-shelf switch chips are getting faster and smaller, the chip vendors are getting faster in adding new features. Not only the new networking startups such as Arista, Nicira, BigSwitchNetworks, were all software centric, but also did big tycoons like Cisco and Juniper start to use off-the-shelf chips in their top performance TOR switches. This indicates the chips have been commoditized and the need of proprietary chips has diminished.
Why Isn’t It Happening?
In theory, if the market is changing from vertical integration to a horizontal structure, we should see the hardware price drop significantly and software start to diversify. Why isn’t it happening? Why aren’t we seeing lower cost 10GE platforms? Why aren’t we seeing tens of startups to promote their niche software?
In a way, it is actually happening, but just not as fast as we’d have expected. The cost of the 10GE is dropping fast in the past two years, from $500 a port to around $250 a port, mainly because of the competition between Broadcom, Marvell, and Fulcrum. We expect the price continues to drop even further when more software options are available.
What Can Accelerate the Change?
The most critical step of creating a horizontal platform is to define the interface between different horizontal layers.
As many have hoped, OpenFlow might be one option to provide a unified interface to various chipsets (or platforms). However, while we might see OpenFlow start to solve niche (but could be big-scale) problems soon, it will likely take years before we can use OpenFlow a the ONLY interface to control the switch chips.
How about asking switch chip vendors to open source their Software Development Kit (SDK) so software vendors and users can easily develop and share the code? Well, based on our talk with these switch vendors, they have a big concern of opening the SDK mainly because there are a lot of “trade secretes” embedded in these SDK packages.
What about Pica8 driver? Well, we hope so. We are willing to open the API and even the software stacks so people can use it as a foundation to develop their own code. However, there are not really that many developers familiar with the switch programming and it takes time to train these developers. From the users end, it will also take a couple of years for Xorplus to build the reference accounts and gain users’ confidence.
In the meantime, we also believe there are rooms to improve our switch platforms to make it more developer friendly. For example, using x86 CPU or creating native compilers on Pronto might help people to mitigate the learning curve of cross compiler. Creating virtual ETH devices for each data ports might help people to virtualize the switch chips. If you have any idea that can help accelerating the transition, we would love to hear about it.