DEV Community: Sreekanth Kuruba

Linux User & Group Management Explained Simply

Sreekanth Kuruba — Thu, 28 May 2026 12:42:16 +0000

Ever wondered how Linux knows:

who can access what, and what they are allowed to do?

That’s not random.

It’s controlled by users and groups — one of the most important concepts in Linux security and DevOps.

Let’s break it down simply.

What is a User in Linux?

A user is an account that interacts with the Linux system.

Every user has:

Username
User ID (UID)
Home directory
Default shell

Everything in Linux runs under a user identity.

Examples:

A developer user
A system admin user
A service user (like nginx)

What is a Group in Linux?

A group is a collection of users.

Think of it like a team:

Developers group → devs
QA group → testers
Admins group → system administrators

👉 Instead of assigning permissions one by one, you assign them to a group.

This makes Linux scalable and manageable.

Check Current User & Groups

whoami

Shows your current logged-in user.

id

Shows:

User ID (UID)
Group ID (GID)
All groups the user belongs to

groups

Shows all groups of the current user.

Creating a User

sudo useradd john

Creates a new user named john.

Note: This may not create a home directory in some systems.

Better way (recommended on Ubuntu/Debian):

sudo adduser john

👉 Automatically creates home directory + setup

Setting Password

sudo passwd john

Used to set or update user password.

Modifying Users (`usermod`)

sudo usermod -aG developers john

Adds user john to developers group.

Other examples:

sudo usermod -l newname oldname   # rename user
sudo usermod -d /new/home john    # change home directory

Deleting Users

sudo userdel john

Removes user only.

Remove user + home directory:

sudo userdel -r john

Managing Groups

Creating a Group

sudo groupadd developers

Deleting a Group

sudo groupdel developers

Important System Files

`/etc/passwd`

Stores user information:

username:x:UID:GID:comment:home:shell

Example:

john:x:1001:1001::/home/john:/bin/bash

👉 This file contains all users in the system.

`/etc/group`

Stores group information:

group_name:x:GID:user_list

Example:

developers:x:1002:john,mike

👉 Shows which users belong to which group.

What is sudo?

sudo allows a user to run commands as an administrator (root).

Example:

sudo apt update

Why sudo is important

Linux protects system files.

Normal users cannot modify system-level settings.

👉 sudo gives temporary admin power.

Important sudo concept

Not every user has sudo access
Only users in sudo or wheel group can use it

Check your groups:

groups

Real-World Example

In a company server:

Developers → normal users
Admins → sudo users
Services → system users (nginx, docker, etc.)

Each user has restricted access based on role

This keeps systems:

security
structure
control ⚙️

Why User & Group Management Matters

In DevOps and system administration:

You use this to:

control server access
manage teams on shared systems
secure applications
isolate services

Without it:

Linux systems become unmanageable and insecure

Summary

In this guide you learned:

What users are in Linux
What groups are
whoami, id, groups
useradd, adduser
usermod usage
userdel and cleanup
groupadd, groupdel
/etc/passwd structure
/etc/group structure
sudo basics
Real-world DevOps usage

Linux Process Management Explained Simply, (ps, top, htop, kill)

Question for You

Have you ever worked on a shared Linux server where multiple users caused confusion or permission issues?

I’ll show how real systems solve that in Part 5.

Linux File Permissions Explained Simply

Sreekanth Kuruba — Tue, 26 May 2026 12:13:26 +0000

Ever ran a Linux command and saw this?

Permission denied

It feels random at first — but it’s not.

That error is Linux protecting your system using file permissions.

Once you understand this, Linux security suddenly starts making sense.

What Are Linux File Permissions?

Every file and directory has three types of permissions:

Read (r) → View file content
Write (w) → Modify or delete file
Execute (x) → Run file as a program/script

👉 These decide what you are allowed to do with a file.

3 Types of Users in Linux

Permissions are not just for files — they are for users.

User Type	Symbol	Meaning
Owner	u	The owner of the file
Group	g	Users in the same group
Others	o	Everyone else

👉 Linux is a multi-user system, so access control is essential.

Understanding `ls -l` (Very Important)

Run this command:

ls -l

Example output:

-rwxr-xr-- 1 user group  1024 Apr 10 12:34 script.sh

Now it Breakdown:

First character → - = file, d = directory
Next 3 → Owner permissions
Next 3 → Group permissions
Last 3 → Others permissions

Permission Symbols

Symbol	Meaning
r	Read
w	Write
x	Execute
-	No permission

Changing Permissions `chmod`

Make script executable

chmod +x script.sh

Numeric method (very common in servers)

chmod 755 script.sh

Numeric permissions are a shortcut to set all three permission types at once.

Common Numeric Permissions:

Number	Permission	Meaning
7	rwx	Read + Write + Execute
6	rw-	Read + Write
5	r-x	Read + Execute
4	r--	Read only

👉 So:

755 = rwx r-x r-x

Owner → full access
Group → read + execute
Others → read + execute

Change Owner (`chown`)

chown username file.txt
chown user:group file.txt

Recursive:

chown -R user:group folder/

Only the root user or sudo user can change ownership.

Changing Group (`chgrp`)

chgrp developers project/

Used when:

multiple developers work on same project
shared access is needed

⚠️ Dangerous Mistake Beginners Make

chmod 777 file.txt     # ❌ Very Dangerous

🚨 This gives:

full access to everyone
no security control
breaks Linux permission model

👉 Never use this in real servers.

Real-Life Example

You create a script:

./script.sh

And get:

Permission denied

Fix:

chmod +x script.sh
./script.sh

👉 This is one of the most common Linux beginner issues.

Simple Mental Model

Think of Linux permissions like a building:

