VA

Moving ISV applications in a Sales 2.0 world -- What a difference an “A” makes

Mon, 2011-05-09 08:26 — Greg O'Connor

Innovative technology deserves new words. Back when “EJB” was the new shiny, bright center of Java standards, I was part of the team that created “ESB” – both the moniker and the market. It was a natural for me to christen AppZero’s patented, OS-free server application virtualization technology “Virtual Application Appliance” (VAA). Why VAA? To compare with, and contrast against, the well-established “Virtual Appliance” (VA) concept. To both build on the known and to differentiate from it.

The compare part is that, packaged either as a VA or a VAA, applications travel fully configured and arrive at their destination ready to run – for instant deployment. The contrast part is that, whereas VAs travel on a Virtual Machine (VM) complete with a fully functioning OS, AppZero VAAs travel OS-free.

The difference that the contrast makes? Let me count the ways:

An application packaged as a VA of 40+ Gigs is going to be 10 to 100 times smaller as a VAA
Sending a 40+ GB file over a network with an average file transfer rate of 1 GB every 4 hours – is measured in days; AppZero’s VAAs will most likely make the same trip over lunch (see my last blog: (Size matters for apps on the move: physics for ISVs and IaaS providers)
Sending Microsoft OS around in VA/VMs is pretty much prohibited by Redmond-crafted license agreements. For that reason, of the 1667 matches found on VMware’s Virtual Appliance Marketplace today, you will find many, many, many Linux based VAs. Windows? Not one.
Sending applications that run on Microsoft OS, in AppZero VAA OS-free packages, is quick, easy, and Microsoft compliant.

Put another way, AppZero VAAs let Microsoft-based ISVs deploy their applications across a network for instant PoCs and demos. Something they can’t do with VAs. And, while we’re in the VMware and Microsoft neighborhoods, let me mention that AppZero VAAs are hypervisor and cloud agnostic - happy on any machine (physical or virtual), anywhere (datacenter, private or public cloud).

Which brings me to Sales 2.0. Debate over the definition of Sales 2.0 fuels blogs. But, by any name, successful sales for ISVs in today’s technology-shaped economy require that an application be readily accessible to its buying public, at a click of a mouse.

When an ISV uses the OS-free AppZero VAA approach, the application arrives swiftly, and ready-to-run – requiring no installation. The potential customer sees hassle-free implementation and can concentrate on using an application – not the laborious process of installation and configuring it.

And that just makes plain old-fashioned good business sense for ISVs. I’ll take a look at some of the specific Sales 2.0 benefits in my next blog. In the meantime, check out our ISV Accelerator http://www.appzero.com/content/appzeros-isv-accelerator-program, or join us for a brief webinar Thursday, May 12^th: “ISVs: Provision your App in a Snap for Labor-free PoCs”

I’m always looking for ways to sharpen my discussions. So, if you have thoughts on this subject, drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor

Add new comment

VA and VAA: what a difference an “A” makes

Wed, 2009-12-09 11:03 — Greg O'Connor

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 Whos 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.)