Forem: Turjo Chowdhury

What Are Containers? The Lightweight Alternative to VMs

Turjo Chowdhury — Mon, 26 Jan 2026 14:19:12 +0000

From Virtual Machines to Containers

In my last post, I talked about virtual machines and how they let you run multiple operating systems on one computer. But I also mentioned they're heavy and slow. That's where containers come in.

Containers are like virtual machines, but much lighter. Instead of running a full operating system for each application, containers share the host operating system while keeping applications isolated from each other.

What Exactly Is a Container?

A container packages an application with everything it needs to run: code, libraries, dependencies, and configuration files. It's like a shipping container for software.

How Containers Work: Namespaces and Cgroups

Containers rely on two powerful Linux kernel features: namespaces and cgroups. Understanding these helps demystify how containers actually achieve isolation.

Namespaces: Creating Separate Worlds

Namespaces are what make containers feel like separate machines even though they're sharing the same OS. Think of namespaces as creating different "views" of the system for each container.

There are several types of namespaces:

PID Namespace (Process ID): Each container gets its own set of process IDs. Inside a container, you might see a process with ID 1, and in another container, there's also a process with ID 1. They don't conflict because they're in separate namespaces. From inside the container, you can only see your own processes, not processes from other containers or the host.

Network Namespace: Each container can have its own network interfaces, IP addresses, and routing tables. This is why different containers can run web servers on the same port (like port 80) without conflicts. Each thinks it owns that port in its own network namespace.

Mount Namespace: Gives each container its own file system view. One container might see /app with Node.js files, while another sees /app with Python files. They're completely separate even though the path is the same.

User Namespace: Maps users inside the container to different users on the host. You might be "root" inside the container, but you're actually an unprivileged user on the host system. This adds security.

UTS Namespace: Lets each container have its own hostname, making it feel like a separate machine.

Cgroups: Limiting Resources

Control groups (cgroups) are about resource management. While namespaces control what a container can see, cgroups control what a container can use.

CPU limits: You can tell a container, "You can only use 50% of one CPU core." No matter how hard the application tries, it can't exceed that limit. This prevents one badly-behaved container from slowing down everything else.

Memory limits: Set a maximum amount of RAM a container can use. If it tries to use more, the container gets killed and restarted. This is crucial because without limits, one memory leak could crash your entire system.

Disk I/O limits: Control how much a container can read from or write to disk. Prevents one container from monopolizing disk access.

Network bandwidth: Limit how much network bandwidth a container can consume.

How Containers Access Computer Resources

The operating system has two layers. Kernel space is where the kernel directly manages hardware and security. User space is where applications run. Applications can't touch hardware directly—they ask the kernel through system calls.

When a container needs to do something, here's the flow:

Application makes a request: Your app in the container wants to read a file or send a network packet.
System call to kernel: The container makes a system call to the shared kernel. For example, read() to read a file or socket() to create a network connection.
Kernel checks namespace: The kernel sees that this request came from a container. It checks which namespaces apply. "This process is in network namespace X, so it can only see network interfaces in that namespace."
Kernel checks cgroups: Before granting the request, the kernel checks cgroup limits. "Has this container exceeded its memory limit? Is it trying to use too much CPU?"
Kernel executes or denies: If everything checks out, the kernel performs the action and returns the result to the container. The container never directly touches the hardware.

Why Containers Are Better for Many Use Cases

After learning about both VMs and containers, here's why containers often win:

Speed: Containers start in seconds because they don't boot an entire OS. VMs take minutes.

Size: A container image might be 100-200 MB. A VM image is often several gigabytes.

Efficiency: I can run dozens of containers on my laptop. Running more than 2-3 VMs would bring it to its knees.

Portability: If it runs in a container on my machine, it'll run the same way on a server, in the cloud, or on my teammate's computer.

My Understanding So Far

Containers solve the "it works on my machine" problem. They package everything an application needs, making it consistent across different environments. They're lighter than VMs but still provide isolation.

This is what Docker is all about – making containers easy to create, share, and run. In my next post, I'll dive into Docker specifically and how it became the standard tool for working with containers.

Part 2 of my Docker learning journey. Slowly connecting the dots between VMs, containers, and Docker.

Understanding Virtual Machines: A Docker Journey Begins

Turjo Chowdhury — Mon, 26 Jan 2026 13:09:16 +0000

