Intro to IaC

Get to Know Your Toolkit 

Now that we’ve established what IaC is, we can start thinking about some of the tools used for infrastructure as code. Many tools fall under the IaC umbrella, including Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Ansible, Puppet, Chef, SaltStack and Pulumi. It’s important to understand that some of these tools have different use cases, each with its own benefits. Due to the varied use cases of these IaC tools, having infrastructure provisioned, configured and deployed end-to-end will require using a combination of IaC tools rather than a single solution. To better understand these tools, this task will cover some of the key characteristics which distinguish these tools from each other so you know what tool to use and when. Bear in mind that the behaviour of these tools can often depend on exactly how they are used, often leading to debate over some of their characteristics; with this in mind, we will define those characteristics in question and how each tool is generally used.

Declarative vs. Imperative 

First off, let’s establish the difference between declarative and imperative (also known as functional and procedural) IaC tools:

Declarative

This involves declaring an explicit desired state for your infrastructure, min/max resources, x components, etc.; the IaC tool will perform actions based on what is defined. A state file is kept to ensure your infrastructure’s current state matches the desired state. In other words, it focuses on the what rather than the how. A declarative IaC tool is usually idempotent, meaning the same result will be achieved when run repeatedly. This is because that check is done against the state file, and if the infrastructure is already provisioned, it will make no changes if rerun. Examples of declarative IaC tools are Terraform, AWS CloudFormation, Pulumi and Puppet (Ansible also supports declarative). 

Imperative

This approach involves defining specific commands to be run to achieve the desired state; these commands need to be executed in a particular order. Imperative IaC is usually not idempotent in that if you run these tools multiple times, the same result won’t be replicated, or the tool may run into some configuration issues. This is because these commands will be run regardless of the state of your infrastructure, so running these commands on an already provisioned infrastructure may cause additional unwanted infrastructure to be added or may break the configuration of some existing components (depending on the set-up of the infrastructure and the commands being run). Examples of imperative IaC tools: Chef is the best example of an imperative tool; however, SaltStack and Ansible both support imperative programming as well.

Imagine it like directions to an X on a map, where imperative will give you a list of directions which will bring you to X if you are at the known start point (e.g., an unconfigured server). However, if you are not at this known start point (e.g., a partially configured server), you will not arrive at X but somewhere slightly different. Declarative takes into account where you are on the map and works out which directions need to be taken to get to X from that point. Deciding which to use can depend on what your infrastructure needs are. Declarative is considered a more straightforward approach that is easier to manage, especially for long-term infrastructure. In contrast, imperative IaC is more flexible, giving the user more control and allowing them to specify exactly how the infrastructure is provisioned/managed rather than the tool itself taking care of it.

Agent-based vs. Agentless

Agent-based vs Agentless is a term that extends beyond infrastructure as code and is also used in the context of monitoring and security tools. In the context of IaC:

Agent-based

An “agent” will need to be installed on the server that is to be managed. It runs in the background and acts as a communication channel between the IaC tool and the resources that need managing. This agent is responsible for executing and reporting on the state of the infrastructure/managed resources. Note that this agent must be installed on every target system/node that needs to be managed. An agent-based IaC tool can perform tasks even when the system has limited connectivity or is offline, making it a robust choice for automation; however, you need to take care with maintenance when using these tools, monitoring the agent software closely so it can be restarted in the event of a crash.

Another thing to consider with agent-based IaC tools is that some of these tools will require opening ports on the server for inbound and outbound traffic so that the agent can push/pull configuration information; from a security perspective, more open ports are negative. Despite this, they offer a level of granular control over managed resources and can collect more detailed monitoring data. Because of this, they might be ideal if control is an important factor in your setup. Some agent-based IaC tools: Puppet, Chef, and Saltstack.

Agentless 

