Infrastructure as Code
Deployment Architectures
In this section we primarily cover deployment architecture for workload. We will not cover the application architectures within those workload, but we will focus on architecture models that can be used to manage the deployment of different types of workloads, but with a focus on workloads that already exists - perhaps as an on-premises workload or a workload already in the public cloud.
The core objective of our deployment model is to maximize the level of automation that can be used to deploy a workload. In an on premises environment many differing tools are often used to manage different technical architectures. Each distinct class of deployment will come with it’s own deployment and management tools; e.g. a virtual machine farm, a mainframe, a “big” unix environment and so on. However, with a public cloud there will be a consistent management capability that covers every model and these will always be accessible through APIs. This open up the possibility for very high levels of automation for all workloads and the target model of “Infrastructure-as-code”.
tip
Implementing an Infrastructure-as-code also has a huge benefit when workloads are being migrated to cloud. In an on-premise environment, it may be the case that environments have been up-and-running for many years and the original deployment is most likely to have been done manually. However, in the cloud any migration will inevitably go through a series of deploy-destroy cycles where the entire cloud environment is regression tested and optimized. In addition, most applications will have multiple deployments (e.g. dev, test, training, acceptance test, path-to-live etc). The result of this is that any cloud migration can benefit to a very large extent from automated deployment.
It’s worth noting here that the move to public cloud can enable a very different model for providing the multiplicity of environments needed for critical applications. In a large number of cases in an on premises environment, dedicated hardware is often allocated to cover the maximum environment size required. This can lead to low server utilization and high levels of unused machine capacity as different environments are used over an application’s lifecycle. However, in the public cloud, and if we have automated deployment as Infrastructure-as-code, then environments can be created and destroyed on demand.
In the next few sections we will cover the architecture principles that we should use when designing and coding for Infrastructure-as-code using Terraform.
Background
System administrators have used code and scripts to manage infrastructure for decades, and the best sysadmins will have versioned and managed their code. So, what’s so different about Infrastructure-as-code?
The challenge with scripts is always that they act on a target which has an unknown or partially known state. Even with the best governance, manual changes, failed changes, and bugs in scripts often leave the physical deployment in an indeterminate state. Subsequent execution of scripts make the problem worse, and so, over time, issues accumulate, failures increase and environments which are supposed to be the same drift over time.
One option for IaC is to put all those scripts which build and maintain environments in strict version control and to focus them on script resilience and repeatability against targets in unknown configurations. This approach can be considered as one type of IaC often referred to as the imeratative approach. Scripts are often organised at Playbooks which take a configuration from one known state to another - giving repeatability.
The second type of IaC is the declarative approach. This is the approach that we will focus on as it is most suited to cloud environments. The core feature of a decarative Infrastructure-as-code approach is the addition of a virtual model of the physical hardware. The virtual model is both human and machine-readable, and has a strong link to the physical deployment through a very high degree of automation. The physical model is, critically, only managed through the virtual model - no manual or even automated changes to the physical deployment should be allowed. The virtual model is strongly version-controlled and governed through similar processes and tools to the code development lifecycle (hence the “…as-code”).
In the following sections we will describe how this is achieved with the use of Terraform as one of the leading IaC tools, and the recommended tool for OCI.