Software as a Service (SaaS) is the darling of today’s real world, enterprise-impacting cloud computing use cases.  Industry analysts and research firms are tripping over each other extolling mega-CAGR for SaaS, with the 451 Group going so far as attributing 75% of PaaS spending for use cases that are attached to SaaS deployments. 

In its 2011 research report “Cloud Computing Takes Off,” Morgan Stanley is bullish on the future of PaaS stating, “The low capex requirements, robust cloud enablement and rapidly improving developer toolsets are significantly lowering the barriers to entry for new application development [emphasis mine] – both in terms of cost and time to market. 

Great.  So the future is bright for new application development heading to the cloud. What about ISVs who have existing applications? Driven to the margin-eroding SaaS model, ISVs frequently find that their largest customers are not willing to surrender the on-premises option. 

The SaaS/on-premises tension sets up a complex series of challenges for the ISV including questions of business models, maintenance of multiple product versions, and updating of software to name a few issues. With apologies to last century’s poet Robert Frost, smart money may rest on the ultimate victory of SaaS, but there are miles to go before on-premises sleeps. 

There is – and will continue to be -- a lot of business in existing applications and the on-premises model.

In future blogs I’ll explore ways ISVs can use AppZero to navigate this changing market. But, for now, I’m offering a white paper about the universal need to successfully sell your software.  Titled AppZero Use Case for Software Vendors: Sales Cycle , this paper introduces the ways AppZero can strip the labor required to configure and implement your PoCs and demos – whether on site or in the cloud. Resulting business gains include:

• Slash configuration and installation time to zero, decreasing the cost of sales, improving PoC quality, maximizing SE resources, and increasing win rate with associated revenue
• Easily deliver complex systems fully and accurately pre-configured
• Improve customer experience and perception of quality and competence
• Focus high-skilled technical service professionals on high-value services rather than on low-margin, repetitive, labor-intensive work that can be automated
• Reduce time to value for customers and speed time to revenue

The intended audience for this paper is anyone responsible for generating software sales revenue, supporting a software sales cycle, or implementing software for a customer.  Independent software vendor (ISV) sales, professional services, and sales engineers will be particularly interested in how AppZero software can directly impact the sales cycle, while IT professionals will find advantages in the time saved throughout the product lifecycle.

I am always looking for a way to communicate better and cut to the heart of any discussion. So, if you have thoughts on this subject drop me a line at GregO {@} Appzero {dot} com or tweet me at @gregoryjoconnor

Moving enterprise apps to the cloud? Check out this 2-minute video.

What do a day at the beach and bringing absolutely unique technology to market have in common?  They are two of my favorite things.  Half educator, half evangelist, I spend my days carving out the difference between virtualizing server applications (AppZero) and virtualizing the servers they run on (Hypervisors VA/VM). 

I’ve been here before.  In 2000, I had the opportunity to gather some of the best and brightest people together as I co-founded Sonic Software with Bill Cullen (product brain and Sonic CTO; now AppZero CTO).  At the time, we saw a market-making opportunity to take the AppServer world standards (formal/XML or market driven/Java) and apply them to the EAI market.  The first ESB to market -- Sonic XQ (Xml Queue) -- was shipped in February 2002.  Sonic itself was bought by Progress Software.

In an entrepreneurial act of déjà vu, I’m at Progress Software’s Revolution conference in Boston.   I am struck by the irony of how very much I could have used the technology I now bring to my fellow software executives, who are struggling to balance revolution and cost. 

If you sell software, you’ll appreciate this observation

Growing Sonic Software, we faced two universal hurdles that significantly impacted our business – and that of pretty much everyone who sells software:

1. Winning or losing – labor-intensive demos, proof of concepts (POC), evaluations, and trials had a huge impact on our growth rate
2. Installs that did not go perfectly, resulted in fire drills, lost business,  and a sharp dip in customer confidence

(These facts of software life are some of the acute pain points we solve here at AppZero.)