Agentless IaC tools, as you may have guessed, do not require agents to be installed on target systems. Instead, these tools leverage existing communication protocols like SSH, WinRM or Cloud APIs to interact with and provision resources on the target system. Agentless IaC tools benefit from being easier to use; their simplicity during set-up can mean faster deployment time, and their agentless nature can also mean the tool can be deployed across multiple environments without custom agent changes needing to be made based on each environment’s needs, making it a flexible choice. Also, compared to agent-based IaC tools, there is less maintenance and no risks surrounding the securing of an agent. However, agentless IaC tools generally have less control over target systems than agent-based tools. Agentless tools are useful in environments which have to adapt to fluctuating workloads, with resources being created/destroyed to meet these workloads. These newly created resources can be managed without having to rely on pre-installed agents. Agentless IaC tools: Terraform, AWS CloudFormation, Pulumi and Ansible.

Once again, both options have their advantages and disadvantages. Infrastructure provisioning and configuration can present developers with a very particular set of problems, and choosing the correct tool for the job, depending on what needs to be done, involves taking these into account.

Immutable vs. Mutable 

Immutable vs mutable infrastructure refers to whether or not changes can be made to an infrastructure. To define both, let’s imagine we have a simple infrastructure, a virtual machine with a web server and application. If you want to change this infrastructure, for example, deploy some application code to your web application, this code will mean your web application will go from version 1 to version 2. How might that look for each?

Mutable

Mutable infrastructure means you can make changes to that infrastructure in place. So, in our current example, we can upgrade the application on the server it’s currently running on. The advantage here is that no additional resources need to be provisioned for this update, with the resources already being used just needing to be changed. Where mutable infrastructure starts presenting issues is, imagine your web application update contains three changes, and whilst these updates are being made, one of the changes fails to apply. This is a common occurrence in development and can occur for several reasons, such as application misconfiguration or a network dropout. Now running on your server will be a web application version with two of the three changes required to be version 2. In other words, it’s no longer version 1 anymore but not quite version 2 either. When an application is updated in a production environment, it will have been tested first in development and staging environments. What won’t have been tested is this halfway version, leading to all kinds of potential issues. Imagine now that this update was not just rolled out on a single server, but many, maybe some updates succeeded, and some failed with errors in different changes. You can see how this can become an issue very quickly with different versions of the web application existing across many servers. 

Immutable

Immutable infrastructure means you cannot make changes to it. Once an infrastructure has been provisioned, that’s how it will be until it’s destroyed. Now, let’s apply that to our example. When this new version 2 of the web application is deployed, an entirely new infrastructure will be deployed with this new version. Now, you have two infrastructures stood up: one with version 1 of the web application and one with version 2. However, if all of the changes are implemented successfully (and only if they ALL are; otherwise, if it fails, the infrastructure will be torn down, and the process will be retried), the version 1 infrastructure can be torn down. This approach has some drawbacks, as having multiple infrastructures stood up side by side or retrying on failed attempts is more resource-intensive than simply updating in place, but it allows for consistency across servers. You know with certainty that x server is running version 2 of the web application.

Immutable IaC tools: Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Pulumi (some of these tools can be configured to be used with a mutable infrastructure but work better with an immutable approach)

In the example given, it makes more sense to use an immutable infrastructure. However, to demonstrate further that each can have its own use case, imagine the server instead is a critical database system that requires regular maintenance updates and patching. If you were to use an immutable infrastructure for this, the critical database would have to be rebuilt from scratch every time, which can be a risky process when dealing with business-critical data. So, in this instance, it might make sense to use a mutable infrastructure.

Provisioning vs. Configuration Management 

All the characteristics discussed in this task so far are behavioural; in other words, how does this tool work? This way or that way. Considering what a tool's purpose is and when it is used in the development of infrastructure will tell us whether it is a provisioning tool or a configuration management tool. You might see these primary functions defined differently elsewhere, for example, infrastructure as code vs. configuration as code, but to determine which tool falls into which category, you simply need to ask, "What can it do?". If we think about four key tasks: Infrastructure provisioning (the set-up of the infrastructure), infrastructure management (changes made to infrastructure), software installation (initial installation and configuration of software/applications), and software management (updates made to software or config changes).