Owner → has master key
Group → shared access card
Others → guest access

And:

r → can look inside
w → can modify
x → can enter/run

Summary

You learned:

What r, w, x mean
User types (owner, group, others)
How to read ls -l
Using chmod
Numeric permissions (755, 644, etc.)
Changing ownership with chown
Changing groups with chgrp
Why chmod 777 is dangerous

Why This Matters

File permissions are not just theory.

They are used in:

Linux servers
DevOps pipelines
Docker containers
Cloud systems
Production deployments

👉 If you understand this, you understand Linux security basics.

Next Post:

Linux User & Group Management Explained Simply,useradd, usermod, groups

Which permission concept confused you the most when you first used Linux?

I’ll simplify it even further in Part 4.

Linux File System Explained Simply

Sreekanth Kuruba — Thu, 21 May 2026 09:53:57 +0000

Most beginners don’t struggle with Linux commands.

They struggle with one invisible problem:

They don’t understand how the Linux file system actually works.

Once this clicks, Linux stops feeling random — and starts feeling predictable.

Let’s fix that.

The Core Idea of Linux File System

Unlike Windows (C:, D: drives), Linux uses one single tree structure.

Everything starts from:

👉 This is called the root directory

Think of it as the “starting point of everything” in Linux.

All files, folders, devices, and even processes branch out from here.

Important Linux Mindset Shift

In Linux:

Everything is a file.

That includes:

Files 📄
Folders 📁
Hard disks 💽
USB devices 🔌
Processes ⚙️

This is why Linux feels different — but powerful.

Visualizing Linux Structure

Think of / like the trunk of a tree.

Everything grows from it:

/
├── home
├── etc
├── var
├── usr
├── bin
└── dev

Once you understand this tree, navigation becomes easy.

Paths in Linux (Very Important)

A path tells Linux where something is located.

🔹 Absolute Path

Starts from /

cd /home/user/documents

✔ Always full location
✔ Works from anywhere

🔹 Relative Path

Starts from where you are currently:

cd documents

✔ Shorter
✔ Depends on current location

Navigation Symbols

.   → current directory  
..  → parent directory

Example:

cd ..

👉 Go one step back

/home — Your Personal Space

/home/user

Each user gets a personal folder:

Documents
Downloads
Projects
Config files

👉 Think of it as your “workspace”

Important Linux Directories

Directory	Purpose	Common Usage
`/`	Root directory (starting point)	Everything is inside this
`/home`	User personal files	Documents, Downloads, Desktop
`/etc`	Configuration files	System & application settings
`/var`	Variable data (logs, caches, queues)	Logs, web server data
`/tmp`	Temporary files	Deleted on reboot
`/bin`	Essential binary commands	`ls`, `cp`, `mv`, `cat`
`/usr`	User installed programs & libraries	Most installed software
`/root`	Home directory of root (admin) user	Administrator files
`/boot`	Boot loader and kernel files	Files needed to start the system
`/dev`	Device files	Hard disks, USB, terminals
`/proc`	Process and system information	Live system data (virtual)
`/sys`	Kernel & hardware information	System hardware details
`/opt`	Optional software	Third-party applications
`/mnt` / `/media`	Mount points for external drives	USB drives, additional disks

Detailed Explanation of Most Used Directories

1./home — Your workspace

Where your projects, downloads, and personal files live.

2./etc — System control center

Contains almost all configuration files.
This is one of the most critical directories in Linux systems.

/etc/passwd — user accounts
/etc/ssh/sshd_config — SSH settings
/etc/nginx/ — web server config

👉 If Linux had a “settings app”, this is it.

3./var — Changing data (VERY important)

Used for data that keeps changing:
Most production issues can be traced by checking logs in /var/log.

/var/log/ — system and application logs
/var/www/ — Default web files (for Apache/Nginx)

4./tmp — Temporary space

Used for temporary files.
Usually cleared on reboot

⚠️ Never store important data here.

5./usr — Installed software

Main location for installed user programs and libraries.

Examples:

/usr/bin/ — most user commands

Most system commands come from here.

6./boot — Startup system

Contains kernel and boot files.

⚠️ If broken → system may not boot.

7./dev — Hardware as files

Represents hardware devices as files.

Examples:

/dev/sda → hard disk
/dev/tty → terminals

Everything in Linux is treated as a file, including hardware.

8./proc — Live system data

Virtual filesystem showing:

processes
memory
CPU info

👉 It’s not stored on disk — it’s generated live.

9./root — Admin home

Not the same as /

/ → whole system
/root → admin user’s home

10./mnt & /media — External drives

Used when you plug:

USB
external HDD
extra disks

What is Mounting? (Important Concept)

In Linux, storage devices don’t automatically appear like in Windows.

Instead, they are “attached” to a folder.

This process is called mounting.

Example:

USB drive → mounted to /media
Extra disk → mounted to /mnt
System disk → mounted to /

Useful Commands to Explore the Filesystem

pwd → Show current location
ls/ → List root directories
cd /var/log
tree → Visual directory structure

Simple Mental Model

Think of Linux filesystem like this:

/ = The whole computer
/home = My personal room
/etc = Settings room
/var = Logs & changing data
/tmp = Temporary workspace
/usr = Installed applications
/boot = Engine to start the system

👉 Once this clicks, Linux becomes predictable.

⚠️ Common Beginner Mistakes

Storing important files in /tmp
Editing files in /etc without backup
Deleting unknown system folders
Running this blindly:

Running `rm -rf /`

⚠️ Never do this.

Summary

You learned:

Linux starts from /
Everything is a file
Absolute vs relative paths
Navigation symbols . and ..
Important system directories:
/home → User files
/etc → Configuration files
/var → Logs and variable data
/tmp → Temporary files
/usr → Installed software
/boot → Boot files
/dev → Hardware devices

