Infrastructure as code: what is it and its benefits

Infrastructure as Code is a code-based approach to infrastructure management and provisioning instead of manual processes. The advantages are many, including scalability,  flexibility and efficiency. But one must also take into account the challenges that IaC brings. 

In order to develop, deploy and scale cloud applications with greater speed, less risk and reduced costs,  it is necessary to abstract and automatically solve the problem of infrastructure management. This can be done with Infrastructure as Code, or IaC for short. 

It is a set of practices and tools that abstracts the problem of infrastructure management and is a  fundamental paradigm shift in software engineering and the way Ops think about infrastructure provisioning and maintenance. 

What is IaC?

Infrastructure is the set of resources required for the development and deployment of software services. IaC is the practice of provisioning and managing an infrastructure through a descriptive model using code. This approach replaces manual processes such as configuration tools, scripts and more. 

Through code, the configuration files created with Infrastructure as Code describe the specifications of the infrastructure. Modifying and distributing configurations thus becomes easier. 

In this way, the configuration of a computer centre's resources (network, servers, virtual  machines, load balancer) can be uniquely defined and managed with a version control  system.

What is the purpose IaC in Cloud Native?

In Cloud Native development environments, it is necessary both that the infrastructure can be used and regenerated as required and that it remains consistent throughout the development and production phases. 

IaC allows developers to manage the configuration of the infrastructure with the same process used for software development, avoiding, for instance, non-reproducible variations. 

This ensures that each time the configuration is applied automatically, the same result is always obtained. A manual configuration can neither guarantee this result nor can it scale to the size required by Cloud Native applications. 

Today, infrastructure management is a real issue in terms of scalability. From servers to load balancers, from firewalls to databases to container clusters: the complexity of software architectures has changed compared to the past. 

The single server is no longer the building block for provisioning, managing the development environment and running software in the cloud. Compared to the past, a single instance of a  single machine is no longer the core. The Cloud abstracts the physical server, delivering  'resources' instead. And manual management is no longer efficient. 

For these reasons, today Infrastructure as Code has become a key component in the adoption of the DevOps methodology and the Continuous Integration and Deployment  (CI/CD) pipeline. Both underpin the development of Cloud Native applications. 

IaC is also an extremely beneficial approach for those practising Site Reliability Engineering, as it uses software engineering and automation to perform IT operations, traditionally done manually by operations teams. This is why IaC and SRE are closely related.

Infrastructure as code: flexibility and scalability

From this perspective, turning infrastructure into code brings a number of advantages. Indeed,  it makes it possible to make use of all the skills and tools used in software production:  software development life cycle, version control and testing. 

Furthermore, the IaC approach is compatible with software development modes such as, for example, the Agile approach. In essence, IaC means doing infrastructure management and provisioning using code and an automatic interpreter, rather than a series of historically manually managed processes. 

Below we will look at some of these tools for automating the management and provisioning of infrastructure in different environments. 

The IaC approach has several strengths. One of these is that infrastructure resources can be divided into modular components that can be combined as required. This favours the availability and scalability of services, as well as facilitating their visibility and monitoring. 

In addition, documenting and codifying configuration management, which is transformed into configuration files, has another advantage. It is indeed possible to align the different teams involved in the development of software services, their maintenance and their deployment. 

Read also: DevOps: What it is and how can you best introduce it in your Company

Types of IaC Solutions

IaC can be created and managed with many different tools. This can be a bit confusing, also because the market is definitely crowded: there are at least a dozen IaC solutions. The easiest way to distinguish them is to look at which approach they follow. 
There are two: imperative and declarative. 

● The imperative approach defines the specific commands required to achieve the desired configuration. The commands are executed automatically in sequence. It is like defining a path by manually indicating all the steps, one after the other. Obviously, the sequence of commands must be correct in order to have the expected results. 

● The declarative approach, on the other hand, defines the desired state of the system  (i.e. which resources are to be active and with which properties). The dedicated software tool independently takes care of the execution of the steps necessary to reach this state. This provides greater flexibility, but on the other hand, one has less control over what happens step by step in the system. 

The distinction between the imperative and declarative approach 

As we have seen, the imperative approach requires that, in order to reach the desired state of infrastructure, instructions must be given one after the other to manipulate the system in the correct way. An example of this is the Ansible playbooks. 

