Home | Cloud | What is EMC’s Project Nile?
What is EMC’s Project Nile?

What is EMC’s Project Nile?

15 Flares Twitter 0 Facebook 3 Google+ 0 StumbleUpon 0 Buffer 11 LinkedIn 1 Filament.io 15 Flares ×

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.

Sales Model

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:

  1. True elasticity – scale up or down, with no penalty.
  2. Perpetual billing – provide storage on-demand to service/capacity/performance level, refreshed at an agreed interval (ensuring the N-1 products are never deployed)
  3. Monthly billing – option to bill per month for consumed storage, not just deployed.
  4. 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…

Related Links


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.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
15 Flares Twitter 0 Facebook 3 Google+ 0 StumbleUpon 0 Buffer 11 LinkedIn 1 Filament.io 15 Flares ×