Enterprise Technology By Phil Edholm

Older: Visiting Dubai-land
Newer: Changing Corporate and National Cultures

Merchant Silicon - Benefit or Bane?????

By Phil February 21, 2008 11:59 am

Last week Tony Rybczynski put up a blog on the Cisco Nexus switch entitled "The Nexus is no Lexus". Tony got a lot of comments, including a link that was from the Network World Cisco blog. This was responded to on the Network World Cisco blog by Doug Gourley of Cisco. In his response Doug states; "Certainly companies that have consistently failed to innovate and deliver in the networking segment, that have married their own R&D capabilities so tightly to the merchant silicon vendors that they have no capability for competitive differentiation."

Cisco is well known for a profound inability to innovate internally and a penchant for acquisition as well as a penchant for trying to present attempts at catch-up as innovation - see my post on VSS. In the VSS case, the Cisco technology is proprietary and appears to be a pathetic effort to compete with Nortel Split-MLT technology that has been in the market for over 6 years. While I could take Doug to task for "the pot calling the kettle black", the real point of this post is to question his "merchant silicon" comment.

It is always interesting when the industry begins to change and the leaders in the last evolution find the transformation to the future hard to fathom and impossible to adjust to. Using merchant silicon is a logical step in the evolution of our industry…....would anyone suggest not using “merchant memory” or “merchant processors" or “merchant operating systems". The reality of the industry is that the complexity and high cost of ownership that has been the standard in networking is beginning to be questioned. By leveraging the power of the industry and simplifying, it is becoming obvious that better solutions are now in the market. It is absurd to suggest that "internal" engineers are better at building networking chips than the engineers at Broadcom or Marvell without suggesting the same engineers would be better at building processors than the engineers at Intel or AMD.

Attempting to drive a last millennium view of networking as a separate vertically integrated system is both foolhardy and very limiting. Gartner validated this in their articles last year suggesting a dual vendor strategy. The fact that Cisco ships only 37% of the ports yet gets 73% of the revenue in the campus switching market is testament that their solutions are overly complex, pricey and focused to the last evolution.

Using "merchant" parts in products enables vendors to deliver quickly, with quality, cost, as well as features. Dell does not make their chip sets, would you argue they are ineffective as a vendor? IBM left the PC business as it did not see a path forward in an industry moving to "merchant" components. Perhaps it is time for Cisco customers to demand multivendor solutions with integration of "merchant" silicon and thus push Cisco to either change their business/technology model or leave the data market if they cannot migrate with the obvious evolution of the market. Today there is no reason for ANY enterprise to pay for those products based on proprietary components...........”merchant” indeed.

Categories: Networking, Technology, Architecture, Uncategorized Trackbacks (2)

Tags: No Tags

Trackbacks/Pings

  1. […] systematicHR wrote an interesting post today onHere’s a quick excerpt […]

    February 21st, 2008 at 3:36 pm from Merchant Silicon - Benefit or Bane?????

  2. […] Gourlay of Cisco recently responded to my post on “Merchant “silicon by putting a post on the Cisco site on his blog. Thanks to Brad Reese for pointing out the reply on […]

    March 11th, 2008 at 7:11 pm from Enterprise Technology » Blog Archive » Ferrari versus Corvette - Which would you Choose?

