The very nature of the cloud materially separates the cloud user and the resources they are provisioning and consuming. This eliminates the possibility of being able to physically troubleshoot non-performant or failed devices. This necessitates the digitization of all functionality that was done by walking to resources and interacting with them. This is certainly not the sole reason, but it was a leading design imperative in the nascent days of the cloud. CSPs have built their platforms from the ground up with APIs. Each service and feature can be utilized, configured, consumed, or otherwise interacted with programmatically through a set of defined APIs. The syntax, descriptions, command-line interfaces (CLIs), and usage examples are published and maintained by each CSP and are available for free for all to scrutinize and utilize.
Once software defined configuration had taken root, it became possible to express the whole IT environment or stack through code. The concept of Infrastructure as Code (IaC) was born. Many of the same concepts, approaches, and tools that developers used to collaborate, test, and deploy their applications could now be applied to infrastructure (compute resources, databases, networks, and so on). Suffice to say this development has been one of the largest contributions to the rapid advancement of IT systems in general, as it allowed infrastructure architects to iteratively evolve their systems as quickly as developers.
In order to set up a highly available, scalable, and resilient application, it is important for cloud architects to adopt many of the principles at the heart of software development today. We will cover this in more detail in Chapter 8, Cloud Native Operations, but the evolutionary approach afforded by treating your IaC is the enabling factor to reach a high stack maturity (that exhibits high levels of availability, scalability, and resiliency). Do not assume that your cloud-native application will be mature and resilient from day one. With each day, new efficiencies and failovers must be built into it. This evolutionary approach is core to achieving success (often called the "cloud journey" in industry parlance).
Building upon Figure 5.6, we can now define our entire cloud network infrastructure as a code template (we will call this the network stack), as shown in the following diagram:
Everything within the gray dotted line is defined as code within the network stack template. Any changes that need to be made to the network stack can be managed by making changes to the code contained therein.
Building upon Figure 5.4, we can see one approach to managing an application with IaC. The web server configuration, auto-scaling group, and elastic load balancer are defined and managed in the Web Stack Template. The database configuration and resources are managed in the Database Stack Template, as shown in the following diagram:
There are native cloud services and third-party options to use here. AWS CloudFormation, Azure Resource Manager (ARM), and GCP Deployment Manager are examples of native CSP services. Code can often be written in JavaScript Object Notation (JSON) or Yaml Ain't Markup Language (YAML), previously known as Yet Another Markup Language.
A popular third-party tool is Terraform by HashiCorp. Terraform works across all major clouds and on-premise, allowing users to create a unified IaC landscape across a hybrid infrastructure environment. Terraform supports its own format for configurations (otherwise known as templates), creatively named terraform format, but JSON is also supported. While not strictly IaC, there are many tools that perform configuration management, such as Vagrant, Ansible, Chef, and Puppet.
A mature deployment in AWS, for example, would utilize both CloudFormation with a configuration management tool such as Chef to automate and reduce deployment errors.