HashiCorp Terraform Reviews

HashiCorp Terraform is primarily used to manage infrastructure. It is responsible for creating and managing infrastructure components. For example, when we initially designed the infrastructure for this project, we started by designing the VPC. We decided to use a specific region-based VPC. We specified the number of public and private subnets, as well as setting up Internet gateways and NAT gateways, all using Terraform. Once the infrastructure was set up, we deployed our resources, such as ECS containers, ECS tasks, and RDS databases, in private subnets, all properly managed by Terraform.

However, we use GitHub Actions for CI/CD pipeline purposes. While Terraform handles the infrastructure management, GitHub Actions manages the CI/CD pipeline for our ECS clusters. In my previous project, we used Jenkins, but in this project, we use GitHub Actions for deployment, testing, and other pipeline tasks.

Terraform is that it is an open-source tool that gives us great flexibility. Using the Terraform HCL, we are not restricted to a single cloud provider. If my client asks me to deploy the same infrastructure on Azure or GCP, I can use the same code with minor modifications to account for the different providers. This means we are not limited to a specific cloud.

Unlike AWS CloudFormation, which is limited to AWS, Terraform allows us to use a single platform and tool to deploy infrastructure across multiple clouds or on-premises environments. This makes it very easy for us to manage our infrastructure without switching tools or languages. While CloudFormation uses JSON or YAML, HCL is well-documented and user-friendly. It has documentation provided for HCL, which covers almost everything we need to know to use it effectively across different environments.

Terraform does not provide an automatic feature to convert infrastructure code from one cloud platform to another. For example, if I am creating infrastructure on AWS using a VPC and I want to deploy a similar infrastructure on another cloud platform like GCP or Azure, I need to manually rewrite the code to accommodate the different services and resources specific to each cloud provider.

Terraform is very helpful for managing infrastructure across multiple clouds, but it requires using different providers and adapting the code to match the services offered by each cloud platform. An automatic feature to convert Terraform code for use on different platforms would be beneficial, as it would simplify the process for developers. However, such a feature does not exist now, so developers must manually convert the code when switching between cloud providers.

50-60 percent of clients will use Terraform if we use ten projects with DevOps resources. 

Most new clients lack experience or knowledge about Terraform or other IaC tools. They manage their enterprise infrastructure manually. However, clients with experience and knowledge in IaC services typically prefer using Terraform. Most clients without this experience do not use Terraform or any IaC tools, opting instead to manage everything manually.

I was facing some issues, but I didn't approach them because I just read the Terraform documentation and the community groups to find a solution.

Installing Terraform is straightforward on any Linux or Windows-based operating system. However, managing different versions of Terraform can present some challenges. If you're using an older version and need to upgrade to the latest version, you might encounter some issues, such as syntax errors or changes in required formatting. It has built-in modules available in the Terraform documentation; managing upgrades and ensuring compatibility with your existing code can be more complex. Creating custom modules requires some initial effort, but they can be reused as needed.

Terraform is free to use. You don't need to pay for Terraform itself because it's open-source. You need to write the code; the actual cost comes from the resources you create on your cloud provider. The code itself is free, and you can write your modules. Most companies prefer to write their modules instead of using the built-in ones provided by AWS, Google, or Azure. A module is a one-time effort to create, and you can reuse these modules to create multiple resources in your cloud environment.

You must use Terraform when your client plans to scale the infrastructure or replicate it in another region in the future. Terraform is beneficial because once you write the code, it becomes easy to create similar resources in other availability zones or regions.

For small web applications with limited resources, Terraform might not be necessary. However, if your client anticipates major changes or deployments and is thinking about scaling the infrastructure, Terraform is a must. It makes management easier.

Another significant benefit of Terraform or any other IaC tool is that organizations are not reliant on individual resources. For instance, if you lead a DevOps department, you won't depend on a specific DevOps engineer to create the infrastructure. Managing resources through code or cloud automation simplifies scaling the infrastructure without deep knowledge of the underlying code.