At Sonic, we were often faced with a 5 day evaluation for a prospect:  1 day to setup our software on their environment, 3 days to do the work they requested, and 1 day show off the results.  When the 1^st day did not go as planned, we always lost.  

Always.  Every single time. No exception.

A cautionary tale:  If you sell software, you are guilty until you prove yourself innocent

Oh, and here’s how I learned that an imperfect install can still bite you long after you have successfully fought to win a customer (in this case a market icon).  A full year after having won the business and implemented our product at the New York Mercantile Exchange, I received a call from the CIO.  He had some new concerns, “Sonic messaging system appears to slow down under load”. 

Arrgggh.  How could this be possible?  Sonic was ahead of its time with elastic scaling, continuous availability, and best in class through put.  This could not be correct.  As it turned out, it wasn’t. 

But determining and fixing the “root cause”  took 6 labor-intensive weeks filled with tons of anxious phone calls, numerous pointing fingers (with chewed fingernails), and a couple of flights to NYC by our top troubleshooter .  Life got very unpleasant before it returned to good.

The culprit? A bug in the Java Virtual Machine (JVM) and Java Runtime Environment  (JRE) that would not do garbage collect (free memory) under load.  Now, long before that fateful phone call, we at Sonic knew all about this issue.  We had documented it, changed our install and packaging to make an easy fix. 

(Cue scary music) But then the customer got involved.  

Someone, somewhere along their line had installed their company’s “certified” version of the JVM/JRE thereby putting our product and reputation at risk.

“It wasn’t my fault” just doesn’t matter.  It took a long time, involving many smart people to find the 2 files that needed to be changed so that all the oil futures in the world could once again flow over the Sonic messaging system.

Morale of the story: Once a customer has your software, things happen.

If I had a time machine, I would bring the AppZero product to my(then)self 

AppZero not only solves the PoC puzzle for software vendors, but protects their Windows and Linux server applications from customers.  We make it possible for applications to be pre-installed, pre-configured and then provisioned onto a physical or virtual OS -- in minutes, perhaps over lunch.  

This capability effectively changes the math around POCs in a big way: we reduce the install, setup and configuration time to zero.  If I had been able to use AppZero at Sonic, I would have freed up a whole day to actually do the customer requests on every single PoC.   What would a 33% increase in productive time have meant?  I’m going to guess a higher win rate against the competition, faster company growth, bigger promotions, and more time spent with the wife and kids.  

And if I had had AppZero at Sonic, our very cool software would have been safely isolated from the customer’s operating environment instead of deeply enmeshed in it.  Innocent from the start.  Hey, how’s this for a new tag line? “AppZero -- protect your software from your customers.” 

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

As luck would have it, I recently attended two thought-provoking Sales 2.0-focused presentations almost back to back. In the first one, Ben Nye of Bain Capital Ventures spoke about lessons learned from SolarWinds, a poster child for Sales 2.0.  At the next, David Skok of Matrix Partners gave a first-rate talk with practical advice on "How to Build a Sales and Marketing Machine" .  With apologies to Ben and David, I’d “nutshell” one of their key points as follows:

Your product is your sales person.

Technology and expectations have combined to shift away from a sales-rep model to one that is product centric; one that lets the buyer take it for a test drive and become self educated. In this model, the product is made available for evaluation and is the vehicle by which an interested person will become a highly qualified prospect.

Success here requires: 1) ease of installation 2) ease of use 3) intuitive and instruction free interface 4) fast proof that the product works as advertised, which in turn implies that marketing has set clear and accurate expectations ahead of time.  (For articles and videos on these topics, visit the Sales 2.0 company).

Here, is how AppZero acts as a Sales 2.0 tool when ISVs package their application as a Virtual Application Appliance (VAA):

• Instant provisioning of demonstrations and PoCs
• Installation time is removed from the delivery process
• Time consuming configuration processes are eliminated
• As there is no installation or configuration required, errors are removed from the equation
• Applications can be instantly provisioned on premise, at the customer site, and/or in the cloud
• The application can be moved from server to server (physical or virtual) with no lock-in