Why This Matters

If you understand the Linux file system:

Commands become easier
Debugging becomes faster
Servers stop feeling confusing
DevOps becomes logical instead of random

Next Post:
Linux File Permissions Explained Simply (chmod, chown, chgrp)

Question for You

Which Linux directory confused you the most when you started?

I’ll simplify it in Part 3.

10 Essential Linux Commands Every Beginner Must Know

Sreekanth Kuruba — Tue, 19 May 2026 03:24:57 +0000

Most beginners don’t struggle with Linux because it’s hard.

They struggle because they try to learn everything at once.

The truth is simple:

You only need a small set of commands to start working confidently in Linux, DevOps, and cloud environments.

In this post, you’ll learn 10 essential Linux commands that are used every day on real servers.

If you understand these, Linux will finally start to “click”.

What You’ll Learn in 5 Minutes

By the end of this post, you will know how to:

Navigate files and folders
Create, copy, move, and delete files
View file contents
Understand basic system interaction

These are the exact commands used in real DevOps workflows.

Before We Start (Important Mindset Shift)

Think of Linux like your smartphone.

Android/iOS → Linux OS
Apps → Programs
Settings → System configuration
Storage → Linux folders
Permissions popup → File permissions
Restart phone → System reboot

You don’t “see” the system — you just use it.

That’s exactly how Linux works.

1. `ls` — List Files and Directories

ls
ls -l     # Detailed list (permissions, size, date)
ls -a     # Show hidden files
ls -la    # Most commonly used combination

Real-world usage:
Used daily to check files, permissions, and directory contents.

2. `cd` — Change Directory

cd /home/user/documents
cd ..     # Go back one directory
cd ~      # Go to home directory
cd -      # Go to previous directory

Real-world usage:
Used to navigate between directories in servers and systems.

3. `pwd` — Print Working Directory

pwd

Shows your current location in the filesystem.

Real-world usage:
Used to verify current working path.

4. `mkdir` — Make Directory

mkdir myfolder
mkdir -p dir1/dir2/dir3   # Create nested directories

Real-world usage:
Used to create project folders or directory structures.

5. `rm` — Remove Files or Directories

⚠️ Dangerous command — can delete everything permanently if misused.

rm file.txt
rm -r foldername          # Remove directory
rm -rf foldername         # Force remove (very dangerous)
rmdir foldername          # To remove only an empty directory

Safer alternative with confirmation:

rm -ri foldername

-i asks before deleting each file.

Tip: Always use ls first before deleting anything.
Tip: In Linux, there is no recycle bin in most servers. Deleted files are usually gone permanently.

Real-world usage:
Used to delete unwanted files or clean up space.

6. `cp` — Copy Files and Directories

cp file.txt file_backup.txt
cp -r folder1 folder2     # Copy folder

Real-world usage:
Used for backups before modifying files.

7. `mv` — Move or Rename Files

mv file.txt /home/user/docs/
mv oldname.txt newname.txt   # Rename file

Real-world usage:
Used to move logs, configs, or rename files.

8. `cat` — View File Content

cat filename.txt

Real-world usage:
Used to quickly view file contents like logs and configuration files.

9. `touch` — Create Empty File

touch newfile.txt

Real-world usage:
Used to create log or config files.

10. `echo` — Print Text / Write to File

echo "Hello World"
echo "Hello Linux" > file.txt     # Create/overwrite file
echo "New line" >> file.txt       # Append to file

Real-world usage:
Used to write data into files or test outputs.

Beginner Basics (Highly Recommended)

What is a Terminal?

The terminal is a text-based interface used to interact with the Linux operating system using commands.

Basic Command Structure

Most Linux commands follow this format:

command [options] [arguments]

Example

ls -la /home/user

ls → command
-la → options
/home/user → argument

Linux is Case-Sensitive

Linux treats uppercase and lowercase differently.

file.txt
FILE.txt

These are considered two different files.

Paths in Linux

Absolute Path

Starts from the root directory.

cd /home/user/documents

Relative Path

Starts from your current location.

cd documents

Useful Beginner Commands

man ls       # Show manual for any command
ls --help   # Quick help
whoami       # Show current logged-in user
id           # Shows user and group IDs
uname -a    # Display system information
history      # Show previously used commands

Keyboard Shortcuts Every Beginner Should Know

Ctrl + C     # Stop a running command
Ctrl + Z     # Pause/suspend a running process

Bonus: sudo — Run Commands as Administrator

sudo apt update
sudo mkdir /newfolder
sudo chown user:group file.txt

sudo stands for “SuperUser DO” and runs commands with admin (root) privileges.
Gives you temporary admin rights
You will use it very often for installing packages and editing system files

Warning: Use sudo only when necessary.

Why These Commands Matter

These commands form the foundation of working with Linux.

Almost every advanced Linux task — DevOps, cloud computing, scripting, server management — builds on these basics.

Summary

You learned:

Navigation → ls, cd, pwd
File Management → mkdir, cp, mv, rm, touch
File Content → cat, echo
Administrator access → sudo
System & User Info -> whoami, id, uname -a, history

Next Steps:

After mastering these basics, next learn:
Linux File System Explained Simply,(/, /home, /etc, /var, etc.)

Docker Storage & Volumes Internals: Understanding Layers, OverlayFS & Persistence

Sreekanth Kuruba — Tue, 12 May 2026 04:52:58 +0000

Docker storage often feels like a black box — images appear, containers run, disk space disappears, and volumes behave magically.

This post explains how Docker actually stores data on disk.

