Treating Your Infrastructure as Code

In the previous chapter, we familiarized ourselves with AWS. We also created an EC2 instance and deployed a Hello World web application onto it. However, to get there, we had to go through a number of steps to configure the instance and its security groups. Because we did that in a very manual fashion using the command-line interface, the steps that we went through will not be reusable or auditable, as you may recall from the first chapter when implementing DevOps best practices. Two key concepts that you should rely on as often as possible are source control (version control) and automation. In this chapter, we will explore how to apply those principles to our infrastructure.

In a cloud environment, where almost everything is abstracted and served through the intermediary of virtual resources, it is easy to imagine that code can describe the topology of a network and the configuration of a system. To go through that transformation, we will learn about two key concepts in an effective DevOps organization. The first one is commonly called Infrastructure as Code (IAC). This is the process of describing all your virtual resources in the form of codes. These resources may include virtual servers, load balancers, storage, the network layer, and so on. The second concept, which is very close to IAC, focuses further on system configuration and is called configuration management. Through configuration management systems, developers and system administrators have the ability to automate operating system configuration, package installation, and even application deployment.

Going through that transformation is a crucial step for any DevOps-focused organization. By having the code to describe the different resources and their configurations, we will be able to use the same tools and processes as we do when developing applications. We will be able to use source control and make smaller changes to individual branches, as well as submitting pull requests, following standard review processes, and finally, testing changes before they are applied to our production environment. This will give us better clarity, accountability, and auditability for infrastructure changes. Because of that, we will also be able to manage a much bigger fleet of resources without necessarily needing more engineers or without spending a lot more time operating all the resources. This will also open up the door to further automation, as we will see with continuous deployment in Chapter 5, Adding Continuous Integration and Continuous Deployment. In this chapter, we will cover the following topics:

• Managing your infrastructure with CloudFormation
• Adding a configuration management system