Terraform is an open-source tool that permits us to construct, change, and version of our infrastructure in a simple and productive manner. It utilizes the declarative language HCL (HashiCorp Configuration Language) to characterize infrastructure as code. Terraform is a tool for building, changing, and forming foundation securely and productively. Terraform can help with multi-cloud by having one work process for all cloud. The framework Terraform manages can be facilitated on an open cloud like Amazon Web Services, Microsoft Azure, and Google Cloud Platform, or on-prem in private mists, for example, VMWare vSphere, OpenStack, or CloudStack. Terraform regards infrastructure as code (IaC) so you never need to stress over your infrastructure floating away from its ideal configuration.

Terraform Components

Terraform allows you to create infrastructure configurations that affect resources across multiple cloud services and cloud platforms. Terraform does this with a few different components: 

• Configurations: A Terraform configuration is the text file that contains the infrastructure resource definitions. You can write Terraform configurations in either Terraform format (using the .tf extension) or in JSON format (using the .tf.json extension).
• Providers: Terraform leverages multiple providers to talk to back-end platforms and services, like AWS, Azure, DigitalOcean, Docker, or OpenStack. 
• Resources: Resources are the basic building blocks of a Terraform configuration. When you define a configuration, you are defining one or more (typically more) resources. Resources are provider-specific, so a resource for the AWS provider is different than a resource for OpenStack.The one major flaw in Terraform. If you wanted to convert a configuration from using AWS to using OpenStack (or vice versa), you’d essentially have to re-create the configuration because all the resources are provider-specific.
• Variables: To help make configurations more portable and more flexible, Terraform supports the use of variables. By changing the value of the variables, we could potentially re-use a single configuration multiple times (but not across providers, since resources are provider-specific).

Working oF Terraform

 There are two methods to implement Infrastructure as Code - ‘Push’ and ‘Pull’: The Push approach is based around a controlling server, ie the user’s machine, pushing all the provisioning information to the actual destination server/s to be configured. (Chef, Puppet).The Pull method involves the IaaS requesting it’s the configuration from another server, either at a set interval(Terraform, Otter, Ansible Tower). Although there are a number of cloud provisioning IaC tools, each with its own implementation. Terraform uses a Push approach and initiates the provisioning process by interacting directly with AWS to communicate the desired infrastructure. It does this by using the supplied AWS credentials with the Terraform AWS Provider Plugin, which under the hood utilizes the AWS Go SDK. From its knowledge of the live infrastructure, Terraform generates a ‘terraform.tfstate’ file, with which it can effectively employ a ‘diffing’ technique on the declared desired infrastructure and that which is actually deployed. Once any required live changes have been calculated, a plan (.tfplan) file is generated. If approved, Terraform can get to work in effecting these changes in AWS. It’s important to note that in the majority of cases, Terraform treats these resources as immutable, rather than trying to make configuration changes to already deployed infrastructure, it opts to destroy the resource and create a new one. This directly relates to the ‘speed’ and ‘experimentation’ advantages - rather than wasting time fiddling with deployed resources, developers can just destroy them and create them anew. After all, in today’s world, server time is cheap and developer time is expensive.