There is no single tool that can perform all 4 of these tasks. Instead, combining two tools, a provisioning tool and a configuration management tool, is common practice to cover all these. There will be a practical example of exactly what tools can cover which tasks in the static site coming up. Some examples of each type of tool:

Provisioning tools: Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Pulumi

Configuration management tools: Ansible, Chef, Puppet, Saltstack

Let’s consider a real-life industry example of how these two types of tools might be used. Say you work for a company which needs to set up a new infrastructure for a web application. A similar one has been deployed before and fell prey to some malicious activity, so this time, you will install an agent to monitor for this activity. The infrastructure would be defined and provisioned using a provisioning tool like Terraform, and then a configuration management tool like Ansible would be used to install an agent within the provisioned infrastructure to monitor for malicious behaviour. 

Put That All Together

Now, you’ve been introduced to the world of infrastructure as code tools and their various uses. Each has its characteristics which best suit different use cases and scenarios. In that way, they are no different to physical tools; you have to assess the problem and choose the best tool to address it. Here's a little summary of what we've discussed, as well as a little bit more information about some of the tools mentioned:

Terraform: is a declarative, agentless infrastructure provisioning tool that works with immutable infrastructure. Terraform is one of the most popular infrastructure provisioning tools out there, allowing for the management of infrastructure across multiple cloud providers like AWS, GCP and Azure.

Ansible: is a hybrid, typically agentless configuration management tool that works with mutable infrastructure. Another example of a massively popular tool in the DevSecOps space. It's slightly harder to categorise than some of the other tools, because of how this tool functions and what it does can depend on how you employ it. For example, there is much discussion over whether Ansible is an imperative or declarative tool. In reality, Ansible is sort of a hybrid in a sense.

Pulumi: is a declarative, agentless infrastructure provisioning tool that works with immutable infrastructure. Pulumi is similar in nature to Terraform but has become increasingly popular in recent years due to its ability to let users define their desired infrastructure using familiar general-purpose languages like Python, JavaScript, Go, Java and markup languages like YAML.

Aws CloudFormation: is a declarative, agentless infrastructure provisioning tool which can be used to implement an immutable infrastructure on AWS. This is an AWS-managed service and provisions AWS cloud resources using JSON / YAML templates.

Chef: is an imperative, agent-based configuration management tool that works with mutable infrastructure. Chef gets an infrastructure to a desired state by running a series of instructions contained in a file referred to as a 'Recipe'; a collection of these files is referred to as a 'Cookbook'.

Puppet: is a declarative, agent-based configuration management tool that works with mutable infrastructure. In Puppet, you define the desired configuration state using their own domain-specific language (DSL), "Puppet Code"; Puppet then automates this configuration through a Puppet primary server and agent.

Static Site Scenario 

The year is 2029. The destroyers have risen from the ashes of nuclear fire brought on by FlyNet, an artificial intelligence that has gained sentience. The destroyers have one objective: to destroy humankind. The resistance is led by Ron Connor, who has just received intel that the machines have discovered a technology which allows them to send a machine back to 1984 and kill his mother before he is born. Not cool! Ron Connor needs this technology to send his finest sergeant, Miles Creese, back to 1984 to protect his mother. The only problem is he needs to figure out where to find it! After a successful skirmish, Ron Connor has managed to get employee access to a FlyNet terminal. Boot up the static site, bypass the employee training and retrieve the location info he needs! What could go wrong?

The Lifecycle

Now that it has been established what IaC is and the tools we use to implement it, it’s time to define the lifecycle. There is talk about an IaC lifecycle across forms, blog posts, and academic papers. Still, there is yet to be an agreed-upon and widely adopted lifecycle (as there is for DevOps/DevSecOps). Because we think you, the reader, would benefit from having an IaC lifecycle to use as an educational tool, we have defined one, the infrastructure as code lifecycle (IaCLC). The actions/tasks performed by developers and IaC tools can be broken down into phases, which together make a lifecycle; this lifecycle helps us understand that infrastructure as code has continual and repeatable processes, which don't simply follow a linear sequence of provision and management tasks. This task will outline the stages of the IaC lifecycle, its phases and how they are connected.