This last point deserves elaboration. AppZero VAAs can easily move … again and again. VAAs capture all of an application’s state, enabling a demo to evolve into a PoC, which in turn can move into production.  The sales process is accelerated. (For a brief description of the ISV-relevant characteristics of a VAA, see my previous blog, “Moving ISV applications in a Sales 2.0 world -- What a difference an “A” makes”)

Let’s consider a very realistic ISV sales progression. An ISV delivers an application demo as a VAA and converts it into a proof of concept (PoC) in the cloud. Once the PoC is successfully completed, the application – and all the work that has been put into it during the PoC -- can be moved to wherever the customer wishes it to live. That place could be their data center, a private cloud, or a public cloud. 

The technical nutshell of Sales 2.0 reasons for ISVs to use AppZero’s VAA approach include: ZeroInstall, small image size, fast network delivery, works with Windows, Linux and can migrate to where the customer wants. The business nutshell is even simpler: faster time to customer satisfaction, lowered cost of acquiring customers, and winning more business.

My own Sales 2.0 proposition for ISVs is AppZero’s ISV Accelerator Program.  In this program, we offer qualified ISVs the following at no charge: professional services to assist in encapsulating the ISV application as a VAA; the right to use that VAA to deliver demonstrations and PoCs with no time or volume limitation; and six months of support. Hop into our funnel and move your Sales 2.0 self right on through it to satisfied customer/enthusiastic reference.

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

As it turned out, the brilliance and competence of Amazon’s technocracy were no match for simple human error. An incorrect manual update to the network set up a domino effect of Catch-22-esque compound failures to Amazon’s EBS (Elastic Block Store) details of which can be found in a 6 page explanation the company offered last week.

Although cloud naysayers will no doubt try to make this event the poster child for Luddite agendas, it won’t work. Data was lost. Business was lost. News was made. But overall, the fallout has not been too bad as users have quickly come forward to stand by Amazon and the choice to use its services.

And the risk was largely knowable. As Jason posted in an article On Cascading Failures and Amazon’s Elastic Block Store  “This is not a “speed bump” or a “cloud failure” or “growing pains”, this is a foreseeable consequence of fundamental architectural decisions made by Amazon.“ 

The gains surpassed the risk. And will continue to do so. Though still in its early stages, life in the cloud is really a lot more of a learning experience than it is an adventure. Everyone involved will continue to get a little wiser in the ways that only experience – usually bad ones – can confer on those gaining the wisdom. 

As the only software vendor offering patented technology to virtualize Windows, Linux, and Solaris server applications – AppZero is a huge fan of all things cloud. We invite our customers to move their applications to and from datacenter and cloud(s) and cloud to cloud, with no lock-in. I’ve seen the hesitancy that comes from skepticism and trepidation as well as the high fives and smiles that accompany seeing and believing.

But here’s something I’ve also seen that I will never understand: Organizations running very important (though not “mission critical”) Solaris 2.6 applications on hardware that is past the hope of life support. The hardware will fail and take with it the applications. When I say, “It’s not a matter of if … it’s when.” I get knowing chuckles and head shakes as IT pros tell me how very right I am. 

When I go on to tell them that AppZero software can encapsulate their Solaris 2.6 and 7 applications, pick them up, and deposit them on Solaris 10 and bright shiny, inexpensive, reliable machines, all without a line of code … they are intrigued. Of course they are. Here’s a very cost-effective solution to a guaranteed problem.

Okay.  So here’s the question: Then why doesn’t every one of them just jump up and sign on with AppZero? Human nature or human error? Have they lived so long in denial that they’ve crossed over into magical thinking, convinced that because it hasn’t happened … it won’t? Or do they expect to be in new jobs before the when = now?