1. How Docker Images Are Stored (The Layered Filesystem)

Docker uses union filesystem concepts (implemented via OverlayFS) to build images efficiently.

Each instruction in your Dockerfile creates a new read-only layer.

Most RUN, COPY, and ADD instructions create filesystem layers
Instructions like ENV, LABEL, CMD, and EXPOSE only add metadata (no filesystem layer)
Every layer has a unique SHA256 ID
Layers are immutable and shared across images (deduplication)

Key Idea:
Docker images are stacks of immutable layers, not a single filesystem.

2. Storage Driver: overlay2 (Default on Linux)

Modern Docker uses the overlay2 storage driver, based on the Linux kernel’s OverlayFS (a union filesystem implementation).

How OverlayFS Works

OverlayFS combines multiple directories into a single unified view:

lowerdir → Read-only image layers
upperdir → Writable container layer
merged → Unified filesystem view inside the container
workdir → Internal working directory required by OverlayFS

Important Behavior

The container never modifies image layers directly.
Instead, it uses copy-on-write — when a file is modified, it is copied into the writable layer first.

3. What Happens When a Container Starts?

When you run a container:

Docker mounts all image layers (read-only)
It creates a thin writable layer on top
The container sees a single unified filesystem (merged view)
All changes go into the writable layer

Container Lifecycle Note

When the container is deleted:

Its writable layer is removed
Image layers remain unchanged and reusable

However:

Data stored in volumes or bind mounts persists independently

4. Volumes vs Bind Mounts

Feature	Volumes	Bind Mounts
Management	Docker-managed	User-managed
Location	`/var/lib/docker/volumes`	Any host path
Portability	High	Low
Performance	More consistent across platforms	Depends on host OS/filesystem
Best Use Case	Production, databases	Development, live code sync

Recommendation:

Use Volumes for production and persistent data
Use Bind Mounts for development workflows

5. Why Docker Consumes So Much Disk Space

Docker disk usage grows mainly due to:

Unused images and dangling layers
Stopped containers with writable layers
Orphaned volumes
Build cache (including BuildKit cache layers, often the largest hidden consumer)

Useful Commands

# Show overall usage
docker system df

# Detailed breakdown
docker system df -v

# Clean unused data
docker system prune -a --volumes

⚠️ Be careful: prune commands permanently delete unused data.

6. Best Practices for Storage

Use volumes for persistent and stateful data
Avoid storing important data inside container writable layers
Use multi-stage builds to reduce image size
Clean unused resources regularly
Monitor disk usage with docker system df
Minimize unnecessary files inside images (logs, caches, temp files)

Summary

Docker storage is built on three core principles:

Immutable image layers (shared and reusable)
Copy-on-write writable container layer
External persistence via volumes and bind mounts

Understanding this model helps you:

Reduce disk usage
Debug storage issues faster
Design efficient container architectures
Avoid accidental data loss

Next Topic

Docker Security Internals: Namespaces, cgroups, Capabilities, Rootless Docker & Best Practices

CNI Plugins in Kubernetes Explained: The Networking Engine Behind Every Pod

Sreekanth Kuruba — Thu, 07 May 2026 09:50:58 +0000

You create a Pod.
It gets an IP address and can communicate with other Pods.

But how does that actually happen?

Kubernetes doesn’t manage networking itself. It delegates the entire job to CNI Plugins — the invisible plumbing system of Kubernetes.

Kubernetes schedules Pods, but CNI plugins give them network identity and connectivity.

Let’s break it down clearly.

What is CNI?

Container Network Interface is a specification, not a single tool.

It defines a standard way for Kubernetes (and container runtimes) to configure networking for Pods.

When Kubernetes needs to connect a Pod to the network, it calls a CNI plugin and says:

“Give this Pod an IP, set up connectivity, and make it work.”

Why Kubernetes Uses CNI

Networking needs vary across environments:

Simple setups for learning
High-performance production clusters
Strict security and network policies
Cloud provider integrations

CNI makes Kubernetes networking agnostic — you can choose different plugins without changing Kubernetes.

How CNI Works (Step-by-Step)

When you create a Pod:

kubelet detects the new Pod on the node
kubelet asks the container runtime (containerd/CRI-O), which then calls the CNI plugin
The plugin:

Creates a network namespace for the Pod
Sets up a veth pair (virtual cable between Pod and host)
Assigns an IP address (using IPAM)
Configures routing and interfaces
1. The Pod becomes ready and can communicate

This entire process usually takes milliseconds.

Core Components of CNI

Network Namespace — Isolated network stack for each Pod
veth Pair — Virtual Ethernet cable connecting Pod to the host
Bridge / Router — Connects multiple Pods (Linux bridge or direct routing)
IPAM — IP Address Management (assigns and tracks IPs)

Popular CNI Plugins (2026 Guide)

Plugin	Type	Best For	Strengths	Best Used When
Calico	Routing + Policy	Most production clusters	Excellent NetworkPolicy, scalable	You need strong security
Cilium	eBPF-based	Performance + Security	Kernel-level networking, observability	You want modern, high-performance
Flannel	Overlay	Learning & small clusters	Extremely easy to set up	Just getting started
AWS VPC CNI	Native	AWS EKS	Native AWS performance	Running on AWS

Recommendation:

Beginners → Flannel
Production → Calico or Cilium

Overlay vs Routing vs eBPF

Overlay (Flannel, Weave): Easy but adds encapsulation overhead
Routing (Calico): Better performance using real routing protocols
eBPF (Cilium): Modern approach — extremely fast with powerful security

Debugging CNI Issues

# Check running CNI pods
kubectl get pods -n kube-system | grep -E "calico|cilium|flannel"

