Infrastructure as Code pills with Terraform

In this article we will broadly explain the topics touched in the webinar held just over a week ago in which we talked about Infrastructure as Code with Terraform.

What is the target that a company usually sets itself when it wants to make the most of cloud environments?

For Criticalcase it is to achieve the so-called DevOps on the hybrid multicloud, that is to be able to reach a level of automation in various areas involving the internal procedures of the company and the methodologies, in order to change the paradigm and make the most of multicloud environments.

Criticalcase’s approach is a hybrid approach, and it is completely agnostic on any cloud platform.

Starting from Infrastructure as Code, in our opinion, should be the first step that a company must face, as it is the first step in the creation of platforms.

Infrastructure as code (IaC)

It is a process that allows the management and provisioning of infrastructure components both on premise at proprietary or third-party data centers and on the Cloud.

It is accomplished through definition files that are readable by a program such as Terraform.

Infrastructure as a code has multiple advantages, among the most important:

  1. Make the infrastructure dynamic, so much so that we can integrate the infrastructure components into the DevOps pipeline
  2. Standardize the infrastructure, so that changes in the infrastructure code level, if applied through IaC, affect the various remote infrastructures without the risk of misalignments
  3. Implement DR policies
  4. Having a single point of view on all resources related to a platform, whether they are SaaS, PaaS, or IaaS

Terraform is an opensource project by HashiCorp able to manage any available Cloud platform

  • Automation
  • Workflow management
  • Ecosystem

Having a very large ecosystem, it is easy to approach the cloud directly through Terraform, as there are about 150 official or verified Providers and over 800 communities.

  • OFFICIALS –> are those directly managed by Terraform
  • VERIFIED –> verified suppliers are owned and managed by third party technology partners and approved by Terraform
  • COMMUNITY –>Community suppliers are published in the Terraform register by individual maintainers or other members of the terraform community.

Unlike other IAC (Infrastructure as Code) systems that are born with an imperative approach, Terraform is an important tool born with a declarative approach that allows you to represent infrastructural objects.

The “final state” of the infrastructure is declared from the beginning, meaning that it is well known what it must look like.

Therefore, it will be Terraform itself and its plugins and suppliers, who will take care of the implementation of the infrastructure initially designed.

  1. The main purpose of the Terraform language is to declare the resources that represent the infrastructure objects. All other features of the language exist only to make resource definition more flexible and convenient.
  2. The configuration files (HCL format) describe to Terraform the components that need to run for a single application or for the entire datacenter.
  3. Terraform generates an execution plan that describes what it will do to achieve the desired state, then executes it to build the infrastructure described.
  4. When the configuration changes, the Terraform state changes

The new version 1.0 of Terraform has been out for a few weeks now, introducing several features such as:

  • Greater interoperability between Terraform states
  • Extended maintenance periods
  • Improved update experience


This is a list of best practices that derive from the experience Criticalcase has had with the use of Terraform

  1. A module is a container for multiple resources that are used together.
  2. Each Terraform configuration has at least one module, known as the root module, which consists of the resources defined in the .tf files in the main working directory.
  3. A module can call other modules, which allows the child module’s resources to be concisely included in the configuration.
  4. Modules can also be called multiple times, either within the same configuration or in separate configurations, allowing resource configurations to be packaged and reused.
  5. It is also very important to create your own forms.

We at Criticalcase have developed many modules for each type of AWS component that we are going to use when needed.

The first point to consider when scaling the system is the centralization of the state management and its lock (if used by multiple points).

Data sources allow Terraform to use information defined outside Terraform, it can be defined by another separate Terraform configuration or by different functions.

Each provider can offer data sources along with its own set of risk types.

In this case, a resource already present on Terraform will not be used but a program will be run by the developer code.

Even if the owner of Terraform (HasciCorp) advises not to use the Provisioners unless you can really cannot do without them, with Terraform it is not possible to manage everything and therefore you will have to intervene on the remote machines (if it is a Server), or perform local actions.

There are 3 types, two of which are the ssh connection to the servers:

  1. Local executive
  2. Remote Exec – Via SSH
  3. File – Via SSH

Some types of resources include nested blocks that can be iterated N times over “settings”, which typically represent separate related (or embedded) objects within the container object.

In addition to all the best practices, there are also warnings that can be summarized in 3 points:

  1. Workspaces: sometimes too risky
  2. Terraform Cloud – Cloud Secrets – Lock-in
  3. Log External Forms – Be Really Aware of What You Are Doing?

If you are interested in learning more about the subject, below you will find the video of the webinar held by our Delivery Manager and Cloud Architect Pasquale Lepera

If you want to learn more about the webinar, or if you want to receive the slides that have been projected, contact us using the following form.


Compila il form e un nostro esperto ti ricontatterà entro 24 ore: non vediamo l’ora di conoscerti!

Richiedi la tua prova gratuita

Ehi! Stai già andando via?

Iscriviti alla nostra newsletter per restare aggiornato sulle novità dell’universo Criticalcase