One area for improvement could be the inclusion of more dedicated Terraform providers developed by the companies themselves, rather than relying on third-party developers. Additional features could include more intuitive environment-specific configurations and possibly enhanced support for development and production environments.
IT Consultant at a tech vendor with 1-10 employees
Consultant
Top 10
2024-06-06T15:20:00Z
Jun 6, 2024
Terraform should monitor the backend storage more closely. You can handle it within Azure, but HashiCorp should release a dedicated tool to protect those secrets and ensure they're fully encrypted but this functionality is on its way for Terraform. They do have functionality that encrypts secrets and rotates which is great just like what Microsoft have and should be used in the wider community to safeguard public cloud systems
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.
Senior Devops Engineer at a tech services company with 201-500 employees
Real User
Top 5
2024-03-05T10:16:28Z
Mar 5, 2024
The versions of Terraform providers are an area of concern where improvements are required. If a person wants to use the modules created by someone else a few years ago, then there is a need to change all the resources or use the version of the product in which the modules were created. The modules are suitable only for the particular provider version on which they were created. The product should be made more dynamic in nature.
Senior Devops Engineer at a financial services firm with 501-1,000 employees
Real User
Top 5
2024-01-04T17:40:23Z
Jan 4, 2024
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.
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.
Site Reliability and DevOps Engineer at a tech services company with 51-200 employees
Real User
Top 5
2023-08-22T11:48:19Z
Aug 22, 2023
I know a UI tool is available in the licensed version of HashiCorp Terraform. From a user's perspective, it would be great if a UI tool is made available in the open source version as well, but I don't think it may be introduced because of the high costs for it announced by HashiCorp in its licensed version. HashiCorp Terraform can improve backward compatibility. From users' perspective, migration from one version to another is okay. The migration from an older version to a newer version is a big challenge in HashiCorp Terraform. We tried to fix the migration issues multiple times at our end and saw that some will not be compatible sometimes while, at times, certain aspects will be compatible with the new version.
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.
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 initially found the initial HashiCorp Terraform difficult to comprehend. It's not straightforward especially in complex cloud environments, requiring proper training to grasp it. Even someone with a background in networking or cybersecurity would need guidance from someone knowledgeable. Inclusion of revert function or rollback action for any invalid or wrong changes to resources.
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.
Kubernetes Consultant, Cloud Architect at a computer software company with 51-200 employees
Real User
2022-11-29T17:21:17Z
Nov 29, 2022
In Terraform, there's a file called main.tf, where everything starts. In the main.tf, you need to specify the provider you're using. For example, maybe you want to use GCP, but you don't want to work on GCP. That's where you will list everything you need. It's like a key for you to access GCP. Sometimes, it can be challenging to undo. Let's say I'm using the provider here, and you want to use it on your site over there. You have to delete the provider you are using before switching providers. It doesn't sync well. The providers don't sync well. And also the documentation sometimes, they need to work on the documentation of Terraform. They're not concise. The error logging could be better. Sometimes, when you try to set something on Terraform, it gives you an error, but you don't understand how the error has been logged.
Co Founder and Technical Architect at Think NYX Technologies LLP
Reseller
2021-01-05T13:40:10Z
Jan 5, 2021
I think, they should come up with the feature to write code for the resource which we import using their import capability in the in our project, that will definitely help many users to prefer this tool which help them out to manage their existing setup as well using Terraform itself.
Senior Build And Release Engineer at a tech services company with 1,001-5,000 employees
Real User
2022-10-04T14:10:53Z
Oct 4, 2022
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.
Executive Vice PresidentExecutive at a government with 10,001+ employees
Real User
2022-09-28T17:08:25Z
Sep 28, 2022
There is always room for improvement somewhere. I don't know everything about the product. I read about the improvements and the different things that are coming out all of the time. They continue to maintain it.
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.
On occasion, I have noticed a number of bugs in this solution that have needed to be fixed. In a future release, it would be great to have an easier way of troubleshooting. We'd like to have a dashboard where company management can get a full view of provisioning.
Chief Technology and Strategy Officer at The White House
Real User
2022-02-22T00:36:17Z
Feb 22, 2022
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.
This solution could be improved by adding features such as CDM to accelerate the access of data by the users. It would be useful to be able to test functionality when building infrastructure. Currently we use other tools to do this.
I would like to see a short-term option for a short-term plan. The last few versions contain plans with very long output which have since been altered. When one receives a plan involving many changes, it will not be applied. Even should nothing need apply, there is a very long history which is not really useful, as many find its application confusing.
Senior Information Technology System Analyst at YAUSH Technologies
Real User
2021-04-29T09:06:32Z
Apr 29, 2021
The state locking functionality can be improved. In certain situations, we have to force-unlock the state, which sometimes does not work. When that happens, we have to manually go to the state backend and remove that particular state, which is kind of a cumbersome process. It should also have more functions, more expressions, and support for more products.
Co Founder and Technical Architect at Think NYX Technologies LLP
Reseller
2021-01-04T11:46:00Z
Jan 4, 2021
They have added a feature that helps us to import existing resources to our workspace, but if they can help us to create the code for the import, as well, then it would be a great addition.
Sr. Systems Engineer / Tech Logic Consultant. at a non-tech company with self employed
Real User
2020-11-13T18:28:00Z
Nov 13, 2020
I'm really happy with Terraform because it has really come a long way up to this point. It has a stable version. For the moment, Terraform is actually working really well with a majority of our providers and technologies. At this point, the news cables are about 80% to 90% from the feed. I don't see a problem with the product. But if you're talking about homes, bugs and some certain features, I think there are features that could be included. For example, if you are copying something from a well running machine to a remote machine, there are some issues with the current version, but it is acceptable.
Partner & principal technologist at SwanSpeed Consulting
Real User
2020-11-09T21:19:00Z
Nov 9, 2020
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 personally say it's already simplified. I don't see many areas for improvement because Terraform employs a lot of skilled engineers that put their time and energy into providing a fantastic enterprise-level tool like this. There is not much more to simplify. There are already quite notable features in Terraform and we've already been provided with updates and other features. In short, there are many things which are already in place, so I don't think that we need anything more from Terraform.
HashiCorp Terraform is a powerful configuration management solution that aims to provide users with the ability to maximize the ease with which users can perform their configuration management operations. It makes it so that organizations can reliably configure and manage their infrastructure. Terraform is a tool that transforms every user into an administrator and project collaborator. Businesses that use it have at their command a solution that they can use for the entire lifecycle of...
One area for improvement is real-time syncing with the actual infrastructure. Currently, you have to run CLI commands to sync the state file.
One area for improvement could be the inclusion of more dedicated Terraform providers developed by the companies themselves, rather than relying on third-party developers. Additional features could include more intuitive environment-specific configurations and possibly enhanced support for development and production environments.
They perform better with their commercial product, Terraform Cloud. Everything in the free product is already available in a comparable solution.
Terraform should monitor the backend storage more closely. You can handle it within Azure, but HashiCorp should release a dedicated tool to protect those secrets and ensure they're fully encrypted but this functionality is on its way for Terraform. They do have functionality that encrypts secrets and rotates which is great just like what Microsoft have and should be used in the wider community to safeguard public cloud systems
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.
The versions of Terraform providers are an area of concern where improvements are required. If a person wants to use the modules created by someone else a few years ago, then there is a need to change all the resources or use the version of the product in which the modules were created. The modules are suitable only for the particular provider version on which they were created. The product should be made more dynamic in nature.
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.
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 know a UI tool is available in the licensed version of HashiCorp Terraform. From a user's perspective, it would be great if a UI tool is made available in the open source version as well, but I don't think it may be introduced because of the high costs for it announced by HashiCorp in its licensed version. HashiCorp Terraform can improve backward compatibility. From users' perspective, migration from one version to another is okay. The migration from an older version to a newer version is a big challenge in HashiCorp Terraform. We tried to fix the migration issues multiple times at our end and saw that some will not be compatible sometimes while, at times, certain aspects will be compatible with the new version.
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.
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.
They should provide more tutorials to understand the solution's use cases. Also, they include more specific features into it.
The syntax is a bit difficult, and it would great if it could be easier.
The solution is missing a lot of properties for specific resources.
I initially found the initial HashiCorp Terraform difficult to comprehend. It's not straightforward especially in complex cloud environments, requiring proper training to grasp it. Even someone with a background in networking or cybersecurity would need guidance from someone knowledgeable. Inclusion of revert function or rollback action for any invalid or wrong changes to resources.
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.
The price of the solution could improve.
In Terraform, there's a file called main.tf, where everything starts. In the main.tf, you need to specify the provider you're using. For example, maybe you want to use GCP, but you don't want to work on GCP. That's where you will list everything you need. It's like a key for you to access GCP. Sometimes, it can be challenging to undo. Let's say I'm using the provider here, and you want to use it on your site over there. You have to delete the provider you are using before switching providers. It doesn't sync well. The providers don't sync well. And also the documentation sometimes, they need to work on the documentation of Terraform. They're not concise. The error logging could be better. Sometimes, when you try to set something on Terraform, it gives you an error, but you don't understand how the error has been logged.
I think, they should come up with the feature to write code for the resource which we import using their import capability in the in our project, that will definitely help many users to prefer this tool which help them out to manage their existing setup as well using Terraform itself.
It would be helpful for us if the open source tech support was a little better.
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.
There is always room for improvement somewhere. I don't know everything about the product. I read about the improvements and the different things that are coming out all of the time. They continue to maintain it.
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.
On occasion, I have noticed a number of bugs in this solution that have needed to be fixed. In a future release, it would be great to have an easier way of troubleshooting. We'd like to have a dashboard where company management can get a full view of provisioning.
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.
This solution could be improved by adding features such as CDM to accelerate the access of data by the users. It would be useful to be able to test functionality when building infrastructure. Currently we use other tools to do this.
I would like to see a short-term option for a short-term plan. The last few versions contain plans with very long output which have since been altered. When one receives a plan involving many changes, it will not be applied. Even should nothing need apply, there is a very long history which is not really useful, as many find its application confusing.
The state locking functionality can be improved. In certain situations, we have to force-unlock the state, which sometimes does not work. When that happens, we have to manually go to the state backend and remove that particular state, which is kind of a cumbersome process. It should also have more functions, more expressions, and support for more products.
They have added a feature that helps us to import existing resources to our workspace, but if they can help us to create the code for the import, as well, then it would be a great addition.
I'm really happy with Terraform because it has really come a long way up to this point. It has a stable version. For the moment, Terraform is actually working really well with a majority of our providers and technologies. At this point, the news cables are about 80% to 90% from the feed. I don't see a problem with the product. But if you're talking about homes, bugs and some certain features, I think there are features that could be included. For example, if you are copying something from a well running machine to a remote machine, there are some issues with the current version, but it is acceptable.
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 personally say it's already simplified. I don't see many areas for improvement because Terraform employs a lot of skilled engineers that put their time and energy into providing a fantastic enterprise-level tool like this. There is not much more to simplify. There are already quite notable features in Terraform and we've already been provided with updates and other features. In short, there are many things which are already in place, so I don't think that we need anything more from Terraform.
It should have a more object-oriented approach like different coding languages.