Much has been written about applications that are stranded on Solaris 2.6/7 OS and rare-as-unicorn hardware. In fact, much of it has been written by me. My trusty biz dev leader suggested that I take an ROI run on the topic in my next blog .... which is this one. But I just can’t bring myself to do it. 

Why? Because I can’t see building an elaborate spread sheet showing how AppZero is the best option, when the choice is a no brainer that my 7 year old son could make. 

Let’s play the model out and you tell me if a spreadsheet would help clarify the choices:

1.      Magical thinking:  Just close your eyes and do nothing. The do nothing option has worked this far for you, hasn’t it? And, in the statistically guaranteed eventuality that the hardware fails, you have a set of Bond-like people (James) ready to jump in with rapid-fire duck tape. After all, unexpected events only happen in the movies and to your other IT friends. You’re on a lucky streak – so when you look in the mirror and ask, “Do you feel lucky?”  The answer is “yes”. Your compliance team will not find you amusing.

2.      Call in the cavalry: Bring in a team of pros and replace the apps with brand, shiny new ones. IBM, among many others, will gladly show you a multiyear and multimillion dollar path to a SOA base set of services to replace the critical but aging back office services. In the meantime, we suggest you budget a week to move your old apps to new Oracle hardware via AppZero where they can safely run for the duration of the new development project. 

3.      Binary compatibility: Port your application using a set of tools authored by the guys from TrecLogic, now part of Zylog. The tools will give you some insight into how difficult this path might be. The challenge becomes clear when the code has been lost, or when a 3^rd party component is no longer available or has substantially changed. (See option #4 if this is the case). Even when it looks like a go, you’re not necessarily in the clear. We recently saw a case in which an app used a register as a return variable placeholder, which Solaris 10 now uses for a completely different purpose. Ooops. The fact that this problem didn’t rear its ugly head till regression testing made for a very expensive failed porting effort.

4.      AppZero scoop and move: This approach can be run up the flag pole and be operational in 48 hours. No recompile, no source code. Move your mess for less – time and money -- and run on reliable servers. Benefits are long; time and risk is short. 

All fun, games, and references to my 7 year old aside, business applications that have stood the test of time and are providing a necessary function for the business can be modernized in an extremely short period of time using AppZero. We offer a simple, pragmatic, tactical approach to saving money and ensuring that these systems are on a solid foundation now and into the future.

I’ve never claimed to be a marketing genius, but I think “move your mess for less” trumps spreadsheet here. I rest my case. Feel free to cast a vote.

I am always looking for a way to communicate better and cut to the heart of the discussion.  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.

(warning: this blog 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 11^th 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.

I do dream in color, not always vivid color, but color just the same. Today, I was awakened by one of my 5 boys in the middle of a great dream about the future. In my dream, I was in a big white room just as a door was opening and someone was about to walk in. Who was that? That’s when I was awakened.

Don’t you hate dream interruption? Or Idruption? Quick note, I heard the iPad comes with an Idruption finisher, those guys at Apple are so innovative.

What I do recall from my dream was that it was the summer of 2012, and Jeff Bezos, Paul Sagan and I were celebrating the 2 year anniversary of the merger of our three companies. There was a lot of talk about how 50% of the Fortune 1000 had shut down their data centers and moved all their operations onto our Dream Cloud. So much for that Gartner prediction –“By 2012, 20 percent of businesses will own no IT assets.”  The other thing that was clear from the conversation was that Dream Computing as a category had completely replaced the term Cloud Computing.

Akazon’s (the combined company’s name) market capitalization had just crossed the trillion dollar mark. We had over 10 million physical machines or 10 billion virtual instances all around the world thanks to the new Dream chip from Intamd. Close to 70% of the internet traffic was flowing through the Akazon Dream Cloud. The year had started with Paul convincing the board to turn down Eric’s request for us to acquire Google. Paul’s core argument was that Google’s search and ad businesses were going to be replaced by our Dream fulfillment engine. The search-to-decision-to-Dream fulfillment evolution had taken hold. We had solved the issues in China and had a commanding share in this huge piece of the world market. Eric, Larry, and Sergey were not happy but it was clear they were becoming a legacy supplier, and we found a dream number even more magical than √2.

2011 was very busy for Jeff as we divested our online shopping division. I was really surprised Jeff took the lead on this and got such a great price from Larry at Oracle (he never really believed in Dream Computing or its predecessor Cloud Computing). By selling databases, applications and hardware direct in their new online store, Larry had replaced almost his entire sales force. It did do wonders for their margins and profitability.

2010 had been the year in which the Dream was defined. The public Dream, the private Dream, the hybrid Dream, and the enterprise Dream were now clear to the world. Where the environments are located, security concerns, how to move applications from the enterprise to the Dream and back again were completely nailed. The Dream economy was born and unemployment was under 5%. As a side note, national health care had not come to a final vote.

Yes, 2010 was the year Dream Computing was born. The market understood what Cloud Computing (infrastructure as a service, platform as a service) was. Amazon was leading the pack, delivering the self-service, pay-as-you-go, resources-on-demand, utility-in-the-sky. Topping the 1 million developers mark. The challenges to Cloud Computing adoption were surfacing for those in the business.

Secure distribution, and moving existing applications unchanged to the cloud were beginning to slow the paradigm shift down.

Akamai saw competition coming from the roll-it-yourself CDN developers using geographically-distributed clouds, and the world saw more and more content being part of everyday applications. Not as demanding as streaming a Victoria’s Secret video, but delivering more content to the edge faster was a foundation of Dream Computing. It also occurred to Akamai that they had a ton of compute horsepower for serving up those images to millions of eyeballs focused on Heidi Klum and the Black Eyed Peas, which they could sell during the other 364 days and 21 hours. Talk about a spiky workload and over-provisioning. Why not just build out the data centers Akamai had around the world and extend them to have the capabilities like those in Amazon? With global real-time distribution, low latency, and the ability to limit network attacks as the next layer added on to that old concept of Cloud Computing, the transition was underway.

The last piece of the puzzle was the application containment and provisioning provided by Virtual Application Appliances (VAA) from AppZero. The ability to scoop up and move existing applications to any of the Dream Computing nodes, or across any node and back again, was the grease that finished off the legacy concept of Cloud Computing. Moving just an application, not the whole machine, and being able to determine what has changed from provision to provision, made utilizing the dream fabric in the ether easy. Separating and isolating the application or workload from the OS became a “duh.” The death of installing applications and commingling them with OS had gone mainstream with dynamic provisioning replacing standard operations. VAA had become a movement that is now being taught in high schools today. Whoever came up with installing applications anyhow?

Dreaming about Dream Computing  – Now I remember how it ended. It was Paul Maritz at the door. He was there to get us to buy Zimbra from him. Funny how the pioneers and thought leaders of today become a distant legacy dream so quickly. I recall sending him over to see if he could sell Zimbra to Apple. It would be a good service for their iDream offering that we run and manage for Steve while Paul focused on the Bed Bath and Beyond business.

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

We've all been there.  Minding our own business in a local establishment, when a discussion's heat rises to the level of a sporting bet.  Sides are chosen, money plunked down, combatants await the reveal.  Other than adult beverages, the thing these bets seem to have in common is that the winning fact generally runs against commonly held assumptions.

Here's a winner for you:

Q:  What company "invented" virtualization technology?

A:  The long defunct Burroughs Corporation first brought mainframe virtualization to market in the 1960s.  But it was not until the then laggard IBM brought it to their 360 line in the 1970s that the concept was legitimized.

I'm willing to make this little bet with you:  Most people of a certain age are more than willing to bet folding green that IBM 'invented' virtualization.  Gen-any-letters will bet VMware with confidence.  You will win either way.

Today's burgeoning virtualization market is a different story.  And in that story, VMware is the dad.

Phase 1 - Core virtualization infrastructure

Founded in 1998, VMware ruled the virtualization roost free of competition, growing to $1 billion revenue in record-breaking time.  So the hypervisor entered mainstream IT.  Competition from open source Xen and Microsoft's Hyper-V fuels innovation and evolution in the virtualization category.  Regardless of vendor flavor, today's hypervisor comes in two forms:

• Native - hypervisor software runs directly on a host's hardware acting as a hardware controller and a monitor of guest operating systems. The hypervisor is a layer of abstraction that separates the hardware and the guest operating systems.
• Hosted - hypervisor software runs within a conventional OS as a distinct software layer. Guest OS run at the third level above the hardware.

The over-provisioning of servers that otherwise commonly run at less than 10% utilization in datacenters means that Hypervisors are cost-slashing, server consolidating no brainers.  But they are not a panacea.

Enter server sprawl.  Questions of security and compliance, mobility and maintenance.... Real life.

Phase 2 - Management virtualization infrastructure

So a whole marketplace springs up to surround the virtualization world with tools and capabilities to exploit the potential, fill in the blanks, shore up the weaknesses, and counteract the unintended side-effects of the proliferating technology.  It's an exciting phase bursting with startups and speculation, market confusion, and acquisitions.

Companies start-up to monitor, automate, optimize, and otherwise manage this complex frontier, eager to make their marks before VMware wakes to their niche.  In the meantime, the usual suspects BMC, CA, HP and IBM's Tivoli mix invention with acquisition to round out their traditional strengths mapping to datacenter and cloud realities.  Back in the general market, every vendor is slapping the word "Cloud" onto their offerings whether hot off the press or dating from the Paleolithic Age.

Phase 3 - Paradigm virtualization enablement

When a new technology opens new frontiers, innovators are quick to see, exploit, and exhaust the potential.  Virtualization has entered this phase as Hypervisor technology and its phase 2 outgrowths have reached their natural limits.  Case in point: server-side application virtualization.

It was both clever and natural for innovators to leap upon accepted hypervisor technology to virtualize applications.  Hence we have the virtual machine (VM) derivative, the virtual appliance (VA), which packages an application with all of its dependencies and only the itiest, bitiest, piece of OS absolutely necessary to get the job done.  Pragmatists charged with virtualizing server applications using a tool designed to virtualize server hardware, enabled the workaround with the concept of "Just-enough OS" - JeOS.

Marketing kudos not withstanding, any OS is too much OS when it comes to virtualizing server-side applications for complete mobility to and from and around the clouds and datacenters that make up a dynamic IT environment.  I can't say it any better than Chris Hoff did in his September 25th Rational Survivability blog entitled "Incomplete Thought: Virtual Machines are the Problem, Not the Solution".  Speaking of VMs, he says:

"There's still a pile of crap inside 'em.

What do I mean?

There's a bloated, parasitic resource-gobbling cancer inside every VM.  For the most part, it's the real reason we even have mass market virtualization today.

It's called the operating system."

Asking, "But wait, isn't server virtualization the answer to that?", Chris goes on to answer:

"The approach we've taken today is that VMM/Hypervisor abstracts the hardware from the OS.  The applications are still stuck on top of operating systems that don't provide much in the way of any benefit given the emergence of development frameworks/languages such as J2EE, PHP, Ruby, .NET, etc. that were built around the notions of decoupled, distributed, and mashable application 'fabrics'.

Every ship travels with an anchor, in the case of the VM it's the OS. [emphasis mine]"

Beautiful.  AppZero is not an extension of the hypervisor technology.  It is a new paradigm inspired and legitimized by that market's growth, enabled by distinctive and different technology.

With it, you can create one gold image of an application - or a piece of an application, like SQLServer or Oracle DB -- and then provision it to many server instances in a data center .... Or numerous data centers; to many server instances in private or public clouds, disaster recovery sites ...

One gold image - so many destinations.  How is that possible?

Because in the AppZero paradigm, there is no - zero - zilch - no trace whatsoever of any OS component.

Anchors away.