Back to Blogs, News & Events

What is Infrastructure as Code?

Infrastructure as Code

What is Infrastructure as Code?

Infrastructure as Code (IaC) is a method of technology creation, definition, and management where manual steps are eliminated from the creation of an IT Infrastructure hosting application workloads.

The cables, wires, components, connections, plugs, and underlying resources used to deliver application workloads are all hidden from the administrator and ultimately the end-user through a software-defined overlay which can be referred to as a “Cloud Fabric”.

IaC is also sometimes referred to as programmable or software-defined infrastructure. It is a relatively new type of technology capability built using descriptive model source code files that define the connection topologies and underlying resources on which a workload resides.

Of course, there are still cables and wires connecting the resources and networks executing the workload and presenting it to the users consuming that workload. The connections and resource pools still physically exist but they are hidden within the Cloud Fabric which is a software-defined layer that sits on top of the resources.

Different flavours of cloud each have their own specific overlay, for example, the overlay provided on an OpenStack Cloud is different from the overlay provided by Microsoft for their Azure Platform or the overlay provided by Amazon on their EC2 platform.

Cloud Fabric – the Software-Defined Layer

One thing that is common across all platforms though is that the overlay or software-defined capabilities are initially physically set up by the installation of the underlying Cloud Fabric.

The Cloud Fabric (software-defined layer), is presented to the outside world via an Application Programmable Interface (API) and potentially a Graphical User Interface (GUI), which is usually a web portal, which makes it easier for humans to visualise both the Cloud Fabric and its underlying processing/storage resources, services, and connecting networks.

Once the software-defined overlay is installed the resources, services, and networks required to host a workload can then be configured into the architecture required to host the workload at the time of deployment through software-defined automation, which is usually a script or in some higher-level tooling a drag and drop visual representation of the architecture to be deployed.

This code is then ultimately transmitted to the hardware through a REST-based API which leverages the capabilities built into the Cloud Fabric itself to provision the workload along with the resources and capabilities it requires to execute.

The Cloud Fabric provides the required resources to the workload and connects it to whatever networks or downstream services are required for it to function. Routers, switches, servers, and firewalls run the IaC layer, but for our illustrative purposes here let’s assume that they’re all virtual and we are building an abstracted virtual machine hosted workload.

So why should I use Infrastructure as Code?

By using Infrastructure as Code, developers and their corresponding operations teams can automatically manage, monitor, and provision resources directly via scripts. They no longer have to configure discrete hardware devices and operating systems manually. Each time they want to deploy a workload, they simply call functions within the software-defined overlay programmatically, and the resources get set up automatically.

Resources can also be de-provisioned or torn down in the same way, so it makes it simple to iterate workload deployments for each new version of code deployed. Tearing down resources and wiping the environment clean before each deployment cycle is referred to as ‘Immutable Infrastructure‘ and prevents anything from being left around in an environment that could adversely affect the next deployment cycle.

An immutable infrastructure is an approach to managing services and software deployments on IT resources wherein components are replaced rather than changed. An application workload or service is effectively redeployed each time any change occurs.

In practice, IaC is very similar to software programming and leverages deployment scripts to automate IT processes. The contents of the deployment scripts are specific to the underlying Cloud Fabric that they are configuring.

Common Scripting Languages and Cloud Fabric Templates

Whilst each type of script will have its own format and code “Language” which is specific to its own particular flavour of underlying Cloud Fabric, one commonality in any type of IaC script is that they are primarily used to automate a series of static steps that are repeated numerous times across multiple resources.

An Azure Resource Management (ARM) Script used to configure a Microsoft Azure deployment will be different from a Heat Script used within an OpenStack deployment, which in turn will be different from a CloudFormation Script used within an AWS deployment.

Examples of common scripting languages and their associated Cloud Fabric specific templates used within IaC for the most popular providers are:

  • JSON and Resource Orchestration Service (ROS) Templates – Alibaba Cloud
  • JSON or YAML and CloudFormation Templates – Amazon Web Services (AWS)
  • Python and Cloud Deployment Manager Templates – Google Cloud Platform (GCP)
  • Powershell and ARM Templates – Microsoft Azure
  • Python and Heat Orchestration Templates (HOT) – OpenStack
  • YAML and VMware Cloud Templates – VMware vRealize Automation (packaged) and vRealize Automation Cloud (SaaS) version 8.2 onwards

Infrastructure as Code uses higher-level or descriptive language to code more versatile and adaptive provisioning and deployment processes.

In terms of implementation, IaC is not a world apart from software application code used to build apps – in that it is a “descriptive model” for defining and provisioning the structure of an IT capability, its dependencies, and associated physical resources.

That descriptive model also includes specifications to detail data storage capacities and capabilities, server structures, and other associated base elements such as load balancers, permissions, and agents to be installed for monitoring and security.

The descriptive model should also be able to call additional configuration scripts or inject the parameters directly into the agents and resources deployed to facilitate communication with their management systems.

When IaC is ‘done right’ the descriptive model within the script deploys everything in the correct order to get the workload and its management tooling into a fully operational state without ANY manual intervention.

What Next?

For help with your journey to the public cloud, get in touch to find out how CSI can support you with Infrastructure as Code services and building a secure foundation in the cloud.