Mathias Rosenthal - Fotolia
When to use AWS OpsWorks vs. CloudFormation or Elastic Beanstalk
There are multiple ways to define and deploy resources on AWS. Break down when to use the different AWS configuration management tools and how they integrate together.
IT teams can programmatically deploy and dispose of entire application stacks on AWS -- and they have multiple ways to do so.
That range of options on AWS can make it difficult to choose the best configuration management tools or practices. Let's compare a trio of Amazon cloud services -- AWS OpsWorks vs. CloudFormation vs. Elastic Beanstalk -- IT teams can implement to deploy and configure applications. These services can be used separately or together, depending upon your needs.
Use CloudFormation to deploy AWS resources
AWS CloudFormation is a declarative tool best used to deploy infrastructure required for simple applications, such as a website that requires few updates or when the whole infrastructure instance can be replaced for each update. The declaration takes the form of a CloudFormation template -- a text file that describes what AWS resources to deploy for infrastructure and applications. CloudFormation reads the template and deploys the described infrastructure. Developers can also use shell scripts in CloudFormation, though those scripts have limited configuration capabilities inside EC2.
Developers can apply change sets in their templates to modify their infrastructure stack. They preview the changes they want to make to their stack -- for example, adding or removing existing AWS resources -- and then decide whether to have CloudFormation execute those changes. But change sets can't apply updates inside a deployed EC2 instance or application, as CloudFormation only manages resources and doesn't orchestrate infrastructure.
OpsWorks vs. CloudFormation: Manage EC2 configuration
With AWS OpsWorks, developers can deploy Puppet or Chef to manage declarative configurations within EC2 instances. Like CloudFormation, you can use OpsWorks to deploy AWS resources. However, OpsWorks automates the initial deployment of applications, as well as the ongoing changes to the operating system and application infrastructure. Both Puppet and Chef can also control the deployment of AWS infrastructure.
You should use OpsWorks in place of CloudFormation if you need to deploy an application that requires updates to its EC2 instances. If your application uses a lot of AWS resources and services, including EC2, use a combination of CloudFormation and OpsWorks.
When to use CloudFormation with OpsWorks
IT teams can integrate CloudFormation with OpsWorks to configure newly deployed EC2 instances with Chef or Puppet, rather than simple shell scripting. In this deployment model, use CloudFormation to deploy all of the AWS resources for your application, and use OpsWorks to do the detailed configuration of the operating systems and infrastructure. Changes are deployed in the same manner -- CloudFormation for AWS resource changes, and OpsWorks for the operating system and application changes.
Elastic Beanstalk vs. CloudFormation
Many applications are just active websites accessed directly through a web browser, or indirectly through another application, possibly on a mobile device. AWS Elastic Beanstalk is a provisioning service that deploys the required infrastructure for a web application. This frees you from having to define and deploy the required infrastructure so you can launch web apps quickly.
Elastic Beanstalk deploys the required web servers and configures auto-scaling, monitoring, logging and alerting for you. If your application fits entirely inside Elastic Beanstalk, then you may not need additional tools.
Most likely, however, your application will need other AWS resources, such as database or storage service. In this scenario, use CloudFormation to deploy Elastic Beanstalk along with the other resources.
Declarative configuration
It's possible to provision your infrastructure with scripts full of command line interface (CLI) commands, but this is the least efficient method of AWS resource deployment. CLI scripting is an imperative model that specifies every command to be executed and must be custom written for every application. You also have to enforce a process for error checking and handling on top of this labor.
A far more straightforward method is to use the declarative tools mentioned above, where a text file describes the required state and a deployment engine manages the actual deployment. This way, the deployment engine does the error checking and handling and doesn't have to be redeveloped by each user. The text file is much easier to create and can be stored in a version control system for an infrastructure-as-code approach. This declarative text file only has the deployment specifics for this user and this application.
