When it comes to understanding anything, I've always believed in digging into the fundamentals and wrapping my head around the "why," "what," and "how".
We've all encountered or heard the infamous phrase: "It works on my machine." Running an application on our computer seems smooth, but the same app might stumble or not even run on our friend's system. Then, we configure the dependencies and libraries to get it working.
Containers offer exceptional portability, eliminating the "it works here but not there" dilemma.
For now, let's put aside the technical aspects of containers. And, let's dig into the real-world problems that led to the birth of container technology.
How it started
Alright, picture us back in the early 2000s, when I'm a business owner running a clothing company, selling our garments through physical stores and malls.
Seeing the internet's potential, I decided to ride the wave and expand my business online. I create an e-commerce website. But to make this website available to users, we need computing resources. So, I purchased some computing resources (before the cloud era), which we refer to as on-premise servers.
As my business gains momentum and the user base grows, we've expanded our offerings well beyond clothing. Now, to make these services accessible to end users, we require more computing resources.
Now, one option could be to buy and set up more servers with much more computing power. But that involves a financial commitment, and I'm not sure if we'll need all those servers in the long run.
Upon examining each server, I notice a lot of unused resources. A lightbulb moment happens: why not use most of these resources by hosting different services on a single server? This way, we handle the increasing number of services without the hefty investment, which means more revenue for us.
This very approach is what we call virtualization.
Virtualization and Virtual Machines
Now, you might be thinking, "Okay, so virtualization means running multiple services on a single server. Got it!" But let's add a bit more color to the picture.
Virtualization eliminates the constraint of running a single application on a server and introduces the concept of virtual machines (VMs) to leverage the server's potential fully. VMs act as isolated entities, each hosting distinct services or applications.
Hypervisors, like VMware or Hyper-V, manage VMs, allocating resources, and facilitating communication between VMs and the host.
The benefits that virtualization brings to the table
Resource Isolation:
VMs operate independently, isolating their resources, ensuring one VM's activity doesn't impact others,
Different VMs can run various operating systems and software, isolating environments and preventing compatibility conflicts.
Resource Utilization:
- VMs utilize the server's hardware more efficiently by allowing multiple VMs to share the same physical resources, avoiding underutilization.
Cost Savings:
- With optimized resource utilization, fewer physical servers are required, leading to reduced hardware, power, and cooling costs.
Dynamic Scaling:
- VMs can be easily provisioned or de-provisioned, enabling dynamic allocation of resources based on demand.
This evolution continued, and containers were developed.
You must be thinking, but wait, why 🤔 ??
What was the problem with Virtual Machines to begin with ??
Problems with Virtual Machine
Let's imagine we've set up a virtual machine (VM) for our frontend app, allocating 8GB of RAM and 20GB of storage.
Upon analyzing the VM and the application, we discover that the major share of the allocated resources is consumed by the operating system and other components. The actual application, along with its runtime, only requires very little resource, say, 1GB of RAM and 5GB of storage.
Now, why not extract only the essential OS components, code and its dependencies, runtime & other components required for our app and package them into a single unit? This then can be utilized to execute our app, freeing up resources that were previously absorbed by unnecessary elements.
This packaged unit is what we refer to as a container.
Containers vs Virtual Machines
| Comparison | Containers | Virtual Machines (VMs) |
| Definition | Containers are an abstraction at the app layer that packages code and dependencies together. | Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. |
| Resource Utilization | Containers are lightweight – they share the host OS kernel, leading to faster and lighter performance, and are typically in tens of MBs | VMs, on the other hand, are more resource intensive - they require full-fledged OS and hypervisor, are typically in tens of GBs |
| Portability | Containers are portable – they're crafted for portability and can run on any compatible operating system with ease. | VMs, however, are a bit more rooted, requiring a specific hypervisor to operate. |
| Security | Containers are less secure - they share the host OS, offering less isolation. | VMs are the more secure – each VM has its own OS, providing a higher level of isolation and security from the host and other VMs. |
Resources
Stay Tuned
In our upcoming blogs, we'll deeper into containers like why are containers lightweight. We'll then delve deeper into Docker, exploring its concepts comprehensively. Subsequently, we'll shift our focus to Kubernetes and delve into real-time projects.
If you find the content engaging, consider dropping a like and following.
Your feedback is valuable, so feel free to let me know where I can enhance the quality.
For more insights and updates, connect with me on