For example, if you need to create another EC2 instance for your application, applying small changes to your Terraform code is straightforward. Since your infrastructure code is stored in version control systems like GitHub or Bitbucket, it isn't dependent on individual systems. You can pull the code from GitHub, make changes, and apply them regardless of where you are, which adds to the convenience.

I prefer Terraform because of the documentation and open-source community.

As someone who provides training on various tools, including Terraform, I've observed that many students lack experience with It. One of the main prerequisites for learning Terraform is knowledge of AWS or any other cloud platform on which you want to create your resources. If you know how to create resources manually, it will be much easier to convert them into IaC.

Overall, I rate the solution a seven out of ten.

The most valuable features of Terraform are leveraging public modules for EKS, KMS, and ECR. This allows us to set up infrastructure efficiently by utilizing pre-built configurations. We can manage EKS either through the EKS Manager group or directly with specific variables. This flexibility is crucial as it doesn't require building privileges.

Some areas where Terraform could improve would be challenges in managing sensitive information, especially when dealing with secret files or credentials. There have been issues related to storage and maintenance of these files, particularly when using AWS. Simplifying the process of handling secrets and improving the overall management of sensitive data could enhance Terraform's usability. One suggestion for Terraform improvement could be enhanced remote functionality. It would be beneficial if, for example, I could remotely check the status and perform tasks directly on AWS without needing a full analysis of all tasks locally.

I have been working with Terraform for two years.

I would rate the stability of Terraform as a seven out of ten. While generally stable, there is room for improvement to minimize challenges and provide a smoother experience for users.

Terraform is highly scalable. I would rate the scalability as a nine out of ten. Ten people use it at our company.

The initial setup was very simple and quick. It takes about two minutes to install everything.

When comparing Terraform with other infrastructure automation tools, I often consider AWS CloudFormation. However, I prefer Terraform for its versatility and ease of use. The abundance of modules, well-documented features, and direct integration with AWS makes it my go-to choice. Its flexibility, clear documentation, and ability to handle diverse use cases, from managing directories on GitHub to updating Linux machines, contribute to its efficiency and simplicity.

Overall, I would rate Terraform as an eight out of ten.

Our company uses the solution to deploy resources and infrastructure in Azure Cloud via the Azure DevOps pipelines. 

We have two developers who use the solution. 

It is easy to recreate an exact duplicate or output of an environment. 

The solution is much faster than manual deployments. 

It is much easier to create code than with ARM templates. 

The solution is quite easy to learn and use. 

It should be easy to automatically import everything at once from a manual environment or by a specific resource group. Currently, imports are only per resource so some automation is needed. 

The setup could be a bit easier. 

I have been using the solution for four years. 

From time to time there are stability issues with other providers and original providers in the solution. Stability is rated a seven out of ten. 

The solution is scalable so scalability is rated a seven out of ten. 

I have not contacted technical support. 

The setup for one laptop is quite easy technically.

If you are sharing the environment among staff, then the setup is a bit more complicated. You need knowledge to setup under this specific condition. Once you study it, you will be able to implement correctly. 

The setup is rated a five out of ten. 

We implemented the solution in-house. If you know how to do it, implementation is not too complicated and takes a few hours. 

We use the solution's free version. 

The solution is good for automation and better than regular ARM templates from Microsoft. It might not be as good as Bicep, but is better than most other providers. 

The solution is a strong technically and great for multi-provider or multi-cloud environments.  It is rated a top tool in the market. 

The solution is great technically for the cloud and automations. It can be used with Azure, AWS, Google, and other clouds if you know the syntax.  There are many resources provided and the free version works great for multi-cloud automations. 

I rate the solution an eight out of ten. 

