So sue me.  It's finally summer in New England causing me to surf and run and generally do things that turn my hair white and my fine Irish skin red.  The sun is not beckoning me to blog.

But if I were going to blog this week, it would be about the incredible opportunity AppZero has to revolutionize the economics of the ISV sales cycle.  Specifically, we can do a "Name that tune" approach to proof of concepts (POC) reducing the time needed to install and configure on customer site from days to minutes.  It is a wow factor.

As luck would have it, Syscon this week published a piece I did on just this topic.  Aren't I lucky guy?  You can click here http://cloudcomputing.sys-con.com/node/1035387 or just read the article below.

And when the sun goes back to wherever it's been since May, I've got a feeling I'll be in a perfect state of mind to blog on our experiences at Microsoft's Worldwide Partners conference that just wrapped up in New Orleans.  Which, depending on how you look at it, could be heaven or hell.

As CEO of a company that can cure what ails Windows ISVs, any place they gather is my kind of heaven.  No harps.  Just the sweet sound of cash registers sounding the call of commerce.

Cloud + POC = 'Obvious' ISV Revenue Growth

I've always found that the obvious things in life are easy to understand once you see them.  I've got a good one for you.

Question:  If an ISV can bring install time close to zero, their proof of concept (POC) efforts will:

1. Take less time
2. Become predictable and repeatable
3. Go more smoothly in the eyes of the potential customer
4. Provide more time for actually working with the customer and proving the concept
5. Look impressive compared to competitors who need to send SEs on site for hours and days of sweating through glitch filled installation and configurations
6. Increase the likelihood of a win
7. Use less of the most skilled and valuable ISV asset - the knowledgeable SE who is also good in front of living, breathing, revenue generating potential customers
8. Lower the cost of sales
9. Generate incremental revenue
10. All of the above

So the obvious thing here is: ISVs should reduce POC installation and configuration time to near zero.  It is obvious, isn't it?  And easy to understand.  As it turns out, it's also easy to do.

How do I know?  Because that's what we do at AppZero.  Delivering an application as a pre-installed, pre-configured virtual application appliance with zero OS component shrinks install, set-up, and configure time to minutes.  Yes, even large German ERP applications.  (You knew I had to get at least one company mention in, didn't you?)  In fact, I'd worked up a nifty Excel-based calculator to let potential ISV customers of ours quickly bang out the financial impact of having zero POC install time.  I ran the calculator by some of our ISV clients to give it a real-world sanity check.

Talking with one AppZero-using ISV with revenue just under $1B in 2008, I was looking for just a few inputs to make my case:  # of POCs, average deal size, average time invested per POC, win rate, how many SEs and the cost of an SE.  Turns out that if you're the SVP that owns responsibility for that almost $1B worth of business, you know the win/loss metrics.  Cold.

Before I could finish explaining my cool calculator concept, he had it filled in:  400 POCs per year, average deal size is $350K (for the first year of course), 5 day average POC duration, time to install and set up POC is one day of the 5 day duration (or 20%), win rate of 70%, SE salary of $130K .... 20 seconds later we had the answer.

Zero install's effect of reducing POC duration by 20% can go to straight cost savings or to increased time spent actually working with the client and application.   It can go to more POCs conducted a year per SE.  In all scenarios, it goes to increased revenue.  In the case of this ISV, the very conservative answer is in the millions.  My client agreed.

Life is good.

The logical next step in the conversation was how to leverage the cloud to get the POC job done.  I've talked with many ISVs ranging from startups to 10s of billions in revenue, as well as leading cloud providers such as Amazon and GoGrid.

One thing is clear to me.  ISVs are doing POCs in the cloud.  Mature, established players are hovering around 10% for cloud-based POCs.  Start-ups are 100% cloud-based POC.  Of course, I'm loving this because AppZero's instant provisioning in the cloud or on-premise and ability to move applications from the cloud to data center is a bulls eye for this market.

Yes, Virginia, I did say "moving from the cloud to the data center".  It turns out that ISVs want to be able to start a POC in the cloud and have an easy way to move that instance of the application to the customer site when the POC converts to a win.  All the work that was done on the POC transitions to a production implementation.  (Yippee. More savings.)  Interesting that this sensible approach has gone unremarked by the cloud hyped media.

In fact, that ISV SVP I referenced earlier in this piece summed up the POC cloud case pretty well, "Greg our partners build their apps on our platforms and are faced with selling in this economy.  For example, they may sell back office manufacturing applications to the likes of the automobile industry.  Fun, huh?  Well, in North America, the ones that are using the cloud for their POCs have revenue up 5-6% compared to last year.  The others?  They are all down for the comparable period."

