- Storage White Papers
At EMC’s recent launch event (coverage here), the company provided teaser information on something called “Project Nile” – a sideways swipe at Amazon Web Services and something that’s due to develop into a product offering some time in 2014. But what is Project Nile, a platform, a product, a service? Hans De Leenheer’s recent interview with Chad Sakac and the latest Speaking in Tech podcast has thrown a little more light on the subject. Here’s what intel I’ve assembled so far.
Project Nile is a new way for EMC to package and sell their products – a “storage on demand” model, of sorts. This is where the indirect reference to AWS comes in, by using the “Nile/Amazon” reference. Rather than buying discrete products, customers can choose to buy per GB, in the same way that VMAX Cloud Edition was sold.
There is no new hardware in Project Nile. Instead it’s a re-packaging of existing products in EMC’s portfolio, probably initially based on the new VNX platform (colloquially named VNX2). The reason why VNX2 is in there (according to Sakac) is the low price point at which the solution could be sold based on the new architecture’s ability to scale. There may be some new software components, but it sounds like the way EMC intend to achieve massive scale is by shipping multiple VNX’s and using ViPR as the overall managing tool. How many platforms are and will be integrated into Project Nile remains to be seen, but I’d watch the ViPR support matrix closely as that’s likely to provide us with the best indication.
The most radical thing Project Nile sets to deliver is a change in the purchasing model for businesses. If we look at how things work today, customers typically work on a three, four or five year buy cycle. The equipment is specified, purchased and deployed. Over time it may be added to, with the initial capital expense amortised over the expected life of the equipment. As more capacity is added, the extra cost is typically co-terminated at the same time the initial agreement would end. Things get interesting at the end of the initial deployment period. At that time EMC (and to be fair all other vendors), will be back knocking on the door, offering the next latest/greatest product at an attractive replacement rate, including professional services to move the data. Alternatively the customer can take much higher maintenance rates for the hardware to aide the incentive to refresh.
Project Nile appears to operate more like the EMC OpenScale model, where buffer capacity was physically installed before it was needed, reducing the panic buying mode. However with OpenScale, deployed (and therefore charged) capacity never went down, even if the customer didn’t need the extra space. In addition, outside of OpenScale, incremental purchases are usually much more expensive than buying up front. But surely, other than integrating ViPR for deployment, Nile must offer more than OpenScale did? Well, let’s look at some of the common aspects of on-demand services.
- Elasticity – will Nile offer true elasticity? Will I be able to scale up as well as down? As the hardware is on the customer premises, EMC can’t easily resell it as Amazon can in a cloud model. In fact, customers could make it very awkward for EMC to retrieve their assets, especially where arrays are partially used. Just think how LUNs are wide striped across many disks; how do you successfully reshuffle data to remove disks? Would that be even practical? ViPR is a provisioning tool and has no data migration capabilities, which surely is a pre-requisite to implement an on-demand model.
- Usage Billing – Sakac indicated that EMC would be covering the asset on their books, for accounting purposes. This throws up few issues; first some financial institutions won’t deploy data on hardware they don’t own. Second, EMC would be taking the accounting hit for effectively providing customers financing. Margins will be tight, so EMC shareholders may not see this as a good return on capital. Third, Nile appears to be nothing more than a 3-year purchasing deal, so EMC would only be providing leasing services. Many financials put the cost of hardware through their own leasing arms and so simply may not want to use EMC’s model.
- Technology Refresh – Cloud services provide abstraction from the physical resources, as we know. So, whether for good or bad, we don’t have to care about the hardware other than to be confident it meets reliability/performance requirements. If Amazon wanted to deploy the next cheapest level of storage, they could do so quite easily and migrate customers over, as it’s part of the design of EC2. But how would that work with Project Nile? Will EMC turn up after three years with replacement technology? I think this isn’t the intention, which gets us back to Nile being nothing more than leasing.
The Architect’s View
At this stage all of my observations are just speculation. However, if EMC are intending to provide a true on-site on-demand storage service, there are a number of issues they need to overcome. I’d like them to include the following:
- True elasticity – scale up or down, with no penalty.
- Perpetual billing – provide storage on-demand to service/capacity/performance level, refreshed at an agreed interval (ensuring the N-1 products are never deployed)
- Monthly billing – option to bill per month for consumed storage, not just deployed.
- Consistent look & feel – performance/availability, should always be the same regardless of purchase intervals and quantity.
Am I asking too much? I’m looking forward to EMC pleasantly surprising me.
Note: Apologies to Chris Mellor, to whom I promised some feedback on what I thought Nile was…
- EMC Speed2Lead – The Right To Answer (Hans De Leenheer blog)
- EMC Megalaunch Speeding to Lead Balloon
- What EMC Should Have Done With VNX
- Exploring our way to the source of EMC’s mighty VNX Nile (The Register)
Comments are always welcome; please indicate if you work for a vendor as it’s only fair. If you have any related links of interest, please feel free to add them as a comment for consideration.
Subscribe to the newsletter! – simply follow this link and enter your basic details (email addresses not shared with any other site).
Copyright (c) 2013 – Brookend Ltd, first published on http://architecting.it, do not reproduce without permission.
- Netapp: The Inflexibility of Flexvols (12,353)
- Windows Server 2012 (Windows Server “8″) – Storage Spaces (11,510)
- Enterprise Computing: Why Thin Provisioning Is Not The Holy Grail for Utilisation (9,709)
- Comparing iSCSI Targets – Microsoft, StarWind, iSCSI Cake and Kernsafe – Part I (7,527)
- Windows Server 2012 (Windows Server “8″) – Virtual Fibre Channel (7,427)
- Review: Compellent Storage Center – Part II (7,390)
- Why Does Microsoft Hyper-V Not Support NFS? (6,772)
- How To: Enable iSNS Server in Windows 2008 (6,326)
- Data ONTAP 8.0 – Part III (5,767)
- How Many IOPS? (4,733)
- Comparing and Contrasting All Flash Arrays – All Vendors (118)
- The Maturing of Flash Storage (90)
- The Virtual Machine is a Legacy Construct (18)
- Windows Server 2012 (Windows Server “8″) – Virtual Fibre Channel (17)
- Review: Compellent Storage Center – Part II (16)
- XtremIO: What You Need to Know (Updated) (15)
- Enterprise Computing: Why Thin Provisioning Is Not The Holy Grail for Utilisation (15)
- How To: Enable iSNS Server in Windows 2008 (13)
- HP 3PAR 7450 All Flash Array (13)
- Netapp: The Inflexibility of Flexvols (11)