HashiCorp Terraform Reviews

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. 

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.

HashiCorp Terraform is a binary executable file, that you can download to your PC and manage any cloud solution in the world, such as Google Cloud Platform, Amazon AWS, OpenStack, CloudStack, or VMware. When you use DevOps in your company, it's a useful tool for it.

The most valuable features of HashiCorp Terraform are automation and management capabilities.

HashiCorp Terraform could improve the integration with the VCloud Director. When we manage the VCloud Director we end up wasting our time when creating virtual machines. HashiCorp Terraform knows about these issues and I think there might be a workaround but they should incorporate the fix in an upcoming release.

I have been using HashiCorp Terraform for approximately one year.

HashiCorp Terraform is a stable solution. We did not have any problems.

The scalability of HashiCorp Terraform is good.

I have not used the technical support from HashiCorp Terraform.

HashiCorp Terraform tool is pre-installed on our DevOps engineer's laptops, and in our GitLab Servers. We assign it to a selection of virtual machines. We just run it, and then we perform some functions, such as creating systems or modifying CPUs or RAM.

We did the implementation of HashiCorp Terraform in-house. We have a good team of three programmers and DevOps engineers with experience.

We used one engineer for the implementation of HashiCorp Terraform. 

HashiCorp Terraform is a free solution.

I rate HashiCorp Terraform a nine out of ten.

A primary use case of Terraform is for deploying a VM on a cloud using Terraform script. If I then want to deploy a third-party toolset, a solution such as Aviatrix can create an overlay on top of each of the cloud providers and you can connect the clouds together. I'm a solutions architect and we are customers of HashiCorp. 

The solution has made a huge difference to us because the automation it provides has given us improved cost efficiency, security and saved many man-hours. It's created once and then that's pretty much it. When you next want to deploy something, you run it and it deploys. 

Terraform removes the manual process; you run it for a specific purpose, destroy it when you're done, and it removes all the associated components. The other good feature is that Terraform is idempotent; if something is already out there, it's not going to try to duplicate another installation of that environment.

One of the other major features of terraform is in its ability to act as a Disaster Recovery tool. Since terraform is an Infrastructure-As-A-Service tool, it can be used as part of the rest of the DR toolset to restore affected infrastructure to its original state without any variation. 

The Terraform manifests can be stored in a version control repository separate from the application code base and can be a single source of truth for an organization's infrastructure. The automation and the efficiency that Terraform brings to the SDLC lifecycle adds to the overall integrity of the infrastructure and provides a value added to the DevSecOps workflow.   

I've noticed that although Terraform is very good at deploying, it lacks in running script. For example, if you wanted to run multiple deployments such as a VM, and then install different softwares and create a full-blown infrastructure within that virtual machine, Terraform would probably lack certain features. I don't think it's very robust in running scripts or going from one sequence to another. You're likely to end up running a huge Terraform code base, where you'd probably get lost in terms of knowing where things are coming from and where they're going. 

I've been using this solution for two years. 

The solution is stable without too many bugs. If we're deploying on top of a current deployment, there can be some issues and that could be improved. If you need a fully idempotent solution, you deploy your infrastructure without touching any existing infrastructure. Unfortunately, Terraform fails when it finds an existing infrastructure and things become complicated. In terms of stability, this is probably one of the biggest deficiencies of Terraform. 

HashiCorp provides very good documentation so we haven't needed to contact technical support. They also have GitHub repository against each of those tutorials, so we can actually clone and tweak those according to our needs. There's also a large open-source community out there and a lot of blogs that complement the documentation. 

Deployment is just about downloading the plug-in. To run it requires each of the cloud environments on the CLI tool downloaded so that they both work together with all the credentials in place so that it can connect to each of the clouds. We are a small organization and still experimenting with Terraform so we only have one dedicated person helping out with the solution. That said, all of the team members are more or less skilled with Terraform.

We're definitely seeing cost savings from a man-hour point of view but I can't quantify it. 