The IaCLC is designed to give DevOps Engineers (or anyone else assigned with the task) guidance on the tasks associated with provisioning infrastructure and the continued support of that infrastructure. Key DevOps practices such as continuous integration and continuous deployment are also parts of best practices throughout the lifecycle. 

Due to IaC being a development process, some parallels can be drawn between the IaC lifecycle and the SDLC, which also covers a solution's planning/designing, implementation, testing, deployment and monitoring. While these parallels exist due to these lifecycles being created on the same foundations (providing developer guidance and improving output quality), they don't directly fit into each other. Both lifecycles break down tasks into phases. However, due to the frequently changing infrastructure needs, the IaCLC distinguishes between two different types of phases.

Breaking it Down

As mentioned above, these phases are separated into two types. Let's break that down: 

Continual (Best Practice) Phases:  These phases are continually done to ensure best practices throughout the various stages of infrastructure development and management. Continual phases can trigger repeatable phases 

Repeatable(Infra Creation + Config) Phases:  These phases are done during the creation/configuration of an infrastructure and are done one or many times at different points and with differing variations depending on what needs to be done. Some examples are below:

Activity: Entirely new infra 

Activity: Config change 

The Continual (Best Practice) Phases 

The Repeatable (Infra Creation + Config) Phases 

IaCLC in Action

When discussing infrastructure as code, virtualisation is a fundamental concept. Virtualisation technologies, when used in conjunction with IaC, allow for some powerful and efficient infrastructure management. While some of these concepts have been touched on in the Intro to Containerisation room, this task will review virtualisation and its relationship with infrastructure as code.

Virtualisation Levels 

When we talk about virtualisation levels, we’re essentially talking about what is being virtualised. Here, we will briefly review the difference between hypervisor-level virtualisation and container-level virtualisation to provide context for upcoming concepts. Hypervisor virtualisation (e.g. VMware) enables multiple virtual machines to run on a single physical server. Imagine a physical server in a data centre. Using a hypervisor, this server’s resources (CPU, storage, etc.) can be divided and dedicated to separate virtual machines within this server. These machines will virtualise everything from the operating system, which can be a different OS than installed on the host, meaning multiple OSs can be installed on a single server; however, deploying a virtual machine at this level can take some time. Containerisation (platform example: Docker) is virtualisation at an operating system level, meaning the same operating system kernel is used to run multiple containers. Virtualising at this level makes these containers incredibly lightweight, allowing for rapid deployment and scaling. 

Use of Virtualisation in IaC

Let’s consider how virtualisation is used in IaC across six areas: Scalability, Resource Isolation, Testing / Snapshots / Rollbacks, Templates, Multi-tenancy, and Portability.

Virtualisation Technology + IaC 

Next, we will discuss some virtualisation technologies used in conjunction with IaC to unlock its power, focusing on Kubernetes. Kubernetes (also referred to as K8s) is a containerisation orchestration software, meaning once an application (and its dependencies) have been containerised, Kubernetes can be used to automate its deployment, scaling and management. Using Kubernetes requires a Kubernetes cluster, in other words, an infrastructure made up of a master node and one or many worker nodes (where the containerised applications run). Infrastructure as code tools can provision the underlying infrastructure needed for this Kubernetes cluster and automate the set-up of the required Kubernetes components. Infrastructure as code can also define scaling policies for a Kubernetes cluster, automating the scaling process and allowing pods/nodes to be added or decreased based on resource usage. The infrastructure provisioning/configuration and automation capability of IaC, combined with the ability to orchestrate lightweight rapid deployable containers, make for a very powerful set-up and is ubiquitous in the world of cloud computing. 

