Why Upgrading to Terraform 0.12+ Should be a Priority

Terraform 0.12 is not just a standard release but is a major one that introduces significant incompatible changes – although HashiCorp have tried hard to minimise the impact through upgrade tools and guides. The release is focused on the introduction of HCL2, (a merger of the HashiCorp Configuration Language and the HashiCorp Interpolation Language).

As a passionate user of Terraform and someone who knows the benefits of Infrastructure As Code, I am going to explore the reasons why upgrading to Terraform 0.12 should be treated as a priority with equal if not more weight to the rest of your project work.

HCL2 – Simplicity and Improved Developer Productivity

During the build-up to this release, Hashicorp has been extremely proactive with regards to keeping the community informed about what to expect and how to upgrade.

This has been positive because HashiCorp identified a need to improve the simplicity and clarity of declared Infrastructure As Code, (IAC). As a result, the Hashicorp Configuration Language and the Hashicorp Interpolation Language have been merged into HCL2.

When comparing your HCL and HCL2 configurations you will notice that expressions are now first-class citizens. The rules around defining nested blocks and arguments have become stricter and new iteration constructs have been introduced allowing data to be transformed and used elsewhere.

These may seem like small changes, but when paired with improved terminal output, you will notice a new clarity emerging from your codebase. Development teams are increasingly being asked to take on DevOps practices. Naturally used to more expressive languages and tools, these changes will make it easier to onboard and up-skill new engineers through a reduced learning curve.

HCL2 directly addresses the convoluted hacks and workarounds that have surfaced over time and is a clear indication of HashiCorp’s direction for Terraform.

Reduce Risk – Avoid Getting Stuck In The Mud

Terraform allows teams to operate at their own pace, but with the one constant that their resources are represented as code. No matter the pace of your organisation, you will at some point be required to reprovision your infrastructure. This might be due to production failure or a need to create a new internal environment.

If you provision your infrastructure frequently then you will be very aware of your Terraform codebase. If your pace is slower, then you might not be aware of the need to upgrade until the crunch point arrives. Without knowing it, you may be walking into a situation where you are unable to maintain or deliver new features to a customer system.

Besides the impact on delivery and your reputation with customers, you may also find you inadvertently fall foul of certain regulations. For example, if you have been relying on the auditability of your Terraform based infrastructure-as-code process, then the inability to use the process as is, and resorting to manual fixes could prove quite problematic.

Terraform 0.12 has some backwards incompatibilities, and even with tools, the upgrade path does not necessarily follow a nice straight line. As John F. Kennedy once said, “The time to repair the roof is when the sun is shining.” A pre-emptive upgrade reduces your risk of hitting “known unknowns” when you can least afford to deal with them.

Improve your Technical & Organisational Alignment

Organisations have increasingly transformed from static private data centres to dynamic multi-cloud environments that offer a large variety of services. As a result, resources that changed infrequently are now recreated many times within a single day.

This has also meant organisations are moving away from monolithic infrastructure management, to a more lean and decentralised approach. An approach where different parts of the business are able to control different parts of the infrastructure. This requires tooling and an underlying approach which is able to effectively allow for the partitioning and integration of cross-cutting infrastructure concerns across teams within the organisation.

Whilst teams have been doing this prior to 0.12, they are constantly looking to breakdown and express their infrastructure more clearly. Establishing clear contracts and communication is a key factor in developing effective self-service offerings – something which is high on the agenda for many companies looking to move to such a model.

HCL2 introduces Rich Data Types as a means to describe more complex structures with your Terraform Modules. Now each team is able to express clearly what is required by their modules and what the wider organisation can retrieve from them. This allows for an infrastructure that is more aligned and can support multiple teams.

Conclusion – The Future has arrived

HashiCorp’s main focus covers the development of consistent workflows across each layer of the cloud and Terraform represents the foundation to evolve the flow of provisioning. Terraform 0.12 itself represents a major milestone and promotes clearer syntax and communication. Along with the announced Terraform Plugin SDK, provider development is also set to evolve behind the scenes.

Recent announcements with regards to Terraform Cloud and Enterprise show that supportive services are now starting to appear and it is only natural that the latest version of Terraform will be to focus for future integrations.

Terraform is always moving forward and by embracing the latest changes you can avoid unknowingly becoming the custodian of a codebase that needs major work at the eleventh hour.

If this is something you’re looking to avoid and need some support, our team of consultants are able to help! Contact us here

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.

RETURN TO BLOG

SHARE