We are using the free version of Terraform. Terraform Cloud has some kind of pricing and enterprise-level model which we haven't moved to yet. I think  Terraform has a pretty reasonable pricing structure. It allows the open-source community to use it as they please, so I'm pretty happy about it.

AWS has a code solution called CloudFormation which I think is a little slower than Terraform although I think CloudFormation is probably a bit more secure and foolproof.

This is a solid product and one of the leaders in this space. Terraform is used across the board as an Infrastructure-as-Code solution. 

There could be some improvements so I rate this solution eight out of 10. 

Our primary use for the solution is to create infrastructure on the cloud. 

We are a cloud integrator. We write our codes in Terraform and reuse them for multiple customers by changing the values. 

The most valuable feature is the great community support. 

The product can be improved by implementing a native provider service. With Terraform, you need to switch the provider's version and get functionality from only that version. 

The competitor tools have native providers. You don't have to wait and request the provider to gain functionality; it's provided directly from the cloud. 

The integration with this solution needs to be improved. For example, if you want to deploy something from Terraform to Kubernetes and make changes very often, practically, it isn't easy to implement. If someone deletes something accidentally, the integration won't function well.  

I have been using this solution for more than five years. 

I would rate stability a nine out of ten. I don't have any problems with the stability. 

I would rate scalability a seven out of ten. It is problematic when multiple people want to work on the same Terraform code.

This solution is best suited for enterprise-level companies, but medium and small businesses can also use it. 

The initial setup is straightforward. The deployment time for the solution is about thirty minutes. 

We are using all the deployment models for this solution. But I prefer to use the CI/CD pipeline, which involves running the Terraform code as a final solution. I also prefer the CLI platform on my computer for development. When I develop the code, I prefer running it from my computer. After the code development, I prefer to have its own CI/CD pipeline. 

I would rate pricing a ten out of ten. You can do everything with the free license of this solution. The paid license is not required to use Terraform. 

We used Pulumi for a project. We found that Terraform is easier to write code and works faster. 

But it would be best if you learned Terraform HCL language. In the competitor solution Pulumi, languages like Go, Python, and other languages can be used. There is no need to learn a new language to use Pulumi. 

For me, it's more complicated to write the same infrastructure. If you are a cloud administrator, you should use Terraform. But if you are a developer or want to deploy simple infrastructure with knowledge of the cloud, then you should use Pulumi.

I will rate the solution a five out of ten. This is because multiple other solutions get used with Terraform. For servers, we use Ansible, whereas, for cloud infrastructure, we use Terraform. Developers need Pulumi for implementation. Terraform is facing a lot of competition. 

I would recommend Terraform to others. If you have more than one environment, you will definitely need Terraform. 

It is easy to architect cloud infrastructure using the solution. Also, its simple interface helps in developing specific scripts.

They should provide more tutorials to understand the solution's use cases. Also, they include more specific features into it.

I have been using the solution for three years.

It is a stable solution.

It is a scalable solution.

The solution's initial setup process is straightforward. It takes a couple of weeks to complete. Once you define everything, you can start working on it right away. The deployment happens almost immediately.

I recommend the solution to others. I rate it ten out of ten.

The office was working out of their office and they had around nine clients. The workspace would be in AWS and doing a VPC manually would have been a really hard job. The time estimated for doing nine virtual private clouds would have taken more than a month or two. Using Terraform, they were able to finish it in two weeks. The speed at which we could create the infrastructure was much faster than physically doing it. Also, having an audit and log for all the infrastructure was managed a lot easier using Terraform rather than doing it manually.

One of the most valuable features is that it offers the ability to create a VPC, Virtual Private Cloud and VPN connectivity to the VPC can be automated without having to do it manually. 

I still struggle a bit when configuring VPNs when we have multiple rules. If we have five or six virtual private clouds and we have to give rights between those multiple VPCs, we can have big problems.  I think it was a learning curve and then we improved it. 

I have not come across anything that really stopped us from not doing anything for our requirement as of now.