Comments

  1. how come Tony’s blog entry has zero comments when I look at it now???

    February 21st, 2008 at 3:19 pm by fermata

  2. nevermind; i see the comments were on Network World…

    February 21st, 2008 at 3:22 pm by fermata

  3. Yes, the comments was there - I will edit the above post to make that clearer.

    February 21st, 2008 at 6:20 pm by Phil

  4. Good read. btw- my name is misspelled :)

    February 21st, 2008 at 6:40 pm by Douglas Gourlay

  5. Hey, i find this comments very interested. Thanks and Regards from Germany

    February 22nd, 2008 at 1:45 pm by Gebäudereinigung

  6. Phil,

    Interesting this subject should come up. We are currently wrestling with quality concerns on a smallish vendor that uses this “merchant” approach. First their choice of hardware platform was inappropriate for the scale they advertised and now it is becoming apparent that their choice of operating system lacks in the robust RTOS (primarily scheduling, I think) to keep such things as process freezes, memory utilization as well as just plain corruption down to an acceptable level in heavy traffic.

    I argue that both “in-house” and “merchant” viewpoints are correct and at the same time miss the point. The tradeoffs to a complete in house silicon, OS and complier development and outsourcing the whole lot are both unacceptable in anything that needs to scale and deliver quickly.

    What is needed is a hybrid approach that allows a segment of the “merchant” vendors to target markets and specific scales of embedded systems (which seems to be happening). As well, a way to target RTOS in a similar manner (Perhaps open systems with in-house licensee development is not an oxymoron?).

    This could enable the best of both worlds. Of course, it could still be bad too.

    I think you still have the issues of programming styles to contend with (see “Worse is Better, “Good Enough” and “The Right Thing” discussion). http://www.mired.org/home/mwm/good-enough.html . In the end, “Good Enough” tends to allow the vendor to target the market they wish to serve, but recent experience tells me that caution is advised, because in most cases it is very painful to switch OS horses mid stream.

    February 25th, 2008 at 10:22 am by many

  7. The merchant approach is the right approach. Yes, of course there are deficiencies with that approach but the first to sort them out will lead the market in terms of price performance. No guts - no glory. Hybrid solutions are the same thing as hedging bets…you dilute the risk by diluting the upside.

    If you stop and think…there is no question that the merchant approach will be the right choice. The variable is timing. Better to risk being a bit ahead of the market than risk being rendered uncompetitive by trailing the market.

    February 26th, 2008 at 1:54 am by Another Nortel Watcher

  8. ANW, respectfully I disagree. (except in the freeware arena of web 2.0) These days, products that are all the same (and their margins) are commoditized very quickly.

    The “secret sauce” value add is the ability of the product to meet or exceed expectations and grow without a major rewrite when demand hits. At the application layer they should at least be stable and perform the task if the data is available, they should not cause havoc with other devices with badly behaving interfaces and finally provisioning, error reporting and prefomance KPIs should reflect the true state of the box and application as a unified network element.

    February 26th, 2008 at 9:31 am by many

  9. Phil, nice to see you are still at it. Having worked at both Cisco and Nortel ( not many of you have that experience at Nortel) you would be better advised not to make the monster angry. Nortel would be better advised to follow some of the best practices Cisco has developed than to throw rocks at them. Having worked with you, I always admired your dedication and determination, but lets face it Nortel has to find a new way. the old way is not working. Hopefully you will not have to be the last man standing.

    February 26th, 2008 at 11:07 am by rob cullen

  10. Many, technologies arrive at what I’ll call ‘merchant state’ on varying timelines. And often merchant products are used as components in ‘not-yet-merchant’ solutions. A market leading application may be built on top of merchant platforms but be differentiated by a non-merchant OAM&P system. In this case the ’secret sauce’ is the OAM&P.

    My point was really just that as soon as merchant components are available - use them, Be the first to use them if you can. In parallel, it’s important to shift to a new secret sauce strategy. Given the state of most OAM&P systems in the telecom industry, I think it’s safe to say that OAM&P by itself will offer nearly limitless potential for differentiating ’secret sauce’.

    February 26th, 2008 at 7:26 pm by Another Nortel Watcher

  11. ANW on this we agree. My recent experiance has been with a company deploying applications on top of hardware, kernels, RTOS and memory management that cannot support the demand. Furthermore, their OAM does not even tell our support systems when they are in trouble and you end up managing by outage. I am just a bit jaded this week, I’ll get over it.

    February 27th, 2008 at 12:14 am by many

  12. Many - I understand. I’ve been there. As you struggle with the problems, are they a result of merchant components or the *wrong* merchant components? Every industry has lemons. But I sympathize because no matter what, if the OAMP system is weak, life is hell. It amazes me that after observing 25+ years of network evolution, nobody in the industry has recognized that OAM&P may be the killer app that everyone seeks. In fact, MCI was built on a piece of OAMP. Friends and Family and the like were billing apps, not cool technology. Nobody ever learns.

    February 27th, 2008 at 9:33 pm by Another Nortel Watcher

  13. It is interesting that the issues are not at the HW level, but at the “system” level. I believe that those are generally independent of the underlying HW. The integration of the “merchant silicon” is what is critical. The real value of the product now is in the SW and the way the HW is integrated and built. IN many ways tis is no different than the PC industry (or automobiles where manufacturers use “merchant” products such as tires).

    February 28th, 2008 at 5:45 am by Phil

  14. ANW; they are the wrong merchant components and you are correct, that is the point. Bad choices early on.

    F&F was an early “viral” application.

    GOOG gives away their apps in hopes they will become viral so they can collect data to mine and for ad revenue. I think the GOOG model a large component of future growth for many :). OAM (I think) will evolve to measure acceptance and rate success against business KPIs, sort of a survivor gauge for the application jungle.

    February 28th, 2008 at 10:57 am by many

  15. Phil, Generally true. What I was commenting on and ANW clarified is 1) the poor *choice* of HW, and 2) failure to take advantage of what the HW offers (e.g. memory allocation and protection).

    Your automotive legacy is showing through, but I get your point. What is missing is the engineering. In some ways I see the explosion of the network into more discreet, responsibility driven devices a lot the same as OO programming.

    February 28th, 2008 at 10:57 am by many

  16. I think this was the highest number of comment posts yet!!!! All great comments. I agree that devices optimized for their location in the network are critical, I was surprised there were no comments from either marvel or Broadcom.

    March 3rd, 2008 at 4:36 pm by Phil

  17. “Cisco is well known for a profound inability to innovate internally ”

    Hmm, a quick look back at articles on the launch of Cisco’s CRS-1 router reveals the following:

    “[The] Silicon Packet Processor implements 188 massively parallel RISC cores in an 18 million-gate CMOS device with 8 Mbits of embedded memory. The switching-fabric ASIC, called Sea, implements a three-stage Benes nonblocking switch network with more than a hundred 2.5-Gbit/s channels.”

    Similarly, Cisco just launched a new edge router with something called a “Quantum Flow Processor”, a 40-core ASIC.

    40 cores on an ASIC? 188 cores on an ASIC? Over a hundred 2.5 Gbit/sec channels on an ASIC? What part of a “profound inability to innovate” am I missing?

    March 10th, 2008 at 3:00 pm by Mark

Leave a Reply