Consider a practical example from the world of DevOps. Say a DevOps Engineer is planning to deploy a new web application from scratch, and their tech stack includes both Terraform and Kubernetes. They can combine these tools and use Terraform to automate the creation of a new Kubernetes cluster, and once this cluster has been deployed, any other resources that might be needed, like an Nginx web server or a load balancer. This is just a simple, stripped-back example of a task that would even be possible by just using Kubectl (or other CLI-based tools) to manage K8s clusters and resources; however, using an IaC technology like Terraform boasts many benefits when you start to consider DevOps at the scale of a larger company where these tools allow you to define Kubernetes deployments, services, config maps etc. as Terraform modules, which are repeatable across different projects/clients/environments. We've also discussed how Terraform is a declarative tool ensuring that the state of the Kubernetes cluster matches the desired state making infrastructure management an easier task. Terraform is also aware of dependencies, meaning if 'resource x' is dependent on 'resource y' and 'resource y' fails to deploy, Terraform won't attempt the creation of 'resource x'. Another way in which Terraform can save time is by reducing the need for DevOps Engineers to sift through deployment errors, working out the point of failure. Again, both of these tools are powerful, but when used together, their true power and utility in the DevOps space are unlocked.

Kubernetes is just one example of how virtualisation technologies and IaC can work hand in hand and are nearly essential to each other (at least to get the most out of the respective tool). Some other examples include Vagrant (used by developers to spin up and manage VMs or containers for local development and testing; IaC can make this a consistent process) and OpenStack (an open source cloud computing platform where you can create your own cloud environments where IaC can also be used to automate the provisioning and management of cloud resources).

This is just an overview of virtualisation to emphasise its use within IaC, but if you want to learn more, we have plenty of rooms that go in-depth on this topic, like Virtualization and Containers and Intro to Containerisation. Check them out! 

Infrastructure as code has two use cases. On-premises IaC and cloud-based IaC. Going forward, this module will go in-depth and give practical examples of both of these. Let’s first establish the key differences between the two. Here, we outline key differences between on-prem IaC and cloud-based IaC across five categories: Location, Tech, Resources, Scalability and Cost.

Comparison

On-prem: As the name implies, if your infrastructure is on-prem, then the code written will configure servers, network devices, storage and software located on your premises. This can mean physical infrastructure in a premises owned by an organisation or rented in a data centre.

Cloud-based: This means provisioning and configuring infrastructure resources in a cloud environment using cloud resources. This is done using a cloud service provider (CSP) such as AWS, Microsoft Azure, GCP, etc.

On-prem: Typically, when working with an on-premises infrastructure, IaC tools like Ansible, Chef and Puppet would be used (although others can be configured to do so) to manage and provision infrastructure on physical servers or virtual machines in an on-prem data centre. 

Cloud-based: There are many tools available to provision and manage cloud infrastructure designed to leverage the elastic nature of cloud computing, with some cloud service providers having their own IaC tool/service. Some examples of tools that can be used for cloud-based IaC are Terraform, AWS CloudFormation, Azure Resource Manager (ARM) templates and Google Cloud Deployment Manager.

On-prem: When using on-prem IaC, you’ll likely be dealing with physical hardware, which comes with the caveats of hardware compatibility, physical upkeep and limited physical resources. This will mean setting up and configuring those physical resources (physical servers, storage devices, network equipment, etc.). On-prem IaC may be used by companies who rely on their on-premises infrastructure due to legacy systems and require assistance in the efficient management of this infrastructure. 

Cloud-based: In the cloud, you interact with virtual resources provided by the cloud service provider (AWS, GCP, Azure, etc.). These resources can be provisioned/managed by cloud-based IaC tools. The underlying infrastructure is handled by the CSP and not the user. Cloud-based IaC would be perfect for companies that offer video streaming services. Due to the nature of this service, it can lead to a fluctuating demand on computing resources, which can peak. Cloud-based IaC makes it easy to gain access to additional cloud-based virtual machines or storage depending on resource consumption to ensure consistent performance during these peaks.

On-prem: Scaling resources using on-prem IaC can be a slow and cumbersome process. This can involve manual/physical changes and procurement. Because scalability is such a slow process, consideration is required, and hardware limitations must be enough to handle peak load. This can prove challenging in situations where an on-premises infrastructure starts receiving increased traffic (think enrolment or exam season at a university/college).