# View CNI config
ls /etc/cni/net.d/

# Check Pod networking
kubectl exec -it <pod> -- ip addr

# Kubelet logs for CNI errors
journalctl -u kubelet | grep -i cni

Summary

CNI plugins are the networking engine of Kubernetes.
They handle IP assignment, interface creation, routing, and connectivity using Linux kernel primitives.

Understanding CNI helps you:

Choose the right networking solution
Debug connectivity issues faster
Design better Kubernetes clusters

Next in Series:
Kubernetes Services & kube-proxy Internals

Dockerfile & Image Build Internals: From Layers to Lightning-Fast Builds

Sreekanth Kuruba — Tue, 05 May 2026 12:31:48 +0000

You write a Dockerfile, run docker build, and get an image.

But what’s really happening under the hood? Docker isn’t just “building” your app — it’s assembling a stack of immutable filesystem layers.

Docker doesn’t build applications — it builds filesystem snapshots layer by layer.

Let’s break it down.

1. What is a Docker Image, Really?

A Docker image is not a single file.
It’s a stack of read-only layers.

Every instruction in your Dockerfile creates a new layer:

FROM → Base layer
RUN → Executes command and snapshots the result
COPY / ADD → Adds files into a new layer
ENV, WORKDIR, CMD → Metadata layers

These layers are:

Immutable
Content-addressed (using SHA256)
Reusable across images and builds

This design is what makes Docker fast and efficient.

2. How Docker Build Works (Step by Step)

When you run docker build .:

Docker CLI sends the build context (files + Dockerfile) to the daemon.
BuildKit (Docker’s modern build engine) takes control.
Dockerfile is read from top to bottom.
For each instruction:

Docker checks the cache.
Cache hit → Reuses existing layer (very fast).
Cache miss → Executes the instruction and creates a new layer.
1. All layers are stacked to create the final image.

3. Layer Caching – The Real Superpower

Docker follows one strict rule:
If a layer changes, Docker invalidates that layer and all subsequent layers.

Bad Order (Slow Builds)

FROM node:20
COPY . .                    # Code changes frequently
RUN npm install             # This runs every time

Good Order (Fast Builds)

FROM node:20
COPY package*.json ./       # Rarely changes
RUN npm install             # Cached most of the time
COPY . .

Rule of Thumb: Put stable things (dependencies) at the top. Put frequently changing things (your code) at the bottom.

4. BuildKit vs Legacy Builder

Feature	Legacy Builder	BuildKit (Recommended)
Speed	Slow	Much Faster
Parallel Execution	No	Yes
Cache Intelligence	Basic	Advanced
Multi-platform Build	Difficult	Easy
Secret Handling	Risky	Secure

Enable BuildKit:

DOCKER_BUILDKIT=1 docker build .

5. Multi-Stage Builds (The Pro Move)

# Build Stage
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production Stage
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

Benefits: Smaller image, faster deployment, better security.

Multi-stage builds ensure only the final artifacts are kept — everything else is discarded.

6. Quick Debugging Tips

Build is slow → Reorder your Dockerfile
Cache not working → docker build --no-cache
Image too big → Use multi-stage + .dockerignore
See detailed output → docker build --progress=plain .

7. Under the Hood (How Layers Actually Work)

Docker uses a Union File System (like OverlayFS) to combine layers.

Lower layers → read-only
Top layer → writable (when container runs)

To you, it looks like a single filesystem.
Internally, it’s multiple layers merged together.

Summary

A Dockerfile is not just a list of commands.
It’s a performance blueprint for building layered, cached, and efficient images.

Master layer order and caching, and your builds will go from slow and frustrating to fast and predictable.

🔜 Next in Series

Docker Storage & Volumes Internals – Why containers eat disk space and how to control it.

Failover Sounds Good… Until It Doesn’t Work

Sreekanth Kuruba — Mon, 04 May 2026 12:32:53 +0000

“We have failover.”

That sounds reassuring.

But when real failure hits…

many systems still go down — hard.

Why?

Because failover is easy to configure — but extremely hard to make reliable at global scale.

Here are the most common ways failover fails in production:

❌ 1. Failover That Was Never Tested

RDS Multi-AZ enabled
Kubernetes failover configured

Looks good on paper.

Reality:

Takes minutes instead of seconds
Gets stuck
Or doesn’t trigger at all

Lesson: Untested failover = fake failover.

❌ 2. Failover Works… But Breaks Something Else

Sudden traffic spike crashes the secondary instance
Connection storms overload the database
DNS cache delays routing

Result: Failover triggers… but the system still suffers.

❌ 3. Manual Failover at the Worst Time

Someone has to manually promote the replica
Or run a script under pressure

At 3 AM with global users watching — this turns seconds into minutes of downtime.

❌ 4. Partial Failover Strategy

You protected the application ✔️

But forgot:

Database
Cache (Redis)
Message queue
Secrets manager
CI/CD pipeline

One missing piece = entire system impacted.

How to Make Failover Actually Work

Test it regularly — simulate real failures every month
Automate everything — zero human dependency
Reduce failover time — lower DNS TTL, fast retries, pre-warm instances
Handle traffic spikes — add rate limiting and circuit breakers
Run team drills — everyone must know what to do

🌟 Final Thought

Failover is not a checkbox you tick once.

It’s a capability that only proves itself when everything is on fire.

At global scale, the difference between a 10-second blip and a 40-minute outage is usually one thing:

How well your failover actually works under pressure.

💬 What’s the biggest failover issue you’ve seen?

Drop your experience below 👇

Why Most Systems Still Have Hidden Single Points of Failure (SPOF) – Even in 2026

Sreekanth Kuruba — Tue, 21 Apr 2026 12:45:58 +0000

