VMware Officially Validates the Hyperconvergence Model with VMware EVO: RAIL
[dropcaps type='square' color='#ffffff' background_color='#e04646' border_color='']A[/dropcaps]t VMworld 2014, VMware announced the availability of a new product the company has named EVO: RAIL, a hyperconverged infrastructure appliance. EVO stands for “evolution”. RAIL describes the fact that this offering is based on four node servers with each server node having rails to include that node in the chassis. EVO: RAIL is the next evolution of VMware’s foray into the world of converged compute and storage and follows last year’s VSAN product announcement. To be clear, VMware itself is not getting into the hardware biz; this offering is a software-only play and VMware has partnered with a number of server hardware vendors – Dell, EMC, Fujitsu, Inspur, Net One Systems Co. and Supermicro – to handle the hardware side of the EVO: RAIL house. According to VMware’s press release, these vendors are expected to begin shipping EVO: RAIL appliances by the end of the calendar year.
Repackaging + Tidying Up
At it’s core, EVO: RAIL is a repackaging of vSphere and VSAN with a streamlined administrative experience intended to accelerate the deployment data center infrastructure and to make it easier to deploy and manage. And, although it’s a real product, it’s almost a reference architecture in some ways. VMware is prescribing hardware requirements that vendor partners need to meet in order to be considered a valid EVO: RAIL product. From what I have seen so far, VMware is not allowing hardware partners to alter the specific node configuration either up or down. If this is not accurate, please correct me in the comments. While I understand that consistency is important in such a product, the inability for hardware partners to adjust configuration means that there will be a struggle to differentiate between hardware vendors.
Demand Simplicity in All the Things
As I’ve said for a very long time, IT organizations must get on the simplicity bandwagon – regardless of the form that takes – in order to enhance their value to the business. VMware’s introduction of EVO appears to be another step in the direction of simplicity. Perhaps the primary downside that I see to EVO: RAIL is the product’s 100% reliance on a full VMware stack, in particular VSAN. There are far more mature hyperconverged offerings in the market today that can fill the same niche that VMware is attempting to fill and can fill it with a product that has more capabilities.
In particular, EVO: RAIL’s reliance on VSAN as the data store will give some potential customers pause as to the suitability of the product for production. VSAN, while a good 1.0 product, is missing some key features that make storage enterprise-worthy, such as deduplication. Obviously, VMware is continuing to develop VSAN and I expect that we’ll see a number of improvements in VSAN 2.0. However, for today, I don’t see VSAN as being a suitable replacement for other storage options in the data center. The offerings from traditional storage vendors and the options from established hyperconvergence vendors such as Nutanix and SimpliVity are simply overwhelmingly more suited to production use and offer far more capabilities.
While I don’t believe that EVO is going to find its way into millions of data centers overnight, I believe that VMware will ultimately have some success with the product. For now, though, I believe EVO will play a far more important role in lifting the fortunes of the rest of the hyperconvergence market. Hyperconvergence was – until Monday, at least – a foreign concept to so many in the IT space, but it carries with it some really important potential technical and business outcomes. It provides organizations with a way to reduce the amount of sheer effort that it takes to manage the data center while also helping organizations to “operationalize scale”.
What, exactly, does that mean?
Consider the traditional data center buying cycle. Every few years, IT gets a capital infusion as a part of the established replacement cycle for data center hardware. At that time, we can have what I like to call a “scaling event” during which we expand data center resources to meet the then-current and expected future needs – at least those that we expect to happen before the next replacement cycle – of the business. There are two downsides to this approach:
[unordered_list style='circle' number_type='circle_number' animate='no' font_weight='']
- “Scaling events” are taking place more often. As business accelerates, the need to scale data center resources may happen off cycle. This creates an exception in the scaling process that often requires a different kind of approval process that would happen at the normal buying time. In other words, scale is often treated as an exception.
- In an effort to buy enough for last for the full cycle, IT tends to overbuy resources. This leads to waste and increased costs until those resources are used, which may be never.
[/unordered_list]Rather than treating scaling events as abnormal, consider them as a normal part of IT operations. In other words, operationalize scale both from a process perspective as ell as a budgetary one.
This can be easier said than done with legacy infrastructure.
Hyperconverged infrastructure scale takes a more granular approach to expansion, allowing organizations to scale when needed without needing a massive cash infusion. Yes, it still costs money, of course, but can be accomplished far more easily.
It was a big week for those that play in the hyperconverged infrastructure space. Although EVO:RAIL does not currently appear to be a game changer, VMware’s official entry into hyperconverged infrastructure provides further validation for the hyperconverged market as a whole.