A decision to use a cloud for a particular service or application can be based on simple economics and the appealing logic of only paying for what you use. Worries about physical server components such as storage, network and connectivity, power and cooling, warranties and service contracts-all fall on the shoulders of the cloud service provider. The customer of the service is freed from all such physical plant issues as they relate to ongoing maintenance, but that’s the “easy part.” Much harder is architecture of cloud automation that is adapted to your application and business model. For example, the agility to rapidly scale your application up and down without lost investment, which is a primary benefit of the cloud.

Public clouds are complicated under the hood

Once you select a public cloud provider, like Amazon Web Services (AWS), Rackspace, SoftLayer, or others, things can start to get more complicated. Basically you need to learn to program through a particular cloud provider’s Application Programming Interface (API) to get your work done. Cloud infrastructure that is highly adaptive to your application often requires an element of programming, or at least a deep understanding of a given cloud provider’s automation stack. An example is an on-demand web farm that grows from a dozen servers to thousands of servers and back down again in the space of a few days or even hours.

The intelligence on when and how to scale is developer-driven and the cloud provider API is the toolset that powers the automation. If you need to move to a different cloud provider, or use two or more providers, you need to learn each provider’s unique API stack all over again. So moving between public clouds can be rather difficult and can induce a ‘locked in’ feeling for the cloud customer. The time to market on a new project using your first public cloud provider can be lengthy while you learn the API, and is delayed in a like manner with each successive cloud provider added to your portfolio.

The true economic and technical benefits of the public cloud emerge for the cloud customer only after development of custom automation and instrumentation using a cloud provider API. In particular, advanced cloud computing features, such as on-demand scaling, and self-healing of failed application components, demand a certain mastery of the API for a given cloud provider. Rather than grow your staff with that expertise for each additional cloud provider, another option is to leverage a middle-layer cloud infrastructure provider that works across multiple cloud providers. Welcome to an innovative tier of IT abstraction that ‘outsources’ the engineering task of cloud infrastructure automation.

Automate, aggregate, and federate public clouds with RightScale

RightScale is an example of a new breed of service provider that essentially brokers and manages your applications across a variety of public and private clouds. RightScale has written a customer-facing API that is cloud-vendor neutral-the promise is: You can write your application to the RightScale API one time, then move or scale your application using another cloud provider without application rewrite. When you want to provision public cloud virtual machines (VMs) and applications, you author your application using RightScale methodologies, and then RightScale uses your cloud provider login information to translate the RightScale API to the API of the particular cloud provider.

This approach logically aggregates your cloud providers (making them appear like different accounts you have at the same bank) and federates them-you have a single sign-on experience using the RightScale API and don’t need to manage multiple cloud security boundaries. RightScale’s solution packs include pre-configured server templates and “RightScripts” that reduce complexity and risk in the cloud equation. The cloud customer is empowered using infrastructure middleware because if you are unhappy with one cloud provider, you are not hostage and can migrate to a different cloud with predictable costs and timeframes.

The RightScale customer portal: Adding public and private clouds for deploying your applications into (click to enlarge)

Figure A shows the RightScale customer portal web page where you add the back-end cloud providers of your applications. Notice there is a button to add a private cloud in addition to the well-known public cloud providers. RightScale lets emergent and open source private cloud providers like Eucalyptus and Citrix-owned cloud.com leverage the RightScale platform for automation as well.

Making new things possible for the cloud application architect

An example of how outsourced cloud automation helps in a project is an answer to a cloud architecture question like, “How does one deploy and support a Windows domain controller in a public cloud?” Issues like Active Directory backup and the lack of individual VM persistence can take the idea of a domain controller in a public cloud out of consideration. RightScale has a scripted solution using native Microsoft technologies that deploys and even recovers that complex server role consistently across cloud providers. If it were not for a cloud automation provider that had a proven configuration, it might be too risky to architect a domain controller role in a public cloud solution, even when doing so would provide a business value.

To date, the largest public cloud providers like AWS and Rackspace do not seem to have devoted resources to developing interoperability standards between their clouds. However, the need for cloud federation exists in the IT ecosystem, so that enterprises are not restricted to a single cloud provider. Distributing your cloud application across redundant public cloud providers can protect your enterprise from outage even when a major player like AWS has an outage. What RightScale and a few others are doing in this new industry segment can only contribute to a gain in cloud momentum by increasing confidence and reducing risk in cloud scenarios.