I liked it because since it's scriptable, the way you create the infrastructure is the same way you can delete the infrastructure also. If you created 10 to 20 different services and objects in AWS using a Terraform script, it's much easier for a person to get the whole infrastructure down. You can do a backup and then you don't really need AWS services because either the client does not exist anymore, or there is some gap before the client comes back, you don't have to manually go and delete all the resources. One script would actually remove everything from AWS. 

Cost-wise, going through the script and then removing everything that you have created through the script is much better than manually doing it. That was helpful for the client as well.

We use it to manage infrastructure. For day-to-day work, the main developers were not using Terraform, so it was only three of us who used it. We were working on Terraform, created those scripts, and then gave it to the client for whom I was doing the work. Since it's now scriptable, they are able to manage and do all these small changes. They don't come back to me. Since they don't come back to me, it seems like it is working fine.

Terraform keeps updating its scriptable platform, the engine through which they communicate. So if there is any change in AWS, they keep updating it. Even from the deployment side, they have to be aware of the features, which Terraform still supports and the features, which Terraform doesn't support and then work around accordingly.

The initial setup, like doing the AWS credentials, putting it in place, and getting the API keys are the parts that took time. Otherwise, it is a lot faster and the learning curve is also much easier since it's a YAML-based scripting language. Even a non-programmer in a normal office can understand what is happening in the flow.

The deployment took around 15 days. In around 20 days we were ready with the Terraform scripts and then made small changes. Every time they need a new infrastructure that requires a small change, it would take a day or two. We created the initial Terraform script and gave it to a client so that it could later be managed by the client itself to create and run. Fifteen days was good enough for us to create and test the Terraform infrastructure and then give it to the client.

We started the deployment by seeing how we would divide the infrastructure. One is the list of infrastructure, which we would need irrespective of the clients for the VPC, VPN gateway, and active directory services. Those are all mandatory items that we would need for all the VPCs. And there are some items that are client-specific. We divided it into multiple parts. One is generic, which you will need for all the clients that are a base level. Then you keep playing the client's specific scripts on top of the base script.

It's open-source.

Rather than doing a monolithic Terraform for the whole infrastructure, it would be good for the script to be reusable. Use the base level script that every infrastructure would need. Generating a local IP network and then creating two instances or creating some databases and other basic scripts that all the infrastructure would need should be a base level script. Then add on your base level script with the add-on scripts on top of the base script to create infrastructure that is specific to clients. You can reuse the script, the same base group for many other purposes as well.

Before using Terraform, for auditing, creating machines, etc, we would either rely on AWS infrastructure itself or documents that had infrastructure-related data. Using Terraform, a lot of this data was captured automatically since it's a YAML script. It could be easily exported as a document or Excel file as well. Documentation and infrastructure was much easier to maintain than doing it otherwise.

I would rate Terraform an eight out of ten. 

We are using HashiCorp Terraform to deploy infrastructure for our customers in Amazon AWS.

Our process has been made more efficient with the use of HashiCorp Terraform. This includes the ability to create deployments while also avoiding errors and misconfigurations. With this solution, we can ensure consistency in the deployment of all our customers.

The state file is the most beneficial aspect of HashiCorp Terraform. It enables the retrieval and utilization of a previous state to build upon. This feature is particularly important since it allows for the identification of changes from the previous state, making the state file a critical component of the process.

When a misconfiguration or drift occurs, fixing the issue can be difficult. For instance, if there is a change in API calls while a script is running, it can be challenging to make corrections. This may require additional review and modifications to the code. I recall an instance where an industry budget creation process was altered, and it took significant time to amend the code. In fact, I had to add five or six different script portions to resolve the issue.

In a future update, it would be beneficial for HashiCorp Terraform to include a code-writing feature. There is the availability of third-party solutions, it would be preferable to have the ability to write code, create a plan, and receive feedback on what will be implemented. It would be great if the generated code was easily readable and viewable, as this would be an exciting addition.

I have been using HashiCorp Terraform for approximately two years.

My advice to others is its crucial to handle key and access management properly because the most convenient method is to add your key to your computer's environment variables. However, this approach is not the most secure way to manage your keys. Therefore, exercise caution in this regard.

I rate HashiCorp Terraform a nine out of ten.