Photo-K - Fotolia
A successful DevOps workflow depends on consistent underlying IT infrastructure, but few developers can -- or want to -- manage subnets and other infrastructure configurations.
Instead, infrastructure engineers take on this role, using automation and an infrastructure as code (IaC) methodology. For DevOps in the cloud, AWS infrastructure operations teams should deploy infrastructure via CloudFormation templates with OpsWorks configurations to manage infrastructure more efficiently. Some teams will even take AWS infrastructure management into CI/CD, with version control repositories, just like their developer teammates.
DevOps processes are incompatible with manually built, slowly documented infrastructure configurations. Even automation is not enough if it simply repeats an exact procedure written out by an infrastructure admin. Organizations should switch from these imperative models -- where an admin or automation tool follows a specific process to get a consistent outcome -- to a declarative model.
Declarative infrastructure management tools deploy and change IT resources as needed to match the desired state described in a configuration file. Every new deployment and change should occur in the source files, driven through configuration management onto the live systems, which eliminates the need for manual changes. In this setup, the configuration files are the infrastructure engineer's most crucial assets. Configuration files are often stored in a version control system, just like software source code. Past configurations, also kept in the version control system, can be used to roll back changes to the last known-good state.
AWS infrastructure management tools
CloudFormation. CloudFormation is the primary IaC tool for AWS deployments. CloudFormation templates accommodate most of AWS' offerings, and engineers can update templates to make changes to existing infrastructure. AWS operations teams should commit CloudFormation templates to version control as soon as possible.
Typically, users build an AWS deployment through a series of templates that address layers of the infrastructure. This design pattern enables companies to reuse templates across environments. For example, all of the company's applications on AWS can share standard template layers for security with Identity and Access Management, hosting with Amazon Virtual Private Cloud and other services, while the data, application and presentation tiers are unique.
Templates can also have a conditional configuration, which enables flexibility throughout the application lifecycle. For example, one application can be associated with two data-tier templates -- one for production and one for development. The production data-tier template includes high redundancy, while the development-tier template uses lower-cost infrastructure without as much uptime assurance. At deployment, the DevOps engineer directs CloudFormation to use the appropriate template.
OpsWorks. CloudFormation can set up EC2 instances and other AWS infrastructure, but it does not have sophisticated functionality to manage the OS and applications on these instances. AWS OpsWorks configures software on the infrastructure services. OpsWorks links with CloudFormation and can trigger application configuration and decommissioning as AWS spins up and destroys instances.
AWS users have the option to work with Chef or Puppet through OpsWorks. Chef calls configuration files recipes, while Puppet has manifests. Both technologies describe the application's desired state on the AWS instances. Recipes and manifests should be stored in a version control system and used for deployment and updates.
CodeCommit. To take AWS infrastructure management into a true DevOps approach, the operations team can use an AWS version control repository for its configuration files. CodeCommit provides private Git repositories, where infrastructure managers can store and update CloudFormation templates, as well as recipes or manifests for OpsWorks.
CodePipeline. CodePipeline is part of AWS' CI/CD-as-a-service offering. Advanced users set up the service to take automated actions when they check in new versions of configuration files. Not all operations teams are ready for CloudFormation template changes to automatically update live environments, but the option is available.
Imperative automation. In addition to declarative tools, such as CloudFormation and OpsWorks, there are plenty of AWS infrastructure management options for imperative configuration. AWS Command Line Interface is a shell script full of commands to build infrastructure. DevOps teams can also use AWS API bindings for their preferred programming language, such as Python or PowerShell.
Pick up these options as needed, but be mindful that imperative scripts require more work to create and maintain than declarative configuration files.