Before we look at some of the challenges you may be facing, I quickly wanted to take you through my journey with Infrastructure as Code before it was really what we now know as Infrastructure as Code.

When I talk about Infrastructure as Code, I mean the following:

Infrastructure as Code is an approach to infrastructure management where it is provisioned and managed using code and automation tools rather than manually configuring resources through a user interface.

This allows you to version control, track, and manage your infrastructure in the same way you do with application code and, in many cases, use the same tooling, processes, and procedures you already have in place.

Infrastructure as Code can help improve your infrastructure operations’ efficiency, reliability, and reproducibility by introducing consistency across your deployments and reducing deployment times versus more traditional manual deployments.

My own journey

I have been working with servers of all types for longer than I care to remember; back when I first started working with servers, it was all very much a manual process to do pretty much anything.

The bare-metal days

Before virtualization became a common practice, I remember having to block out a whole day to build a customer’s server. This process would generally start with ensuring that the hardware I was given to work with was of the correct specification – if for some reason it wasn’t, which was quite common, then I would typically have to replace RAM and hard drives, and so on.

This was to ensure that I didn’t get too far into configuring the server, only to find that I had to tear it down and start from scratch; once the hardware was confirmed as being correct, it was time to start on the build itself.

Typically, to build the server, I sat in a tiny, hot, and noisy build room surrounded by equipment, bits of computer, and what felt like reams of paper, which contained not only instructions on how to manually install the various operating systems we supported but also build sheets containing configuration and information on the customer’s required software stack I was deploying.

Once built, the server was packed back into its box, put in the back of someone’s car, and taken to a data center. From there the server was racked and cabled for both power and networking and then powered the server on – if everything was configured correctly, it would spring into life and be available on the network.

After some quick testing, it was back to the comfort of the office to complete the build steps and, finally, hand the server over to the customer for them to deploy their software on.

While this process was fine when there was one or two of these deployments, once in a blue moon, as things got busier, it quickly became unmanageable.

The next logical step was to have a build server that contained drive images for all the supported operating systems and base software stack configurations, with some custom scripts that ran when the server first booted to customize the base configuration and get it onto the network when the server was racked in the data center.

Enter virtualization

Once we started to move from provisioning bare metal servers for customers to virtualized servers, things got a lot easier – for a start, as you didn’t have to physically connect RAM, CPUs, or hard drives to the servers, assuming the cluster you were building the server in had the resource available, it made quite a dramatic change to the deployment time and also resulted in less time in the build room and data center.

At this point, we had built up a collection of custom scripts that connected to both the virtualization hypervisors and virtual machines – these were shared between the team members in our subversion repository and documented in our internal wiki.

This was my first, extremely basic by today’s standards, introduction to Infrastructure as Code.

Virtual machine configuration

The next logical steps were to add a remote configuration into the mix by using a tool, such as Puppet or Chef; we could deploy our virtual machines using our custom scripts and then have the servers call back to our main management server, and then bootstrap itself as per the customer’s desired configuration state.

Putting it all together

This was the final piece of the puzzle, which took our deployments from taking a few days per server to an hour or so, with the bulk of that time waiting for automated tasks to complete – though, as a lot of the initial stages of the deployments were initiated by our in-house DIY scripts, we still had to keep a careful eye on the progress.

This was because there wasn’t much logic built in to handle errors or other unexpected hiccups during the deployment, which, in some cases, resulted in some challenging post-deployment problems – but the least said about those, the better.

Today’s challenges

So, how do today’s challenges differ from my own experiences? During my day job, I get to work with a lot of internal and external teams who are nearly all technical and are very hands-on with the day-to-day management and development of their own applications.

It’s all documented

When discussing Infrastructure as Code with teams, one of the most common answers I get is as follows:

“We have the process to deploy our infrastructure documented, and anyone in the team can work through it to quickly deploy a resource.”

While it is great that there is documentation and that it is accessible by all of the members of the team, you would be surprised, even with the presence of comprehensive and easy-to-follow documentation, at just how much variance there is when people come to actually implement it. They don’t fully understand it because it is simply a set of tasks that lack any context as to why the tasks are being actioned.

Another potential issue is that the process is followed so often by a member of the team that they simply just get on with it, missing any updates or steps that have been added to the documentation.