What Are Virtual Machines?

Before diving into Docker, I needed to understand virtual machines (VMs). Think of a virtual machine as a computer inside your computer. It's software that mimics physical hardware, letting you run a completely separate operating system on your existing machine.

For example, I can run Ubuntu Linux on my Windows laptop, or run Windows on my Mac, all through virtual machines.

How Virtual Machines Work

A virtual machine uses something called a hypervisor. This is special software that sits between your physical hardware and the virtual machines. Popular hypervisors include VirtualBox, VMware, and Hyper-V.

Here's what happens: the hypervisor divides your computer's resources (CPU, RAM, storage) and allocates portions to each VM. Each VM thinks it has its own dedicated hardware, but really it's sharing with your main system.

Why Use Virtual Machines?

Isolation: Each VM is completely separate. If one crashes or gets infected with malware, it doesn't affect your main system or other VMs.

Testing environments: I can test software on different operating systems without needing multiple physical computers.

Learning safely: Perfect for experimenting with new tools or configurations without risking my main setup.

Running incompatible software: Sometimes you need Windows-only software on a Mac, or vice versa.

My Takeaway

Virtual machines taught me the concept of isolation and resource allocation. Understanding VMs makes it easier to grasp why Docker and containers were created. They solve many of VM's limitations while keeping the benefits of isolation.

This is part of my journey learning Docker and containerization. Follow along as I document what I learn!

What happens inside the computer when you run your Go server

Turjo Chowdhury — Thu, 21 Aug 2025 00:20:58 +0000

Before we deep dive, let's learn a couple of important concepts

What Are Sockets and File Descriptors?

Sockets are endpoints for communication between computers over a network, enabling real-time data exchange.
Unlike regular files, sockets do not store data but facilitate data transfer between machines.
When Go requests a socket from the operating system (OS), the OS creates the socket and assigns a unique identifier called a file descriptor.
A file descriptor is an integer handle that the Go server uses to manage and reference the socket.
This mechanism allows the server to efficiently send and receive network data through OS-managed resources.

Go’s Concurrency with Goroutines

Go uses goroutines, lightweight threads, to handle many client requests concurrently.
The main goroutine continuously waits for incoming requests.
For each new request, Go creates a new goroutine to process it independently without blocking the main one.
This design ensures the server remains fast and scalable, handling multiple clients simultaneously.
When no requests arrive, the main goroutine sleeps to conserve system resources and improve overall efficiency.

Understanding How It Works in Your Computer

The kernel is the core part of the operating system that manages hardware and processes.
Network requests first travel through a router and then reach your computer’s Network Interface Card (NIC), like a WiFi adapter or Ethernet port.
The NIC converts the wireless or wired signals into binary data and temporarily stores it in a buffer.
It then sends a signal to the kernel to process this new data.
The kernel copies the data into a socket buffer that the Go server listens to, and marks it ready for reading.
The Go runtime wakes up the goroutine to read and process the request.
The server sends the response back through the socket and NIC.
The response reaches the client’s browser.

The Truth Behind "Accept All Cookies": What You're Really Agreeing To?

Turjo Chowdhury — Fri, 22 Nov 2024 23:50:26 +0000

Let me break down what actually happens when you click that seemingly innocent "Accept All" button.

🎯 When you accept all cookies, you're not just enabling basic website functionality. You're potentially giving permission for:

Multiple companies to track your digital footprint
Advertisers to build detailed profiles of your browsing habits
Your data to be shared among unexpected third parties

📌 What's Actually Required?
Here's the fascinating part - contrary to popular belief, websites DON'T need your consent for essential cookies! The EU laws are crystal clear: consent is only required for non-essential tracking. That "login" cookie keeping you signed in? Totally legal without asking.

Despite privacy laws that require explicit consent, often websites used "dark patterns" which deliberately makes it harder to reject cookies than accept them.

⚖️ The Good, Bad, and Ugly:

Legitimate tracking: Improving user experience, fraud detection
Gray area: Marketing analytics, behavioral studies
Concerning: Cross-site tracking, detailed profiling

💡 What should you do:

Consider privacy-focused browsers with built-in cookie limitations
Use browser extensions that automatically handle cookie popups
Configure your browser to block third-party cookies
Take an extra moment to customize your cookie preferences

🤔 Next time you see that cookie popup, pause and ask yourself if you really want to do this.