HashiCorp Terraform Reviews

I used HashiCorp Terraform primarily as infrastructure as code. It allows you to create, modify, and delete infrastructure resources. This includes tasks such as manually creating instances in the console or automating infrastructure deployment.

Variables are used to parameterize and customize configuration. We can use data to manage infrastructure. 

Additionally, HashiCorp Terraform allows for controlling storage and infrastructure status. Terraform modules make it easier to manage complex infrastructure and code within an organization.

There are potential improvements in the backend stability of HashiCorp Terraform. There are instances where unexpected terminations and destruction of running projects occur before releasing a lock. A stable backend would be beneficial. 

Additionally, there might be room for improvement in the user interface to make it more intuitive. The learning curve could be eased with better learning materials.

I have used HashiCorp Terraform for only eight months.

Stability has been a concern, particularly around backside stability with unexpected terminations and the necessity for a more stable backend.

My company employs seniors with extensive experience for complicated issues, but I have not escalated any questions or queries about HashiCorp Terraform directly. Therefore, I cannot comment directly on the customer service.

Neutral

The initial setup of HashiCorp Terraform was easy. I was involved in setting it up in my personal usage, which included installation commands on Linux, updating the system, and ensuring the correct version of Terraform was installed.

I was involved in the setup process of Terraform in my personal usage. In my organization, we follow standard operating procedures. Multiple users in the project used Terraform simultaneously.

In my organization, the integration of HashiCorp Terraform is recently being adopted, so I haven't observed any return on investment yet.

I would recommend HashiCorp Terraform to others due to its utility in creating multiple instances quickly. In cloud environments, it saves time in instance creation compared to manual methods. 

I rate Terraform a six out of ten.

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.

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. 

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.

The solution is a success code. We use open-source software.

The first thing I like about the solution is that it keeps a version of your infrastructure. And you always have, for example, the bill of materials with what it produces in terms of YAML files that you can manipulate and understand exactly what infrastructure you deploy, what is active, and what is not. We use it with the Amazon database, where the solution does not deploy the second time if somebody triggers a build or deployment. Apart from those features, the fact that you have your infrastructure on code is tremendous.

It would be nice if they could put our infrastructure on graphics or at least provide a map of our infrastructure, especially with links, to see what it looks like graphically. That way, we could understand the relationship between all the machines. That helps with redundancy purposes, where, for example, if we need to create redundancies to create high availability for some services, we could look at the map directly.

I've worked with the solution for three or four years.

The solution works very well every time. It calls APIs from Amazon, so it's always up to date. I rate the solution's stability a nine out of ten because we never had a problem.

I rate the solution's scalability an eight out of ten. It's pretty scalable on the Amazon cloud. We have around three or four users on the solution.

HashiCorp's technical support is very good. They know what they're talking about.

The initial setup is really simple. We just created YAML files with what we needed, and somebody deployed machines and load balancers. It's just a binary we needed to place anywhere.

We deployed the solution on Amazon's cloud. For the AKS cluster, we just launched Terraform, which region and which kinds of machines we wanted to install.

Terraform's philosophy is different, but Ansible is a similar product. It's not the same, though you can also deploy virtual machines, for example. However, I would not use Ansible because it does not have the same features as Terraform when it comes to history. Terraform pulls the API first to understand what you have from your schema and compare it with your existing infrastructure.

Ansible would not do that. It would just execute the code and deploy without knowing what it does.

We don't use Terraform in a very fancy way. The solution did not have a difficult use case, nor did we go into a specific feature of Terraform that we tested very thoroughly. We used it in a basic way, simply trying not to run the same script twice or by two people simultaneously.

I rate HashiCorp Terraform a nine out of ten and recommend it to everyone.

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 the solution for provisioning.

The most valuable feature is the solution does not need installation.

The solution is missing a lot of properties for specific resources.

I have been using the solution for almost three years.

The solution is very stable.

We just need to download the installer from HashiCorp. We don't need to install the solution; we just need to place the file on our system, point it to the enrollment variables, and then we can run Terraform. There are three or four commands that must be executed before we can start using the solution.

The solution is open-source.

I give the solution eight out of ten.

The solution is the most popular for provision in the cloud, not only in Azure.

It enables us to create our cloud implementations without a technician needing to sign on to the cloud.

We are able to do multiple hybrid cloud implementations for clients that need to support Azure and AWS. 

It allows for the abstraction of the work away from the developer into automated processes. 

The reuse simplification is very good. 

It can enforce DevOps. 

It is stable. 

Technical support has been fine. 

The workflow and automation could be better.

The user interface could be easier for non-technical people. 

There's a learning curve involved with the setup; however, it is low to medium. 

I've used the solution for a long time. I've used it for 12 years at least. 

The stability is excellent. There are no bugs or glitches. It doesn't crash or freeze. 

It's not a customer-facing solution. We've never had an issue with it. However, it is not a primary concern of ours in terms of the ability to expand. 

Most business analysts and sometimes architects use the solution. We have 1700 people in our organization, and we are doing 100 projects at a time. Almost all of the projects require the use of the product. Half of the people are engaged in the solution in one way or another. We have about 750 people using it. 

Technical support is very good. 

The initial setup is very simple for the most part. 

The pricing is expensive. It's more for enterprise implementations. The cost is above average in general. 

We're a consulting company. 

I'd advise other users to automate to the greatest extent possible to get the best ROI.

I'd rate the solution nine out of ten, even though the workflow is not the strongest on the market.