Cloud-based: Due to the cloud’s elastic nature, scaling resources is far more flexible than on-premises. Cloud-based IaC tools can define scaling policies so resources can be scaled up or down based on demand and resource consumption, leveraging auto-scaling features. This ensures that only the resources needed are paid for. Cloud-based IaC can streamline the process of scaling infrastructure to meet demands during peak seasons. Imagine an infrastructure that supports an online game. This infrastructure would see increased traffic when the game releases a new update, or an event is underway.

On-prem: On-premises infrastructure expenses mean having to pay for physical hardware (or leasing a server from a third-party data centre - depending on the use case); this also comes with the costs of physical upkeep (fault repairs/part replacements, etc.), operational costs and expenses involved in upgrading the infrastructure. An on-premises infrastructure and the use of on-prem IaC doesn't boast any cost benefits per se. If choosing on-prem, it would likely be due to a combination of other factors rather than cost.

Cloud-based: When using cloud-based IaC, you’ll deal with infrastructure that cloud service providers bill for on a pay-as-you-go basis. This means you only need to pay for what you use (which can be made more cost-effective by the efficient use of auto-scaling). Cloud-based IaC tools are an ideal and cost-effective solution for scenarios where infrastructure needs to be automatically scaled up and down on demand. For example, if an online retailer is expecting an increase in traffic over Black Friday weekend or over the holiday period, they may want to scale up their resources but not have to pay for those resources when traffic returns to an average rate.

When comparing cloud-based infrastructure as code with on-premises infrastructure as code, it primarily comes down to the location of the infrastructure and what tools are used in their management and provisioning. Cloud-based IaC uses virtual elastic resources, which are charged on a pay-as-you-go basis and provided by a CSP, whereas on-prem IaC deals with physical hardware.

Benefits 

Let’s examine how the above-mentioned differences translate into benefits depending on specific use cases. Here are some of the benefits of each to give you an idea of when you might use on-prem IaC and Cloud based IaC: 

On-prem IaC: The main advantage of on-premises infrastructure as code is that it allows complete control. This complete control is sometimes required due to regulations/security and compliance requirements. This is common in bigger banking corporations or businesses that deal with customer-sensitive or government data. These regulations can call for data sovereignty (meaning the data has to be stored and processed within the country). Whilst cloud providers offer specialised government cloud environments for some of these cases (e.g. us gov cloud in AWS), these offerings are only available in certain regions; for regions like Africa, there is no dedicated government cloud, meaning on-premises infrastructure as code would need to be used to adhere to strict security/compliance requirements. 

Cloud-based IaC: It has many advantages for fast-paced and growing businesses. The scalability allows infrastructure to be rapidly scaled up or down to meet fluctuating demand without the constraints of physical on-premises infrastructure. Cloud-based infrastructure also allows infrastructure to be deployed globally across different regions, reducing user latency, which can be essential for businesses that need to provide a service to customers worldwide with little to no latency, like online gaming. With cloud providers billing on a pay-as-you-go basis, this can mean that companies can pay only for the infrastructure that they need/use, meaning investment doesn’t need to be made into physical hardware and the maintenance of that hardware.

Time to Fight

The technology required to send Sergeant Miles Creese back to 1984 is being held in a lab complex. All that's left now is to capture it and retrieve the tech. There's only one issue: it's located in a heavily fortified exterminator base, and the resistance doesn't have the resources to take them on. Lucky for the resistance, though, one piece of technology they do have their hands on is their 'Infrastructure at a Click' weapons system. This allows resistance fighters to deploy a weapon infrastructure (requiring a network and server components so the weapons can communicate with each other) to take on the machine army! After all, weapons can be reprovisioned; resistance fighters cannot! Simply define how many weapons you want using provision points and upgrade those weapons using configure points to defeat the incoming machines! Just don't let the machines take down your server, or it's game over!