Skip to Content

AppZero

VAA

Measuring cloud agility in lunches, not days

Thu, 2011-08-11 05:48 — Greg O'Connor

Question: Why did the server application cross the network?  Answer: For the same reason the chicken crossed the road – to get to the other side … (in this case) of the datacenter and clouds.

Follow up question:  If all a server application ‘wants’ to do is get to another server – physical or virtual – why would it drag along an OS?  Answer: Because it didn’t know it had a much more agile and faster option – OS-free server application virtualization.

And here we get to the heart of the matter …. Server application virtualization is frequently misunderstood because when they think about virtualization, most people think of:

  1. VMs – close cousin to hypervisors; the packaging of server applications with an OS
  2. Desktop application virtualization – for desktop applications, not server applications.

In fact, server application virtualization is different in type and kind from these market mates – not better – different.  AppZero does server application virtualization -- well suited for different use cases and requiring a different market lens than the ones formed by either VMs or desktop.

Agility is the benefit that showcases our use case and brings clarity to the discussion.

The basic math of server application virtualization agility over the VM approach is multiplication of results, by subtracting the OS.  When you separate an application from the OS, the resulting image size is 50 – 1,000 times smaller than a VM image, which can easily surpass 30 GB.

So what?

Well, try on this dirty little cloud secret:  If an enterprise uses the Internet to connect to their cloud provider, it will take DAYS to move that 30GB VM image to the cloud.  Yes, days. 

By contrast, AppZero virtual application appliance (VAA) images are most often measured in MB, not GB.  AppZero math means that you can provision your server application to a cloud, or multiple clouds, over lunch instead of days.

Lunch is agile.  Days are not.

I’ll do a deeper dive on server application virtualization in Cloud and ISV use cases in my next few blogs.  But for now, if you want real enterprise application agility, server application virtualization is probably as close as you’ll get to a silver bullet.

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. 

Server application virtualization = Sales 2.0 accelerant for ISVs

Mon, 2011-05-16 04:39 — Greg O'Connor

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.

The Death of Cloud Computing the Birth of Dream Computing

Thu, 2010-01-28 12:59 — Greg O'Connor

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.

Good fences between apps and OS make good neighbors in the cloud

Wed, 2010-01-06 13:39 — Greg O'Connor

Did you ever have the invisible dream?  I don’t like it.  It’s the one where I have “the answer” to a big problem (usually involving giant, malevolent aliens) but everyone walks right past me because I’m invisible. I had that feeling yesterday reading James Urquhart’s blog titled, “Application packaging for cloud computing: A proposal”.

He’d written a series of posts considering deployment and operations in infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) environments. Looking at the impact of cloud computing on the use of virtual machines and operating systems, Urquhart wrote, “The very heart and soul of software systems design is being challenged by the decoupling of infrastructure architectures from the software architectures that run on them.”

Yes.  Exactly what I’ve been saying.  Exactly what AppZero does in divorcing server applications from the underlying OS in virtual application appliances (VAA).

Urquhart goes on to say that the more he explores the question of IaaS/PaaS server application packaging in light of what he calls his “big rethink,” the more he thinks…” there is an opportunity to simplify cloud computing through changing the focus from infrastructure to applications.”  Yes, again.

He suggested that the answer might be found in, “a uniform description of an application, its configuration, and its operational requirements that can be used to describe any software deliverable to the cloud, whether meant for IaaS or PaaS.” He allows as how “such a packaging format would have to be open and standard,” (read, in the land of distant future where most visions live.) 

My take is that Urquhart has proposed far more than standardized application packaging. What he has sketched is a proposal for a cloud system application lifecycle. To that notion, I give James two thumbs up. But no smart proposal changes the basic fact that when an installation inter-mixes an application with the OS, complexity follows with inflexibility and cloud lock-in. And its cousin datacenter lock-out.

So here’s where that bad dream feeling starts to sneak up on me: The world has embraced the great benefit that comes from decoupling the OS from hardware but leaves the rest of the software stack as a giant, monolithic black box.  And it doesn’t have to.

If the cloud as IaaS or PaaS provided separation of server application and OS we’d:

  • Enjoy the cost savings of using the OS license provided by the likes of Amazon and GoGrid instead of building our own image with our own OS license
  • Expect the cloud provider to stay current with OS and security updates instead of doing our own patch management in the cloud
  • Have the option of moving up the stack to use cloud provider middleware like SQL Server, MySQL, WebSphere, or Oracle WebLogic Server, adding the rest of the pieces I need to make my application sing like a springtime robin. The way I see it cloud users going up the stack and using other middleware components are building new apps, not leveraging the cloud stack to its fullest potential
  • Move more responsibility, cost, and management overhead from our side of the ledger to that of the cloud providers.  Why would you want to do anything that your cloud vendor can do and is already charging you to do?
  • Avoid cloud lock-in and enable where to run flexibility.  Applications can move from data center to cloud to cloud in a matter of minutes
  • Get the benefits of VM’s decoupling and isolation at the application/application component layer -- mobility and consolidation at the software stack level, not just hardware.

Just as good fences make good neighbors, the isolation that comes with server application virtualization makes crystal clear who is responsible for what – lines of demarcation that can get really cloudy (yes, pun) once you move up the stack from basic machine provisioning. What’s more, application virtualization is perfect for moving all or any part of an app from a data center to a cloud to another cloud and back to the datacenter. 

Today.  With AppZero.  Can you hear me now?

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

Syndicate content


Theme by Dr. Radut.