Uniting the Cloud Through App Automation

Ten Reasons Why OpenStack Will Rule the Enterprise

It’s common knowledge that if the enterprise hopes to make the most of new virtual/cloud infrastructure it will have to embrace a high degree of automation. But if the whole point of getting on the cloud is to offload infrastructure responsibilities to someone else, how will the enterprise be able to effectively automate this new environment?

The answer is to simply move your focus higher up the stack, to the application layer. Application automation has long been a fixture in enterprise settings as organizations look to streamline the development and deployment process. These days, the need to effectively coordinate app-level operations across disparate infrastructure has made automation a must, which has led most system developers to embrace cloud-ready functionality as an integral component of their platforms.

Appcara’s latest release of the AppStack automation and migration system, for example, features a new Onboarding Agent that allows Windows and/or Linux servers to be managed through the Appstack portal regardless of whether they reside on the physical, virtual or cloud plane. This allows users to manage storage, security, monitoring and other functions no matter where the app goes or what resources it compiles. The system is optimized for Citrix environments through support for the Citrix CloudPortal Business Manager, and it enables automated deployment of XenDesktop environments through the AppStack Marketplace, a collection of prepackaged enterprise applications that are available for rapid provisioning.

Meanwhile, a company called Epic Force has just come out with Leroy, an application deployment engine that allows customized workflows to act as either standalone automation processes or to work in conjunction with other leading systems like Jenkins or Team City. The system works by providing a simplified programming language that oversees deployment operations across multiple environments, providing end-to-end service wherever enterprise infrastructure leads. It uses an agent/controller format that bypasses traditional port access in favor of direct on-line communication, giving apps on-demand access to all configuration files and artifacts needed for deployment and provisioning. And Leroy is available for free under the creative commons license.

With enterprise infrastructure becoming increasingly software defined, it shouldn’t come as a surprise that automation stacks are, as well. StackIQ has a new version of its Cluster Manager that enables software-defined automation for Red Hat Storage environments. The system is optimized for cloud computing, Big Data, HPC and other hyperscale environments, offering a full suite of tools needed to install, configure and manage storage infrastructure and applications. With open environments like Linux usually residing on commodity infrastructure, automation systems like StackIQ are often the only way to integrate components into a cohesive environment.

A key step in the application automation puzzle, however, is the initial migration from the physical to the virtual layer. But while many enterprises are gung-ho on the prospect of migration automation, the percentage that insists on doing so manually is surprisingly high. According to IDC, about 60 percent of respondents in a recent survey said they have already implemented automation processes for their virtual migration projects or plan to do so in the next year. That means 40 percent seem content on keeping things manual for the time being. And a deeper dive into the numbers suggests that those who have gone the automation route have limited themselves to key steps in the process like app identification and rationalization. Other crucial steps, like fix/package compatibility issues and even the actual deployment, are generating little interest in automation.

Frankly, this should not come as a big shock to anyone, considering the idea of a fully automated, hands-off data infrastructure is rather unnerving. When things go wrong, someone’s job is usually on the line and it does no good to tell the front office that “the automation system fouled up.”

A targeted approach to automation, then, will probably be in order for the time-being—one that covers much, but not all, of the application environment. The enterprise can’t reach directly into third-party infrastructure and start messing around with hardware, but it can certainly enforce some ground rules as to how its apps, and the data they generate, should be treated.