We use Terraform for many different use cases. The primary one is ensuring that the security policy is automatically applied to all of the resources within a cloud environment. Another one would be creating and dismantling all sorts of test labs, as well as creating a development environment. We found a way to automatically create a development environment only for the time we need. We develop the infrastructure and cloud-related tasks.

The most valuable feature of Terraform is the ability to use it as a coding language because it works in a way that's similar to other coding languages. They are able to create classes, loops, etc. If you're familiar with coding, you will not have issues with learning to use Terraform.

One thing where Terraform could use improvement would be the types of resources it supports. With cloud providers always adding new resource types, there are certain resources that Terraform does not support. It would be great if it could support those resources as well.

I have been using Terraform for three years.

I give it a ten out of ten for stability.

Terraform is very scalable. A ten out of ten. About four or five DevOps engineers use Terraform at my company. 

We plan to increase its usage. I come from the security world and Terraform is very useful in ensuring that off of the resources within a cloud environment are deployed in a unified way. If you build the Terraform script once and you ask to create a different type of resource, instead of going into the Azure or AWS console and creating the resource from scratch, they use your Terraform script and ensure that all of the secured measures you've deemed necessary are built into that deployment.

I would rate the easiness of the setup a nine out of ten. It takes a maximum of 15 minutes to deploy it, but you need to write the script you want to run first, which takes more time since writing it depends on what you want to do.
I deployed it myself, but Terraform has some great, open people who contributed to the project. Specifically, the cloud part of the project had a lot of valuable contributions and made the deployment easy.

I am currently using the free version of Terraform.

My advice to new users would be to understand that Terraform works like a coding language, so you need to understand how it loops over objects in the same way that coding language loops over. objects You should turn Terraform terms into classic coding terms. 

Overall, I rate it a ten out of ten.

We use this solution to make our migration plan and utilize the images of Azure, GCP, and EC2 instances for our infrastructure. We have basic applications that the bank requires, so we use Terraform to expedite the initial infrastructure preparation. We also created a couple of common modules that we can use in production, development, and test environments.

The environment is very good. That's awesome.

At present, they only support around 300 applications and services from different clouds. They should aim to support more than a thousand to stay ahead of their competitors.

The product can integrate and utilize more services from different competitors. Currently, their commands are quite similar to Kubernetes, which we use in our CI/CD pipeline. Also, they should consider incorporating Windows command line, like PowerShell. 

Moreover, they should involve more technologies instead of just being providers for managing infrastructure; they could become active players in the field.

I have been using this solution for one and a half years. 

The solution is pretty stable. I would rate the stability a nine out of ten.

I would rate the scalability an eight out of ten.

The initial setup is easy. You just need to provide the description and the value for that particular setup. You don't have to learn or by heart remember all those commands. It's really easy. For example, if I want to create a DNS entry, I can use the data as well as resource parameters for the same.

So, that sort of flexibility allows me to use it differently, depending on my needs. When I use it as data, I can redirect my DNS to somewhere else because I'm using GCP as my service provider for my on-premise website. So, I route the incoming requests via GCP using load balancers. I use data as a resource for this. When I'm using Azure DNS, I utilize a resource command for the same in the data.

We have deployed it both on cloud and on-premises. 

The solution is comparatively cheaper than the others.

If you want to stay on top, you should be involved not only in maintaining your current infrastructure but also in adapting to changes. For example, if HashiCorp incorporates certain Linux commands, it will attract more people from the infrastructure field, especially those with a Linux background.

Overall, I would rate the solution a ten out of ten.

HashiCorp Terraform is a tool used for provisioning cloud infrastructure. It is used in this specific use case to deploy and provision all services, including Kafka, MongoDB, and Postgres clusters, using infrastructure as code.

HashiCorp Terraform has greatly assisted in deploying a new service by automating the configuration of pub/subs and secrets on GCS and Drone. We are able to make changes and keep track of configurations by writing code and scripting through Terraform, rather than manually doing it on the cloud. This has led to a change in our perspective on deployment and DevOps.