Instead, the declarative approach describes the desired result and the tool takes care of realising it automatically. Such as Terraform. 

Declarative models also have another property that is not present in imperative ones:  idempotency. This is a property whereby an operation can be performed any number of times and always produces the same result. Put another way, it does not matter how many times the operation is repeated, the system is always in the state it would be in if the operation had only been performed once. 

An example to understand this distinction we have in the dashboard of our cars. The air conditioner allows us to declaratively set a temperature regardless of the condition of the car interior because it is the one that is responsible for reaching the level we want, heating or cooling as required. 

Next to the air-conditioning system is the radio, which has volume buttons that allow the volume to be increased or decreased imperatively, changing it each time they are operated. 

Let us look at another, more operational example: if for a project I want to realise a certain deployment, with the declarative approach I simply have to indicate which docker image I have chosen to use, the number of replicas and with which annotations. Instead, with the
imperative I must describe a sequence of commands that tell the management tool exactly which steps to perform and in what order to arrive at the state I want. 

In many tools, the distinction between the two different types of approach is not always so pronounced: some use, in part, both the declarative and imperative approaches. Some declarative tools, in fact, actually 'hide' imperative functions from the user. While many imperative tools nevertheless have declarative forms of automation. 

The distinction is nevertheless useful, as we will see in a moment because it allows us to choose the tool that best suits our needs and brings us the greatest benefit for what we want to do. 

Infrastructure as code: the advantages

We have already mentioned some of the benefits of IaC. Let us review the main benefits one by one. 

Reducing time and costs 

Doing things manually takes time and costs money. IaC frees people from manual infrastructure management, which allows them to work more and better on other things.  Overall, time is reduced as well as the cost of a project. 

Documentation and testing 

Using IaC makes it possible to automate deployment and management processes, but also to constantly document the work being done for each instance of the infrastructure. 

Using version control systems, different configurations are documented and tracked. In addition,  just as with code, it can be tested that they work and produce the desired effects. This also means a better understanding of one's own infrastructure, its strengths and weaknesses.

More standardised, stable and scalable environments 

This is one of the key objectives of IaC. Create environments that are stable, and can scale rapidly and automatically. Avoid creating ad hoc configurations that are not tracked and cannot be replicated. Or, more simply, they are different from those used in other stages of the pipeline. 

Security, disaster recovery

IaC treats computation, storage and networking functions as code: this means that they are instantiated in the same way every time. A positive consequence of this is that security standards and policies can be implemented and followed across all stages of development and production, without the need for a review at each step. 

In addition, in the event of a sudden interruption of services, it is possible to quickly return to the last stable state of the system, thus drastically reducing incident recovery times. 

Challenges and critical issues in the IaC 

There is no rose without a thorn. The benefits of IaC are numerous, but they bring with them complex challenges. The attention points to be attended to are indeed very important and determine the success or failure of an IaC solution. These are the main ones. 

Outdated tools 

Tools developed by third parties compared to core technology vendors carry the risk of not always being up-to-date. In the case of new cloud functionalities, there may be a delay before they are implemented in the IaC management tool we use. This may not be a  problem, or sometimes it can be.

In the second case, there are two solutions. Either extend the functionality of the tool independently or introduce other secondary tools that complement the main IaC tool. In both cases, however, the complexity increases and the speed of execution decreases. 

UNDERSTANDING IaC

To use the IaC tools, one needs to know how to use the HashiCorp Configuration Language  (HCL). But even if familiar languages are used, such as Python or Ruby, the problem is basically one of understanding the logic and conventions to be used. If one does not understand the key concepts of IaC - such as the declarative approach for example -  problems arise. 

Maintenance with large groups 

IaC makes it possible to solve some problems typical of DevOps environments. However, it also encounters difficulties in maintaining its functions when used by very large groups of developers. 

There is no fixed rule, but in the experience of many when the threshold of 100 developers is exceeded, keeping track of and versioning configurations becomes increasingly complex or even impossible to manage in reasonable time and effort. 

Access and Permit Management 

Access management also becomes an issue when certain thresholds are exceeded. The definition of roles and permissions in large organisations is complex and difficult to manage over time, and that of IACs is particularly critical. 

