)
)
)
)
Explore how Terramate can uplift your IaC projects with a free trial or personalized demo.
Introduction
In our previous article Infrastructure as Code Predictions for 2025 we explained that at Terramate, we are seeing that a number of organizations are shifting towards adopting heterogenous tooling for managing cloud infrastructure with Infrastructure as Code - i.e. running Terraform, OpenTofu, Terragrunt, etc. in parallel.
While the instinctive reaction might be to use a single IaC tool for simplicity and unification, this sometimes presents more challenges than benefits.
This article explores when using different IaC technologies across teams makes sense and how Terramate can help you manage and unify those at scale.
Why you should consider using multiple IaC technologies
The Infrastructure as Code code market is a widely fragmented landscape. Numerous options such as Terraform, OpenTofu, Pulumi, Cloud Formation, Crossplane, WingLang, Ansible, Chef, Azure Resource Manager (ARM), Google Cloud Deployment Manager, Kubernetes YAML, and others exist. When looking at what IaC tool to use, multiple factors need to be taken into consideration:
- Cloud-agnostic vs. cloud-specific IaC technology. If you want to use an agnostic vendor, evaluate what cloud provider integrations exist.
- Learning curve and team experience
- Ecosystem and available supporting tooling
- Documentation, getting started guides, refereance architectures, and examples
- Job market
- Cost and licensing
Another aspect to consider is that tooling often serves different user personas and use cases. For example, Terraform and OpenTofu are well-established tools in the DevOps space, with a large ecosystem and community that have dominated the industry for years. However, newer approaches, such as Pulumi, are gaining popularity. These approaches target software developers because they allow the provisioning and management of infrastructure using general-purpose programming languages such as Go, Typescript, and Python.
The problem with unification
While unifying tooling (one of the core aspects of digitalization) often makes sense in smaller organizations, it can also make sense in larger organizations, especially when dealing with multiple product and engineering teams, to adopt the tooling most suitable for their specific needs and use cases.
Alas, we have seen a number of organizations that tried to standardize Terraform throughout their entire organization and failed in their endeavour. The switching cost, the cognitive load and subsequent developer frustration often lead to a lack of adoption. While the idea of unlocking efficiencies by unifying the IaC tech stack to one technology in theory does sound appealing, in practices is a change management challenge that is not alinged with the original meaning of the Pareto principle, as it improves the lot of some users while created “losers” in the processs.
The question is if it’s in your best interest to relegate specific teams that are veterans in one technology to novice status in another by executive fiat. Also, you may discover that buy-in can be low in case the original tech choice was a good fit regarding their use-case and workflows.
The challenges with migrations
Organizations often go through multiple stages during their IaC adoption journey. For example, a pattern that is commonly changed within an engineering organziation is how to manage environments with Terraform and OpenTofu. Multiple approaches such as workspaces, directories, partial backend configuration, TFVars, or Terragrunt, exists. Migrating from one approach or even one IaC technology to another often comes with migration effort. Migrating old approaches are often time-consuming, error-prone and costly leading managers to decisions to not migrate any previous implementations but to start new projects from scratch and leaving the legacy implement as it is. This is mostly due to the fact that migrations rarely create business value. Now managing multiple approaches in parallel can lead to complexity costs, and it’s hard to keep an overview.
What to do?
In an ideal world, teams can choose the IaC technology they feel most comfortable with often leading to heterogenous environments. To keep control, a management and unification layer needed, allowing teams to keep an overview and retain control for all infrastructure managed with Infrastructure as Code using a single control plane. This allows different IaC tools to be deployed and managed differently and by separate teams while still being able to overview and manage all of it in a single place.
Enter Terramate - Multi-IaC orchestration and monitoring
Terramate Cloud enables teams adopt a multi-IaC stance while still unifying the orchestration, deployments, and control layer. This way, infrastructure leadership benefits from standardization in the management and control plane, while platform teams can focus on their respecitive teams mission - and retaining their IaC tooling choices. To do so, Terramate
- Provides a centralized framework for managing deployments across different IaC technologies.
- Provides a single pane of glass for monitoring infrastructure changes across multiple projects.
- Allows teams to define and share configurations across different projects and teams.
Takeaway
Unification into a single IaC tool and approach is often a false promise. It’s mostly better to allow a certain amount of diversity and to harness the existing experience levels of the teams and individuals within your organization. Terramate allows teams to unify multiple IaC approaches in a single platform, allowing them to orchestrate, automate, manage and observe everything by using a single platform. If you are interested in learning more how Terramate supports a multi-IaC setup, please book a demo with our team at https://terramate.io/demo.