So far you have built REST APIs with Spring Boot, but all of that only runs while your laptop is on. Close the laptop and your API is gone. What if we want to keep using the application at any time and from anywhere in the world? In this case, we must move it to a different machine which is always on and accessible to the internet. This process called Deploying.
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 approaches, from most to least coupled to the hardware:
https://www.youtube.com/watch?v=Jz8Gs4UHTO8
A Dell server. Servers look different from home computers.
"Bare metal" means your app runs directly on a physical server — a real computer in a data center. 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 MacBook running a Windows VM
On 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.
Today, you can easily rent a small VM in the cloud starting for about €5 / month. You can then connect to it and install whatever you need.
A container packages your application with everything it needs to run — the right Java version, libraries, and configuration — into one standardised unit.
<aside> 💭
Unlike a VM, a container does not carry its own operating system: all containers on a machine share the host's OS.
</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>
https://www.youtube.com/watch?v=a1M_thDTqmU
| 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 application 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 a container to the cloud, your containers may sit on top of VMs you never have to think about.
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.