BlogWissenwertesTerraform: Pros, cons and alternatives

Terraform: Pros, cons and alternatives

Ein Beitrag von Thomas Mohrbacher

Why Terraform? – Part III

In our previous blog posts part I and part II, we delved into the world of Terraform, offering a brief introduction and exploring its core principles. Now, in part III, we’ll dive even deeper to uncover advanced insights into Terraform’s pros, cons and alternatives solutions.


  • Irrespective of the chosen provider, such as AWS or Azure, users can define their infrastructure using a single language.
  • Thanks to the declarative nature of the language, only the desired result needs to be defined without considering the transition.
  • Utilizing Infrastructure as Code (IaC) ensures that every change is carefully planned, well-documented, and enables concurrent work.
  • Terraform handles authentication and communication with the provider.


  • Transitioning resources to a different provider, such as moving a database from AWS to Azure, still demands some effort due to varying requirements and contexts.
  • Although Terraform incorporates modules as reusable definitions, there is a potential for a significant increase in duplications.
  • Notably, it lacks the option to import code components, resulting in scenarios where properties must be defined at each layer of the hierarchy.


In order to compare Terraform with its alternatives, we need to further explore some additional decision points.

Decision points

Native provider vs. multiple provider support

While Terraform supports multiple provider, the same guarantee doesn’t apply to all alternatives.

Domain specific vs. multiple language

Depending on the situation, having support for multiple languages can be beneficial, particularly when integrating the tool into an existing project where several languages are still in use. On the other hand, a domain-specific language can unify the understanding among all participants in a project’s implementation. 

Orchestration vs. provisioning

An orchestration tool aims to simplify and coordinate workflows or sequences of commands. In contrast, a provisioning tool’s approach is to create the desired result based on a predefined definition.

Direct change vs. previous planning

Some alternatives lack the capability to plan or check changes before implementation.

Alternative options


Similar to Terraform, Ansible is an open-source tool that embraces Infrastructure as Code (IaC). However, it primarily focuses on orchestration rather than provisioning. Ansible excels in executing workflows across multiple targets and automating procedural steps with result verification in between.

It supports multiple providers, utilizes a domain-specific language, and provides the capability to verify changes before implementation (dry run).

AWS CloudFormation, Azure ARM Templates and Google Deployment Manager

Each cloud provider offers its own IaC automation service or framework. These tools provision infrastructure with a specialization tailored to the unique technology of the respective cloud.

All three of them utilize JSON or YAML as their domain-specific definition language, with AWS CloudFormation being the sole platform to provide an advance differentiation of impending changes.


CDK stands for ‚Cloud Development Kit‘ and expands the development of infrastructure into multiple languages such as Java, C#, Python, Go, or Typescript.

AWS CDK is equipped with an AWS Constructs library, which simplifies the complexity and interconnections among numerous AWS services.

CDKTF, on the other hand, is HashiCorp’s Cloud Development Kit, which leverages Terraform as its operational layer.


Pulumi shares many similarities with Terraform. It’s an open-source tool that relies on state to identify necessary changes and can seamlessly integrate providers from Terraform to enhance its support.

The key distinction is its native support for multiple languages like Java, C#, Python, and more. Pulumi also excels in offering improved reusability and modularity through the introduction of functions, classes, packages, and components.


In our next and final blog post on Terraform, we will provide a brief summary and conclusion. Keep you updated!


Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert