server application

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?