Your system has replicas.

You use auto-scaling.

You have a load balancer.

So you’re safe… right?

👉 Most outages don’t come from what you planned for.

Not really.

Even well-architected systems can collapse because of hidden Single Points of Failure — the ones that look harmless until they bring everything down.

Here are the most dangerous hidden SPOFs that still exist in production systems at global scale:

🗄️ 1. Database Single Point of Failure (Most Critical)

Only one writer instance (even with read replicas)
No automatic failover configured
Backup exists but restore was never tested
Single connection string pointing to one endpoint

At global scale: One DB failure = entire application becomes unusable for millions of users.

🌐 2. DNS / Domain Resolution SPOF

All traffic pointing to one domain without proper failover routing
Single DNS provider with no backup
Missing TTL optimization or latency-based routing

⚖️ 3. Load Balancer / API Gateway SPOF

Single load balancer sitting in one Availability Zone
Weak or missing health checks
All traffic routed through one target group

🔄 4. CI/CD Pipeline SPOF

Single pipeline responsible for all production deployments
No proper rollback strategy
Pipeline failure = whole team blocked

📦 5. Secret & Configuration Management SPOF

Hardcoded secrets or environment variables
Single secrets manager without high availability
Configuration stored in one central place with no versioning

🛠️ 6. Monitoring & Alerting SPOF

All alerts going to one person or one Slack channel
Single monitoring tool with no redundancy
No proper escalation policy

🧠 The Hard Truth

Most systems don’t fail because of obvious SPOFs.

They fail because of the ones no one noticed.

At global scale, even a small hidden SPOF can impact users across multiple countries and time zones.

🛡️ How to Find and Fix Hidden SPOFs

Conduct a regular SPOF Audit
Ask the question: “What if this one component completely fails?”
Add redundancy + automation
Test failure scenarios regularly
Review architecture every quarter

🌟 Final Thought

The most dangerous Single Point of Failure is assuming you don’t have any.

Real resilience begins when you stop looking only at the obvious and start hunting for the hidden ones.

💬 What’s one SPOF that caused a real outage for you?

Let’s discuss 👇

How to Build Systems That Don’t Collapse at Global Scale

Sreekanth Kuruba — Mon, 20 Apr 2026 03:13:05 +0000

Modern systems rarely fail because of one small bug.

They fail when there’s no plan for when things inevitably go wrong.

In 2026, with global teams, multi-cloud environments, and millions of users, resilience isn’t optional — it’s foundational.

⚠️ A Real-World Incident (Why This Matters)

A primary database crashed during peak hours.

There was a backup
There was monitoring

But the critical gaps were:

No automatic failover
The restore process had never been properly tested

Result?

~40 minutes of downtime, manual recovery under pressure, frustrated users, and real business impact.

Lesson Learned:

Having tools and backups is not enough.

They must be automated, tested, and ready when real stress hits.

Here are the core DevOps (and SRE-inspired) principles for building production-ready, resilient systems:

🧩 1. Eliminate Single Points of Failure (SPOF)

One weak link can bring down the entire system.

Common SPOFs:

Single server handling all traffic
One database without replication
Critical service with no fallback

Solution:

Run multiple replicas
Deploy across multiple availability zones or regions
Use load balancers

Mindset: Always design systems assuming failure will happen.

🔄 2. Build Intelligent Failover Mechanisms

When one component fails, the system should recover automatically — without manual intervention.

Key practices:

Database replication (primary + read replicas)
Auto-scaling groups
Kubernetes self-healing (automatic pod restart & rescheduling)
Multi-region active-active architecture

🧪 3. Test Failure Before It Tests You

Most systems look stable… until real-world traffic hits.

Don’t just test success scenarios.

Instead:

Load testing — simulate real user traffic
Stress testing — push the system beyond limits
Chaos Engineering — deliberately inject failures (e.g., Chaos Monkey style)

👉 If you don’t test failure, failure will test you at the worst possible time.

📡 4. Invest in Observability, Not Just Monitoring

You can’t fix what you can’t see.

True observability includes:

Metrics — CPU, memory, latency, error rates
Logs — detailed application behavior
Traces — end-to-end request flow across services

Plus:

Smart alerting (avoid alert fatigue)
On-call rotations with clear runbooks
Actionable dashboards

🧱 5. Plan for Failure as the Default

“Everything is fine” is never a strategy.

Must-have practices:

Regular backup and restore testing
Disaster Recovery planning (clear RTO & RPO targets)
Blameless postmortems after every incident

👉 Treat reliability as a core feature, not an afterthought.

🧭 DevOps Resilience Checklist

No single point of failure
Multi-zone / multi-region deployment
Auto-scaling + load balancing
Full observability + smart alerting
Backup & disaster recovery regularly tested
Chaos engineering practiced
Incident response plan ready

🌟 Final Thought

Reliability is not about eliminating failure completely.

It’s about anticipating failure, detecting it early, and recovering gracefully.

The best DevOps teams don’t just ship faster —

they build systems that stay up when everything else is breaking.

That’s what separates good systems from truly resilient ones at global scale.

💬 What’s one resilience practice that saved your system during a real outage?

Or what’s the biggest reliability challenge you’re facing right now?

Let’s discuss 👇

DevOps vs Platform Engineering in 2026

Sreekanth Kuruba — Wed, 15 Apr 2026 12:29:40 +0000

DevOps transformed how teams build and ship software.
It helped organizations move faster with automation, CI/CD, and shared ownership.

But as companies scale across countries and teams, new challenges start to appear.

What worked for small teams doesn’t always work at global scale.

Why Global Companies Are Quietly Shifting

