Decouple an App From the OS Before You Move to the Cloud

Virtual Application Appliances

Subscribe to Virtual Application Appliances: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Virtual Application Appliances: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

VAA Authors: Destiny Bertucci, Ray Parker, William Schmarzo, Pat Romanski, Gilad Parann-Nissany

Related Topics: Virtualization Magazine, Desktop Virtualization Journal, Virtual Application Appliances


VA and VAA: What a Difference an “A” Makes

Comparing VMware’s virtual appliance (VA) approach with AppZero’s virtual application appliance (VAA)

Virtual Application Appliances on Ulitzer

Cloud Computing Expo - So are we talking tomayto/tomahto or apple/orange here?  Actually, when we compare VMware's virtual appliance (VA) approach with AppZero's virtual application appliance (VAA) it's really a lot more like apple/orangutan.  Not better and worse, winner and loser, but different in type and kind and purpose and optimal use.  A tectonic shift.

Before I proceed to explain, I'd like to point out that I'm on record as being a VMware fan.  (See earlier blogs, "VMware's Genius," "The birth of virtualization" and "The Next Big Cloud Thing: VMWare's Virtual Platform Stack".)  VMware's VA approach has enjoyed real market acceptance for practical reasons, which the company relates as: reduced development and distribution costs; accelerated time to market expanding customer reach; and increased security and control - for both hardware appliance vendors (pre-fabricated product) and software developers (pre-configured package).

In this approach a virtual machine (VM) and an application, complete with all necessary parts of the OS, are packaged into one self-contained virtual appliance (VA).  All of these parts are encapsulated in a little, self-contained world of its own free to travel through space like Horton's Who's all in Whoville.

VMware promotes VAs on its appliance page with the number growing daily.  Today, as I write, it is 1,308; yesterday it was 1,282.  Who knows what it will be when you look.

All Linux.

Yes, all Linux.  Microsoft licensing does not allow for redistribution of the Windows OS.  So this whole VA idea is only good if your application is based on Linux.  But if your organization is one of the zillions who have bought into the Redmond way of life, you can't use VAs without rewriting what you have.  Not likely.

But here's a dirty little question - and I mean no disrespect - Linux or not, why would you want to ship the OS with your hardware product, software package, or data center application?  System admins hate this practice.  They like to maintain clear lines between who owns what, where, and who does what, when.  VAs totally redraw those lines.  I can tell you that the folks running a data center don't want a packaged application vendor patching, up grading, and otherwise maintaining the OS, networking, and management tools.  And, by the way, packaged application vendors aren't wild about owning all OS variants either.

Now, granted, VMware owns a lot of real estate in the data center, but VAs don't travel across hypervisor environments.  So if a company throws Hyper-V, Xen, or KVM into the mix they will need a different VA for each - and they will have no mobility between those environments.  If you're a software provider, you'll need to package your app as different VAs for each VM provider.

And speaking of mobility .... What if you want to move an application to the cloud?  Most cloud providers don't use VMware's VMs, so you'd need a different VA.  In fact, you'd need a different VA for each cloud - Amazon, GoGrid, Rackspace etc.  Who is responsible for this refactoring?  There is no seamless way to move your (Linux-only) apps between clouds in anyone's VA.

The culprit in this story is not VMware, it's the necessary inclusion of the OS - in however small a measure - in the VA.  It's the nature of the VA beast.

AppZero's VAA, by contrast, encapsulates a server application with all of its dependencies - but with zero OS component.  Zero.  Complete mobility across servers - physical or virtual (any VM) - to and from datacenter and clouds at will with no rewriting or packaging required.  And because there is no OS component, we do Windows.

So, if you have a spare 10 minutes on your hands, wander down to wherever your sys admins live and ask them how much they like VAs.  My bet is that they really don't like black boxes in their province.  And your application folks don't like it either.  Maybe they don't know there is a strong alternative ... yes, VAAs.  If not, you have good news for them.

What a difference an "A" makes.

(More on what VAAs can do in a blog to follow.  )

Follow Greg O'Connor on Twitter @gregoryjoconnor

More Stories By Greg O'Connor

Greg O'Connor is President & CEO of AppZero. Pioneering the Virtual Application Appliance approach to simplifying application-lifecycle management, he is responsible for translating Appzero's vision into strategic business objectives and financial results.

O'Connor has over 25 years of management and technical experience in the computer industry. He was founder and president of Sonic Software, acquired in 2005 by Progress Software (PRGS). There he grew the company from concept to over $40 million in revenue.

At Sonic, he evangelized and created the Enterprise Service Bus (ESB) product category, which is generally accepted today as the foundation for Service Oriented Architecture (SOA). Follow him on Twitter @gregoryjoconnor.