Mapping the cloud: rPath

rPath makes platforms that remove humans from the cloud equation (to a degree). We talked to Jake Sorofman, rPath’s chief marketing officer, about the company’s strategy.

Your platform automates IT systems configuration. What gets automated exactly, and how does it apply to cloud architectures?

rPath automates all of the steps associated with constructing a software system, generating new images, provisioning images to physical, virtual and cloud environments and managing change to these systems over time. It dramatically reduces the human effort—and therefore the time, cost and variability—from the process of deploying new applications and application changes.

Where does this fit in? What does it replace?

Today, for the average enterprise, it may take three to six months to deploy a new application or application change to any environment-physical, virtual or cloud. Cloud doesn’t address this problem because it has little to do with provisioning an image and a lot to do with creating or changing that image in the first place. Today, the process of resolving dependencies, integrating software, testing and certifying a software system takes far too long. rPath automates that process, producing ready-to-deploy images and updates that are deployment-ready and virtually guaranteed to be free of conflicts. In the age of cloud, where workloads need to be provisioned and scaled on demand, there is no tolerance for deploy- or change-time failures.

There are no do-overs in these sort of dynamic computing models. rPath takes the time and risk out of this process. Our customers use our products in two key scenarios: Making application deployments and updates push-button simple, for environments where deployments and changes are frequent and the consequence of failure is high; and, as the image factory and automation foundation for private and hybrid cloud environments.

IT professionals already tend to be cautious about cloud services. How do you address that cautiousness, given that you advocate further automation (which some may view as less control)?

I would suggest that automation, when done properly, provides a whole lot more control than a manually executed process. After all, it was a manual configuration error that brought down Amazon EC2. Automation is necessary to minimize variability and human error and also to accelerate processes and scale in a time of flat or declining budgets. It’s also worth noting that cloud itself is contingent upon extensive automation-self-service and elasticity cannot be achieved without automation. Of course, automation of flawed processes only makes bad things happen faster. That’s why we advocate a model-driven approach to automation that ensures that the steps we automate are guaranteed to be correct. We apply an engineering mindset to the process of automation. Yesterday’s script-based approaches to automation are too complex, cumbersome and fragile to provide IT organizations the level of control they need today.

What are the advantages in terms of cost, reliability and performance?

We’ve been able to remove 80 to 90 percent of cycle time from application deployment processes, improve the system-to-administrator ratio by six to ten times and virtually eliminate the possibility of conflicts and failures do to software deployment, configuration and change.

There have been some high-profile cloud outages lately. How can those scenarios be avoided? How do you address it with your customers?

We can help on both the provider and consumer side. Let’s start with the provider. As I mentioned, it was a manual configuration error that brought down Amazon. A model-driven approach to automation could have helped here, allowing the provider to validate the change and understand the dependencies and change impact before the change was implemented. On the consumer side, our ability to generate images on demand abstracts cloud consumers from a specific deployment environment, allowing them to generate new images on demand for retargeting workloads between physical, virtual or cloud environments.

What’s your long-term view on the evolution of cloud architectures and services? Will everything be in the cloud eventually? What still needs to be addressed to make that possible?

Ultimately, the basic cloud characteristics of self-service, abstraction, automation and elasticity will be featured prominently in future IT delivery models. The infrastructure, platform and application resources that make up IT of the future will be a blended combination of public and private options, where the role of the CIO is to optimize across a range of available choices and to define policies that dictate how requirements and demand should flow. The CIO becomes a broker and a sourcing integrator. It certainly won’t happen overnight.