Orchestration:Terraform: Execution Workflow

Basics

Provider: a provider is responsible for understanding API interactions and exposing resources on your targets. Think of your targets could be Azure VM
Resources: This is where we actually define the objects that we want to create in our environment and it helps to understand the syntax that these created in.
Provisioner: When a resource is initially created provisioners can be executed to initialize that resource

Procedural Vs Declarative

Procedural= Series of Steps = Connect to Azure, Create VM, Configure Nic  Install app,                                                        Declarative =Defines End State= Give me a VM with the following  CPU:2. Mem:2 g.Os:Ubuntu, NIC IP:10.0.0.4,Chef role:SQL
Use Case ==>Infrastructure deploy, Multi-tier App install, Self Service, SW demos, disposable env, Multi-Cloud

Terraform Attributes

Terraform keeps attributes of all the resources you create. for example, the AWS instance resource has the attribute "public_ip" address. Those attributes can be queried and viewed as output, this can be useful just to output valuable information or to feed information to an external service/application.

output "VM-IP" {      description = "The VM Public IP is:"      value = azurerm_public_ip.vm1publicip.ip_address  }

Terraform Remote State

Terraform keeps the remote state of the infrastructure. It stores it in a file called the "terraform.tfstate". There is also a backup of the previous state in a file called, "terraform.rfstate.backup". When you execute, "terraform apply" a new "terraform.state" and backup is written to disk.This is how Terraform keeps track of the remote state. If the remote state changes and you hit "terraform apply" again, terraform will make changes to meet the correct remote state again.

For example, you terminate an instance that is managed by terraform, and after "terraform apply", that instance will be created again. You can keep the "terraform.tfstate" in version control. For example, using git, it gives you the history of your "terraform.tfstate" file, which is actually just a big JSON file. It allows you to collaborate with our team members. Unfortunately, with git you can get conflicts when two people work at the same time. You always need to do a "git push" and "git pull", just to make sure that you are on the latest version.
Local state works well in the beginning, but when your template becomes bigger you might want to store your state remote. The "terraform.tfstate" file can be saved remotely, using the backend functionality in Terraform. The default backend is called the "local backend", it's the local terraform state file that we have been using up to now. Back end 

Azure storage accounts 
Consul also with a locking mechanism
S3  which even has a locking mechanism
Terraform enterprise, which is a commercial solution.