Private Cloud Automation

Major public cloud providers, including Amazon, Microsoft, and Rackspace, have been driving hard toward automation since their services hit the market. The reason is simple: It improves both the bottom line and customer satisfaction. Now, automating an enterprise-class private or hybrid cloud is an entirely different affair from Amazon using its development muscle to let a user spin up an S3 instance. But that doesn't mean you can stay stuck in manual mode, because without automation, you don't have self-service, and self-service is one of the most compelling reasons for a private cloud.

As with most complicated projects, you're better off building in automation from the get-go; retrofitting is more expensive and less effective. So we were somewhat discouraged with the results of our InformationWeek 2012 Private Cloud Survey. The good news is, this technology has reached a tipping point: 51% of 414 respondents are either building private clouds (30%) or have them in place now (21%). But when we asked those in the construction stage about nine critical steps, orchestrating automation across multiple subsystems came in dead last.

Let's be clear: No automation, no cloud. How do we figure that? NIST defines cloud as having five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service. Virtualization and solid WAN engineering will provide resource pooling, elasticity, and broad network access, but measured service and--most importantly--on-demand self-service aren't part of standard virtualization management suites. For these, automation is required.

Self-service isn't the only benefit. More efficient use of data center resources, self-healing, improved application availability, better power management, and preplanned responses to various scenarios are among the other potential benefits of a solid automation deployment.

Unfortunately, there isn't a standard way to do cloud automation; in fact, there isn't even agreement on what, exactly, it entails. While virtualization vendors have invested a lot of effort in developing APIs that provide extensibility and control, automating those infrastructures is simply not a part of the core virtualization feature set. And yet, controlling a virtualized infrastructure is going to be a key point of any automation strategy, because virtualization is where your resource pools and elasticity live.

At the most basic level, cloud automation packages support runbooks that take preprogrammed actions when a trigger event occurs. But preprogrammed events are just the beginning; new and innovative products, like those we list on p. 25, take management to a new level by enabling policy-based automation. These products use multiple management engines to stay in touch with all aspects of the infrastructure and make policy decisions based on specific scenarios and self-service requests.

Vendors are evolving these systems from workload management suites used to automate diverse virtualization and infrastructure components through a central policy engine. However, because the enterprise private cloud automation market is relatively new, there's no stock feature set, so what you'll be able to do out of the box varies dramatically. For example, while most of these suites have powerful central execution engines that can read data and act on it, some, like Moab, incorporate enhanced resource management for virtual infrastructures and self-service Web provisioning portals as well.

Despite the immaturity of this market, it's worth evaluating these suites, because automating the cloud has huge potential to maximize your investment and slash operational and capital expenses--an important point, as 61% of survey respondents not using a private cloud cite reduced operational costs as a major reason to consider moving to the cloud, with capital expense savings (44%) and technical advantage (45%) as strong secondary factors.

Build On Your Accomplishments

Successful automation deployments sit on top of strong virtualization deployments that provide high availability, scalability, and a degree of fault tolerance, or at least fault recovery.

Still, the first step in preparing to automate is cleaning house. Automatic actions and self-service provisioning will exacerbate poorly configured virtual infrastructures. In addition, better engines help improve resource management, which is difficult to do if the infrastructure is already overloaded. If you don't have the spare capacity to maintain high availability, self-service provisioning may put core network services at risk.

What exactly does housecleaning involve? Consider resource provisioning first. If demand spikes jeopardize the performance of mission-critical business services by starving application servers, that can be a problem. You must segregate workloads into resource pools and assign priorities to them--as self-service requests come in, critical servers must be given priority access to underlying physical resources. When selecting an automation management system, look for the ability to manage resource load in cloud environments, but be aware that just throwing resource management at a badly configured infrastructure is likely to net you a lot of angry help desk calls.

In addition, make sure you have a method to track when a VM produced by automation becomes a mission-critical server. It's easy enough to increase its resource priority after the fact, but this is one area where you don't want to run blind. And don't spend on automation if the overall capacity of the infrastructure is lacking. If you're barely able to satisfy your current workload, the last thing you need is new machines being rolled out without human intervention.

Informed CIO: Private Cloud Automation

Our full report on automating the private cloud is available free with registration.

This report includes 14 pages of action-oriented analysis. What you'll find:

Get This And All Our Reports

Set Goals

Determine what you want to accomplish with your automation initiative. Do you need self-service machine provisioning? Automated responses to changing infrastructure conditions? How about policy-based virtual machine and application life cycle management?

If the intent is to monitor application performance and spin up additional application servers when demand peaks, the plan is going to be different than if self-service provisioning with departmental chargeback is the primary goal. Formulating a concrete set of objectives is essential to the evaluation phase of your automation project.

Then, since product capabilities vary widely, map that goals list to feature requirements. How easy or difficult it will be to make that match depends on the underlying virtualization and management platforms you're dealing with. A full-featured automation product will need to plug into multiple silos to gather the information it needs to make policy-based automation decisions. This means integrating all relevant server, storage, and network virtualization technologies as well as maintaining accurate licensing and consistent configuration information. Depending on how your network is set up, every one of these resources could be a silo, making integration daunting. Survey respondents with a private cloud strategy underscore that point: 58% say integrating existing IT products with cloud is a major issue.

Because integration can be such a challenge, it's important to delve deep into the compatibility matrix of any prospective product before writing a check. If a vendor provides few hooks, it may be impossible to link policy engines without an absurd investment in labor. How absurd? A 2-to-1 or 3-to-1 investment in expert consulting services or internal staff commitment vs. software costs before the benefits of automation are apparent isn't unheard of.

Why? Again, a lack of standards.

That brings us back to goal setting. When it comes time to dig into the details, automation requires that you have a very clear idea of what you want to accomplish so you can create workflows and processes that are repeatable, consistent, trustworthy, and (this is key) reusable. Take incident response: Say an application server has a meltdown that jeopardizes the availability of a key software system. If the application is in a well-constructed app server farm, other servers should continue to meet client demand, but at a higher load with reduced efficiency. If one goal of your automation initiative is a self-healing response to the loss or degradation of an application server, many variables must be considered before an automatic action is taken. We provide examples of goals and their related processes in our full report.

What You Get For The Money

For large enterprises, the cost of these suites can easily reach six figures and climb to $300,000 or more, depending on the level of automation and customization required and the size of the infrastructure. For your licensing investment, you get a task engine that can react to data by triggering workflows and whatever set of common integrations and functionality the vendor bundles; self-service provisioning Web portals, a virtual machine optimization scheduler, or some basic VM power management policies are commonly included.

What you don't get are workflows specific to your network, application portfolio, and business processes. That's why the single most important step is to carefully scope goals and requirements, identify overlap, and conduct a thorough cost-benefit analysis before tackling an automation project.

Still, it's worth getting started. Survey respondents who have private clouds say they've gotten excellent results in terms of reducing operational and capital expenses as well as managing their IT teams' time. Better resource usage overall, life cycle management, and automated provisioning--all very achievable goals--can easily make the effort and expense worthwhile.

InformationWeek: June 25, 2010 Issue

Download a free PDF of InformationWeek magazine
(registration required)