HashiCorp Terraform Reviews

We use HashiCorp Terraform to set up AWS infrastructure, and sometimes Cloudflare.

It is not exactly a tool for configuration, it is for setting up the development of the infrastructure.

The concept of infrastructure as code is quite intriguing.

We have an infrastructure in our code and a state file where we can verify whether something is changed when it was changed, and who changed it. When we use Terraform, these kinds of things fascinate us.

I often wonder why they don't create a UI. That is something I always consider. I realize CLI is useful, but I prefer to do things in this manner. Why are we opting for CLI? I want to make things easy. I understand that most don't agree with me, but that is what I would prefer.

I don't think that they will agree on this. I am looking for a drag-and-drop or anything that can just generate modules behind the scenes and allow people to quickly accomplish things. 

I am aware that it does not serve the purpose of Terraform, and that too, is an issue. 

We have a purpose for infrastructure as code, and when the code is gone, you are working on UI. Terraform is not a programming language, most things are straightforward; we cannot do. Terraform lacks these features.

I would say the programming language, perhaps using more of a programming language rather than this declarative language, is something I'd want to explore in the future.

I would want to see more programmatic capabilities implemented, such as if, else, and simple to manage things in terms of how I can use some programming functions to assist us to achieve more.

I would like to have programming language-relevant features, to have programming language be the primary way.

I have been using HashiCorp Terraform for three years.

I don't think HashiCorp Terraform is particularly stable. I would rate it a three and a half out of five. However, we are always working on it and making improvements. They had a lot of problems in the past, but today most things are done correctly.

While there are new versions coming in, there are always issues that arise.

It is not about stability, but about version upgrades. They have newer versions and occasionally backward compatibility. It happened a long time ago but is not an issue anymore. I had a bad experience at the beginning, which is why I remember it.

Someone who is just starting, in my opinion, will encounter difficulties. That is why I believe the language should be changed to a programmed language that everyone can comprehend.

The previous version had several difficulties with the state file, including some backward compatibility and parameter changes, but they are now more stable.

I have not encountered any issues with HashiCorp Terraform's scalability.

We are using Terraform to build up infrastructure in order to document our infrastructure more declaratively. That is what Terraform excels at. I never had any problems with scalability, either in terms of improvement or anything else. 

There are some glitches with Terraform servers. When we are initializing, we occasionally encounter an issue; in three years, this has happened to me twice.

We have 20 people in our organization who use this solution, if we add developers we have approximately 60 people.

From inside the cloud services, I am working on EKS Kubernetes, ECS Elastic Containerized Services, and Elasticsearch, which is now known as OpenSearch. I am working on EKS, Kubernetes, ECS, Elastic Containerized Services, as well as Elastic Search, which is now known as Open Search, and Redis ElastiCache, which is a component of MSK Kafka.

These are the tools I am using. Jenkins is used for the CI process, as well as GitHub Action is used for the CI process. 

As previously mentioned for alerts, we use Opsgenie and Grafana for the dashboards and premises. 

Many third-party services, such as NGINX, are used in Kubernetes. We use Cube Metrics for these kinds of activities, such as metrics scraping.

I have worked with Ansible as well, however, if you asked me to compare the two, I would say Terraform is superior to Ansible. I am not going to get into specifics. 

Terraform, is self-explanatory. It knows how to run, if we want to build some infrastructure, it understands where to start, how to start, what the dependencies are, and so on. 

We must occasionally inform Terraform of some dependencies, which is fine. Terraform, on the other hand, already understands the sequence in which it must execute certain infrastructure to build up. Those are the advantages over Ansible.

The disadvantage of Terraform is that, once again, we must use functions to build up variables or something similar, but Terraform's dry notion is not very good.

When I say dry, I mean that you should not repeat the bad code. Other references are being used to handle this. That is something I would want to suggest.

The initial setup is simple. It is not a difficult process to set up.

I would rate the initial setup a four out of five. it is easy.

When a new version is released, it is backward compatible. And I would say that is good in terms of Terraform maintainability. Normally, we don't have to make many changes, and backward compatibility is beneficial.

In terms of maintenance, it does not require a lot of attention.

It's good, I would rate HashiCorp Terraform an eight 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. 

HashiCorp Terraform is a system solution that allows for infrastructure to be managed as code. allows for the efficient creation and management of infrastructure by packaging everything together in one package. This includes the networking, security, and encryption for Google Kubernetes Engine (GKE) deployment.

By using HashiCorp Terraform, the infrastructure is all in one place and can be easily tested and checked for security vulnerabilities before deployment.

