What's Andy smoking these days? Apple would counter his merchant silicon argument and who's developing full custom chips these days except Intel and AMD. Most merchant silicon in networking are developed using standard cell ASIC libraries.
He's got his head in the clouds these days. Arista will get absorbed into some other networking company if they keep reselling Intel reference designs. Using merchant silicon is good if you want to get to market quickly but you can't hold your lead relying on suppliers. All your competitors have access to the same silicon.
It appears that Andy can get headline articles written based just on his hallway uterings!
His comments on Sparc were referring to the vertical integration of silicon, system h/w and software. This is difficult for any company to keep delivering on. Being able to use the best of current breed of silicon and differentiating on the software is where the system companies are finding success.
Apparently on the marketing front Arista supports the buzzwords of SDN and actually supports some version of OpenFlow.
But privately Andy believes OpenFlow is too limited, low level and incompatible with today's networks to gain traction.
He does believe there will be more mangeable, configurable nets using some form of SDN with each major company probably doing their own API thing for the next several years.
Let's see Apple has it's own HW (silicon, boards, and I/O specs) and SW (OS, and applications). Sounds vertically integrated to me. Only thing missing is manufacturing but if foxcon has more problems, this many change.
Seems the pendulum has swung back the other way and the industry is still stuck in 'core competency' mode -- or rather chucking competency and innovation.
It might be more accurate to say the *market* gave up on SPARC.
SPARC is a RISC processor, and an outgrowth of rethinking the architecture of a CPU. Previous generations had all been CISC architectures, with huge instruction sets. But realization set in that most of those instructions weren't actually used because compilers didn't generate code that used them. Why not design a CPU with only the basic instructions from which others could be constructed, and concentrate on making them as fast as possible, then let compilers do the work?
Sun created the SPARC. HP had Precision Architecture. DEC created the Alpha. AMD had the 29000. But takeup was limited to server space, and steady improvements by Intel ate into any advantages RISC possessed. CISC was just as fast as RISC, and was *cheaper*.
Sun wasn't the only one who backed off. DEC no longer exists. HP moved away from PA to systems based on Intel architecture. AMD concentrated on being an alternate supplier of Intel architecture chips.
Backing away from SPARC didn't kill Sun. Being unable to compete did. You can make an argument that developing SPARC used resources Sun might have better applied elsewhere. If I'm a customer looking at Sun servers, and I see SPARC and Intel-architecture Opteron models, they can do the same things, and Opteron is cheaper, which way do I jump?
SPARC may well be technically superior, but customers aren't buying technical superiority - they're buying bang for the buck. If you offer a product that costs more, you better have something the *customer* will see as justification to pay the higher price. SPARC wasn't it.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...