Reader Question: Cloud vs Virtual Farm?

Date March 16, 2012

I really enjoy getting mail from readers. I know that I sometimes don't answer in what you might consider a timely fashion, but that's just because you're not thinking geologically.

On occasion, though, I do get some downtime to discuss things with my readers, and the other day, I got a good question that I don't think I've written about, so I thought I'd share with everyone else.

Here's the email:

Matt,

This might sound like a nooby question, but I will sally forth...

What is the difference between using a Private cloud solution and a Virtual Machine environment?

I am planning to update my test environment, and if possible use a personal Could based solution for testing various software platforms. Based on my limited knowledge of Cloud based platforms, The VM and Cloud based environments are pretty much the same, except when you shutdown an instance of cloud based machine, it loses it configuration.

I have a VM environment right now, but would like to be able to provision new machines at will (depending on hardware restrictions), but would like to keep some of these machines as configured.

Thanks in advance

Here was my answer:

Hi!

I don't think it's a "nooby" question. It's one that a lot of people struggle with, because there isn't a clear definition, and the marketing in the industry tries to confuse the matter at every turn.

I've thought about it pretty extensively over the past couple of years, and I actually have a definition in my mind of "Cloud" that I think is logical and based on the origination of the term. Remember that the word cloud came from network diagram icons that indicated, for the purposes of that particular diagram, it didn't matter what specific machines or software filled that particular space, only that there was a resource available that provided a service. At its core, it is a term of abstraction.

In my mind, cloud is still a relative term. Amazon's AWS cloud is absolutely not a 'cloud' to the people who work on the discrete components of it. It *IS* a cloud to you and I, though, because when we interface with it, we see no distinction between the particular constituant machines. We only see the interface to the API that controls the creation and management of the resources that are hosted within the cloud. We don't know which actual machine or machines inside the Amazon cloud are handling our resources, and we don't care.

It should also be noted that there are different *types* of Cloud, too, and it all depends on what you want to abstract. If you want to create entire machines and network devices, there is Infrastructure as a Service (IaaS). Sometimes, you just want to write software and not worry about administering the web server that it runs on...then you want a Platform as a Service (PaaS). It's also possible to just want to rent a service, like hosted Email, in which case you want Software as a Service (SaaS). But since you mentioned building virtual labs, IaaS is what we're talking about here.

So, this brings us to your question about a private, internal cloud. It IS possible to build an internal cloud such that you can interface with it in an abstracted way, never knowing or caring (other than for debugging purposes, since you're not only running things on the cloud, you're running the cloud itself) where the resources are hosted. But for the immediate future, its almost always overkill in a smaller shop.

The Eucalyptus Project is devoted to creating private cloud platforms that can be administered using an abstracted API - in fact, it's the basis for the new HP Cloud that's currently in beta.

That being said, is it worth setting up for a lab environment? I guess the answer is, "It depends". It would be an interesting exercise to build a cloud, just for the sake of doing it, but only you know if you have the number of machines available with the (admittedly low) required resources.

It may be possible to configure your current virtual environment to deploy new images quickly and without much manual intervention, but without knowing more details, I can't be sure of the implementation. I would, at the very least, research the API for your virtualization platform and check out something like Cobbler.

I hope this answered any questions you have. Please feel free to follow up if you have any other questions. I'm happy to help.

Thanks!

--Matt

Confusion and misconceptions about what a "cloud" is run rampant because, for a very long time, it was essentially an undefined marketing term. As the idea gels, we get a better idea of what to expect from the service providers.

Also, if you'll note that I said that running a private internal cloud is overkill for the immediate future. That's because I suspect more and more software will be developed with the inherent idea of "cloudiness" built-in. I'd be surprised if software like Tomcat didn't have server abstraction built in during the next couple of releases, where you install Tomcat on a few machines, and then you deploy your application to a central controller, which then deals with the "cloud" instances. There are already commercial services for this, but there's no reason it shouldn't be added into the software itself.

Likewise with an abstraction layer above KVM, so you just launch new VMs onto an array of hardware, and you don't know or care which machine it runs on. This is what Eucalyptus does, of course, but right now, Eucalyptus is exceptional for doing so, where as in a few years, it's going to be par for the course and built in. More and more administration will be done through APIs, I'm telling you...

Of course, I could be wrong! Let me know what you think in the comments below.

One Response to “Reader Question: Cloud vs Virtual Farm?”

  1. SDK said:

    Simply put, it's the interface to the end user that makes the difference. The technology and functionality behind the interface is essesntially same.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*