Worst still – and this is more common than you may think – giving three technical people the same set of tasks to do can sometimes result in three very different outputs, as everyone has different experiences, which normally feeds into how we do things – for example, last time I tried to A, B, and C, X happened, so now I do it C, B, and A or I think it would better to do it B, A, and then C – but don’t have time at the moment to update the documentation.

All of these can introduce inconsistencies in your deployments, which may go unnoticed as everyone thinks they are doing it correctly because they are all following the same set of documentation.

Next, next, next

The next (pun very much intended) answer I normally get is this:

“We don’t need to do it very often, and when we do, it’s just clicking ‘next, next, next’ in an interface – anyone can do it.”

When I get this answer, what I actually hear is, The process to deploy the resource is so easy that we didn’t bother to document it. While this might be the case for some members of the team, not everyone may have the experience or confidence to simply click next, next, next to deploy and configure the resources without a guide.

As I am sure you can imagine, if it is possible for inconsistencies to be present when everyone is following the same set of documentation, then doing the deployment without any of the guardrails that the documentation puts in place is going to introduce even more potential issues further down the line.

Just because a resource has been deployed without error and works does not mean that it has been deployed securely and in such a way that could support your production workloads.

We have everything we need

The final most common answer when discussing Infrastructure as Code is as follows:

“We have deployed everything we need and don’t need any further resources.”

Again, when I get this answer, I normally hear something slightly different – in my experience, this normally means that, a while ago, someone deployed something that is more than capable of the task and has now moved on, either going on to another project or department or has left the company altogether.

While it is great that the resources are running fine, this approach can cause issues if you ever need to redeploy or, worse still, firefight an issue with production, as a lot of knowledge of the underlying configuration is missing.

So, while you know what’s there, you may not necessarily know why.

Conclusion

There are many more examples, but the previous ones are the most common ones I see when working with teams who may not have considered Infrastructure as Code to be a foundation of their deployment pipelines, and if you are reading this, then you may have already come across some of the examples and want to move onto the next step.

So why would you take an Infrastructure-as-Code approach to your deployments? Well, there are several reasons, which include the following:

• Documentation: While we have already mentioned documentation, it’s important to note that if you employ Infrastructure as Code, your deployment is documented as part of your code as it defines the desired state of your infrastructure in a human-readable format.
• Repeatable and consistent: You should be able to pick up your code and deploy it repeatedly – sure, you may make some changes to things such as resource SKUs and names, but that should just be a case of updating some variables that are read at the time of execution rather than rewriting your entire code base.
• Time-saving: As I mentioned, in my own experience, it sometimes took days to deploy resources – eventually, that got down to hours and, with more modern cloud-based resources, minutes.
• Secure: Because you have your infrastructure defined in code, you know that you will have a well-documented end-to-end configuration ready to review as needed. Because it is easily deployable, you can quickly spin up an environment to review or deploy your latest fixes into, safe in the knowledge that it is consistent with your production configuration, as you are not relying on someone manually working through a step-by-step document where something may get missed or misinterpreted.
• Cost savings: I think you should never approach an Infrastructure-as-Code deployment with cost savings being at the top of the list of things you would like to achieve – but it is a most welcome nice-to-have. Depending on your approach, cost savings can be a byproduct of the preceding points. For example, do you need to run your development or testing infrastructure 24/7 when your developers may only need it for a few days a week at most?

Well, that infrastructure can be deployed as part of your build pipeline with next to no or little effort. In that case, you may find yourself in the enviable position of only paying for the resources when you need them rather than paying for them to be available 24/7.

So, now that we have discussed my personal journey with Infrastructure as Code and also gotten an idea of the different scenarios where Infrastructure as Code may come in useful and the potential reasons why you would want to incorporate it into your day-to-day workflows, let’s now discuss some of the basic concepts you need to know about before we start to talk about the tools we are going to look at for the remainder of the book.

In programming, there are different ways to give instructions to a computer to achieve the programmer’s desired result. These ways of telling the computer what to do are known as programming paradigms.

In general, they refer to how we build programs from logical ideas such as if statements or loops. There are other classifications as well: functional, structured, object-oriented, and so on. Each of these describes a different kind of task that programmers might perform when writing code or thinking about code.

Imperative and declarative programming is the most fundamental way in which programmers think about defining their tasks and the two main ways in which we need to think about how we write and structure our Infrastructure as Code.

Before we discuss each way, let us define a quick Infrastructure-as-Code project.

Basic Infrastructure-as-Code project

