Interview: rPath's Billy Marshall on how enterprises can virtualize applications as precursor to cloud use

Read complete transcript of the discussion. Find it on iTunes/iPod. Learn more. Sponsor: rPath.

Many enterprises are factoring how to bring more applications into a virtual development and deployment environment to save on operating costs and to take advantage of service oriented architectures (SOA) and cloud computing models.

Finding proven deployment methods and governance for managing virtualized applications across a lifecycle is an essential ingredient in making SOA and cloud-computing approaches as productive as possible while avoiding risk and complexity. The goal is to avoid having to rewrite code in order for applications to work across multiple clouds -- public, private or hybrids.

The cloud forces the older notion of "write-once, run anywhere" into a new level of "deploy correctly so you can exploit the benefits of cloud choices and save a lot of money."

To learn more about how enterprises should begin moving to application-level virtualization that serves as an onramp to cloud benefits, I recently spoke with Billy Marshall, founder and chief strategy officer of rPath.

Here are some excerpts:

We're once again facing a similar situation now where enterprises are taking a very tough look at their data center expenditures and expansions that they're planning for the data center. ... The [economic downturn] is going to have folks looking very hard at large-scale outlays of capital for data centers.

I believe that will be a catalyst for folks to consider a variable-cost approach to using infrastructures or service, perhaps platform as a service (PaaS). All these things roll up under the notion of cloud.

Virtualization provides isolation for applications running their own logical server, their own virtual server. ... Virtualization gives you -- from a business perspective -- an opportunity to decouple the definition of the application from the system that it runs on. ... Then, at run-time, you can decide where you have capacity that best meets needs of the profile of an application.

I can begin sourcing infrastructure a little more dynamically, based upon the load that I see. Maybe I can spend less on the capital associated with my own data center, because with my application defined as this independent unit, separate from the physical infrastructure I'll be able to buy infrastructure on demand from Amazon, Rackspace, GoGrid, these folks who are now offering up these virtualized clouds of servers.

That's the architecture we're evolving toward. ... For legacy applications, there's not going to be much opportunity. [But] they may actually consider this for new applications that would get some level of benefit by being close to other services.

[If] I can define my application as a working unit, I may be able to choose between Amazon or my internal architecture that perhaps has a VMware basis, or a Rackspace, GoGrid, or BlueLock offering.

Another big consideration for these enterprises now is do I have workloads that I'm comfortable running on Linux right now, and so can I a take a step forward and bind Linux to the workload in order to take it to wherever I want it to go.

rPath brings a capability around defining applications as virtual machines (VMs), going through a process whereby you release those VMs to run on whichever cloud of your choosing, whether a hypervisor virtualized cloud of machines, such as what's provided by Amazon, or what you can build internally using Citrix XenSource or something like VMware's virtual infrastructure.

It then provides an infrastructure for managing those VMs through their lifecycle for things such as updates for backup and for configuration of certain services on the machines in a way that's optimized to run a virtualized cloud of systems. We specialize in optimizing applications to run as VMs on a cloud or virtualized infrastructure.

With our technology, we enforce a set of policies that we learned were best practices during our days at Red Hat when constructing an operating system. We've got some 50 to 60 policies that get enforced at build time, when you are building the VM. They're things like don't allow any dangling symlinks, and closing the dependency loop around all of the binary packages to get included. There could be other more corporate-specific policies that need to be included, and you would write those policies into the build system in order to build these VMs.

It's very similar to the way you put policies into your application lifecycle management (ALM) build system when you were building the application binary. You would enforce policy at build time to build the binary. We're simply suggesting that you extend that discipline of ALM to include policies associated with building VMs. There's a real opportunity here to close the gap between applications and operations by having much of what is typically been done in installing an application and taking it through Dev, QA and Test, and having that be part of an automated build system for creating VMs.

People are still thinking about the operating system as something that they bind to the infrastructure. In the new case, they're binding the operating system to the hypervisor and then installing the application on top of it. If the hypervisor is now this bottom layer, and if it provides all the management utilities associated with managing the physical infrastructure, you now get an opportunity to rethink the operating system as something that you bind to the application.

When you bind an operating system to an application, you're able to eliminate anything that is not relevant to that application. Typically, we see a surface area shrinking to about 10 percent of what is typically deployed as a standard operating system. So, the first thing is to package the application in a way that is optimized to run in a VM. We offer a product called rBuilder that enables just that functionality.

If you prove to yourself that you can do this, that you can run [applications] in both places (cloud and on-premises), you've architected correctly. ... That puts you in a position where eventually you could run that application on your local cloud or virtualized environment and then, for those lumpy demand periods -- when you need that exterior scale and capacity -- you might just look to that cloud provider to support that application [at scale].

There's a trap here. If you become dependent on something associated with a particular infrastructure set or a particular hypervisor, you preclude any use in the future of things that don't have that hypervisor involved. ... The real opportunity here is to separate the application-virtualization approach from the actual virtualization technology to avoid the lock-in, the lack of choice.

If you do it right, and if you think about application virtualization as an approach that frees your application from the infrastructure, there is a ton of benefit in terms of dynamic business capability that is going to be available to your organization.

Read complete transcript of the discussion. Find it on iTunes/iPod. Learn more. Sponsor: rPath.