It’s hard to believe that there are such widespread misconceptions about what constitutes a “cloud” in the IaaS space.
This is evidenced by cloud blogger Ben Kepes’ article yesterday, “Server Huggers and Henry T Ford’s Faster Horse,” which took pretty aggressive aim at bare-metal clouds, and more specifically, our Cloud Spectator report that showed the performance-price benefits of bare-metal vs. virtual cloud. The reality is that IaaS is evolving, and it isn’t always tied to virtualization, although it seems difficult for some to leave this notion behind.
I’m actually surprised that Ben suffers from this misconception since I’ve enjoyed many of his previous articles on OpenStack and open source, but in this case, I think he’s just plain wrong. As many still do, Ben equates cloud to virtualization and goes on to cite two important cloud influencers that we both mutually respect – Dave Nielsen and Joe Weinman – on the attributes that make up “cloud”. Here they are (combined and consolidated):
- On-demand
- Self-service
- Scalable
- Measurable
- Common
- Location-independent
- Online
- Utility
I totally agree with these characteristics, and I’ll even add another requirement of my own – programmable. It’s not enough to simply provide a self-service portal to create a true infrastructure “cloud”; functionality has to be completely exposed and programmable over an API.
I also absolutely agree with Ben that the cloud is more about changing business models than it is about changing technologies. Indeed, in the infrastructure world, how IT is consumed is undergoing a fundamental shift. With “cloud”, you don’t have to spend the capex or plan for the worst case. Instead, you can pay for what you need, when you need it. And, it’s all commoditizing rapidly.
So, back to the virtualization topic. I’ll agree that virtualization is an enabler of a lot of clouds, but it’s definitely not a requirement. It’s interesting that “virtualized” isn’t on either Nielsen’s or Weinman’s list. Nor is it in the NIST definition.
What if we could get all of the things on our mutually agreed-upon list for “cloud” but without virtualization? We can.
Our bare-metal cloud is just commodity compute. Each server has a CPU, RAM, and disk(s). It’s provisioned over an API (or a portal). You can install pretty much any flavor of Linux and Windows. It’s available to you within a few minutes (generally about 5-10). It’s very elastic and is billed on an hourly basis – you can spin them up and throw them away when you’re done.
Only, with our bare-metal cloud, there is no hypervisor. The server nodes aren’t sliced and diced by the likes of KVM and Xen. Instead, each node is dedicated to you. All of the disk’s blinking lights are yours. There’s no noisy neighbor problem or co-tenancy issue and no virtualization overhead.
I think it’s also worth pointing out the confusion and overlapping usage around “bare metal” terminology in the industry. A true bare-metal cloud delivers on the agility (and the shift in business models) that the cloud brings. Many providers are cloud-washing dedicated hosting, which is often sold on a term contract and offers zero automation or elasticity. That’s not what is happening here.
We think bare-metal cloud has a lot of interesting implications, and we’re not alone. Before Voxel was bought by Internap, it was one of the first companies to make dedicated, bare-metal servers available over an API in 2009. Soon after, many of our competitors (including Softlayer, recently bought by IBM) did the same thing.
As I mentioned above, we also understand the value of and offer a fully-virtualized cloud. There’s no doubt that the hypervisor gives you interesting options, and it’s a big enabler. We leave the choice with our customers as to whether they want their instances to be virtualized or not.
They can make that decision on a per instance basis, depending on the best match for their specific application and workload. And, they can use the same API, IP addresses and images regardless of whether the server is virtualized or not. A lot of them choose to deploy a beefy bare-metal server (loaded to the gills with SSDs) for high-end databases. Do they suddenly turn into “server huggers” if they do?
But don’t just take my word for it. OpenStack has a top-level project that’s focused on bare-metal cloud. The reason? Because for some workloads, it makes more sense. A lot more sense.
Admittedly, it’s early days in OpenStack land and the project is just getting rolling. Even in the latest stable release of OpenStack (Havannah), they use the term “hard hat required” with regard to bare-metal functionality. Nonetheless, we are actively working on launching the next version of our bare-metal cloud platform that will be largely OpenStack under the hood. We think it’s one of the most interesting and fast-moving projects in the infrastructure cloud space. We’re adding a lot of our own value on top of OpenStack, including expertise and technology around bare-metal cloud garnered over the last 4 years.
How am I going to break the bad news to our engineering team and all of the bare-metal OpenStack developers in the industry that we are all “server huggers”? Creating so-called “cloud” server instances that aren’t virtualized? Blasphemy!
At the end of the day, I’ll put an Internap bare-metal cloud server up against the equivalent price-point Amazon instance any time.
It’s not a religious argument – it’s all about the right tool for the job. This is the reason for our broad approach to hybrid IT infrastructure.
Ben’s article was well-written and provocative, I’ll give him that. Maybe he should consider trying his hand at fiction instead.
