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.

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

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

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

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.

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.

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.

The solution is complex when we use it for a loop. This is a problem, not because of the language itself, but because of how the infrastructure generally works. It's different from Python.

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.

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

The product must improve DevOps features.

Terraform doesn't support Artifactory as a backend.

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.

HashiCorp Terraform state management could be improved to be used efficiently with multi-users. Even though there are logs, there are always issues I've seen with people manipulating the TerraForm state. We cannot work efficiently with the solution if the state is incorrect. Due to certain reasons, if I have to change some piece of some resource, I cannot change it. I have to destroy the whole thing and then build a new one.

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

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. 

It would be helpful for us if the open source tech support was a little better. 

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

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.

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.  

The syntax is a bit difficult, and it would great if it could be easier.

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. 

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.

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.

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. 

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. 

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.

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.

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.

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

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.

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. 

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.