Infrastructure as code (IaC) is a set of mechanisms for managing virtual infrastructure through descriptor files or scripts. Initially dedicated to virtual machines (Instances), the evolution of virtualization offerings has made it possible to manage a full-fledged infrastructure, from instance to network, including the management of the DNS service, Load-Balancing, sub-networks and security groups. Often popular in cloud computing, Infrastructure as Code offers developers the ability to automate their deployments to avoid manual tasks or to have to write calls to programming interfaces on their own. This technology is a response to business needs in terms of scaling applications focused on automating and simplifying IT project infrastructure. In general, Infrastructure as Code is part of the broader DevOps movement to unify software development and system administration.
In 2006, Amazon unveiled the concept of Infrastructure as code allowing the provisioning of instances via computer code on Amazon Web Services. Despite strong limitations, this practice was well received and the market quickly adopted it. Microsoft Azure and Heroku are two platforms that quickly proposed similar tools for their respective services. In 2010, OpenStack positioned itself in the market by offering the ability to create a private cloud. The principle of having a dedicated tool for each platform becomes an important limitation. As a result, many companies prefer to use a private cloud for important data and keep a public cloud (such as Amazon AWS or Microsoft Azure) for less critical applications. Several tools dedicated to Infrastructure as code appeared on the market. Depending on the impetus given by OpenStack, the public cloud platforms previously mentioned developing new cloud services, allowing to manage DNS, load distribution, sub-networks, security groups, virtual routers, volumes or object storage. These services allow for the deployment of complete virtual infrastructure and are no longer limited to instances.
General Operation of Infrastructure as code (IaC)
There are three types of Infrastructure as code: imperative, functional and environmentally based.
---
Imperative: Resources (instances, networks, etc.) are declared by a formal list of instructions, followed in a specific order, to achieve the expected result.
Functional: Resources are declared so that the final configuration of these resources is the expected ones. The order itself does not matter.
Environment-based resources are declared so that their final configuration and state are consistent with the rest of the environment around them. This is the most elaborate version and the one to which Infrastructure as code tends: the creation of resources is not only automatic, it is intelligent.
As a general rule, Infrastructure as Code consists of descriptor files, possibly supporting variabilization, to generalize the code and avoid having to duplicate it for each deployment environment (development, integration, pre-production, production, etc.). These are read by an appropriate interpreter, who will convert all written code into calls to programming interfaces6. These interpreters need to know where the resources (providers) and login credentials will be deployed to make the calls. The infrastructure as Code is therefore subject to the fact that programming interfaces exist, or that appropriate proprietary software is provided.
In addition to the deployment of infrastructure, some Infrastructure as Code tools offer interactions with software that is heavily used in infrastructure management and tracking (Grafana, Prometheus) to automate other aspects of infrastructure, such as monitoring; or the management of the public DNS6. In the case of the most advanced tools (such as Terraform), it is possible to use multiple providers, and thus deploy instances in several simultaneous locations.
Benefits of Infrastructure as code (IaC)
The main benefits of Infrastructure as Code have cost reduction, risk reduction, speed of execution, and collaboration within the team. Code infrastructure allows a rapid and transparent deployment to the purpose of the deployment. Due to its automation, no human intervention is required once the process has begun. In addition to the improved reliability provided by automated action, without possible human failure (especially on simple and repetitive tasks such as deployment), the speed of execution allows development teams to focus not on the application deployment aspect, but on the project itself. The time saved by the teams is thus a significant key element on a large scale, and the cost associated with deployment is much lower. Finally, Infrastructure as Code allows resources to be deployed and destroyed on the fly, thereby avoiding the need to allow resources to run when there is no use, which represents a substantial saving on large projects.
Also, the Infrastructure as Code helps to contain the risk of a poorly controlled deployment in business: in the event of a deployment error, it is possible to quickly go back; infrastructure code can be released as another software code, and the deployment process is extremely fast. Thus, it is possible to intervene quickly in case of problems when a version of a software is mounted, or simply when correcting a detected anomaly. As a result, software defects remain in the present code for less time, reducing the risks associated with them.
Similarly, Infrastructure as Code allows for better collaboration within a development team, or a company: infrastructure is code, so it’s easy to share the configuration and have it reviewed or modified by a third party. Thus, the infrastructure’s burden (particularly for its technical design and choice phase) no longer rests on a single person, but on a collegial choice of the team, which can commonly make decisions and intervene quickly if necessary.
A final point, partly related to the speed of execution and collaboration, concerns reproducibility: the same script can be used, by a simple change of variables, to deploy all environments for the desired application (production, qualification, test). It is, therefore, possible to have completely identical environments on a technical level and to test deployed applications in real-world conditions, without wasting any extra time.
Present Situation of Infrastructure as code (IaC)
The Infrastructure as Code has experienced massive adoption in recent years because it combines perfectly with the DevOps movement. Indeed, it is possible via the Infrastructure as Code, to fully automate the deployment of applications, from the infrastructure layer to the software layer. Thus, Infrastructure as Code software pair perfectly with other well-known tools, such as Ansible, Vault, and Puppet. Moreover, the speed of setting up so-called “test” environments, totally disconnected from production, but sharing the same technical specifications, is a real plus within companies wishing to push their applications in real conditions before a real rise in production. It is therefore common to see as code infrastructure in continuous integration and continuous deployment pipelines, to build up and destroy resources as soon as a project source code is updated.