Main Theme:
At global scale, traditional DevOps starts to crack. Platform Engineering is the next evolution that makes DevOps truly scalable, consistent, and effective across countries and large teams.

Imagine this:

A company has engineering teams in India, the US, Europe, and Singapore.
Hundreds of developers working across time zones.

Yet, releasing even a small feature still takes weeks — not because the developers are slow, but because they’re stuck fighting:

Setting up environments
Fixing inconsistent CI/CD pipelines
Waiting for approvals
Dealing with tool chaos across teams

👉 This is the reality when traditional DevOps tries to scale internationally.

🧩 What DevOps Solved — And Where It Breaks at Global Scale

DevOps was revolutionary. It brought developers and operations together through:

Automation & CI/CD
Infrastructure as Code (IaC)
Shared responsibility (“You build it, you run it”)

It works beautifully for small and mid-sized teams.

But here’s the uncomfortable truth:
👉 At large scale, many developers become part-time infrastructure managers instead of product builders.

At global enterprise scale, DevOps starts showing serious cracks:

Every team picks different tools → massive tool sprawl
Same problems get solved repeatedly
Compliance and regulations (GDPR, data sovereignty, etc.) become extremely hard to manage
Developers waste more time on infrastructure than on actual features
DevOps fatigue kicks in — frustration, burnout, and slower delivery

🏗️ Platform Engineering: The Next Evolution

Here’s the sharper truth:
While DevOps focuses on collaboration, Platform Engineering focuses on developer productivity at scale.

Think of it like this:

DevOps = Every team manages their own kitchen
Platform Engineering = One professional central kitchen with ready tools, standard recipes, and built-in safety

So developers can stop worrying about setup and just focus on cooking great features.

⚙️ What Platform Engineering Actually Delivers

A dedicated platform team builds an Internal Developer Platform (IDP) that offers:

🚀 Self-service environment creation (minutes instead of days/weeks)
🛤️ “Golden Paths” — safe, standardized, and recommended workflows
🔐 Security, compliance, and observability built-in by default
🧭 A clean developer portal for easy self-service

👉 Often powered by tools like Backstage, Crossplane, along with core DevOps tools.

Result: Developers get guided freedom instead of complete chaos or total restriction.

⚖️ DevOps vs Platform Engineering – Clear Comparison

Aspect	DevOps	Platform Engineering
Main Focus	Collaboration between Dev & Ops	Developer productivity & experience at scale
Ownership	Shared by all teams	Dedicated platform team
Approach	Flexible (every team does it their way)	Standardized with smart guardrails
Best Suited For	Small to mid-size teams	Large global organizations
Key Metric	Deployment frequency & speed	Time saved + Developer Experience (DevEx)

One-line summary:
DevOps gives freedom.
Platform Engineering gives freedom that actually scales globally.

🌍 Why Global Companies Are Making This Shift in 2026

At international level, complexity explodes — multi-cloud setups, different regulations, time zone differences, and 100+ engineering teams.

Platform Engineering solves these by:

Drastically reducing repetitive work and cognitive load
Bringing consistency across countries and clouds
Making security & compliance automatic
Improving developer happiness and retention
Delivering faster feature delivery with lower risk

👉 This is exactly why Platform Engineering roles are becoming some of the highest-paying and most strategic positions in 2026.

⚠️ Challenges & Smart Way to Adopt

It’s not effortless. Common pitfalls:

Building the platform without real developer feedback
Making it too rigid
Ignoring legacy systems

Better approach:

Start small (fix one major pain point first)
Treat developers as customers
Iterate continuously based on feedback

🧭 What Should You Learn?

If you're an engineer (especially aiming for global or remote opportunities):

Step 1: Master DevOps fundamentals
→ Docker, Kubernetes, Terraform, CI/CD

Step 2: Level up to Platform Engineering
→ Internal Developer Platforms (IDP)
→ Developer portals (e.g., Backstage)
→ Developer Experience (DevEx) mindset

💡 Pro tip: Build even a small internal platform project — it gives you a massive edge in interviews and LinkedIn.

🔮 Final Thought

DevOps is not going away.

But the companies winning in 2026 are not just “doing DevOps”.
They are building Platform Engineering on top of it — turning DevOps into something scalable, structured, and developer-first at global scale.

👉 The future is DevOps made effortless through smart platforms.

💬 What about you?

What is the biggest time-waster in your current DevOps setup?

Environment setup delays?
CI/CD issues?
Too many tools?

Drop your real experience in the comments — curious to see what teams are struggling with most 👇

Types of APIs Explained: REST, GraphQL, gRPC & SOAP (With Real-World Examples)

Sreekanth Kuruba — Thu, 09 Apr 2026 12:07:06 +0000

Types of APIs Explained: REST, GraphQL, gRPC & SOAP (With Real-World Examples)

When beginners start learning APIs, they usually think there’s only one kind:

“Send a request → Get a response.”

But in reality, there are multiple types of APIs, each built for different purposes — speed, flexibility, security, or simplicity.

In this guide, you’ll learn the main types of APIs with simple explanations, code examples, and real-world use cases.

🧠 What is an API? (Quick Recap)

An API (Application Programming Interface) is a set of rules that allows different software systems to communicate with each other.

One system sends a request → another system processes it → and returns a response.

The style and protocol of this communication decide the type of API.

🔹 Main Types of APIs by Architecture Style

1. REST APIs – The Most Popular Type

REST (Representational State Transfer) is the most widely used API style in 2026.

It uses standard HTTP methods:

GET – Fetch data
POST – Create new data
PUT / PATCH – Update data
DELETE – Delete data

Example:

GET /users/1

Response:

{
  "id": 1,
  "name": "Sreekanth",
  "email": "sreekanth@example.com"
}

