Terraform, the leading IaC (Infrastructure as Code Orchestrator), was created by HashiCorp 9 years ago and is now considered the de facto cloud infrastructure management tool with code. What started as an open source tool has quickly become one of the largest software communities in the world, and for every problem you might encounter, someone has already found and published a solution.
At the end of the day, DevOps managers are looking for a simple, predictable, drama-free way to manage their infrastructure, and that’s probably why many have chosen Terraform, which is a well-known, well-established tool with a very large community.
And I, as CTO, took the plunge and chose Terraform as our cloud management tool because it ticked all the boxes. One of the most important criteria for choosing any tool is to avoid vendor lock-in.
Just as choosing the main programming language and database was important to us, our cloud management tool also needed to meet this criteria.
In August of last year, following HashiCorp’s announcement of upcoming changes to the Terraform license, several players in the DevOps community united to create a fork of Terraform known as OpenTofu. OpenTofu is an open source IaC (Infrastructure as Code) framework powered by the community and managed by the Linux Foundation. It was created and developed to provide Terraform users with a truly open source option.
In this article, we’ll take a deep dive into both of these frameworks to better understand and explore the core features, highlighting key differences, to give you all the information and insights you need on whether or not you should switch from Terraform to OpenTof.
Hashicorp license change
So what does the new license mean in practice?
A company cannot use Terraform in its production chain if it does not meet the required conditions. It is currently a requirement that you not compete with any of HashiCorp’s products.
And yes, it is very vague. Any company that develops a product that competes with one of HashiCorp’s products cannot use Terraform. The fact that you meet the criteria today does not mean that you will meet them in the future. If the company you work for develops a mining product and in the future HashiCorp buys a mining startup, you become HashiCorp’s competitor from that moment on.
There is currently a cloud of uncertainty surrounding Terraform, and this level of uncertainty, in my opinion, should be taken very seriously when choosing a tool to manage your infrastructure.
Changes to the Terraform registry
The change that I think is more interesting and kind of went under the radar is that a few days after the Terraform license change, without official notice, they changed the terms of their registry. In fact, “improper” use of the HashiCorp registry is also a legal offense.
Now what does that mean? It’s very vague.
For those who don’t know, the registry contains all the provider mappings available to Terraform. But the story emerging here is that one day HashiCorp may decide that every call to its registry will cost a dollar, and then what?
The control of the project is by one entity and this is where the problem arises.
Terraform is not another project that has become closed source; Today, Terraform is the foundation for millions of people around the world to manage their infrastructure and configuration.
Many companies have built amazing things on top of Terraform, so this project is simply too important to be controlled by one entity.
So what do we do? What does it mean to be open source?
The rise of OpenTofu
HashiCorp’s license change is what created OpenTofa with one clear goal, which is to return the project to true open source as it was in its original form.
From a technical point of view, OpenTofu is a fork of the Terraform project, but some will say (and I am among them) that the drastic license change is a fork and OpenTofu is a natural continuation of Terraform.
To this end, many efforts have been made since the beginning to bring the project under the umbrella of the Linux Foundation, and this, in my opinion, is the central part of the OpenTofu initiative. From the moment a project comes under this umbrella, it is guaranteed that decisions about the features and direction of the project will be guided by a technology committee that is independent, disinterested and whose role is to resolve conflicts that will arise between different collaborators, like any major project it works on several people with different opinions.
Decisions are guaranteed to be made in the best interest of the community and not in the interest of a single player. Does this mean that every feature request will be accepted? Not. But the decisions will be completely transparent. A prime example of this is the PR that Hashicorp has refused to approve since 2016, which allows encryption of the Terraform State File.
Why does Hashicorp refuse to approve this PR? Because it goes against their commercial offer.
This requested feature will be released in version 1.7 of OpenTofu.
OpenTofu: Dive Deep
In the short term, the project will be used as a “super set” of Terraform. According to this definition, all functionality of Terraform will be in the form of OpenTofu, and the Tofu project will contain additional features. In the long term, it is very likely that along the way the projects will go in completely different directions in their plans. There will be features in Terraform that will not be available in Tofu mode and vice versa.
For the most part, the open source community tends to innovate more than large enterprises.
It’s not because the ideas are better, it’s simply a matter of execution and agility.
This is thanks to the mobilization and contribution of the community to the project. In the last few years, if you look at the number of HashiCorp employees who have contributed to Terraform over the years, that number does not exceed 5.
With significant contributions from various companies in the community, the development of OpenTofu seems likely to surpass that of Terraform.
These are the features that have been released or will be released soon in OpenTof:
- 1.6 – Dedicated OpenTofu registry
- 1.6 – Testing framework
- 1.6 – Improved S3 background
- 1.7 – Removed block
- 1.7 – False information
- 1.7 – Client-side state encryption
Migration from Terraform to OpenTof
Let’s talk about how to migrate from Terraform to OpenTof.
For all versions lower than 1.6, OpenTofu is a replacement for Terraform. It already becomes addictive to use the various features as you progress through the versions. The technical side of the migration is pretty trivial, instead of the startup terraform command, all you have to do is run it tofu command.
Let’s look:
So! Migration done!
I would also like to mention that migrating a single “stack” is quite simple. The challenge comes when you have 100 or 1000 stacks that you want to run with OpenTofu and make sure there are no differences. It is more of a management challenge than a technical challenge.
Another important consideration when performing a migration is to ensure that your code is not using the HashiCorp registry. This means that no one is using the fully qualified module/provider name. For example:
Since I am using a fully qualified name with registry.terraform.iothe provider will be taken from HashiCorp’s registry, which is prohibited under their license.
- It’s here
tofu initcommand output:
Conclusion: should I migrate or not?
The decision to move from Terraform to OpenTof depends on several factors. I think the most important one is: are you willing to use the original project with only one commercial product you can buy (Terraform Cloud/Enterprise)? What are the implications of not being able to choose between different Terraform Operations platforms?
Other factors include:
- What if the license changes again tomorrow?
- What if tomorrow HashiCorp releases a product that competes with mine?
At the end of the day, as a technical manager you have to make decisions. Choosing an IaC tool for your organization is likely to be a decision that will impact the next few years. On the one hand, HashiCorp is a public, experienced company with a proven track record in building Terraform, and on the other hand, are you ready to commit to a product with a single commercial project? That is a question that each manager will have to answer for himself.