Data Center Advisors

Since I’ve been talking about commodity versus novel implementations as well as innovation of late something recently caught my eye.  Notably a purist debate on how Fedora will no longer include the TomBoy application and folks are equally skeptical about Mono.

Now mind you I am a fan of Open Source, but I look to interesting things that can come from it not purism.  For instance, I posit that IBM uses Open Source to circumvent the politics which exist in a huge company.  That means that if a engineer in division X of IBM wants to collaborate with an engineer in division Y they can use the power of Open Source to jointly collaborate without having to get permissions from the associated management chains.  That is pretty  cool and has nothing and I mean nothing to do with a purist view of Open Source, the selected license, etc.

The debate referenced above caused me to go and review Miguel’s blog on innovation with respect to Mono and C#. I have to say that he brings up some pretty good arguments and tries to cut through a lot of the emotion referencing facts which are hard to refute.  (In fact it reminds me of my exchange with Barry where he got huffy and ultimately folded under the weight of fact.) The big take away that I get from Miguel is that his team continues to innovate, and I could not agree more.  The political distractions in the Open Source community only mean that the detractors are distracted with rubbish comments while the engineers innovate right past them.  This is how I see EMC and Hitachi.  EMC is so caught up in marketing the next big thing that they forget to innovate and end up buying a company, copying Hitachi or copying industry incumbents like Amazon.

So Miguel, thanks for the great post and continue the good innovative work on Mono!

Tweet

Posted in Innovation 5 Comments »

Comments (5 )

Post Comment

Perhaps the funniest thing you’ve said in this debate is the proprietary hardware affords faster time to market.

Let me say this: the LAST thing EMC would do is copy Hitachi.

Would we, and we’d be 5 years behind the market leader, and fading fast.

Let us recall that is EMC who was first to deliver:

* LC-FC/FATA drive support
* SATA drive support
* Enterprise Flash Drive support
* In-the-array storage tiering
* 3 site replication w/continuous protection
* 4 site replication w/continuous protection
* Truly dynamic cache partitioning
* True scale-out storage architecture with virtually unlimited scaleability
* Automated storage provisioning for Virtual Server clusters
* VMware management and SRM integration
* Full SMI-S provider support across all platforms
* Integrated NAS/FC storage (Celerra)
* Secure erase for failed disk drives
* Non-disruptive migrations across platforms AND generations
* Integrated content-addressable storage (Centera)
* Thin/Virtual provisioning on all storage platforms
* A roadmap for Fully Automated Storage Tiering
* Integrated data compression/dedupe
* Copy-on-write snaptshots
* Fully non-disruptive code upgrades
* Comprehensive line up of disk library and dedupe archive platforms
* Platform-independent CDP replication
* more than 64GB of usable global memory

If anyone is copying anyone, it is Hitachi struggling to keep up with EMC.

And when you pause in your tirade against solutions based on industry-standard technologies, you may suddenly realize that ALL of EMC’s storage assetts now run on the multicore Intel architecture. Throw in a little hypervisor technology, and there isn’t a big leap required to foresee the opportunities to integrate different assets within each platform, thus accellerating the pace – and multiplying the opportunities – of EMC innovation…

Meanwhile Hitachi is mired in the muck of incompatible proprietary platforms, forced to implement each so-called “innovation” multiple times, and falling further and further behind as a result.

Well Barry I see that I’ve struck a nerve. However, as we’ve mentioned before we’ll have to agree to disagree here. The largest flaw I see in your thesis above is “EMC is great because we include Intel,” which is ironic because this is a post on innovation and using Intel is not innovative.

In the immortal words (and in respectful memory) of David Carradine:

No, grasshopper. Using Intel is inarguably not innovative. It is the things you accomplish as a result that are innovative.

And whether bought, replicated or invented doesn’t really matter – the innovation is to recognize the unique value of integrating good ideas (whatever the source) into differentiated solutions to customer problems. In this sense, Intel is merely an enabler for greater things.

TTFN!

Hopefully, I will succeed in adding my 2Cs without rekindling this lively debate.
Arguing against the merits of leverage is like arguing against apple pie, and I will avoid such trap. Multi-core, hypervisors, etc. are just the canvas to paint on. In years gone by I “painted” on various risc and cisc processors, drams, srams, and special purpose hardware. One should never reinvent the wheel, and when the tools and building blocks available are adequate, one does not.
This leads me to the “one size does not fit all” philosophical argument.
When I was the CTO of Snap!Server, the product was defined as the ultimate intelligent disk (Feature wise it was a full featured NAS). To achieve the cost goals a very inexpensive embedded processor was used which enabled achieving the product goals.
Designing high-end, high performance and scalable NAS required building blocks beyond the available processors. This is not in violation of my opening remarks. If a multi-core available platform would have allowed the required scalability, any design should focus on the added value and leverage available components.
Without turning this into a long technical dissertation, the three elements which required custom design were: Offloading, Pipelining and fine grain Parallelism.
Embellishing a little,
– High Degree of parallelism: Parallelism is key to performance. Many systems attempt to achieve such parallelism. While processors based implementations can provide some parallelism (provided the data has parallelism), as demonstrated by traditional MIMD architectures, (Cache coherent or message passing), such implementations require synchronization that limits scalability. Fine grain parallelism by implementing in state machines avoids the chatter associated with multiplicity of cores, and allows a much larger degree of parallelism…
– Off-loading: Allows the core file system to independently process metadata and move data while the processor module is dedicated to data management. This is similar to traditional coprocessors (DSPs, Systolic Arrays, Graphics engines). This provides yet another degree of parallelism.
 This also enabled the achievement of the design goal of Consistency of performance.
– Pipelining: Is achieved when multiple instructions are simultaneously overlapped in execution. For a NAS system it means multiple file requests overlapping in execution. This has been achieved by implementing a bi-directional pipeline (“To” and “From” disk).
Back to where I started, “One size does not fit all”. Offloading / Acceleration/ pipelining and fine grain parallelism are implementation methodologies when the benefits of performance and scalability are apparent. In segments (“bands”) where good enough and cost are the key attributes Multicore architecture will do just fine.

So, I suggest we abandon any dogma. A good design and a good product start with describing the goals and targets of its function, and if proprietary implementation is required to achieve such goal, it is the best way to get there. Otherwise, sure, use standard platforms.
Note that this is a journey. As multi-core platforms and hypervisors progress, some functions will migrate there. Offloading will remain a key advantage when consistency of performance is required, allowing multiplicity of data management applications to share the platform without robbing the metadata processing engine of its compute resources. Remember that parallelism is only as good as the parallelism provided by the data.
Finally, in such architecture the list of features listed above (By the previous contributors), can still be leveraging multi-cores, etc, while the offloading assures that all those features (=applications) perform adequately while launched simultaneously.

Shmuel, thanks for the comment. I think that you groked my intention directly.

Post a Comment