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: William Schmarzo, Pat Romanski, Gilad Parann-Nissany, RealWire News Distribution, Josh Mazgelis

Related Topics: Cloud Computing, Virtualization Magazine, Microservices Journal, Virtual Application Appliances

Blog Post

AppZero Arms ISVs to Face the Dark Side of Freedom

(Warning: this blog post comes with a pop quiz)

Hypothetical question:  If a big ISV were to fall in love with AppZero technology but turn out to be a VMware sibling, do I have a.) a great opportunity, b.) a giant time sink, or c.) a competitive trap on my hands?

I love talking with Independent Software Vendors (ISVs) about how Virtual Application Appliance (VAA) is the way to go for delivering applications to their users.  It's true.  It's fun.  It's revolutionary.

Last week my CTO and I were in a room with 5 engineers who were describing the challenge of supporting close to 10,000 customers on a software application that does replication for mirroring, backup, business continuity, and other such mission critical functions.  Their comments went pretty much like this:

  • "Every day we have an install that doesn't seem to work"

  • "We had Microsoft and InstallShield on a call with a customer last week"

  • "Files are sometimes in use during installation and then don't get updated"

  • "I have to visit tech support everyday in person now"

  • "I hate when a customer upgrades their environment"

  • "Maintaining the customer base is very expensive"

It is hard for an ISV of any size to simplify what is, by nature, the very complex task of delivering, installing, and upgrading their applications - with of course the ability to rollback an application if an upgrade doesn't work as planned.

What makes it so hard?  The dark side of freedom.

Math on the dark side

It turns out that a customer's environment can have almost as many combinations as does a lottery ticket:  Base operating system with major/minor versions, hypervisor, clustered, storage configuration, anti-virus, java or .net runtime, back up, security, update manager, monitoring system form the top level 11 environmental variations that an enterprise application will have to run in.  A conservative estimate about how many different products a set of customers might have across these 11 dimensions begins to highlight the problem for ISVs.

Let's do the math.  If a set of customers, on average, have 4 different types each per dimension (for example on the OS dimension: W2003 32, W2003 64, W2008 64 R1, W2008 64 R2) we can estimate 4 to the 11th power or 4,194,304 combinations ....Even a much more concretive software infrastructure stack of 6 dimensions generates 4096 combinations.

Give or take any number you'd like, leaves a very long tail of what successful ISVs face every day.

.... back to my merry band of ISV engineers

Now, the engineering group I was talking with last week have it a lot easier.  Because their product has only existed for 8 years and there are only 10,000 customers, each with an average of 9 installations, these engineers face only 90,000 unique combinations....way better than that theoretical math above.

The team has investigated the Virtual Appliance (VA) approach, but they do not want to own managing the OS.  They see the same problem occurring once a customer inserts their software support infrastructure.  And, because 8,000 of their 10,000 customers run on Windows, the VA approach is dead on arrival anyway.  Microsoft does not allow ISVs to ship their OS as a VA.

Whatever will they do to slash this complexity and beat the dark side of freedom?  (grin)

The plot thickens and a pop quiz quickly follows

This prospect downloaded our software from the AppZero site, created a VAA (as opposed to a VA) and is now busily demonstrating the benefits and ease of use to his superiors.

Now, let's say - hypothetically - that his superior owns nearly 80% of VMware.  Today VMware's Thinapp can not work for server-side applications. And AppZero does.

Here is my challenge and the pop quiz.

Question:  Do we continue to help the prospect?

Answers:

a.      Yes killer early adopter customer sees big win.

b.      No - they're just gathering competitive information to feedback to the sibling ship

c.      Yes position it as complementary and survive the process to get a win, and maybe even a partner on the Linux front

What would you do? Drop me a line at grego [at] appzero [dot] com. I could use some fresh ideas about how to turn this David and Goliath situation into a win.

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.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.