mplementation plan:
So far you have built REST APIs with Spring Boot, connected them to PostgreSQL, and secured them — but all of that only runs while your laptop is on and you type ./mvnw spring-boot:run. Close the laptop and your API is gone.
Deploying means putting your application on a computer that is always on, so real users can reach it over the internet at any time — without your laptop being involved.
<aside> 💭
In the Core program you already deployed an app to Render and met Docker containers briefly (see Deployments). This chapter zooms out: before you package your own Spring Boot app with Docker in the next chapter, let's understand the different places an app can run — and why the industry settled on containers.
</aside>
Your app has to run on some kind of machine. There are three main options, from oldest to newest: bare metal, virtual machines, and containers.
"Bare metal" means your app runs directly on a physical server — a real computer in a data centre — with nothing virtualised in between. The app gets the whole machine: all of its CPU, memory, and disk.
This is how almost everything ran 20 years ago: buy a server, install an operating system, install Java, copy the app over, run it.
A virtual machine (VM) is a software simulation of a full computer, with its own operating system, running on top of a real physical machine. A program called a hypervisor slices one physical server into several VMs, each behaving as if it were a real computer.
Now one powerful server can run, say, ten VMs — each with its own OS, its own Java, and its own copy of your app, isolated from the others. This is what most cloud servers are: an AWS EC2 instance or an Azure VM is a virtual machine, not a physical one.
<aside> 💡
The guest operating system is the heavy part of a VM. Hold on to that idea — it is the single biggest difference between a VM and a container.
</aside>
A container packages your application with everything it needs to run — the right Java version, libraries, and configuration — into one standardised unit. Unlike a VM, a container does not carry its own operating system: all containers on a machine share the host's OS kernel.
<aside> 💡
The name is borrowed from shipping. Before steel shipping containers, cargo was loaded piece by piece in every shape and size. The standard container changed everything — any crane, ship, or truck can handle any container without caring what is inside. Software containers do the same for code: the same container runs identically on your laptop, a teammate's machine, and a server in the cloud.
</aside>
Because they skip the guest OS, containers are:
<aside> ⚠️
A container is not a tiny VM. A VM virtualises hardware and boots a whole operating system; a container shares the host's kernel and isolates only your app. That is why containers are lighter — and also why a Linux container needs a Linux kernel to run on.
</aside>
| Bare metal | Virtual machine | Container | |
|---|---|---|---|
| What runs your app | The physical server directly | A simulated computer with its own OS | A packaged app sharing the host OS |
| Startup | Weeks (buy + set up) | Minutes | Seconds |
| Overhead | None | High — a full OS each | Low — no guest OS |
| Isolation | Whole machine | Strong (separate OS) | Good (shared kernel) |
| Portability | Low | Medium | High |
| Apps per server | One | Several | Many |
💬 If containers are lighter, why do VMs still exist?
💬 Does a container include an operating system?
Over the last decade the industry moved decisively to containers, because they combine everything a modern backend team wants: the same artifact travels from a developer's laptop to production unchanged, they start in seconds, they are cheap and dense, and they fit naturally into CI/CD pipelines and orchestration tools like Kubernetes.
It is not strictly either/or: in the cloud, containers usually run inside VMs managed by the provider. When you deploy to AWS ECS or Azure Container Apps, your containers sit on top of VMs you never have to think about.
<aside> ❗
This is why Docker appears in nearly every Dutch backend job advert, and why companies like Adyen, bol, and Booking.com run their services in containers, usually orchestrated with Kubernetes. For a backend developer in the Netherlands, understanding containers is no longer optional.
</aside>
<aside> 💭
Watch (optional, ~8 min): search for "Containers vs VMs" on the IBM Technology channel for a clear visual explanation of everything above.
</aside>
<aside> ⌨️
Hands on (~10 min): Open a Dutch job board (LinkedIn, or a company careers page) and find one backend / Java developer posting. List every deployment-related keyword you can spot — Docker, Kubernetes, CI/CD, AWS, Azure, containers. You will see the same words again and again. That is exactly the gap this week closes.
</aside>
<aside> 🎉
You can now explain bare metal, VMs, and containers — and why containers dominate. Next, you will build your first one with Docker: Docker.
</aside>
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.