While automated deployment tools are nice to have when deploying applications, they are not considered a necessity. However, that perception is changing as organizations see the benefits of automation. In fact, experts say automated application deployment tools are a requirement when hosting an application in the cloud. Because the tools used for on-premise deployment may not be capable of deploying to the cloud, organizational leaders should consider which tools they need when making the choice to host on-premise versus the cloud.
Oftentimes, organizations fail to consider how they’ll get their applications to the cloud until they’re ready to do so. “Deployment in the cloud is attached to the whole idea of running the application in the cloud. People don’t say, ‘Should I automate my deployment in the cloud?’ It’s, ‘Should I run it in the cloud?’ Then, ‘How do I get it to the cloud?'” says Paul Burns, president and analyst, Neovise.
Not only is deployment an afterthought, it is a surprising one at that, says Burns. Organizations find themselves having to either retrofit their existing scripts and tools to work with the cloud or adopt an automated tool to get the job done. The preferred method: the use of an automated tool.
“I would argue that using a deployment tool regardless of where you’re deploying is really a best practice,” says Theresa Lanowitz, founder and analyst, voke Inc. “You end up with much better quality if you’re using deployment tools anywhere.”
There are two types of tools that automate application deployment to the cloud: those that deploy existing applications that weren’t designed to run in the cloud and tools that deploy new applications developed natively for the cloud. The tools designed for existing applications, explains Burns, put a “wrapper” around the application to insulate it from the cloud. The tool then pushes the application out to the cloud, and the application doesn’t necessarily know the difference between where it’s running, be it on-premise or in the cloud, says Burns.
The tools used for deploying new applications built specifically for the cloud can “work with the whole stack,” says Burns, “from the hardware up to the application and everything in between.” For example, the tool may reserve the necessary servers and build them from the ground up, deploy the application across multiple servers, and adjust the rest of the IT environment, including switches, routers, firewalls, storage area networks, etc.
The benefits of using automated deployment tools
Automating each of these steps in the deployment process offers significant benefits, including efficiency. “You could do these things manually, but it is time consuming,” says Burns. “The productivity difference is really high.”
For organizations that are accustomed to developing and deploying applications that are hosted on-premise, setting up automated deployment tools does introduce a new step in the software development process that has a learning curve and an investment associated with it. “But the payoff is pretty quick because every time you do a round of development, you can quickly deploy out to the cloud and do the test process,” says Burns. “Getting things set up for the first time is a challenge, but it’s totally worth it.”
Automating application deployment also improves overall software quality. “Using good tools across the entire lifecycle, and that includes deployment, minimizes the amount of human intervention that we actually have; the time we depend on some person doing something manually. When you can remove that, your quality becomes more predictable, it becomes better,” says Lanowitz.
Considerations when choosing a tool
There are a couple factors that organizations should take into consideration when choosing an automated application deployment tool for cloud-hosted apps, and they depend largely on internal development processes and strategy. One factor to think about, says Burns, is change and configuration management capabilities.
“Can the tool replace one part of the application without having to replace the whole thing? A pitfall would be having a tool that doesn’t allow you to handle ongoing changes,” says Burns – if that’s the approach you want to take. Some tools require you to redeploy the entire application after changing any part of the application. “It’s a benefit if you can change one piece,” says Burns. “But some people are saying, ‘Hey, forget that whole mess… these tools are fast enough. Deploy the whole thing.’”
Ultimately, says Burns, it’s up to you, but you need to choose a tool that supports your internal change and configuration management strategy.
Another factor to consider when evaluating a tool is whether or not it supports multiple public clouds. “You can get a tool that’s all fancy and nice and quickly deploys your application to Amazon, but will it do the same thing for Rackspace?” says Burns. Again, this requires some forethought and understanding of future plans for application deployment.
Burns advises organizations to try free editions of the tools before making a purchasing decision. But, eventually, you will need to buy something. At that point, he says, “Instead of buying everything upfront, buy it as you use it.”
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
This was first published in March 2012