The feature "Terraform Plan" is the most valuable in HashiCorp Terraform as it allows us to see the differences between the current infrastructure and the one we are about to deploy, keeping things safe. Additionally, we appreciate the use of the modules as it helps in making the application scalable.

The price of the solution could improve.

I have been using HashiCorp Terraform for approximately six months.

I rate the stability of HashiCorp Terraform a ten out of ten.

We have approximately 1,500 users using this solution in my company. We plan to increase our usage.

I rate the scalability of HashiCorp Terraform a ten out of ten.

I have not contacted support.

I have not used similar solutions to HashiCorp Terraform before.

I have seen a return on investment using the solution.

I rate the price of HashiCorp Terraform a seven out of ten.

My advice to others is to treat Terraform as code, not just another configuration management tool. It's similar to writing backend code, so approach it with the same mindset and level of care.

I rate HashiCorp Terraform a nine out of ten.

Terraform is our main infrastructure as code at the bank. Our entire deployment site and the AWS solution are based on Terraform. We use EBridge and the Dochub solution on the Bitbucket pipeline. Terraform runs on a container in the Bitbucket pipeline, but to create my entire cloud solution, I use EBridge.

Terraform centralizes all our applications and it’s the best way to do it. When you work with the container and the EC2 clusters, you need to create each service manually. Terraform allows you to create a lot of them at once and check if they are being created correctly. It is a huge timesaver.

I find almost all the features valuable. It is the customization of Terraform's modules that I find most valuable.

Terraform could create more examples in the documentation. It is an enterprise/free solution, and you have to do a lot to customize the tools. A huge example I faced before that drove me nuts was when I created an entire data lake using Terraform. A DMS solution using Oracle didn't read some options in AWS on the Terraform module. I opened a ticket to support, asking, "Could you improve this module, only adding these features as variables?" After four months, my ticket was closed by a bot because support was not looking for it. I don't know if there were many issues or tickets, but support should listen to the Terraform community better and make adjustments to their tools.

I've been using HashiCorp Terraform since 2017.

Terraform is stable. I don't use Terraform Cloud, though they offered it to me previously. Using other clouds, we don't face many issues or instability in our ecosystem. The only issue or instability I have faced was because the AWS cloud was unstable, so Terraform got timed out and could not finish the task, trying again and again and being stalled for two hours. That is the only issue I remember because we use the EBridge environment. We try to compensate for Terraform's instability and make it viable using other platforms. Using Terraform's cloud solution brings more stability, but for what we are using right now, Terraform only breaks if we make a mistake in the code.

Terraform is hugely scalable. If I have everything in place, you can create an entire environment, like a data lake, in one simple deployment. But it is complex to scale. You will face some limitations if you try to work with multiple servers or accounts. Terraform works similarly to a FIFO context, but you must wait a long time to create the entire deployment before going to the next account. If deployment on one account fails, you cannot proceed to the next one because Terraform's main focus is on the security of the infrastructure. My entire squad of four uses Terraform because we centralized the DevOps for Terraform. We are planning to expand this tool to our entire development team. We will have at least 15 to 30 developers using the tool in the future.

Their customer support is the worst. I opened a ticket, and I never got an answer, and the community does not listen to the most common issues. But I understand why I was left out because I asked a hugely specific question about a little bug in the code. My experience was not the best, but I no longer need to ask them because I make my own workarounds. Besides, we don't face issues that require us to talk to support.

The customer should receive an answer regardless of the question. Even answers like, "This isn't a feature," "We can't do this right now," or "This isn't the roadmap."

Neutral

I compare Terraform with Ansible. I work with multiple servers in Ansible in a FIFO method. You have a list of servers you apply one after the other. But you can work with those servers in parallel, even if one server fails to deploy. In Terraform, you must finish deployment on each account before going to the next one.

When I joined my current company, they were already using Terraform, and we had to create the environment on AWS manually. We are not using any IaC tools.

