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.

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.