Infrastructure-as-Code (IaC) is one of the best DevOps practices which accelerates development and increases the quality of deployments. IaC has become a true industry standard. We observe that many of our customers who start their cloud journey adopt IaC, and specifically Terraform, from the very beginning. In our previous post, we have looked at different IaC tools. In the current blog, we would like to present the latest IaC developments and trends and share our experience.
Improved testing capabilities
Terraform offered different kinds of validations such as input variable validation, resource preconditions and postconditions, and check blocks for a long time. Finally, Terraform has launched a more powerful framework for unit and integration tests. Many things that previously had to be implemented manually using other programming languages and frameworks are now possible with HCL. The new framework introduced new file formats such as .tftest.hcl and .tftest.json as well as a new Terraform CLI command „test“.
The main capability of the framework is to perform tests on the real-world infrastructure. Per default, the Terraform test command applies test configurations, but the behaviour can be changed to plan only. Optional assertions can be defined which can refer to variables, resource attributes and built-in functions, but executing a custom script in an assertion is not possible. A workaround for using custom scripts can be to embed them in the shell resource provider or similar and then read the output of the resource or data source in the assertion.
The new framework will also automatically destroy the infrastructure provisioned during a test after the test is finished. This aspect is not useful, since post-apply analysis can be very useful for debugging in some case. An option to skip destruction is not implemented yet.
An advantage of the Terraform test is the introduction of run-blocks. Each run-block can refer to a specific test case or module and override the variable and provider configuration. This gives a great flexibility for tests that require some initial setup which is not the part of the main infrastructure code. The initial setup can be implemented by a run-block with a reference to a dedicated test module.
Finally, Terraform is able to accelerate the testing process by using mock-providers without provisioning real-world infrastructure. This function is particularly useful for testing large infrastructures or resources with a long deployment time and for a large number of tests with different parameter values.
HashiCorp has changed its source code license from Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL). This decision is motivated by the lack of valuable contributions to HashiCorp’s OSS from some other commercial vendors using this OSS. The new license model prohibits, among others, the production usage of Terraform which competes with HashiCorp’s paid offers. Thus, many use cases remain unaffected by the licensing change.
However, for customers using the Terragrunt extension for Terraform, a restriction to the underlying Terraform version (v1.5.5 or older) has been introduced. As a reaction, Terragrunt and other vendors have founded OpenTofu, a fork of Terraform which is open-source, community-driven, and managed by the Linux Foundation. OpenTofu is already GA and its community will continuously implement important features compatible with future Terraform releases.
Time for the Cloud Edition?
When working with Terraform it is also about deciding which edition (self-hosted, cloud or enterprise) to use. Each option has its benefits and drawbacks.
Terraform Cloud and respectively Enterprise have gained further improvements such as dynamic provider credentials, drift detection, stacks, third-party tools integration and policy evaluation. Note that Terraform Cloud is even free for up to 500 resources per month. The latest changes make Terraform Cloud/Enterprise even more attractive. However, there are still some points to consider.
First of all, it is about data security and the authorised storage locations for data. Many European companies restrict the store location to the EU. In this case, Terraform Cloud, which stores all customer data in the United States, is not an option. If Cloud features are still required, then Terraform Enterprise is the choice which is a self-hosted version of Terraform Cloud and, consequently, requires more installation and administration work.
Although Cloud and Enterprise editions provide customers an all-in-one tool to develop and operate IaC, a good portion of its feature, e.g. state and credentials management, RBAC, drift detection, can be quite easily implemented by other DevOps frameworks and public cloud services. From our experience, the Terraform community edition is more than sufficient for the most use cases, but of course the scale of infrastructure matters.
Looking at Competitors
Among other IaC tools, it is only Pulumi which can potentially compete with Terraform. The important criterium is the number of supported resource providers. Pulumi has launched its registry in 2021 with support for 64 leading cloud providers and offers today over 150 packages. Terraform Registry overwhelms this number with over 3800 providers. Similar relation reflects on the number of customers which are 2000 and 40000 for Pulumi and Terraform, respectively. Terraform clearly stays an industry leader for IaC.
We have made a review of, in our opinion, the most important trends in IaC world with the focus on Terraform as a leader. As expected, Terraform has brought many new valuable features to the market in the last year and still remained OSS for our use cases. At the same time, it is exiting to observe the raise of other OSS IaC projects. Clearly, there is no consolidation in the developer community yet. We will continue to pursue this development in our next blogs.