Best For: Public APIs, mobile apps, and web applications

Popular Examples: Stripe, Razorpay, GitHub, Google Maps

Why it’s popular: Simple, scalable, and works everywhere.

2. GraphQL – Get Exactly What You Need

GraphQL solves a major problem of REST called over-fetching.

Instead of getting extra data, the client can request exactly the fields it needs.

Example Query:

{
  user(id: 1) {
    name
    email
    posts {
      title
      createdAt
    }
  }
}

Best For: Modern frontend and mobile apps

Popular Examples: Facebook, Shopify, GitHub, Airbnb

Big Advantage: Faster responses and better control for developers.

3. gRPC – The Fastest for Microservices

gRPC is a high-performance framework developed by Google.

It uses Protocol Buffers (binary format) instead of JSON, making it much faster and lighter.

Key Strengths:

Extremely fast and low latency
Smaller data size
Strongly typed
Supports streaming

Best For: Internal microservices communication and high-traffic systems

Popular Examples: Uber, Netflix, Google, Kubernetes

When to choose gRPC: When you need maximum speed between services.

4. SOAP – The Secure Enterprise Option

SOAP (Simple Object Access Protocol) is an older but still important protocol, especially in large organizations.

It uses XML and has strong built-in security features.

Still Used In:

Traditional banking core systems
Government and highly regulated industries

Important Note for India:

Modern systems like UPI, BBPS, and most fintech apps primarily use REST APIs with ISO 20022 standards. They have largely moved away from SOAP for better speed and flexibility.

🔹 Types of APIs by Access Level

Public APIs → Open to everyone (Example: Weather API, Google Maps)
Private/Internal APIs → Used only inside a company
Partner APIs → Shared with specific business partners

🔄 Real-World Architecture Insight

Most modern applications use a hybrid approach:

External-facing (apps & websites) → REST or GraphQL
Internal microservices → gRPC (for high speed)
Legacy systems → SOAP (for security & compliance)

In India’s fintech ecosystem:

UPI and public integrations → REST APIs
High-volume internal services → gRPC
Old core banking systems → Often still use SOAP or hybrid setups

🎯 Final Takeaway

There is no single best API type — each has its own strengths:

REST → Best for simplicity and wide compatibility
GraphQL → Best for flexibility and precise data fetching
gRPC → Best for speed and microservices
SOAP → Best for security in enterprise environments

Understanding these types of APIs helps you design better systems and choose the right tool for every situation.

💬 Your Turn:

Which type of API have you used the most?

Which one do you want to learn next?

Drop your answers in the comments below! 👇

DEV Community: Sreekanth Kuruba

Linux User & Group Management Explained Simply

What is a User in Linux?

What is a Group in Linux?

Check Current User & Groups

Creating a User

Setting Password

Modifying Users (usermod)

Deleting Users

Creating a Group

Deleting a Group

Important System Files

/etc/passwd

/etc/group

What is sudo?

Why sudo is important

Important sudo concept

Real-World Example

Why User & Group Management Matters

Summary

Next Post:

Linux File Permissions Explained Simply

What Are Linux File Permissions?

3 Types of Users in Linux

Understanding ls -l (Very Important)

Permission Symbols

Changing Permissions chmod

Change Owner (chown)

Changing Group (chgrp)

⚠️ Dangerous Mistake Beginners Make

Real-Life Example

Summary

Linux File System Explained Simply

Important Linux Directories

Summary

10 Essential Linux Commands Every Beginner Must Know

1. ls — List Files and Directories

2. cd — Change Directory

3. pwd — Print Working Directory

4. mkdir — Make Directory

5. rm — Remove Files or Directories

6. cp — Copy Files and Directories

7. mv — Move or Rename Files

8. cat — View File Content

9. touch — Create Empty File

10. echo — Print Text / Write to File

Beginner Basics (Highly Recommended)

Example

Docker Storage & Volumes Internals: Understanding Layers, OverlayFS & Persistence

1. How Docker Images Are Stored (The Layered Filesystem)

2. Storage Driver: overlay2 (Default on Linux)

How OverlayFS Works

Important Behavior

3. What Happens When a Container Starts?

Container Lifecycle Note

4. Volumes vs Bind Mounts

5. Why Docker Consumes So Much Disk Space

Useful Commands

6. Best Practices for Storage

Summary

Next Topic

CNI Plugins in Kubernetes Explained: The Networking Engine Behind Every Pod

What is CNI?

Why Kubernetes Uses CNI

How CNI Works (Step-by-Step)

Core Components of CNI

Popular CNI Plugins (2026 Guide)

Overlay vs Routing vs eBPF

Debugging CNI Issues

Summary

Dockerfile & Image Build Internals: From Layers to Lightning-Fast Builds

1. What is a Docker Image, Really?

2. How Docker Build Works (Step by Step)

3. Layer Caching – The Real Superpower

4. BuildKit vs Legacy Builder

5. Multi-Stage Builds (The Pro Move)

6. Quick Debugging Tips

7. Under the Hood (How Layers Actually Work)

Summary

🔜 Next in Series

Modifying Users (`usermod`)

`/etc/passwd`

`/etc/group`

Understanding `ls -l` (Very Important)

Changing Permissions `chmod`

Change Owner (`chown`)

Changing Group (`chgrp`)

1. `ls` — List Files and Directories

2. `cd` — Change Directory

3. `pwd` — Print Working Directory

4. `mkdir` — Make Directory

5. `rm` — Remove Files or Directories

6. `cp` — Copy Files and Directories

7. `mv` — Move or Rename Files

8. `cat` — View File Content

9. `touch` — Create Empty File

10. `echo` — Print Text / Write to File