Because having some kind of “cloud” related service you could market and sell was SOOOOOO 2 months ago, I’m now seeing nearly every service provider in the market trying to convince me that they are suddenly capable of selling some new flavor of “PRIVATE cloud”… as though what they’re offering isn’t simply a re-marketing of the same private dedicated virtual hosting solutions they’ve already been selling and delivering for the past few years.
Thankfully, when the last straw hit my inbox from a sales rep at yet another provider I actually work with, and I was about to throw open a window and yell “I’m mad as hell and I’m not going to take it anymore!”, I happened to be sitting in the offices of my good friends over at Unitas Global downtown Los Angeles who understood my pain. Thus began a most enjoyable conversation with Grant Kirkwood, CEO and Founder of Unitas, (one of the most brilliant, experienced and holistic engineers I know) on what IS and IS NOT a Private Elastic Cloud.
Combined, Grant’s team and I have spoken with over 2 dozen clients over the past few months alone looking to deploy some flavor of “private cloud”. The consensus we came to was that if it is not as easy to spin up new compute and resources as it is to buy a book online, it’s not private ELASTIC cloud. RightScale gets this… who I had been speaking with the day prior on the same topic. I’ll even go so far as to say that those working with OpenStack and CloudStack for the most part get this as well.
One of the most depressing stories I heard during these conversations however was about a client who had spent nearly $2M with the likes of Accenture to build what they thought would be a functional private elastic cloud. They ended up terminating the engagement however, when they realized the sales and engineering team responsible for delivering the solution was doing no more than setting up vmware across a new and expensive Cisco UCS solution… and as the oh so clever Microsoft billboards up and down Highway 101 clearly tell us, “Virtualization does not a cloud solution make”.
Reality is more and more companies are seeing their own internal IT departments preferring to spin up new resources from the likes of Azure and AWS without permission from corporate vs. hassle with whatever complicated approval process for adding compute may be in place at their company. Why? Because it’s simply EASIER for them to do so.
Thus, business process and ease of consumability are essential to delivering a functional and useful private elastic cloud, or we are simply looking at a virtualization or dedicated hosting solution… which is far from anything new or evolved. If you are interested in continuing this conversation and exploring your options, please don’t hesitate to contact us.
Hi Sean,
I just read this article and wanted to comment on the idea of “private cloud.” You’re right – lots of companies go to public cloud providers and spin up resources without permission… because their staff recognize that the rules against using public cloud are not based on business need. However, those companies that legitimately need private cloud are trying to comply with legal or business rules that require fully PHYSICALLY and ELECTRONICALLY separated infrastructure. For example, the highest levels of PCI compliance have this written into them. This requirement is the definition of “private Cloud,” despite the fact that as you have observed, many MSPs love to give it a different meaning.
If the hardware used to deliver a private cloud truly is physically separate from other consumers’ clouds, then you can never spin up new resources as easily as “buying a book online” because it cannot be done by moving a running server *logically* from one domain to another as the public cloud does. It must be moved *physically* (in other words, installed, or turned on if already installed.) Installation of course can’t happen in real-time, especially if you include the purchasing process.
Because of this “elastic private cloud” is oxymoron. Sure, the MSP can achieve some level of logical separation using VLANs, switches, virtualization, etc. but that separation will not meet the line-in-the-sand criterion of physical separation, so it is not private, and therefore not elastic. At best, it’s SEMI-private – which may be more than enough privacy to give the business what it needs without eliminating the benefits of elasticity.
“WTF” is most applicable!
Cheers,
-Eric
Eric, you are most definitely correct in your statements regarding the need for physical and electronic separation as a key component of PRIVATE “cloud”. This was taken for granted in the post, but should have been mentioned… and yes, there is a finite pool of compute resources within a private hosted environment no matter how you slice or dice it. A distinction here must also be made between a hosted private or semi-private environment and a wholly owned private environment.
Regardless, if forecasting is done correctly, one can predict load and add resources ahead of schedule eliminating the need to add the physical resources on a frequent basis, be it the hosting provider or the end user themselves.
The key however is that I would point to services/resources such as what Rightscale brings to the table as a tool that DOES provide the ease of provisioning new compute resources as simple as buying a book. The interface and FEEL of your private elastic hosted environment can in fact mirror the simplicity and FEEL of the public IaaS providers. The environment simply will not be infinitely elastic (or near infinite) without a large and likely unnecessary CapEx or OpEx should you choose to either build your own or work with someone like ENKI.co, Unitas Global, Redapt… etc. to provide such an environment for you via a hosted model.
The word “elastic” within a Private Elastic Cloud is thus referring to the user experience and interface used to spin up new compute. This, I still contend, is what differentiates simply another private dedicated hosting solution and one that can claim to be “elastic”.