The following diagram shows the basic infrastructure for deploying a single virtual machine in Microsoft Azure:

Figure 1.1 – The basic Infrastructure-as-Code project diagram

As you can see, the project is made up of the following components:

• Resource group (rg-iac-example-uks-001) – This is a logical container in Azure to store the resources.
• Virtual network (vnet-iac-example-uks-001) – This is a virtual network that will host our example virtual machine.
• Subnet (snet-iac-example-uks-001) – This is not shown in the diagram, but the virtual network contains a single subnet.
• Network Security group (nsg-iac-example-uks-001) – As we don’t want management ports such as 3389 (RDP) or 22 (SSH) open to anyone on the internet, this will add some basic rules to only accept traffic on these ports from trusted sources. This will be attached to the subnet, so the rules apply to all resources deployed there.
• Virtual machine (vm-iac-example-uks-001) – This, as you may have guessed, is the virtual machine itself.
• Network interface (nic-iac-example-uks-001) – Here, we have the network interface, which will be attached to the virtual machine and the subnet within the virtual network.
• Public IP address (pip-iac-example-uks-001) – Finally, we have the public IP address; this is going to be attached to the network interface, which will allow us to route to the virtual machine from the trusted locations defined in the network security group.

While this is a basic infrastructure example, there are quite a few different resources involved in the deployment. Also, as we are going to be talking at a very high level about how this could be deployed, we won’t be going into too much detail on Azure itself just yet, as this will be covered in Chapter 4, Deploying to Microsoft Azure.

Declarative approach

When talking about my own experiences, I mentioned that I used a configuration tool; in my case, this was Puppet. Puppet uses declarative language to define the target configuration – be it a software stack or infrastructure – but what does that mean?

Rather than try and give an explanation, let’s jump straight in and describe how a declarative tool would deploy our infrastructure.

In its most basic configuration, a declarative tool only cares about the end state and not necessarily how it gets to that point. This means the tool, unless it is told to be, isn’t resource-aware, meaning that when the tool is executed, it decides the order in which the resources are going to be deployed.

For our example, let us assume that the tool uses the following order to deploy our resources:

• Virtual network
• Resource group
• Network security group
• Subnet
• Public IP address
• Virtual machine
• Network interface

On the face of it, that doesn’t look too bad; let us explore how this ordering affects the deployment of our resources in Azure.

The following figure shows the results of the deployments:

Figure 1.2 – The results of deploying our infrastructure using a declarative tool

As you can see, it took three deployments for all the resources to be successfully deployed, so why was that?

• Deployment 1: The virtual network failed to be deployed as it needed to be placed with the resource group, which wasn’t deployed yet. As all the remaining resources had a dependency on the virtual network, they also failed, meaning the only successful resource to be deployed during the first execution was the resource group, as that had no dependencies.
• Deployment 2: As we had the resource group in place from Deployment 1, then this time around, the virtual network and subnet both deployed; however, because the deployment of the network security group was attempted before the subnet was successfully deployed, that failed. The remaining failed resources – the public IP address and virtual machine – both failed because the network interface hadn’t been created yet.
• Deployment 3: With the final set of dependencies in place from Deployment 2, the remaining resources – the network security group, public IP address, and virtual machine – all launched successfully, which finally left us with our desired end state.

The term for this is eventual consistency, as our desired end state is eventually deployed after several executions.

In some cases, the failures during the initial deployment of the resources don’t really matter too much as our desired end state is eventually reached – however, with infrastructure, and depending on your target cloud environment, that may not always be true.

In the early days of Infrastructure as Code, this was quite a large issue as you had to build logic to consider dependencies for the resources you were deploying – which not only meant that you had to know what the dependencies were but the bigger your deployment, the more inefficient it became.

This is because the more logic you start adding to the code, the more you start working against the declarative nature of the tool, which also carries the risk of introducing race conditions when the code is executed. For example, if you have one resource that takes five minutes to deploy – how do you know it’s ready? This would mean even more logic, which, if you got it wrong or something unexpected happened, you could be sat waiting for the execution to eventually time out.

Fear not; things have most definitely improved as the development of the tools has matured, and the tools have become more resource-aware. A lot of the manual logic you had to employ is now unnecessary, but there are still some considerations that we will go into in more detail in Chapter 2, Ansible and Terraform beyond the Documentation.

Imperative approach

