Introduction
A couple of weeks ago I announced my new role in the EVO:RAIL Team – the fact is I’ve been working with the team since just before VMworld US, but it wasn’t really until last week when I had finished up my work with my previous team, and the HR wheels had turned, that I was able to tell folks publically. Not to fear, my new role means I’m even more committed to the community – and that includes projects like Feed4ward and speaking at VMUGs generally. I hope to pick up a schedule of events for next year, and that includes coming to the US to speak at the big VMUG User Conferences too.
So I’ve been thinking about the topic of hyper-convergence generally. It’s popular in the US to talk about the ‘journey’ so I want this article, and the articles that will follow it, to be the basis of my own thinking around the subject – call it my own Personal IP. At some stage I need to write my own VMUG style presentation about hyper-convergence. Folks who know me will know I hardly ever use the standard corporate decks when talking about VMware technologies. Right now I am – but going forward I want to put my own personal “Mike Laverick” stamp on that. My hope is that this series of blog-posts will help me develop my own stance and perspective. So here goes…
EVO:RAIL. Already there are innumerable spellings (evo:rail, evo-rail, EVO-rail, Evo:Rail and so on), and it doesn’t help that you can’t actually pronounce “: “. So for the record it’s meant to be EVO:RAIL in capitals. One of the funny things about the name is if said too quickly it could sound like EVIL:RAIL, prompting a typical Dr EVIL:RAIL meme:
I’ve been using this to good effect when anyone asks how much EVO:RAIL costs. The reality is VMware doesn’t set the price. The six different Qualified EVO:RAIL Partners (QEPs) do. VMware licenses the EVO:RAIL engine and associated software (vSphere, VSAN, LogInsight) to the partner and the partner sells the final product to the customer – one throat to choke, as my US friends are fond of saying.
The other amusing thing is what happens if you type EVO:RAIL into Google Images. Along side pictures of servers and logos, you’ll also see pictures like this:
It’s heartening to see an interest in VMware EVO:RAIL is starting to work its way through the Google Images algorithm. A couple of weeks ago there were just photos of semi-automatic weapons! Of course, my lame pun has been – “VMware EVO:RAIL – Your Weapon of choice for the Datacenter”.
So for the record EVO is for evolution – the natural evolution of VMware technologies to be consumed in a hyper-converged fashion. As for RAIL, well if you have ever been into a datacenter hall and racked up some gear… you get the picture…
Hyper-Consolidation – How did we get here?
Although I quite like the term hyper-convergence, I can see already a parlour game of “define your terms” is already cranking up. Sometimes that can be dangerous because if a vendor defines hyper-convergence they are likely to use a definition that presents their product in the best light – it’s a phenomena that customers will be have to cautious about. Personally, I find this game of defining terms slightly pedantic. But sadly, its unavoidable – I think the simplest definition is a server (call it an appliance if you must!) which provides both compute, networking and storage in a single bundle. It’s an approach that scales-out the environment by adding more servers in a block-by-block method with each new server joining the existing environment seamlessly.
Phew, definition done.
What interests me more is where we have come from, and how we got here as an industry and community. For me it seems only right and proper for VMware to deliver (with partners!) a hyper-converged solution, after all VMware was the company that brought server-consolidation to the masses and popularized virtualization. That’s partly the pun in my title – from server-consolidation to hyper-consolidation. For me it makes perfect sense – or the perfect EVOlution for the company that brought server consolidation to the market, to also popularise hyper-consolidation too. Incidentally, I’m not trying to coin a new term here. It’s hyper-convergence, not hyper-consolidation, right? I’m just using the term as metaphor…
Way, way back in 2003, VMware could have taken this route. They could have bought cheap commodity servers from the white box market, yanked the bezel off, and replaced with a VMware bezel and sold that to customers. Mercifully they didn’t take that route at all. They took the market route of being a software vendor, and working with partners and the channel to get VMware ESX and VMware VirtualCenter (to use its old name for a moment) as a way of popularizing virtualization. It’s an approach that helped take the company from a handful of employees with a couple of hundred customers – to being a billion dollar company with 20K+ employees, and 450K customers. So what I like about EVO:RAIL is it delivers on the appliance model for the consumption of VMware technologies, whilst at the same time staying within a tradition and business-model that has been tried and tested before.
I remember when ESXi first came out, and it became possible to boot the hypervisor from a USB/SD-Card. There was talk back then of server vendors shipping the hardware with VMware ESXi already pre-installed, in a sort of embedded format. In my mind I imagined that when the server first booted, you’d merely select which hypervisor you wanted (the best one, of course!). As far as I could tell that never really ever happened. Quite possibly because there wasn’t enough add-value for either the server vendors or customers to make it happen. The truth is installing VMware ESXi is totally trivial event – the fun starts in the post-configuration phases. That’s why I think EVO:RAIL will be successful. Looking back over the years, I’ve personally done a lot of automation. It started with simple “bash” shell scripts in ESX 2.x, and then evolved to using the UDA to install ESXi 3.x from a PXE boot environment. About the time of vSphere4 I moved away from bash shell scripting to building out environments with PowerCLI. It has literally hundreds of cmdlets and can handle not just ESXi but vCenter configuration too. I burned a lot of time building and testing these various deployment methods. Now, EVO:RAIL has come along allows me to do that in less than 15mins.
For me that doesn’t mean all that previous hard work has been for naught – after all I believe there is still legs in other model for delivering infrastucture. I still will still support those methods, but what EVO:RAIL has delivered is much more automated, standardized and simpler method of doing the same thing. As independent it always sort of irked me that VMware didn’t have a pre-package, shrink wrapped method of putting down vSphere, and it was sort of left to the community to develop its own methodology. The trouble with that is everyone has their own personal taste on how that should be done. And we all know that leads to things being not standard between organizations, and in some cases within organizations. Despite ITIL and change-management controls, configuration drift from one BU or geo to another is a reality for many organizations. I see EVO:RAIL as offering not just hyper-converge consumption model, but an opportunity to standardize – especially for companies with lots of branch offices and remote locations.
It means that VMware has empowered the partners to enter the market place rapidly, and provide to customer’s choice, bringing much needed competition to the hyper-converged space where previously there was much narrower range of options. It’s also a further step down the road to hyper-convergence becoming as mainstream as virtualization. Once companies such as VMware, Dell, Fujitsu, EMC, and SuperMicro join the party, hyper-convergence will come to the attention of everyone in the industry – from the guy who racks ‘n’ stacks to the management team.