Basically whenever your DevOps engineers are overseeing in excess of ten machines or when you need numerous groups not zeroed in on DevOps to assist with claiming the framework facilitating their code. Prominent sentiment is that Terraform isn't exceptionally secure, fight tried, and spilling mysteries happen effectively on mishap. Thus, Terraform is not so great when you need to store bunches of touchy mysteries that your organization is lawfully needed to watch in case it is the finish of you.

Deploy Infrastructure rapidly and dependably. Repeatability because of utilization of modules. the suppliers work really hard keeping awake to date on the most recent changes from the Cloud suppliers Features Updates. This makes exploiting the new elements dispatched not an issue. Terraform is totally and absolutely better than utilizing CloudFormation straightforwardly.

The actual language is somewhat surprising and this makes it difficult for new clients to get onboarded into the codebase. While it's improving with later deliveries, essential ideas like "map a variety of choices into a bunch of designs" or "apply this rationale in the event that a variable is indicated" are conceivable however superfluously unwieldy. A rollback component would be a welcome expansion to Terraform. At the time I'm composing this, when Terraform experiences a mistake, it stops on the progression where the blunder is experienced and any assets recently made are left set up. While this is wanted as a rule, and choice for moving back those assets would give usefulness like other IaC devices.

Using Terraform allows us to use the Infrastructure as Code pattern (IaC). This means, rather than logging into the cloud service providers and manually amending things and not being able to do all those things quickly, accurately, and repeatedly (for deployments), using Terraform allows us to do all of that automation.In addition, because the changes are done as code, they are submitted to a version control system (Git) and so reviewable, approvable (or not), merged, and automatically deployed by a secure pipeline setup.

The ease of use and the speed at which bug fixes and related enhancements can be submitted via GitHub and be approved and so you end up running your amendments without needing to work around them.

One aspect is that there is a library that doesn't include all aspects of Terraform and so dependent applications are not fully capable of exposing all the aspects.

1. There was generally one example on each resources in terraform documentation which makes understanding a bit challenging. 2. There are very few developers with the terraform experience. 3. After writing the terraform scripts, the developers has to check the terraform plan properly before proceed the terraform apply command . There is a possibility that Developers run terraform apply command directly which would lead to deletion or modification of the resources and once resource is modified or deleted, there is no way to get the resources back.

1. Terraform state file which keeps the record of all the provision resources done by using Terraform script. 2. Reduces the repetitive task of developers: If there are resources which are created in Development environment and we need the same resources in Production environment too. Then instead of developers provisioning resources manually, we can easily reuse the terraform scripts that were used in Development environment to provision resources . 3. Terraform manages infrastructure on multiple cloud platforms like Azure, AWS, etc.

1. Less Examples in documentation. 2. Less support. 3. Since Terraform is new IAAS, there are many changes or upgrades going on.

We manage a multicloud infrastructure using Terraform for a major corporation. Terraform has been very flexible, easy to plugin with other systems. Without Terraform, managing a multicloud environment(and even hybrid env where few resources are on-premises) would have been a lot harder.

1. It is very extensible and works with multiple cloud platforms, popular hosting platforms like DigitalOcean, GoDaddy etc. Terraform uses providers for interacting with vendor specific APIs for provisioning infrastructure. 2. It uses HCL (Hashicorp language) which is quite powerful compared to plain YAML or JSON. Many other IAC tools use plain YAML or JSON - which can be limiting. With HCL, you get for loops, conditionals, and even the ability to get data from different data sources and even shell scripts 3. It is easy to run Terraform code from a Jenkins or any other build pipeline.

The state file management could be better. Although wrapper solutions like Terragrunt exist, it would be great if Tearrform's native capabilities with state management could be even better. Other nitpick is: secrets end up in plain text in state file. Hashicorp suggest using their product vault to avoid this issue. But, not everyone uses or wants to use Vault.

my overall experience has been a great one so far.

What i like most is terraform is cloud agnostic and i like the reusability of terraform modules for faster infrastructure provisioning.

what i like least is that when we write thousands of lines of code then managing the state becomes difficult.