So, I know first-hand how hard it is to start a business, create a new product from a blank sheet of paper, create a new category that Gartner eventually buys into, raise money .... But I can not imagine how hard it is to sell ERP to manufacturers that sell into the auto industry right now.  That has got to be tough to the 10th power.

Even more reason to run POCs in the cloud - and it's good for marriages.  "Honey, I'm going to run down to the ball bearing factory to check on the POC.  Don't worry.  It's running on the cloud so I'll be home in plenty of time to pick up the kids from school.  Should have time to finish painting the fence before dinner."

Maybe if we used the TARP money to accelerate cloud evolution, we would have full employment, a housing boom, and time for Mr. Cleaver to pick the kids up from school.

Just a thought.

Bottom line first: Microsoft has absolutely no incentive to move a revenue-slashing technology out of its labs at all - never mind quickly.

Virtualization of server-side applications that decouples an application from the OS (which Microsoft demoed from its development lab and which AppZero does today for real customers in the real world) drastically cuts the $$$$$s expended for OS-s and support infrastructure.

Q:What about this cost-savings value proposition is attractive to our pals in Redmond?
A: Absolutely nothing.

Q: Are they lying when they say that this capability is under development?
A: No reason to do that.

Q:When will it be released?
A: No plan to do that. At least none that are announced.

The most logical scenario is that the lab elves are indeed scurrying around developing just the capability that they demoed. (Not to be repetitive, but exactly the capability that AppZero offers today.) And that Microsoft will let the fledgling product fly when the inevitable public demand ... well ... demands it.

And I do believe that public demand for server-side application virtualization is inevitable because:

• Virtualization is not a fad - It is the IT version of common sense

• Client-side application virtualization is well accepted and proven to save bundles of $$$s. But of the many players in this space, to date, none have addressed the complexity of server apps.

• Server-side applications can not sit on the sidelines of virtualization

• In the move to cloud computing, enterprises will not do a wholesale discard of current applications, so they'll need a way to cloud-enable or retro-fit those apps (In fact, Gartner anticipates that companies will do just that - move existing applications to the cloud with as little modification as possible, rather than rearchitect and rewrite.)

• Windows server applications are not a rare occurrence in the IT landscape. So there must be a way to virtualize them for movement to the cloud and in the data center without violating licenses ...Oh, wait a second ... there is a way - it's AppZero (I crack myself up.)

We're doing really well for lots of reasons. But believe me, feeding our shareholders takes more than our being a Gartner Cool Vendor in Cloud Computing (cool though that is.) Right now, the virtualization of server-side applications is early market. I'm in a position to know. So there is really no pressure on Microsoft to come out with this technology and no shame in not having what no one else but a nifty company called AppZero has to date.

Hey, props to McKinsey's PR machine, which created a blogsplosion of activity on the release of a study titled, "Clearing the Air on Cloud Computing".  The frenzy began as William Forrest, the lead analyst/author of the study, was reported to be planning to "present a report aimed at debunking cloud computing's appeal for large businesses" (Forbes.com, "Deflating the Cloud" 4.15.09).

"Planning" is the word that hit me here.  The report was headlines before it was released.  And when it was released, mainstream press (New York Times, Forbes, Washington Post et al) and bloggers alike covered the story as if it were big news.  Very big.  Leading with such phrases as ,"trying to adopt the cloud model would be a money-losing mistake for most large corporations", the coverage acted as if McKinsey had pronounced cloud computing dead-on-arrival.

McKinsey did no such thing.  Far from it.

The report itself is very conservative, if a little preachy, and is actually pretty common fare for a symposium presentation - which it was.  McKinsey's William Forrest, of the great press coverage, was scheduled to present this report at a symposium sponsored by the Uptime Institute.  Who are they I wondered?  Well, Uptime Institute is a research and advisory group whose mission is to improve data center efficiency, and whose tagline is, "The Global Data Center Authority".

Well, well, well .... It seems we have a pretty big coincidence here:

• An organization that excels at making money from advising IT how to improve their data center operations makes a presentation that is reported at a symposium sponsored by a group that is dedicated to data center success (formerly known as "Computer Site Engineering, Inc".)
• The study is reported in the press and blogs as if McKinsey had put up a sign saying "Cloud computing: Abandon all hope ye who enter here." and sounded the clarion call, "Back to the Datacenter."
• All of the potentially inflammatory things that McKinsey is reported to have concluded were found - not in the bland little report - but in the words of Mr Forrest speaking to the press.

I promise you that if you were to download the 34 slide presentation itself, you would find very little interesting and absolutely nothing that is news-worthy.  If I had to make a synopsis (using direct quotes where practical) it would roughly go as follows:

