Problem solve Get help with specific problems with your technologies, process and projects.

Pros and cons of a non-VM-based IaaS model

Building an IaaS cloud without using VMs has some limits. The ability to progress to a mixed-service cloud can help IT teams ignore potential issues.

Even though Infrastructure as a Service is often described as a predecessor of the virtual data center, not all IaaS platforms are built on virtual machines. Using a non-VM-based IaaS model for your private cloud could be a key strategy to take it to the next level -- a mixed-service cloud that combines IaaS with SaaS and PaaS.

Using a non-VM-based IaaS model for your private cloud could be a key strategy to take it to the next level -- a mixed-service cloud.

Most virtualization software uses a hypervisor to partition a server into VMs, each of which run their own copies of the underlying OS, middleware and applications. When IaaS is based on this virtualization model, a cloud director allocates images and resources to each VM. Because each VM is independent, any application that can run on the native hardware can run on the VM. This is the strength of virtualization-based IaaS.

But VM-based IaaS also has limitations. As cloud-specific applications are developed, there is little reason to write them in a way that enables VM hosting since they do not depend on virtualization. service-oriented architecture (SOA) as well as multitasking and multi-threading principles can be used to write cloud components that run under an OS, but don't require that the OS or middleware be duplicated for each.

How do you create a cloud platform for cloud-specific software while offering IaaS? The answer is to create containers, virtual environments or “jails.” For the purposes of this tip, we'll use the term “virtual environments,” or VEs.

Using virtual environments to build OS-based IaaS clouds
VEs are partitions in a host OS that isolate guest OSes and applications and allow them to run in a multi-tenant environment. Unlike normal threads or programs running under multitask support within the host, guest VEs are protected from each other, though not to the degree they would be in hypervisor-based virtualization. Unlike hypervisor-based virtualization, which supports nearly any OS or middleware, VEs expect all guest OSes to be the same as the host OS. While this reduces overhead, it also limits flexibility, making it critical that you carefully select the right IaaS platform to ensure compatibility with the full range of existing and future apps.

The most popular VE-hosting software platforms are OpenVZ and VServer for Linux, FreeBSD Jail for BSD Unix, Container/Zone for Solaris (including Open Solaris) and the VM Role supported by Microsoft Windows Azure. Oracle and Joyent both provide a customized, commercial version of container/zone platforms. Joyent's SmartOS combines hardware virtualization (Xen) with Solaris Zones support; the company bases its offering on the large-scale data model Solaris ZFS.

Problems with VE-based IaaS models
It's tempting to see a VE-based cloud model as the ultimate cloud strategy, at least for IaaS and mixed-model cloud services. However, at least some of these cloud models create management complexities and cloud security concerns as well as complications with stateful applications that are being constantly updated.

The VE-based IaaS model does have some downsides, but none are serious enough to completely disqualify it.

Management complexity. Cloud management can be more complicated in VE-based IaaS models, despite using a single OS. None of the OS-level, non-VM strategies for IaaS will replace the cloud control function unless all cloud VEs are on a single machine, which is highly unlikely. You still need to integrate a cloud control software layer that will imitate a hypervisor, such as those provided by open source cloud providers such as Eucalyptus, OpenStack, Nebula and others. Because more users build VM-based IaaS clouds, it can be difficult to find information on how to perform this integration. Research existing examples of VE-based IaaS setups and evaluate how this affects other operations.

Security issues. A major presumption of IaaS is that applications are hosted on what is effectively a virtual server, but that’s not always true in the VE model. Virtual machines are ships in the night; they have minimal interaction with one another. VEs, on the other hand, introduce communication among applications about resource use and performance. However, this can leave VEs susceptible to cross-application cloud security issues. It's important to know these security issues beforehand and ensure they won't impact future service plans.

Stateful applications. Failure modes are a concern in any hosted service. VE-based clouds run the risk of host OS failure, which can bring down all guest OSes. Because the hypervisor in VM-based IaaS models has minimal functionality and less logic, the risk of failure is lower. For example, application data with a Windows Azure VM role won’t remain persistent if that role fails; VM applications should be based on RESTful stateless principles to avoid data loss.

The VE-based IaaS model does have some downsides, but none are serious enough to completely disqualify it. And the benefits -- facilitating coexistence with or evolution to a multi-service model that combines IaaS, Platform as a Service and Software as a Service – are great enough to help enterprises deal with its challenges.


Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982.

Dig Deeper on Infrastructure (IaaS) cloud deployment strategies