The learning curve of the IaC approach and the individual tools available can be steep but can also vary greatly depending on which tools are chosen. Let us see in conclusion what they are.

All the tools for IaC

There are many tools for managing Infrastructure as Code. They are not all the same, nor do they follow the same approach, as we saw earlier. 

Many are open source (such as Terraform and Pulumi), others are tied to specific platforms: CloudFormation by AWS (Amazon), Resource Manager by Azure (Microsoft) and Google  Cloud Deployment Manager. But there are still others. Let us take a more analytical look at the main ones.

 
Many of these tools are designed to be linked to Kubernetes (K8s), the open source container orchestration system for automating software distribution, scalability and management. 

• Google Config Connector, for instance, offers the possibility to manage Google  Cloud resources (currently more than 150) via K8s. Above all, the Config Connector  offers a unique and automated way to configure multiple services and resources  scattered in different parts of the Google Cloud platform thanks to the tools and APIs  exposed by Kubernetes. GCC uses a declarative approach for GCP that greatly eases  the work of DevOps using Google's platform. 
• HashiCorp Terraform d is one of the most popular if not the most popular multi-platform cloud tool because it is capable of managing infrastructure on various platforms including AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud and even Kubernetes and  Heroku. Terraform's strength is its ability to enable its users to achieve the desired state with a multi-cloud infrastructure and the expressive power of the language used to define the objectives. 
• Puppet is another popular configuration management tool that integrates with leading cloud providers such as AWS, Azure, Google Cloud and VMware, allowing the deployment of infrastructure across multiple cloud platforms to be automated. Puppet is based on a template approach, designed for system administrators. Puppet servers can be installed on one or more servers, while installing the Puppet agent on all nodes to be managed. The model is therefore a client server or agent-master model. 
• Chef is another of the most popular configuration management tools used in continuous integration and deployment processes, not least because it was one of the first to be developed. Chef (the name comes from the fact that declarative configuration files are called 'recipes') is independent of the cloud platform on which it  works, in the sense that it is compatible with many cloud service providers such as  AWS, Microsoft Azure, Google Cloud Platform, OpenStack and others. 
• Pulumi is a relatively new tool, designed for Kubernetes, which has the particularity of supporting different programming languages to create the IaC. Those provided by default are Python, TypeScript, JavaScript, Go, C#, F#. Pulumi has recently released a  Kubernetes Operator. It allows deploying infrastructure (Pulumi Stacks) where virtual machines, block storage, Kubernetes-managed clusters, APIs, serverless features and more can be enabled. 
• RedHat Ansible  (in turn acquired by Ibm) is an open source tool that allows the automation of server configuration and management procedures to which IaC functions have been added for both cloud and on-premises. It also has the particularity of being  able to function as an agentless tool by receiving commands via Ssh or WinRM. 
• Saltstack is a software tool for configuring infrastructures similar to Terraform or  Puppet that has some advantages including speed and versatile options. Salt (as it is also called) is available for more than 25 public or private cloud platforms and  uses a fast configuration distribution system made secure with AESand Reliable  Asynchronous Event Transport (RAET). 
• AWS CloudFormation and Azure Resource Templates are tools developed by  Amazon and Microsoft respectively for the IaC of their infrastructures. Obviously,  CloudFormation has very advanced integration with AWS services, while Azure Resource Templates follow a different approach and offer a set of consistent management examples for Microsoft's cloud platform. Finally, the Cloud AWS Development Kit (AWS CDK), a framework similar to Pulumi but specific to the  Amazon environment. 
  

Conclusions

Cloud Native application platforms offer a number of advantages that cannot be renounced today: speed of release, ease of management, cost reduction, scalability, and system reliability. 

All this requires new tools and new ways of development and management. As far as infrastructure is concerned, the use of Infrastructure as Code practices and tools has become indispensable over the past ten years. 

This approach is a real revolution for software development and infrastructure provisioning and maintenance. IaC today is a key component in the adoption of DevOps methodology and the continuous integration and deployment (CI/CD) pipeline. However, although IaC brings undeniable advantages (speed, cost reduction, standardisation, security), it also requires specific skills to understand how it works, choose the right tools and govern operations.