The valuable features of HashiCorp Terraform are the infrastructure can be written, shared, and collaborated on using code, which speeds up deployment. Additionally, bugs and issues can be fixed in the code and redeployed, making it less risky. It is a more efficient method compared to the traditional approach of writing scripts to set up infrastructure.

The infrastructure is transparent, as it is stored in a source control system, such as Bitbucket, making it easy for all team members to access and review. Furthermore, Terraform enables the creation of a deployment pipeline using tools, such as Atlantis, which automates the process of scanning and deploying the code. This streamlines the deployment process and adds features, such as auditing, risk management, and security scanning to the deployment process. Terraform provides a more organized and secure way of managing infrastructure, compared to the traditional ad-hoc method.

HashiCorp Terraform is an open-source tool that relies on external developers to create plugins to expand its capabilities. However, this approach can be problematic as not all plugins are created by professionals and some may have security vulnerabilities. In the case of GKE, Google has created a solid plugin, but for other services, one must search for plugins on the HashiCorp Terraform registry, which can be hit or miss, as many plugins are created by students or hobbyists, who may not continue to maintain or update them. This model of open-sourced plugins may not be the most reliable or secure way of expanding the tool's capabilities. 

It is possible that when using a plugin with HashiCorp Terraform, there may be security issues or the plugin may become outdated in the future. HashiCorp Terraform only takes responsibility for the infrastructure and code of the program itself, not the plugin. This is a point of concern as it is the responsibility of the user to police and manage the plugins, which can be a significant overhead. Additionally, the solution requires plugins for modules, so without them, Terraform cannot communicate with certain resources.

To improve this, it would be beneficial if HashiCorp Terraform had a system in place where they certify and test the plugins. This would take the burden off of users and reduce the cost of using the solution. The current system relies heavily on open-source plugins which may not be fully developed, lack features, or may not be secure. It is not uncommon for users to have to fork or manage these plugins themselves, which can be a significant undertaking.

The module system in the solution is not the best, as it forces users to rely on third-party developers who may not be qualified from a security or engineering standpoint. This can create a problem for users as they may not have access to all the features they need, and may have to fork or manage the plugins themselves. HashiCorp Terraform, as the creators of this system, should take more responsibility for the management and security of these third-party plugins.

The use of open-source code, such as that used in this solution, can present issues as it may not always be fully supported or maintained by its creators. This publicly traded, multi-billion dollar company, may not want to take full responsibility for the plugins and modules that are created by third parties. This can be problematic for users, as they may have to police the plugins themselves to ensure they are secure and functional. Furthermore, while some companies such as Google may have the resources to create their own Terraform plugin and take responsibility for it, many other companies and developers do not have the same resources and may not take responsibility for maintaining their own plugins. This can lead to a broken system where users may have to pay extra to have broken plugins fixed. Overall, this highlights the need for a better system of support and maintenance for open-source code and plugins.

I have been using HashiCorp Terraform for approximately four years.

The solution is scalable. It is well suited to managing complex cloud environments, such as Google Kubernetes Engine, that require various services and configurations.

HashiCorp Terraform is a cost-effective solution.

HashiCorp Terraform has issues with testing and the modules. Overall, the concept is great. What they did works well. However, the extension to it is not the greatest.

I rate HashiCorp Terraform a seven 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 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. 

I use this solution for infrastructure for my projects that are deployed in Google Cloud. I work in EPA systems. 

The solution allows you to have infrastructure-like code which is basically what Terraform has been about. Terraform makes it easier to figure out the kind of problem that has occurred, why, and who was responsible.

Although using an older version, I've found the biggest advantage of Terraform is that it can be used across multiple cloud providers and multiple platforms and it has a simple API. 

The biggest disadvantage of Terraform is its lack of flexibility in common programming languages. It also lacks flexibility in creating some functions like complex expressions to declare random variables, and features that require any programming language. Those issues are because HashiCorp is trying to keep the API as simple as possible. I would like to see some idea of functional programming in Terraform. It would be great if you could process your data and push it back to the model. It would mean a huge improvement in flexibility. 

I've been using this solution for three years. 

The solution is stable and we haven't had any problems in that regard. 

The solution is scalable and we are constantly working on increasing of size of our infrastructure.

The initial setup is a little complex but not very difficult. Implementation time depends on the size of the deployment. Our deployment was carried out in-house. We need at least one person per 50 models of Terraform for implementation. 

We've had a return on our investment because it's decreased the overall ops overhead via the front team.

I am not using a payable Terraform although I'm quite familiar with the price and don't consider it to be expensive. Licensing costs are mid-range. 

I would suggest reading documentation and experimenting with the solution. 

I rate the solution 10 out of 10. 

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 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.