As you may have already guessed, when using an imperative approach, the tasks execute in the order you define them – and we know the order in which we need to run the tasks to deploy our resources, which is as follows:

• Resource group
• Virtual network
• Subnet
• Network security group
• Network interface
• Public IP address
• Virtual machine

It means that the result of running our first deployment will look like the following:

Figure 1.3 – The results of deploying our infrastructure using an imperative tool

Great, you may be thinking to yourself, it works the first time! Well, sort of; there is a big assumption that you know the order in which your resources need to be deployed, and you need to structure the code in such a way that takes that into account.

So, while this way would typically work first when executed, there could potentially be a little more upfront work to get the scripts in the right order using a little trial and error – however, once they are in the correct order, you can be confident that each time you execute them, they will work the first time.

Now that we have discussed the key differences between declarative and imperative when it comes to Infrastructure as Code, let’s now talk about the differences between another deployment approach, pets versus cattle.

Traditionally, pets or cattle has been a way of defining your data center resources. It’s an analogy that describes a collection of hardware or virtualized resources as either pets or cattle.

Pets

Pets are resources that are owned by individual users/teams or managed on an individual basis.

Normally, they are seen as important fixed points within any application architecture and, like with a pet, you do the following:

• You give them names: For example, your server may have a hostname that looks something like backendapplication.server.domain.com, so it is easily identifiable.
• You feed and water them: For example, you take and keep backups that you review regularly. You keep a close eye on resource utilization and add more RAM and drive space as required.
• If they get ill, you care for them: They have monitoring agents installed, meaning you are alerted if there is a problem – sometimes 24/7 – and if there is an issue, you do everything you can to restore service by having troubleshooting procedures in place.
• You expect them to live for a long time: Given their importance within your application architecture and that you are caring for them, you expect them to be around for quite a while.

Resources that are now considered pets have typically been around for some time, and their configuration has organically evolved over that time based on their utilization, making them each a unique deployment, which is why you care for them, just like having a real pet – a good example of this is a long-running server.

Cattle

With resources that have been deployed to be treated as cattle, you only care about the health of the herd and not an individual resource:

• There are too many of them to give names: For example, your servers may have a hostname that looks something like beapp001.server.domain.com to beapp015.server.domain.com; you just keep incrementing the number rather than assigning a unique name that makes them easily identifiable.
• You watch them from afar: Given the number of resources, you only really care about the availability of the herd, meaning you probably only just ship performance stats and logs from the resources, and you do not need to back them up as it would be quick to replace them.
• If they get ill, you replace them: As already mentioned, if there is an issue with a resource, rather than troubleshoot the problem, you terminate it and replace it with another resource ASAP. Typically, this process is automated so that a resource is quickly taken out of service and another one put in place.
• You don’t expect them to live for a long time: Given their numbers, they can be quite short-lived – in some cases, resources may only exist for a short amount of time to handle an increase in the workload. Once the demand for additional resources has ceased, some of the resources are terminated.

Conclusion

Pets versus cattle mainly applies to application deployment strategies rather than purely just the underlying infrastructure. After all, let’s say your application, for whatever reason, needs to run as a single fixed point – for example, your application does the following:

• Writes essential files to the local disc, which can’t be lost if an instance is terminated
• Has manual steps for bringing an application instance online after it has been deployed
• Is licensed to a MAC address or CPU ID of a host

In this case, you may not be able to treat your deployments as cattle, but you can write your Infrastructure as Code so that the bulk of your deployment is as automated as possible.

These are technical reasons, but there are some considerations from a business point of view as well.

The one that will get most businesses’ attention is cost efficiency. Your choice of either a pets or cattle approach could have a significant impact on your hosting costs.

The cattle approach, which treats servers as ephemeral resources, allows for better resource utilization and automated scaling, potentially reducing costs. On the other hand, deploying pets, which emphasizes individual server care, may result in higher maintenance and management costs but could be justified for mission-critical applications that demand special attention.

Taking a cattle approach enables faster deployment and scaling of your workloads; this allows businesses to respond more quickly to market changes and customer needs. Deploying pets might lead to longer deployment times, potentially impacting a company’s competitiveness.

Regulatory and security requirements could also influence the choice between pet and cattle deployments. The pets approach, focusing on managing individual resources, may be more appropriate for businesses with strict regulatory or security requirements, as it allows for more fine-grained control and auditing of server configurations. However, the cattle approach, emphasizing automation and rapid scaling, might not provide the same level of control and may require additional efforts to ensure compliance and security.