The initial setup was complex. You need to understand what you want to do exactly. You are a child in a playground with many toys to play with, and you can create anything you want. But if you pick up the wrong "toy," you can hurt yourself and the environment. Using the wrong module can bring a huge cost to your infrastructure, and it won't perform as well as you initially expected. Initial setup is more difficult to start if you have some infrastructure completed.

If you are setting up from the start with baby steps, it is a little hard to understand the documentation, though it makes the setup look much simpler. You need some knowledge to understand how Terraform can apply to your environment. After that, it's easier. And just like riding a bike, you never forget.

The time taken to deploy the solution depends on what you are creating. For example, if I create a DMS instance for my data lake, it takes 15 minutes to deploy. If I'm creating a different data lake on the Athena database, it takes exactly 23 seconds to create. A DMS takes much more time, but not more than half an hour.

While deploying Terraform, we checked the Terraform statement on AWS. Each account has its own statement. We checked the difference between statements, made a Terraform image, made a plan, and checked the plan to see if it was correct and applied.

I did the deployment myself, looking at the documentation.

We use the free platform using Dochub. Terraform is a little expensive. In a basic scenario, the price is too high to use such a complex tool in the long term. As a small company starting to use Terraform, the price is too high, so I recommend the free solution. If you are a huge company with a huge environment and infrastructure, the price will seem cheaper because you can control your entire infrastructure using Terraform. The solution then pays for itself. Choosing the paid version depends on the size of the company and your team's expertise.

Terraform licenses are per account.

We currently use a statement for replication, trying to embed Terraform into our applications, but that's a new feature. We are applying some other features, for example, to check for vulnerabilities on your first code or to scan if you have hard-coded passwords, but we have not found anyone to help with these use cases. One of my co-workers is certified on Terraform, and they bring similar solutions also being used on Terraform for scanning. For myself, I want them to make that code work on as many accounts as possible. The same code must work on our deployment, homologation/staging, and production accounts. These are the three environments the code needs to work in. We tried making this a few months ago.

When deploying the solution, I did it by myself, looking at their documentation. Their documentation is good and bad. Their documentation is good because it gives a huge amount of information for several different possibilities, but it's bad because the documentation does not have a lot of real-life examples. Terraform prefers documentation as much as hard-coded information. For example, you might be using a certain string to do something, but in reality, you can do that in many other ways, and the documentation won't show all of those. You need to do trial and error or take a course with the Hashicorp organization to understand the different ways you can do something or use the platform.

I rate Terraform a seven out of ten because of its complexity.

We use Terraform to create infrastructure. We get the name of the resource provider, and the Terraform script is returned in HashiCorp Configuration Language (HCL). 

We can find readily available code from the HashiCorp community to create a virtual machine or Kubernetes service cluster. We take that code, provide the resource provider name, and run the script using Terraform commands to create the infrastructure

We currently use Terraform in our Azure pipelines in the cloud. Our team has 10 developers, and we will increase our usage as the team grows. 

We frequently need to create and replicate infrastructure from various environments like dev and QA. The QA resources need to be identical to those in the dev environment. With a Terraform script, we can replicate the same 50 in the dev environment to the testing environment. This is tedious to do manually, and Terraform speeds up the process. 

Infrastructure replication is Terraform's most valuable feature. 

Terraform should also support YAML language, which is more user-friendly than HCL. They should also add a GUI, so you don't need to memorize all the commands. A GUI would enable us to do everything with a click of a button. 

I have been using Terraform for the last three years.

I rate Terraform seven out of 10 for stability.

I rate Terraform eight out of 10 for scalability.`

I rate HashiCorp seven out of 10 for technical support.

Neutral

I rate Terraform eight out of 10 for ease of setup. 

Terraform is an open-source solution.

I rate HashiCorp Terraform seven out of 10. It's interesting to see how the infrastructure is created rather than creating it manually.