# Day 11 - Infrastructure as Code | Terraform

## **1\. Scenario: You Are a DevOps Engineer at Flipkart**

Flipkart has many applications (example: 300 apps).  
To run these applications, servers are required.  
These servers (compute resources like CPU, RAM, storage) can be created:

* On cloud platforms (AWS, Azure, GCP, etc.)
    
* On physical machines (on-premises)
    
* On other cloud providers like DigitalOcean, Oracle Cloud, etc.
    

You decide to host everything on **AWS**.  
So you automate the creation of resources like EC2, S3, RDS using:

* AWS CLI
    
* CloudFormation Templates (CFT)
    
* AWS CDK
    
* Other AWS automation tools
    

You create hundreds of scripts using **CloudFormation (CFT)** to automate AWS resources.  
Everything works smoothly.

---

## **2\. The Problem: Cloud Provider Migration**

Later, management decides to **move from AWS to Azure**.  
Your existing CFT scripts become useless because:

* **CloudFormation works only for AWS.**
    

On Azure, you now have to rewrite everything using:

* **Azure Resource Manager (ARM templates)**
    

So you again convert all scripts manually.

After some time, the company is unhappy with Azure too and decides to move to **on-premises** using:

* **OpenStack**
    

OpenStack uses **Heat Templates**, so again you must rewrite all automation scripts.

This is a repeating problem:

✔ Every cloud provider has its own IaC syntax  
✔ You keep rewriting scripts again and again  
✔ It wastes time, effort, and learning resources

---

## **3\. Hybrid Cloud Makes Things Worse**

Nowadays, many companies use **Hybrid Cloud**, meaning:

* Some infrastructure in AWS
    
* Some in Azure
    
* Some on-prem with OpenStack
    
* Sometimes even GCP or others
    

Example:

* AWS is good for **storage**
    
* Azure is good for **DevOps services**
    

So Flipkart uses both.

This forces a DevOps engineer to learn:

* AWS CFT
    
* Azure ARM
    
* OpenStack Heat Templates
    
* Many other provider-specific tools
    

This becomes too complicated.

---

## **4\. Solution: Terraform**

To solve this multi-tool problem, **HashiCorp** created **Terraform**.

Terraform says:

> “Instead of learning dozens of tools, learn just one — Terraform.”

### Terraform Features:

* Works with **all cloud providers** (AWS, Azure, GCP, OpenStack…)
    
* You write **one type of script (HCL)** for all providers
    
* Terraform internally communicates with the provider’s API
    
* Migration from one cloud to another becomes much easier  
    (only small changes like provider block / module updates)
    

Terraform uses the concept:

### **API as Code**

Earlier tools were:

* CFT → AWS-specific
    
* ARM → Azure-specific
    
* Heat → OpenStack-specific
    

But Terraform works across all providers because:

### Terraform converts your code → cloud provider API calls

---

## **5\. What Terraform Does Internally**

Each cloud has APIs:

* AWS APIs
    
* Azure APIs
    
* GCP APIs
    
* OpenStack APIs
    

Terraform reads your `.tf` scripts and:

1. Converts them into correct API calls
    
2. Sends those calls to providers
    
3. Creates or updates the infrastructure
    
4. Shows results back to you
    

So you don’t need to write API requests yourself.

---

## **6\. Understanding API (Simple Explanation)**

API = **Application Programming Interface**

It allows one application to talk to another programmatically.

Example:

* Normally, you open Google in a browser and search manually (UI).
    
* But if you want to talk to Google using a script, you use an API.
    

Similarly:

* Instead of manually creating cloud resources in a console,  
    Terraform talks to cloud APIs and does it automatically.
    

---

## **7\. Summary**

### **Infrastructure as Code (IaC)**

* Writing infrastructure using scripts (CFT, ARM, Heat)
    

### **API as Code**

* Terraform talking directly to cloud APIs
    
* One language, multiple cloud providers
    

Terraform solves the problem of learning many IaC tools.