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.
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.
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.
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
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.
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.
We have already mentioned some of the benefits of IaC. Let us review the main benefits one by one.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.