Cloud risks pale against cloud gain. Life on the San Andreas Fault brings a great lifestyle until the big one. But important apps on Solaris 2.6?  I don’t have a clue so feel free to send me one. In the meantime, let’s cloudify those Windows and Linux client/server apps – no code, no lock-in, no pain.

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

“So, VMware … separate hardware from OS = virtual server, right? Well, we’re like that but completely different – we separate application from OS = virtualized application.” Because we’re in the vast virtualization market space with a technology that is unique (patented), I am often asked to differentiate AppZero’s server-side application virtualization from the rest of the pack. Especially in the Oracle/Sun/Solaris/SPARC context.

And especially since we’ve been promoting a Webinar series drawing a straight line from ancient Solaris 2.6 and 7 applications to execution on OS and hardware from this millennium. (We broke the marketing bank naming the webinars: “Virtualize-2-Modernize; Solaris 2.6 + 7 applications run unchanged on 9 + 10” and the follow-on “How to run Solaris 2.6 and 2.7 applications unchanged on Solaris 9 and 10”)

Good news/frustrating news

So I’ve recently been immersed in SPARC-dom through the “Virtualize-2-Modernize” series, in tandem with doing exactly that type of Solaris application modernization work for some household name clients. The good news is that our customers clearly see AppZero’s value proposition and ROI as very high. Understanding and adoption go hand-in-hand – as do confusion and delay. What is so frustrating to me is that this clear value proposition is too often occluded by confusion surrounding the various flavors of virtualization in this market.  Specifically:

• Oracle VM Server for SPARC, the technology formerly known as Logical Domains (LDOM) – This server hardware virtualization and partitioning technology was released in 2007 by Sun and rebranded since Oracle’s acquisition of the company in 2010.
• Solaris Containers/Zones (global, non-global, branded) -- First made available in 2005 as part of Solaris 10, this operating system-level virtualization accommodates applications running on isolated virtual servers within a single OS instance.
• AppZero Solaris application virtualization – First shipped in 2006, AppZero separates an application from the OS, capturing that application and its dependencies in isolated capsules that can execute on a single Kernel OS instance.  For example, AppZero encapsulates Solaris 2.6 and 7 applications with enough OS distinctives that they can execute on the newer OS versions. (Copied and run, the applications are not installed in the traditional sense although they execute as if they were.)

It’s easy to delineate LDOM/hypervisors and application virtualization; it’s trickier to come up with a one-liner for containers/zones. Part of the difficulty stems from the fact that this Solaris technology and AppZero’s Solaris application virtualization solution both use analogous approaches to create isolated application executions on a single OS kernel instance. For those of you interested in differentiated elephants and nuances, I’ve included a comparative matrix at the end of this blog.

Differentiation by use case

In the meantime, AppZero use cases are clear. Tuned for rapid provisioning (what we call “ZeroInstall”), AppZero enables moving/copying a pre-installed, pre-configured application to any machine to be up and running in seconds. This resultant extreme agility has direct value for:

• ISVs who want rapid provisioning of demos and proof of concept (POC) as well as fast distribution of software.
• Provisioning of applications for scaling and de-scaling in a cloud.
• Moving applications from data center to the cloud … to another cloud … and back … etc.
• Reducing OS and image sprawl by dynamically applying “gold OS” and “gold application” images.

And in a category almost by itself ….

• Modernizing old Solaris 2.6 and 7 applications – separating them from the kernel – so they can move to Solaris 10, enjoying all the benefits of hardware and Solaris services from this millennium.

Differentiation by attributes

Inspired by a recent Peter Baer Galvin blog, “Pete’s all things Sun: comparing Solaris to Red Hat Enterprise and AIX” I offer this matrix comparing the technologies. I welcome your comments, refinements, and (should the unthinkable happen) corrections.

*Including apps that are deemed not compatible with Binary Compatibility Guarantee and are statically linked

Note: AppVirt: AppZero for Windows platform has a different interception level that Linux and Solaris 

I am always looking for a way to communicate better and cut to the heart of the discussion. If you have thoughts on this subject drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor.