Forem: Rohan Nalawade

Kubernetes namespaces: concepts & key commands

Rohan Nalawade — Sat, 17 Jan 2026 13:22:04 +0000

Introduction
As part of my Kubernetes learning journey, today I focused on understanding Namespaces — what they are, why they exist, and how to work with them using basic kubectl commands.
I have written down my current understanding of namespaces and the commands I practiced hands-on.

What are Namespaces in Kubernetes?

A namespace in Kubernetes is a logical grouping of resources within a cluster.
Namespaces help organize resources and make it easier to:

Separate environments (dev, staging, prod)
Avoid naming conflicts
Apply access control and quotas
Manage large clusters more effectively Namespaces are logical, not physical. They do not create separate clusters or nodes.

Important Things about Namespaces

A Kubernetes cluster can have multiple namespaces
Pods run on nodes, not inside namespaces
A single node can run Pods from multiple namespaces
Namespaces do not provide isolation by default
Resources like Pods, Deployments, and Services are namespace-scoped

Key namespace commands i learned today
Below are the core commands I practiced while learning namespaces.

Get all namespaces in the cluster

kubectl get namespaces

This command lists all namespaces present in the cluster.

Get Pods from a specific namespace

kubectl get pods -n <namespace-name>

Displays all Pods running in the specified namespace.

Create a namespace

kubectl create ns <namespace-name>

Creates a new namespace with the given name.

Create a Pod in the default namespace

kubectl run <pod-name> --image=<image-name>

Creates a Pod using the specified image in the default namespace.

Create a Pod in a specific namespace

kubectl run <pod-name> --image=<image-name> -n <namespace-name>

Creates a Pod using the specified image in the specified namespace.

Delete a Pod from a namespace

kubectl delete pod <pod-name> -n <namespace-name>

Deletes the specified Pod from the given namespace.

Apply a YAML file

kubectl apply -f <file-name.yml>

Creates or updates Kubernetes resources defined in the YAML file. This command is commonly used for declarative configuration.

Delete a namespace

kubectl delete namespace <namespace-name>

Deletes the specified namespace and all resources inside it. This is a destructive operation and should be used carefully.

Key takeaways
Namespaces help organize and manage resources within a Kubernetes cluster, but they do not control where Pods run or provide isolation by themselves.
Understanding namespaces is important before moving on to:

Deployments
Services
RBAC
Resource quotas

What’s Next?

Next, I plan to explore:
Deployments vs Pods
How controllers manage Pods
Real-world namespace usage patterns

I’ll continue documenting my learning as I go.

Basics & Architecture of Kubernetes.

Rohan Nalawade — Fri, 16 Jan 2026 17:04:23 +0000

Introduction
I’ve recently started my Kubernetes learning journey, and instead of waiting until I “know everything,” I decided to document my learnings from day one. This helps me solidify concepts and might also help others who are just getting started.

This post covers my current understanding of Kubernetes fundamentals, especially its architecture and core components.

What is Kubernetes?

Kubernetes is a container orchestration platform.
In simple terms, it helps you deploy, manage, scale, and heal containerized applications automatically.
Instead of manually running and monitoring containers, Kubernetes does that work for you.

Kubernetes Architecture: Nodes
A Kubernetes cluster consists of nodes, which are essentially servers (physical or virtual machines).

There are two main types of nodes:

1. Control Plane
The control plane is responsible for managing the cluster.
It does not run application containers directly; instead, it makes decisions and maintains the desired state of the cluster.

2. Worker Nodes
Worker nodes are where the actual application workloads (containers) run.

Control Plane Components
The control plane consists of several key components:

kube-apiserver

Acts as the entry point to the Kubernetes cluster
All requests (from users, controllers, scheduler, etc.) go through the API server
It is the only component that talks directly to etcd

etcd

A distributed key-value store
Stores all cluster state (Pods, nodes, configs, secrets, etc.)
Acts as the single source of truth for Kubernetes
You can think of etcd as the brain’s memory of the cluster.

kube-scheduler

Decides which worker node a Pod should run on
Considers resource availability, constraints, and policies
It does not create Pods — it only assigns them to nodes

kube-controller-manager

Runs multiple controllers
Each controller continuously compares desired state vs actual state
If there’s a mismatch, it takes corrective action
Examples: Node Controller ReplicaSet Controller Job Controller

This is what enables Kubernetes’ self-healing nature.

Worker Node Components
Each worker node runs the following components:

kubelet

An agent running on every worker node
Communicates with the kube-apiserver
Ensures that Pods assigned to the node are running as expected
Interacts with the container runtime to start/stop containers

Container Runtime

Responsible for actually running containers
Examples: containerd, CRI-O, Docker (via CRI)

kube-proxy

Handles networking for Services
Maintains network rules (iptables/IPVS)
Enables stable access to Pods via Services

Pods

A Pod is the smallest deployable unit in Kubernetes
A Pod can contain one or more containers
Containers in the same Pod: Share the same network namespace Can communicate via localhost

In most cases, a Pod contains one container, but multi-container Pods are used for sidecar patterns.

How kubectl Fits In
As a user or DevOps engineer, we interact with Kubernetes using kubectl, which is a command-line interface (CLI).
Flow:
User → kubectl → kube-apiserver → cluster components

kubectl sends requests to the API server
The API server validates and stores state in etcd
Scheduler and controllers watch the API server and act accordingly
kubelet executes the decisions on worker nodes

Final Thoughts
This is my Day 1 understanding of Kubernetes.
I’m intentionally starting with fundamentals before jumping into deployments, services, and YAML files.
If you’re also learning Kubernetes, I’d highly recommend:

Taking time to understand the architecture
Building a strong mental model of how components interact

I’ll be sharing more learnings as I go. Feedback and corrections are welcome.

Blue Green deployment strategy.

Rohan Nalawade — Thu, 08 Jan 2026 16:22:45 +0000

Blue-Green deployment is a release management strategy that minimizes downtime and reduces risk by running two identical production environments.
It moves away from the traditional "in-place" upgrade model, where you overwrite the live application, to a model based on traffic routing.
Here is the technical breakdown of how it works, the workflow, and the database constraints you need to know.

The Architecture
The core concept relies on maintaining two separate environments:

Blue (Live): The currently active environment hosting the old version (v1). It receives 100% of user traffic.
Green (Idle): A clone of the Blue environment (same infrastructure, OS, configs). It is idle or accessible only via a private network. Sitting in front of these environments is a Load Balancer (or Router/DNS). This component dictates which environment is "Live" by directing traffic to the appropriate backend target group.

The Deployment Workflow

Preparation: You have traffic flowing to Blue (v1).
Deploy: You deploy the new version (v2) to the Green environment. Since Green is disconnected from public traffic, this has no impact on users.
Verification: The QA team or automated test suites run smoke tests against the Green environment using a private URL or internal port.
The Switch (Cutover): Once verified, you update the Load Balancer rules to route traffic from Blue to Green.
Monitoring: You monitor metrics (latency, error rates) on Green.
Rollback (If needed): If critical errors appear, you immediately revert the Load Balancer routing back to Blue (which is still running v1).
Cleanup: If Green is stable, Blue is eventually decommissioned or recycled to become the "Green" environment for the next release.

The Database Challenge
In stateful applications, Blue and Green generally share the same database. You cannot replicate the database easily because data written to Blue during the deployment would be lost when switching to Green.

Because both environments access the same DB simultaneously during the switch, database schema changes must be backward compatible.

The "N-1" Compatibility Rule
If you need to rename a column or change a schema:

Expand: Add the new column but keep the old one. Deploy this schema change first.
Deploy Code: Deploy the application code (v2) that writes to the new column but can still read the old one if necessary.
Contract: Only after v1 is completely offline do you remove the old column in a separate cleanup migration.

Pros and Cons
The Advantages:

Zero Downtime: The switch happens at the load balancer level, often within milliseconds.
Instant Rollback: Reverting to the previous version is just a routing change, not a redeployment.
Environment Isolation: You are testing on the actual infrastructure configuration that will serve production traffic.

The Trade-offs:

Cost: You effectively double your infrastructure footprint (compute resources) during the deployment phase.
Complexity: Requires sophisticated load balancing and CI/CD pipelines.
Data Handling: Requires strict discipline regarding database migrations and state management.

Summary
Blue-Green deployment is the gold standard for mission-critical systems where downtime is not an option. By decoupling the deployment of artifacts from the release of traffic, you gain control, speed, and a significantly lower Mean Time To Recovery (MTTR) in case of failure.

Terraform Provisioners - local-exec, remote-exec & file.

Rohan Nalawade — Tue, 06 Jan 2026 13:09:04 +0000

Introduction
When Terraform provisions infrastructure, it creates the resources defined in the configuration files, such as virtual machines or databases. However, a newly created resource is often in a default, unconfigured state. To make a server functional, it usually requires software installation, configuration file placement, or initial bootstrapping.

Terraform provisioners handle this specific stage of the deployment lifecycle. They act as a bridge between infrastructure provisioning and configuration management, allowing users to execute scripts or transfer files as part of the resource creation process. While best practices often recommend using image builders (like Packer) or user-data scripts for these tasks, provisioners provide a necessary solution for immediate, post-deployment actions.

Here is an overview of the three primary provisioners available in Terraform.

1. local-exec
The local-exec provisioner invokes a local executable or script on the machine running Terraform, not on the resource being created. This process runs on the device where the terraform apply command is executed, whether that is a developer's laptop or a CI/CD build server.

This provisioner is typically used for tasks that need to happen outside the infrastructure environment, such as updating local configuration files, saving output values to a disk, or triggering external automation tools like Ansible playbooks.

Example: In this example, the provisioner saves the public IP address of a newly created EC2 instance to a local text file immediately after the instance is provisioned.

resource "aws_instance" "web_server" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"

  # Executes on the machine running Terraform
  provisioner "local-exec" {
    command = "echo 'Server IP: ${self.public_ip}' >> server_ips.txt"
  }
}

2. remote-exec
The remote-exec provisioner executes commands directly on the remote resource being created. Unlike local-exec, this requires a network connection to the resource. For Linux servers, this is typically done via SSH, and for Windows servers, via WinRM.

This provisioner is essential for bootstrapping a server. It is commonly used to update package repositories, install necessary software packages, or start system services immediately after the operating system boots. Because it requires access to the machine, a connection block providing credentials (user and private key) is mandatory.

Example: This configuration logs into a new Ubuntu server and runs commands to install and start the Nginx web server.

resource "aws_instance" "web_server" {
  # ... standard ec2 config ...

  # Define connection details
  connection {
    type        = "ssh"
    user        = "ubuntu"
    private_key = file("~/.ssh/my-keypair.pem")
    host        = self.public_ip
  }

  # Executes on the remote server
  provisioner "remote-exec" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx",
      "sudo systemctl start nginx"
    ]
  }
}

3. file
The file provisioner is used to copy files or directories from the machine running Terraform to the newly created remote resource. It serves as a simple transport mechanism for configuration management.

This is particularly useful for moving static application files, configuration settings (such as nginx.conf), or scripts that need to reside on the server. Like remote-exec, the file provisioner requires a valid connection block to establish a secure transfer channel.

Example: This snippet uploads a local configuration file named app.conf to the temporary directory of the remote server.

resource "aws_instance" "web_server" {
  # ... standard ec2 config ...

  connection {
    type        = "ssh"
    user        = "ubuntu"
    private_key = file("~/.ssh/my-keypair.pem")
    host        = self.public_ip
  }

  # Copies local file to remote destination
  provisioner "file" {
    source      = "configs/app.conf"      # Local path
    destination = "/tmp/app.conf"         # Remote path
  }
}

Conclusion

Terraform provisioners provide essential functionality for the "last mile" of infrastructure deployment. They enable immediate interaction with resources through local scripting, remote command execution, and file transfers.

While they are powerful, they should be used judiciously. Since Terraform cannot track the state of changes made inside provisioners, complex configurations are often better handled by dedicated configuration management tools or pre-baked machine images. However, for straightforward bootstrapping and setup tasks, provisioners remain an effective and flexible tool in the Terraform ecosystem.

Lifecycle rules in Terraform.

Rohan Nalawade — Wed, 31 Dec 2025 13:31:41 +0000

Introduction
Lifecycle rules are used to override the terraform's default behavior.
Lifecycle rules control how terraform creates, destroys, updates a resource.

There are three lifecycle rules in terraform.

create before destroy
prevent destroy
ignore changes

1. Create before destroy
This rule is used to avoid downtime. It is used when creation of new resource is important before deletion of old resource. Suppose you updated the configurations of a EC2 instance and you have applied this rule there. Terraform will create the new resource first and then delete the old resource. This only works if the resource supports parallel existence (for example, multiple EC2 instances or ALB versions). This is helpful to avoid downtime.
This rule is mainly used for ALB, EC2 replacements, ASG.

2. Prevent Destroy
It is used when you want to prevent the accidental deletion of your important resources, such as a S3 bucket. When you run the terraform destroy command and if this rule is applied to the resource, that resource will not get deleted unless and until you change the rule to false. It is mainly used for Critical S3 buckets, Production databases, Important IAM roles, etc.

3. Ignore Changes
It simply ignores the changes to the resource if the change is made from out of terraform. For example you have defined configurations of ASG such as desired capacity, and you have applied the rule of ignore changes to the resource. If ignore_changes is applied and someone modifies the resource outside Terraform (for example via the AWS Console), Terraform will ignore that drift and will not attempt to bring the resource back to the value defined in the Terraform code.

Conclusion
Terraform lifecycle rules provide fine-grained control over how resources are created, updated, and destroyed. By using rules such as create_before_destroy, prevent_destroy, and ignore_changes, you can reduce downtime, protect critical infrastructure, and safely handle changes made outside Terraform. When applied thoughtfully, lifecycle rules help make Terraform-managed infrastructure more reliable, predictable, and production-ready.

Remote backend and State locking using S3 in terraform.

Rohan Nalawade — Mon, 29 Dec 2025 11:38:44 +0000

Introduction:
Terraform uses a state file with .tfstate extension to provision infrastructure. I compares the actual aws state with what is desirable state and accordingly creates the infrastructure. Now this state file is very much important because it contains all the details about the infrastructure configurations. It also contains some important details like passwords, IDs public ips, etc. So safety of this file is always important. By default this file is created locally on the laptop you are working, and it is totally fine if you are working solo. But if you are working in a team there are several problems.

Problems with terraform state file.
First of all, "Emailing the State" problem. f you create a server, the state file on your laptop knows about it. If your colleague wants to update that server, they don't know it exists because the state file is on your computer. You would have to email the file to them (which is messy and dangerous).
Then there is state conflict problem. If you and your colleague entered the terraform apply command at the same time. You try to change the server name. They try to delete the server. Terraform has no way to stop this. The infrastructure enters a corrupted state, or the last person to save overwrites the other's work.
Also the Terraform state file is written in plain text. It can contain sensitive data in it like access keys. Security of this file also a problem.

The Solution: Remote Backend
Remote Backend simply means storing the state file into a remote location typically a cloud location instead of storing it locally on your laptop. When you are using AWS as provider for your terraform you use S3 bucket as the remote backend location. This solves two problems. The "Emailing the state" problem is now solved because everyone who is working on the project can access this file from there laptop without you needing to send it to them. It also solves the problem of security.
The only problem remaining is of "State Conflict", because this is the single source of truth and anyone with permissions can access it, meaning two or multiple colleagues can access it at the same time creating the state conflict. For this terraform uses conflict of state locking.

State Locking
It is a mechanism that prevents two or more people modifying the infrastructure at the same time. When you run terraform apply Terraform locks the state file, ensuring no one else could run the terraform apply command at the same time. When the command gets completed it releases the lock. This completely prevents race conditions and corruptions.

The Mechanism:
To Store the state file into remote backend we use S3 because it is highly durable. If something goes wrong you can easily rewind the file. Also S3 offers built in locking mechanism.

Code block for the Remote Backend code in terraform:

terraform {
  backend "s3" {
    bucket       = "my-state-bucket"
    key          = "prod/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true 
    encrypt      = true
  }
}

Conclusion
Remote backend and state locking is a powerful and much helpful concept in terraform that makes sure the state file is safe and it prevents the corruption of file, making the infrastructure consistent.

Variables in Terraform: My learnings.

Rohan Nalawade — Sun, 28 Dec 2025 11:41:04 +0000

Introduction:
I have been learning terraform and today i came across concept of variables in terraform. Variables allow you to store values which can be used in multiple places in terraform code. There are two types of variables:

Input Variables
Output Variables

1.Input Variables
Input variables allows you to store hardcoded values and use them in your terraform code as inputs. For example you can store instance types, region, instance count, etc. The syntax for input variables is like this:
variable "" {
default =
type =
description =
}

2. Output Variables
Output variables are used to store the output values which are generated after the terraform apply command. You can store values like public ip of ec2 instance, public dns, id of the instance, etc. The syntax for output variables is like this:
output <"variable name"> {
value =
description =
}

Data types in terraform
Terraform has two types of Data types. Primitive and complex data types.

The Primitive data types includes:

string
number
bool

