Would VMware be in it’s current enterprise server virtualization leadership position if they had decided to cap ESX technology 3 years ago? (not sure of exact timing, but am sure someone will correct me :) What would be the consequences of declaring VMotion requires a whole new image, disk and disk pool format, incompatible with VMware ESX / GSX or Workstation/Fusion formats? I propose that would have resulted in a far worse reality for VMware and their customers than what we enjoy today.
History – learn from others or repeat their mistakes
It is every successful vendor’s dream to create a large and loyal installed base. If and when that dream is actually realized, it’s then every vendor’s resulting nightmare to migrate that significant and growing installed base forward as technology foundations underneath inevitably shift. That is what I define as the “Burden of Success” in our industry.
There are numerous industry parallels on how this dilemma was encountered and ultimately conquered. NetApp used many of these examples for strategic guidance as we evolved our primary & secondary storage product strategies.
Sun Microsystems
For example, Sun Micro needed to migrate their kernel from BSD to SysV for a host of technical, business and marketing reasons. They could not justify the engineering, support and sales investments in two kernels and thereby unleashed a relatively rapid and somewhat forced migration upon their installed base. Although not well received by Sun customers, Solaris ultimately prevailed as a great Unix OS for many years. Sun’s ultimate demise today has little to do with the technical excellence of the Solaris kernel.
Microsoft
During roughly the same timeframe, Microsoft needed to consolidate (rather than further fragment) their feeble DOS / Windows 3.x / Win95 / Win98 / WinMe kernels with some more resiliency and scalability. Enter Windows NT. Learning from Sun’s mistakes, Microsoft continued development, sales and support of both Windows kernel families for far more time than Sun. This was at great expense to Microsoft, but for the benefit of their customers.
Consequently, Microsoft kept a giant installed base happy while allowing those most in need (and other early adopters) to adopt the more robust NT kernel at their own pace – while being very transparent about the application and device driver incompatibility limitations of adopting the new NT kernel.
This is not unlike our early parallel Data ONTAP 7G and GX kernel strategies.
Apple
Arguably, Apple has best managed this type of transition. While one could debate their need for more HW & SW stack control than Microsoft, they have nevertheless delivered the smoothest migration for their installed base from a simple single-tasking kernel to BSD, from Motorola to PowerPC to Intel architecture, and most recently from 32bit to 64bit.
NetApp Homogeneous & Heterogeneous Investment Protection
Much like Apple and complete end-end 64 “bitness”, NetApp’s DataONTAP transition from scale-up (7G) to scale-out (DOT8 family) is still a work in progress, but we have both recently delivered on an critical milestone which will serve our installed bases very well as a solid foundation (see top headline for Aug28) for a long-term future.
There are too many parallels and relationships between NetApp and Apple for me to mention in this blog, but we both share the same belief in providing the best possible customer experience via tight HW & SW integration. Note that with NetApp technology, this doesn’t require a purchase disks from NetApp or discarding pervious enterprise storage investments.
All Cloud is Unified Infrastructure
Which brings me to my final and most important point. Unification is absolutely essential to Cloud Success. The entire economic basis for Cloud Computing (and related Storage) is lower end-user cost due to economies of scale based on efficiency via shared resources.
Can you imagine Amazon or Google achieving economies of scale with disparate data center, server or storage infrastructures? Repeatability via common, unified SOI is the uncontested recipe for Cloud success.
Shared infrastructures are the basis for all Cloud services, and pooled storage is the foundation for all scalable shared infrastructures. Any SOI based on NetApp Unified Storage enjoys tremendous competitive advantage in the Cloud marketplace due to common operational characteristics around planning, auto-provisioning, auto-protecting and troubleshooting that unified storage foundation.
Recognized Cloud leaders such as Joyent, Oracle, Rackspace, T-Systems, Telstra, Terremark & Yahoo! (to name but a few NetApp Cloud Partners) are all differentiating from their competitors with a NetApp Unified SOI as their foundation. Because …
OpEx efficiency matters far more in the world of Cloud than optimal CapEx “budget flushing” in the public sector and enterprise IT landscape.
Compounding Benefits vs Fragmented Compensation
Coupled with the compounding benefits of unified storage efficiency across SAN / NAS / iSCSI and now FCoE deployments, NetApp Cloud customers are delivering market-leading SOA’s, instead of elaborate rearview-mirror SOI’s which strain to carry forward legacy storage architectures resulting from fragmented product families.
Reality checks such as true cost parity with DAS / Internal Server Storage in a physical as well as virtual environments are proof that in a world of continuously evolving & improving technology, only NetApp is uniquely able to deliver the benefits of Unified Storage in the Cloud.

I used NT 3.1, 3.50, and 3.51. None of those versions had good driver support and MS never admitted it. I was involved in purchasing a network of machines for the specific purpose of running NT 3.51. I selected hardware from the MS Hardware Compatability List (HCL) and the machines crashed repeatedly. I needed to replace the SCSI controllers and video cards to get them going.
Not that early versions of NT were particularly robust even when you had good drivers. It wasn't until a long time after the initial release of NT4 that they got it working reasonably well.
As for keeping the installed base happy, as far as I recall MS customer happiness peaked in 1990 and went steadily downhill. Even in 1993 the MS monopoly position was well known.
Posted by: Russell Coker | August 31, 2009 at 05:34 PM
I like the Apple graph. It helps put the timeline of NetApp's Spinnaker integration into proper perspective by showing how long it took both companies to ship their visions.
I find the timing of Snow Leopard's release and NetApp's DataONTAP 8.0 announcement the same weeks quite ironic!
Posted by: Nils | August 31, 2009 at 11:45 PM
What about the timeline involved in these transitions? I guess Apple still has a MUCH better track record then ntap. Think how long ago Spinnaker was purchased until DOT8 hits the "mainstream" market...
Still some way to go, Val ;)
Posted by: Peter Lehmann | August 31, 2009 at 11:48 PM
But keep in mind that ONTAP GX (based on the Spinnaker acquisition) has already been shipping since 2006...
Posted by: Geert | September 01, 2009 at 05:46 AM
@Peter, It's a loose analogy to be sure, but I think rather a valid one. Both companies began their "scalability quests" around 2003, and both are nearing completion but not yet done.
Apple's scalability quest is to fully utilize the multi-score 64bit CPU and 128bit GPU technologies via "processor scale-out". They are getting closer, but not yet done.
NetApp's scalability quest is to fully utilize Spinnaker technology for storage scale-out. I would argue they accomplished that with GX, but adding the additional WAFL features (moving target with SAN, thin provisioning, dedupe et al) is taking more time.
I get the sense that true 64bit Grand Central and 128bit fully parallel OpenCL apps for Apple OSX will appear about the same time as fully converged Data ONTAP 8.x with SAN & Object Store.
Posted by: Nils | September 01, 2009 at 07:17 AM
@Nils, makes sense when looking at it this way.
For my point of view, these are totally different Painpoints.
The Pain on a MacBook is not the same, when te OS running on it is not fully utilizing the available Processor Power or GPU.
The Pain in my Storage Backend (or Cloud) is much bigger, if the OS is not providing the scalability and flexibility (and features, GX is very much stripped down compared to 7G).
@Geert
Shipping and providing features (FCP, iSCSI, support for SnapManager Family) is not really the same... And this is still far away!
Posted by: Peter Lehmann | September 02, 2009 at 01:08 AM