Now that we have a good idea of the type of deployments you could be dealing with, let’s now talk about what this means for an Infrastructure-as-Code deployment.

So far, we have spoken a lot about some of the approaches and journeys people take to get to the point where they are considering using Infrastructure as Code, so before we look at some of the toolings in Chapter 2, Ansible and Terraform beyond the Documentation, let’s talk about some of the actual use cases.

In my opinion, the most significant advantage of using Infrastructure as Code is consistency – if you need to repeat a process or deployment more than once, then define your deployment as Infrastructure as Code.

This will make sure that resources are deployed the same every time, no matter who is deploying them; if everyone is using the same set of code, then it stands to reason that the outputs will be the same (apart from variables you allow to override the values on such as SKUs, resource names, etc.).

An Infrastructure-as-Code approach not only gives you consistency between team members deploying the code but also between environments. Before I started defining my deployments as Infrastructure as Code, configuration drift between environments was quite a significant issue – environments were online for so long that tweaks were being applied and not carried through, so when code moved between my development, test, and finally, production environments, unexpected things would start to happen.

Next up is collaboration; as your infrastructure is defined in code, you can use the same development workflows you use for your applications. I am sure that most of you use a version control system for your code, more than likely Git via hosted services such as GitHub, GitLab, BitBucket, or Azure DevOps – if so, you have everything in place to track changes and collaborate on your infrastructure configuration.

You can also extend this further by introducing branching and pull requests based on your existing procedures to encourage change and testing, making the ongoing maintenance and development of your Infrastructure-as-Code projects genuinely collaborative.

Once you have your Infrastructure as Code hosted in version control, you can also take advantage of automation, again using the same processes and pipelines you use to build your application – using services such as GitHub Actions or Azure DevOps Pipelines.

Using services such as these gives you the ability to execute tasks from a single location that is covered by the service’s role-based access control, rather than being reliant on each member of the team downloading and running the Infrastructure-as-Code deployments locally.

If a team member would be running it locally, then that would mean that each team member who needs access to deploy would also need quite a high level of access to target resources – such as the public cloud you are deploying to.

Using automation solutions such as the ones mentioned previously means that you can allow people to use credentials in their pipelines without them having to know what the credentials are. This means you can grant the individuals a lower level of access to your resources – such as read-only – as they only need to view resources rather than manage them.

One significant side effect of this approach is that because people don’t have a level of access outside of the automation, they won’t be tempted to quickly jump into the portal and make a change to fix something manually and instead will need to update the code and do a deployment, meaning that the change is tracked and the execution logged, so you know who did what, when, and why.

Finally, something that we have already mentioned – cost savings. If you have your Infrastructure-as-Code deployments in version control and automated, then it’s not a stretch to deploy your infrastructure as needed rather than running it 24/7.

For example, if you have a pipeline to build your application, once that pipeline has successfully executed, then it can trigger, which builds the infrastructure – once built, that in turn triggers a deployment, and from there, your tests can run against the deployment and freshly deployed resources. The results of the test can be stored, and the infrastructure is then torn down as it is no longer needed.

This end-to-end process may take half an hour – but that’s that half an hour’s worth of resource cost versus paying for 24/7 resource costs – which I am sure you will agree is quite a saving.

In this chapter, we discussed and covered some of the core concepts we will be following throughout the remainder of the book. We talked about my own journey with Infrastructure as Code, which we will be picking up in further chapters.

We discussed some of the common questions that get raised when discussing Infrastructure-as-Code projects, along with some of the positive and negative feedback you may get. Then we went on to talk about the differences between the two deployment approaches.

The first is declarative and imperative, which is how your deployment code is executed and in which order.

The second approach we discussed, pets versus cattle, while not strictly an Infrastructure-as-Code method, does have relevance to the approach you would take to writing your Infrastructure-as-Code scripts.

As we get more hands-on, I will share some of my own challenges and successes with Infrastructure as Code.

Speaking of getting more hands-on, in our next chapter, Chapter 2, Ansible and Terraform beyond the Documentation, we are going to look at two of the most common Infrastructure-as-Code tools and start looking at some actual Infrastructure-as-Code examples, as well as get an idea of how concepts such as declarative and imperative apply to them. Plus, we will be covering some tips and tricks based on my own experience with the two tools.