The Complex data types includes:

list
map
set
object
tuple

The Primitive Data types:
1. string
string stores any text based values. For example, the input variable named region can store value as "us-east-1" or "ap-south-1".

2. number
number is used to store any integer based values. For example the input variable instance_count can have values like 2 or 3.

3. bool
bool is used to store boolean values. It can include only two type of values which are true or false. For example the variable named is_running can have value like true, which means the instance state is running or it can have value like false, which means the instance state is not running or stopped.

The Complex Data types:
1. List
The list is used to store multiple values of same data type. For example we can store multiple region values in a single list. ["ap-south-1", "us-east-1", "us-west-1"]. The list must contain values of same data type only. The list is mutable, meaning it can be modified after it is created.
The list is always ordered in nature.

2. set
The set is also similar to list but a set cannot have duplicate values. It can only contain unique values. The values in a set must be of same data type. The set is also mutable in nature. Unlike list set is not ordered.
For example ["ap-south-1", "us-east-1", "us-west-1"]. It is similar to list but it can't contain duplicate values.

3. map
The map data type is used to store key-value pairs. The keys in a map must be unique and the data type of key is always string. The values in a map can be duplicate and they can be of any data type but all the values should be of similar data type only.
For example we can use map to store tags
tags = {
name = "ec2_instance"
description = "ec2 instance for running the backend"
env = "prod"
}

4. tuple
Tuple is also similar to List and it allows you to store ordered values. The difference between list and tuple is that tuple is immutable, meaning the tuple cannot be modified once after it is created and it has fixed length. Unlike list, a tuple can have multiple data types for its values.
For example we can store network addresses in tuple as ["192.168.1.2", "192.168.1.1"]

5. object
The object is used to create variables that contain structured data and named attributes. It is similar to maps but map can contain only similar types of data for its values, whereas object can have multiple data types in its values. For example,
user = {
name = "Rohan"
age = 20
email = "rohan@gmail.com"
}

Conclusion:
Terraform variables are a great way of simplifying the codebase and reusing values without hardcoding literal strings whenever you need to reference something.

From ClickOps to DevOps: My First Infrastructure as Code Project with Terraform

Rohan Nalawade — Sat, 27 Dec 2025 12:37:26 +0000

Introduction
Like many cloud enthusiasts, I started my AWS journey using the Management Console—clicking through wizards, manually selecting subnets, and hoping I didn't forget a configuration step. It works, but it’s prone to human error and hard to replicate.
This week, I decided to level up. I started learning Terraform to embrace Infrastructure as Code (IaC).
In this post, I’ll walk you through my very first hands-on task: provisioning a custom network stack and launching an EC2 instance entirely through code.

The Architecture
Instead of just launching a default instance, I wanted to build the network from scratch to understand how the components connect. Here is what I built:

VPC: A custom Virtual Private Cloud.
Subnet: A public subnet for the instance.
Internet Gateway (IGW): To allow internet access.
Route Table: Configuring routes to the IGW.
Security Group: Allowing SSH, HTTP, and HTTPS.
EC2 Instance: The server itself.

Why Terraform?
Before diving into the code, here are the immediate benefits I realized while working on this:
Speed: I can destroy and recreate the entire infrastructure in seconds with one command.
No Human Error: No more accidentally clicking the wrong checkbox. The code is the source of truth.
Documentation: The code itself acts as documentation for the infrastructure.

The Code
Here is a look at the main.tf file I created.

1. The Network Setup
First, we define the VPC and the Internet Gateway.
`resource "aws_vpc" "terra-vpc" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "terra-vpc"
}
}

resource "aws_internet_gateway" "terra-igw" {
vpc_id = aws_vpc.terra-vpc.id
}

resource "aws_subnet" "terra-subnet1" {
vpc_id = aws_vpc.terra-vpc.id
cidr_block = "10.0.1.0/24"
}`

2. Security Groups
This was the trickiest part! I learned that enabling traffic requires specific ingress (incoming) and egress (outgoing) rules.
`resource "aws_security_group" "terra-ec2-sg" {
name = "terraform-ec2-sg"
vpc_id = aws_vpc.terra-vpc.id
}

Allow SSH from anywhere
resource "aws_vpc_security_group_ingress_rule" "allow_ssh" {
security_group_id = aws_security_group.terra-ec2-sg.id
cidr_ipv4 = "0.0.0.0/0"
from_port = 22
to_port = 22
ip_protocol = "tcp"
}

Allow all outbound traffic
resource "aws_vpc_security_group_egress_rule" "allow_all" {
security_group_id = aws_security_group.terra-ec2-sg.id
cidr_ipv4 = "0.0.0.0/0"
ip_protocol = "-1" # Represents all protocols
}`

3. The Instance
Finally, tying it all together by launching the EC2 instance inside our new security group and subnet.
`resource "aws_instance" "first_terra_instance" {
ami = "ami-02b8269d5e85954ef" # Check your region!
instance_type = "t3.micro"
key_name = "terra-key-pair"
vpc_security_group_ids = [aws_security_group.terra-ec2-sg.id]
subnet_id = aws_subnet.terra-subnet1.id

tags = {
Name = "Terraform-EC2"
}
}`

The Workflow: 4 Magic Commands
Learning the syntax is one thing, but understanding the lifecycle is another. These are the four commands I used constantly:

- terraform init: Initializes the directory and downloads the necessary AWS providers.
- terraform validate: A lifesaver! It checks your code for syntax errors before you even try to run it.
- terraform plan: This is my favorite. It shows a "dry run" of what will be created, changed, or destroyed. It gives you confidence before making changes.
- terraform apply: The command that actually makes the API calls to AWS to build the resources.

Conclusion
Building this project gave me a much deeper appreciation for modern DevOps practices. It’s empowering to see an empty AWS account populate with resources just by typing terraform apply.
My next step? I plan to look into Terraform Variables to stop hardcoding values and make this script reusable for different environments.
If you are just starting with cloud, I highly recommend picking up Terraform. It changes the way you look at infrastructure!

Have you worked with Terraform? What was the first resource you automated? Let me know in the comments! 👇

Differences between Terraform & Ansible, when to use what.

Rohan Nalawade — Fri, 26 Dec 2025 13:38:38 +0000

Introduction
When I started learning Cloud Computing, I was confused by the sheer number of tools. I knew Terraform was for "Infrastructure as Code." I knew Ansible was for "Configuration Management."
But then I saw people creating AWS EC2 instances using Ansible... and I saw people running shell scripts using Terraform. I asked myself: If they can both do the same things, why do we need both?
After digging into the documentation and building a few labs, I realized that while there is overlap, they have completely different philosophies. Here is what I learned about the battle between Provisioning and Configuration.

The Core Difference: Builder vs. Interior Designer
The best way to visualize the difference is to imagine building a house.

Terraform is the Builder (Provisioning) Terraform is designed to create the infrastructure from scratch.
It pours the concrete foundation.
It builds the walls.
It installs the plumbing and electricity.
In Cloud terms: It creates your VPC, Subnets, EC2 Instances, and Databases.
Ansible is the Interior Designer (Configuration)
Ansible is designed to setup the house once it exists.
It paints the walls.
It installs the furniture.
It makes sure the TV is plugged in.
In Cloud terms: It installs Nginx, updates software patches, creates user accounts, and deploys your application code.

The "State" Debate: Why not just use Ansible for everything?
This was my biggest question. Since Ansible has modules to create EC2 instances, why bother learning Terraform?
The answer lies in one file: terraform.tfstate.

Terraform has "Memory" (Stateful)
When Terraform creates a server, it writes down the details in a State File. It remembers exactly what it built. If you delete a server from your Terraform code and run it again, Terraform looks at its memory (State file), sees that the server shouldn't exist anymore, and destroys it.

Ansible is "Forgetful" (Stateless)
Ansible doesn't have a memory of what it did last time. It just follows your current instructions list. If you remove the "Create Server" task from your Ansible code, Ansible doesn't delete the server. It just ignores it. This leads to "Configuration Drift"—where you have "ghost" servers running that you forgot about, costing you money.

How they work together
In the real world, you rarely pick just one. A standard DevOps pipeline looks like this:

Terraform builds the empty servers and networking.
Terraform calls Ansible automatically.
Ansible connects to those new servers and installs the application.

Conclusion
You can use a hammer to drive a screw, but it's going to be messy.

Use Terraform to build the house.
Use Ansible to make it a home.

I have currently started learning terraform and in the future i will be learning ansible also, if you have any suggestions or tips you can comment below.

Server-based vs Serverless Compute Services on AWS: My Notes for Beginners.

Rohan Nalawade — Thu, 25 Dec 2025 12:06:14 +0000

Introduction
When I started learning AWS, I thought "Serverless" meant there were literally no servers. I imagined code floating in the clouds like magic. 🪄
As I dug deeper into services like EC2, Lambda, and Fargate, I realized that "Serverless" is just a buzzword for "Someone else manages the servers for you."
But how do you choose? Should you manage it yourself (Server-based) or let AWS handle it (Serverless)? To understand this, I like to use the Pizza Analogy.🍕

1. The "Do-It-Yourself" Approach: Amazon EC2
Think of Amazon EC2 (Elastic Compute Cloud) like baking a pizza at home.

You buy the ingredients (OS, CPU, RAM).
You pre-heat the oven (Provisioning).
You bake the pizza (Running the app). The Catch: You have to clean the kitchen afterwards. If you aren't using the oven, you still paid for it.

In Tech Terms: EC2 gives you a Virtual Machine. You have total control. You can install whatever you want, tweak the operating system, and configure the security.

Pros: Complete control. Great for long-running applications or legacy software.
Cons: You pay for the server 24/7, even if no one visits your website. You are responsible for security patches.

2. The "Buy a Slice" Approach: AWS Lambda
Think of AWS Lambda like walking into a pizza shop and buying one slice.

You don't care what oven they used.
You don't care who the chef is.
You just pay for the slice, eat it, and leave.

In Tech Terms: This is true Serverless. You upload your code (a function), and AWS runs it only when needed.

Pros: You pay $0 when no one is using it. It scales instantly (from 1 user to 1 million).
Cons: "Cold Starts" (it takes a split second to wake up). Not good for long tasks (max 15 minutes).

3. The Middle Ground: Fargate (Containers)
This is where I used to get confused. I kept hearing about ECS and EKS.

ECS/EKS are just "Managers." They organize your containers (like Docker). But where do those containers run? You have two choices:
EC2 Mode: You run the containers on servers you manage. (Server-based).
Fargate Mode: You tell AWS "Here is my container, just run it." (Serverless).

Think of Fargate like ordering pizza for delivery. You get the whole pizza (custom container), but you don't have to worry about the oven or the kitchen. AWS manages the underlying infrastructure, and you just focus on the app.

Which one should you choose?
As I am building my own projects, here is my rule of thumb:

Start with Lambda if you are building a simple API or a background task. It’s cheap and easy.
Use Fargate if you have a Docker container and want it to run without managing servers.
Use EC2 only if you need full control over the OS or have a very steady workload where you can reserve capacity to save money.

Conclusion
There is no "winner" here. Real cloud architects use all of them together. You might use EC2 to host a database, Fargate to run your backend API, and Lambda to process image uploads.
I’m still exploring these services, so if you have a favorite use case for Lambda or Fargate, let me know in the comments!

SSL/TLS Explained: From the Handshake to the Cloud ☁️

Rohan Nalawade — Wed, 24 Dec 2025 16:40:09 +0000

Introduction
Have you ever noticed that little padlock icon next to the URL in your browser? We see it every day, but until recently, I had no idea what magic was actually happening behind it.

I am currently on a journey to learn Cloud Computing. As I was going through tutorials, I kept hitting terms like "SSL," "TLS," and "Handshakes." Honestly, it felt a bit overwhelming at first. To really understand it, I spent sometime watching YouTube tutorials and chatting with Gemini to break down the complex technical jargon into simple English.

Now that it has finally clicked for me, I want to document what I’ve learned. This blog is my attempt to explain SSL and TLS in the simplest way possible—from a learner, for learners.

The Alphabet Soup: HTTP vs. HTTPS
First, let's clear up the basics.

HTTP (HyperText Transfer Protocol): This is the standard way browsers and servers talk. The problem? It's plain text. If I send a password over HTTP, anyone snooping on the network (like a hacker in a coffee shop) can read it as easily as a postcard.
HTTPS (HTTP Secure): This is HTTP with a security layer on top. It encrypts the data so that even if someone steals it, it looks like gibberish.

But what is that "security layer"? That’s where SSL and TLS come in.

SSL vs. TLS: What’s the Difference?
You will hear these terms used interchangeably, but there is a technical difference.

SSL (Secure Sockets Layer): The original protocol developed by Netscape in the 90s. It is now deprecated and considered insecure.
TLS (Transport Layer Security): The modern, secure successor to SSL.

Fun Fact: We mostly use TLS 1.2 or TLS 1.3 today. However, people still say "SSL Certificate" out of habit. It’s like how we say "dial the number" even though we don't use rotary phones anymore.

How It Works: The "Handshake"
When you visit a secure website (like Google or your bank), your browser and the server engage in a conversation called the TLS Handshake. This happens in milliseconds before any data is exchanged.

Here is the simplified version of what happens:

Client Hello: Your browser says, "Hello! I want to talk securely. Here are the encryption methods I support."
Server Hello: The server replies, "Hello! Let's use this encryption method. Here is my Certificate to prove I am who I say I am."
Verification: Your browser checks the certificate. Is it valid? Is it expired? Does it actually belong to this website?
Key Exchange: If the certificate is good, the browser and server use it to generate a Session Key.
Secure Connection: Boom! They lock the connection. From now on, everything sent is encrypted using that Session Key.

Encryption: Asymmetric vs. Symmetric
This is the coolest part of the process. HTTPS uses two types of encryption to balance security and speed.

Asymmetric Encryption (The Handshake) This uses two keys: a Public Key (everyone can see it) and a Private Key (kept secret).
Imagine a mailbox. Anyone can drop a letter in (encrypt with Public Key), but only the person with the key can open the mailbox (decrypt with Private Key).
We use this only during the handshake to exchange the session key safely.
Symmetric Encryption (The Conversation)
Once the secure connection is established, we switch to Symmetric Encryption.
This uses one key that both the browser and server have.
Why switch? Because Asymmetric encryption is slow. Symmetric encryption is incredibly fast, allowing you to stream video or load heavy pages without lag.

What is an SSL Certificate?
The certificate is like a digital ID card (passport) for a website. It does two things:

Encryption: It contains the Public Key needed for the handshake.
Identity: It proves the server owns the domain.

These certificates are issued by Certificate Authorities (CAs)—trusted organizations that verify website owners. If you try to create your own certificate (Self-Signed), browsers will warn users that the site is "Not Secure" because no trusted third party verified you.

SSL/TLS in the Cloud Era
If you are deploying your app to the cloud (like AWS, Vercel, or Google Cloud), you rarely handle certificates manually on your server anymore. The cloud has changed the game with two major concepts: SSL Termination and Managed Certificates.

SSL Termination (The Bouncer) Decrypting data takes CPU power. If you have a popular website with millions of visitors, your application server (the computer running your code) could get overwhelmed just trying to "handshake" with everyone.

To fix this, we use a Load Balancer.

The Load Balancer sits in front of your servers.
It handles the SSL/TLS "handshake" and decrypts the data.
It passes the data to your actual application server as plain HTTP.

This is called SSL Termination. It’s like having a bouncer at the club door who checks IDs (Security) so the bartender (Your Server) can focus solely on pouring drinks (Serving Content).

Managed Certificates (No More Panic) In the old days, you had to buy a certificate, upload it to your server, and set a calendar reminder to renew it in 365 days. If you forgot, your site would go down.

Modern cloud providers (like AWS Certificate Manager or Vercel) offer Managed Certificates.

They are usually free.
They automatically renew themselves before they expire.
You don't touch any private keys; the cloud provider handles the security for you.

End-to-End Encryption (Zero Trust) Wait, didn't I just say the Load Balancer sends plain HTTP to the server? Is that safe? Usually, yes, because that traffic happens inside a private, secure cloud network (VPC) that outsiders can't access.

However, for highly sensitive data (like banking or healthcare), we use End-to-End Encryption.

The Load Balancer decrypts the traffic to inspect it.
It re-encrypts it before sending it to your backend server.
Your server decrypts it again. This ensures that even if a hacker gets inside your private cloud network, they still can't read the internal traffic.

Conclusion
Understanding SSL/TLS is crucial for any developer. It ensures that the internet remains a safe place for commerce, communication, and privacy.
Whether you are configuring a local server with Let's Encrypt or setting up an enterprise Load Balancer on AWS, the core concept remains the same: Encryption = Trust.
If you are building a website today, HTTPS isn't optional—it's standard. With modern tools making certificates free and auto-renewing, there is no excuse to run a site on plain HTTP anymore.
I hope this cleared up the confusion between the acronyms and gave you a glimpse into how cloud security works!

I’m still exploring the world of Cloud and DevOps, so if you have any tips or resources that helped you understand security better, please drop them in the comments. Let's learn together!