Following are the USE cases of Terraform:

• Setting Up a Heroku App:
  • Heroku is a prominent platform as a service (PaaS) for hosting web applications. Developers build an app first, then add add-ons like a database or an email service. The ability to elastically scale the number of dynos or workers is one of the nicest features. Most non-trivial applications, on the other hand, quickly require a large number of add-ons and external services.
  • Terraform may be used to codify the setup required for a Heroku application, ensuring that all ESSENTIAL add-ons are present, but it can also go beyond, such as configuring DNSimple to set a CNAME or configuring Cloudflare as the app's CDN. Best of all, Terraform can achieve all of this without using a web interface in about 30 seconds.

• Clusters of Self-Service: 
  • A centralised operations team managing a huge and growing infrastructure becomes extremely difficult at a given organisational level. Making "self-serve" infrastructure, which allows product teams to manage their own infrastructure using tooling given by the central operations team, becomes more appealing.
  • Terraform configuration may be used to document knowledge about how to construct and scale a service. You may then publish these configurations across your business, allowing client teams to administer their services using Terraform.
• Quick Creation of Environments: 
  • It is usual to have both a production and staging or quality assurance environment. These environments are smaller clones of their production counterparts, and they're used to test new apps before they're RELEASED to the public. Maintaining an up-to-date staging environment gets increasingly difficult as the production environment grows larger and more complicated.
  • Terraform may be used to codify the production environment, which can then be shared with staging, QA, and development. These settings can be used to quickly create new environments in which to test and then readily discarded. Terraform can help to reduce the challenge of sustaining parallel environments by making it possible to create and destroy them on the fly.
• Deployment of Multiple Clouds: 
  • To boost fault tolerance, it's common to disperse infrastructure across different clouds. When only one region or cloud provider is used, fault tolerance is restricted by that provider's availability. When a region or an entire provider goes down, a multi-cloud strategy provides for more gentle recovery.
  • Because many existing infrastructure management solutions are cloud-specific, implementing multi-cloud INSTALLATIONS can be difficult. Terraform is cloud-agnostic, allowing you to manage numerous providers and even cross-cloud dependencies with a single configuration. This helps operators DEVELOP large-scale multi-cloud infrastructures by simplifying management and orchestration.
• Applications with Multiple Tier Architecture: 
  • The N-tier architecture is a relatively popular structure. A pool of web servers with a database tier is the most popular 2-tier system. API servers, cache servers, routing meshes, and more levels are added. Because the stages can be scaled individually and provide a separation of concerns, this structure is used.
  • Terraform is a great tool for creating and managing these types of infrastructures. Terraform will automatically handle the dependencies between each layer if you arrange resources in each tier together. Before provisioning the web servers, Terraform will check that the database layer is up and running, as well as that the load balancers are linked to the web nodes. The count configuration value can then be changed in Terraform to quickly scale each tier. Because resource creation and provisioning are codified and automated, elastic scaling in response to load is a breeze.
• Schedulers of Resources:
  • The static assignment of applications to computers in large-scale infrastructures becomes increasingly difficult. There are a variety of schedulers available to handle this problem, including Borg, Mesos, YARN, and Kubernetes. These may be used to schedule Docker containers, Hadoop, Spark, and a variety of other software tools on a dynamic basis.
  • Terraform isn't just for physical providers like Amazon Web Services. Terraform can request resources from resource schedulers because they can be treated as providers. This allows Terraform to work in layers, such as setting up the physical infrastructure that runs the schedulers and provisioning into the scheduled grid.
• Software-Defined Networking:
  • SDN (Software Defined Networking) is becoming more common in data centers as it gives operators and developers more control over the network and allows the network to better support the applications running on top. A control layer and an infrastructure layer are common in SDN systems.
  • Terraform may be used to codify software-defined network setup. By interacting with the control layer, Terraform may use this configuration to automatically set up and adjust settings. This makes it possible to version the settings and automate modifications. Terraform, for example, may be used to set up an AWS VPC.
• Demonstrations of software:
  • Modern software is becoming increasingly networked and distributed. Although solutions such as Vagrant exist to create virtualized environments for demos, demonstrating software on real infrastructure that more closely resembles production environments remains difficult.
  • On cloud providers like AWS, software authors can give a Terraform configuration to develop, provision, and bootstrap a demo. End customers may simply demo the programme on their own infrastructure, and settings like cluster size can be tweaked to more thoroughly test tools at any scale.