• "Using "clouds" for computing tasks promises a revolution in IT similar to the birth of the web and e-commerce."
• "While it has great potential, many of the claims being made about cloud computing have lead some to the point of "irrational exuberance" and unrealistic expectations."
• "The purpose of this report is to focus the nascent cloud industry and its consumers on setting realistic expectations by taking a "hype free" approach starting with the most basic question of what a "cloud" actually is."
• There is much confusion in the market between cloud and cloud services - a common definition would be useful and McKinsey would be a good arbiter of its definition
• "'Cloud computing' is approaching the top of the Gartner Hype-cycle" (and apparently just beginning the curve of the McKinsey hype cycle.)
• Throw in a little FUD, "The 2000 dot-com bubble provides an extreme example of the dangers of investing in hype." And reminding us all that, "From peak to trough, the NASDAQ-composite lost ~ 80% of it's [sic] value"
• The cloud is good for small and medium businesses
• "Most EC2 options are more costly than TCO for a typical data center." I never thought I'd say this, but 'poor Amazon' takes the fall as the overpriced cloud predator luring unsuspecting CIOs into its web/cloud. Probably because it is best known and most public with its charges.
• IT professionals would be best served by rigorously applying virtualization techniques to their data centers. (I believe McKinsey folks can help here.)

Really nothing earth shaking here.  The controversy stems from the company's assertion that large enterprises would lose money in a wholesale shift of their data centers to the cloud.

A.)   Of course they would

B.)    What large enterprise on earth is contemplating doing that?

C.)    What cloud provider is suggesting that they do so?

D.)   Who would disagree?

E.)    Where's the news value?

Shame on McKinsey for picking on poor Amazon -- and bravo McKinsey PR.

Agile development and deployment workflow

This series describes a development and deployment process optimized for the needs of software-as-a-service in terms of cost structure, agility, staging and test requirements.  The resulting system will tolerate the failure of a local hard drive and crashes of a machine - physical or virtual.  Offering good performance / low cost via Amazon's EBS and EC2 services, the system will provide the ability to rollback changes both on the deployed and development system (independently or together) using Subversion.

You can enjoy instantaneous feedback when you are developing code without affecting existing users of your website by using a two machine development and deployment lifecycle.  Deployment can be a 5 second experience (as opposed to 5 minutes) using AppZero technology.

I have tried a number of lifecycle workflows for the development and deployment of Drupal websites. In this series, I will describe a two machine approach involving a local development and test machine and a deployment machine. Deployment of files will use the Subversion Version Control System; the local machine is Windows to make tools like Photoshop convenient to use; the deployment machine is a Windows machine from EC2; and we will use Apache, Drupal, and MySql.

The one-machine approach, topologically simplest, involves developing directly on the deployed machine on the Internet. I've found this approach, while seemingly simple, to have two serious deficiencies:

• developing a new feature for a site can often involve accidentally breaking existing functionality or look-and-feel. This topology makes it difficult to evolve a site without showing the public every intermediate change.

• tools like Photoshop  are not convenient to use on a remote basis and ftp'ing files back and forth is a cumbersome process. Even text editing on a remote machine incurs painful latencies.

For these two reasons, I advocate at least a two machine approach. This allows you to develop on your local machine, disconnected from the Internet if necessary, with all the tools you like, and deploying when you desire. Of course, in a two machine topology approach, deployment agility becomes paramount. The difference between 5 seconds to deploy and 5 minutes makes the difference between wonderful and painful.

Like a lot of folks, I'm excited about the possibilities that arise when you combine the agility of modern CMS's (like Drupal and Wordpress) with the scalability and administrative control offered by Compute Clouds (like Amazon EC2 and GoGrid).

In my work as VP of Technology here at AppZero, I've had the opportunity to work with a number of web site and web app developers who are trying to realize this potential. I've seen first hand that there are a lot of unwritten, but critical, details we must know to capitalize on this power.

This entry is the start of a blog series in which I'll share my viewpoint -- and I welcome your participation.

I'm going to kick off this series by sharing my experiences in developing, deploying, updating, and scaling out a Drupal installation in Amazon's EC2 Compute Cloud. I'll let you know what's worked and what's failed. I'm hoping I can make your life a little smoother so you can avoid some of the pain we've gone through -- and get right to the good part.

I'll be writing at least one entry a week.  Here's my plan:

Part 1: An agile development and deployment workflow: from your machine, to EC2, and back in 1 minute.
Part 2: Getting Drupal on your Windows machine in 5 minutes.
Part 3: Developing your site.
Part 4: Provisioning an EC2 machine.
Part 5: Moving your Drupal development site to the EC2 machine.
Part 6: Updating your Website and redeploying in a matter of seconds.
Part 7: Scaling out your website.
Part 8: Concluding comments.

Join me on this journey by commenting on the blog or writing me directly at chu@appzero.com.