Docker and Containers - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Docker is the most used tool in cloud development, and it's not even close. You've probably heard the word thrown around like it's basic knowledge everyone else already has. Docker solves one specific painful problem, and once you see it, the whole picture clicks. It's the reason an app runs perfectly on your laptop and then falls apart on someone else's machine. By the end, you'll understand containers, images, and Docker files without writing. A single line of code will also settle the comparison that confuses almost every beginner. Containers versus virtual machines. The problem Docker actually solves. Picture the moment you download a project that someone shared with you, you follow the setup notes line by line. You install everything the instructions ask for, and the app still refuses to start.

0:42 A library is the wrong version, or a setting is missing, or the whole thing only ever ran on the machine of the person who built it. Developers gave this experience a nickname that stuck. It works on my machine. That nickname is the punch line of an old and expensive problem. A program is never just code. It leans on a specific version of one tool, a library from another, and a stack of settings that all have to line up at the same time. Change a single piece on a different computer and the whole app falls over. The details are always small and always annoying. Maybe the app wants an older version of a language than the one you have installed. Maybe it expects a database that's already running, or a hidden setting buried in a file. The instructions never mentioned. None of it is exotic, and all of it can break a project that worked fine five minutes earlier somewhere else.

1:22 If any of that sounds familiar, it's because almost everyone runs into it when the same software behaves differently on every machine. Teams burn hours on setup instead of building. A new developer spends their first days fighting their environment instead of doing the job they were hired for. Code that runs perfectly in testing can still act differently the moment it reaches a real server. Now multiply that by a whole team ten developers, each on a slightly different machine, with their own mix of versions and settings. The number of ways things can break grows fast. Add a testing server and a production server, and the same app is suddenly expected to run in a dozen places at once, all of them a little bit different. Docker's own team summed up the problem when they launched the tool back in twenty thirteen, and their description was blunt Shipping code to the server is hard.

2:04 That frustration is what containers were built to erase. The fix isn't better instructions or more careful setup notes. It's a way to package an app so that the machine underneath it stops mattering. What a container really is. A container is a package that holds your app together with everything that app needs to run. Think of it as a sealed lunchbox. The meal is inside, the utensils are inside. And it doesn't matter what kind of kitchen the person opening it happens to have. That idea sounds almost too simple, which is exactly why the word container throws people off. The name makes you picture something heavy and technical. When a container is really just your app, plus its dependencies sealed into one unit that travels well. A container isn't a computer, and it doesn't carry its own operating system around. Instead, it borrows the operating system of the machine it's running on, and it packs only the app and the pieces that app depends on.

2:49 That's what keeps each container small and quick to start. You can run a whole set of them on a single laptop without the machine slowing to a crawl. The thing that stops a container from tripping over everything else on the machine is isolation. Inside, the app sees a small world that looks like it has the whole computer to itself. That computer is actually shared with other containers and other software. That isolation is what lets you run many containers side by side on one machine without them fighting over anything. It also means one image can spawn as many containers as you need. You built the blueprint once, and from it you can start five copies for five customers or one hundred copies when traffic spikes without building anything twice. The payoff is the part that matters most. The same container behaves the same way on your laptop, on a coworker's machine, and on a server in a data center.

3:31 You package it once and it stops caring where it lands. Two words come up constantly in all of this, and beginners mix them up. An image is the blueprint and a container is the running copy of that blueprint. If a container is the copy, the obvious next question is what exactly it's copying from, and the answer is more interesting than it sounds. Images, Docker files, and the power of layers. An image is a frozen recipe. It's read only, which means nothing inside. It changes once it's built. It holds your app, the files your app needs, and the instructions for how to start it. That read only quality is what makes an image safe to share, because a thousand people can run the same image and get identical results. The clever part is that images are built in layers, and each layer is a set of changes stacked on top of the previous one. Picture a stack of clear sheets where every sheet adds something new.

4:13 One sheet brings the base operating system pieces, the next adds your app's code and the next adds your settings. Stack them all up and you have a complete image. The reason images use layers instead of one giant file comes down to rebuilding. When you change something, Docker rebuilds only the layer you changed and the layer sitting on top of it, while everything below stays exactly as it was. That's why a rebuild can finish in seconds instead of minutes. And it's why images stay small compared to the alternatives. Images also build on each other. A base image that already contains a Linux system and a web server can sit underneath a hundred different projects, and each project just adds its own layers on top. That shared foundation is a big part of why images stay surprisingly small. Those layers come from a file called a Dockerfile.

4:55 A Dockerfile is plain text that lists the steps for building an image one instruction per line. One instruction might start from a base image, the next might copy your code in another might install a dependency and the last one says how to launch the app. Read it from top to bottom, and you're reading the recipe for the whole thing. The order of those lines matters more than beginners expect. If you edit your app's code, Docker reuses the earlier layers and only reads the last few steps, which is fast. If you edit the very first line, everything stacked above it has to be rebuilt from scratch, which is slow. That's why experienced people put the parts that rarely change near the top, and the parts they edit constantly near the bottom. If you remember one thing from this whole section, make it this. The image is the recipe and the container is the meal you serve from it.

5:38 Everything else follows from that split. This is also where the portability promise gets kept. The Dockerfile is the source of truth, and anyone with that file and the code it points to can rebuild the exact same image. There's no guessing and no mystery about which version someone used. There's one more layer worth knowing about, and it's the one that catches people out. When you start a container from an image, Docker adds a thin writable layer on top, and that's where the running container can write new files. That layer is temporary though, so when you remove the container, Anything written there disappears with it. That single rule explains a surprising number of beginner problems, and it comes back later. First, images have to live somewhere and that somewhere is called a registry. Registries where images live and travel. A registry is a place that stores images so they can be shared and downloaded.

6:21 If an image is a recipe, a registry is the shelf of published cookbooks, and anyone with access can pull a copy. The default one is Docker Hub, a public registry that anyone can use. Docker looks there first when you ask for an image, which is why so many commands simply work without you pointing anywhere. If you'd rather keep your images private, you can run your own registry behind your own walls, and plenty of companies do exactly that. Images come with tags, which are just labels for versions of the same image might carry one tag for version three, another for version four, and a third labeled latest that points at whatever is newest. That latest tag is convenient, and it's also a trap, which is something we'll come back to. Two commands. Do most of the work here. Pull download an image from a registry onto your machine, and push sends an image you built up to a registry so that others can use it.

7:02 That's the whole loop. You build an image, push it up, and someone else pulls it down. The first time you pull an image, Docker downloads it and keeps a copy on your machine. The next time you ask for that same image, it's already there. So starting a container takes a moment instead of a full download. This is where the portability promise becomes real. A teammate doesn't need your laptop or your exact setup, because they pull the same image and get the same app. Some of those images are official, maintained by the companies behind the software, which is why pulling a well-known image is usually safer than building every piece yourself. It's also worth knowing how large this shelf has grown. By Docker's own count, Docker Hub serves billions of image downloads every month, and the platform counts millions of registered developers. When people say containers are everywhere, this is the scale they mean.

7:42 With every building block now in place, one question is still sitting on the table, and it's the one that trips up almost every beginner containers versus virtual machines. That question is containers versus virtual machines, and it deserves a careful answer. Before containers, if you wanted to run software in isolation, you used a virtual machine. The confusion is understandable because both tools exist to keep software separate from everything around it. They just draw the line in different places. A virtual machine is a complete computer simulated inside your computer. It has its own operating system, its own memory, and its own storage, and it behaves like a separate machine that happens to live inside a bigger one. The name gives away the size of the thing. A virtual machine carries a full operating system, which is a heavy load to copy. For every instance, containers take the opposite approach borrowing the operating system of the machine they're already running on, so they never have to carry one of their own.

8:30 That single difference explains almost every practical gap between them. Containers are measured in megabytes, while virtual machines are measured in gigabytes. A container starts in seconds, while a virtual machine can take minutes to boot on the same hardware, you can run far more containers than virtual machines because each container is doing so much less work in the background, the trade becomes obvious the moment you line them up. A virtual machine buys you stronger separation and pays for it with size and speed. A container buys you speed and a small footprint and pays for it by sharing more with the machine underneath. Neither side is cheating because they're solving the same problem in two different ways. Before you write off virtual machines, though, they still win in a few important places. They give you stronger isolation because each one is sealed off at the hardware level rather than the process level.

9:13 They can also run a completely different operating system from the machine hosting them, which containers can't do. The two aren't rivals either. A very common setup runs containers inside virtual machines, taking the portability of containers and wrapping it in the stronger isolation of a virtual machine. If you've ever used a virtual machine, you already understand the basic shape of the idea. A container is simply the lighter cousin, and you don't have to pick a side because most modern systems use both where people actually use Docker. That's the theory. In the real world, this tool shows up on almost every modern software team, and the reasons are practical rather than academic. The first reason is a consistent development environment. When a new developer joins a team, they don't spend three days installing the right versions of everything.

9:54 They pull the projects container, run it, and start working on day one, which means onboarding stops being a test of patience. Automated testing and delivery is the next big one. Modern teams build and test their code automatically every time someone makes a change, containers make that reliable because the test runs in the exact same environment every time on every developer's machine and on the build server. If it passes on one machine, it passes on all of them. Another common pattern is breaking big applications into smaller pieces rather than one huge program. Teams split it into small services that each do one job. Each service gets its own container so it can be updated or scaled without dragging the rest of the system along. Picture an online store where the checkout, the search, and the user profiles each live in their own container.

10:38 When checkout needs a fix, the team updates that one container and leaves everything else untouched. Portability across places rounds things out. The same container runs on a laptop, on a server, in a data center, or in the cloud. A team can move or grow without rewriting how the app is packaged. There's a smaller, everyday use. Two developers run databases, message queues, and other tools as containers on their own laptops so they never have to install and configure those tools by hand. When they're finished, they delete the container and the machine is clean again. None of this is a niche use case in Stack Overflow Developer Survey, Docker shows up as the most used tool in the cloud development category, ahead of Kubernetes and every cloud provider on the list. Millions of developers rely on it every day, which is a strong signal that the skill carries across jobs and projects.

11:22 The mistakes beginners make before you rush off and start building, it's worth knowing the mistakes that catch almost everyone in their first week. None of them are hard to avoid once you can see them coming. The most common one is grabbing whatever version is labelled latest. It's tempting because latest sounds current. The trouble is that latest changes over time, so the same setup can build differently next month, and pinning a specific version keeps your builds predictable. Then there's data, and this one surprises people. A container isn't a place to store files because that writable layer vanishes the moment the container is removed. Anything you need to keep has to live in a volume, which is storage that sits outside the containers. Short life. Lose sight of that and you'll watch important data disappear the first time you clean up. Size is another trap.

12:02 It's easy to copy and files you don't need and start from a bloated base, and every one of those choices makes the image slower to move and slower to start. Security habits matter. Two. Running everything as the root user is a common shortcut. Root can do anything on the machine, so a problem inside a root container has far more room to cause damage. A limited user inside the container keeps the blast radius small. And finally, there's the habit of fixing a running container by hand instead of fixing the image. Any change you make to a running container disappears the next time you start it, and the image is the source of truth, so the fix belongs there. A quieter mistake is confusing the image with the container. The image is the frozen blueprint you build and share, and the container is the running instance you throw away. Mixing the two up leads people to treat a disposable container as if it were permanent, and that confusion causes plenty of lost work.

12:47 One more small habit saves a lot of time. A short file tells the build which folders to leave out. So large files you never meant to include. Stay out of the image and your builds stay quick. None of these mistakes are fatal, and every one of them is easier to sidestep than to untangle later when you should not reach for containers. Containers are powerful, and that's exactly why it's worth being honest about the times they're the wrong tool. If your workload needs strong isolation at the hardware level, a virtual machine is the safer choice. The same goes for software that needs a completely different operating system than the machine it runs on, since containers share the operating system underneath them. If you have a small one off task, a container can be more ceremony than it's worth. And sometimes running a script or a normal app is simply faster.

13:29 You could spend an afternoon learning the tool for a job that would have taken ten minutes without it. Heavy workloads that hold on to a lot of data often do better with other approaches, because containers are built to be disposable rather than to be long term homes for state. There's also a learning curve to weigh. Containers reward you once you're running many of them across many machines. For a single small project on one computer, that reward can be hard to feel at first. None of that takes away from what containers are good at. It just means the real skill is knowing when to reach for one and when to leave it on the shelf. Once you strip away the jargon, a container is just your app, packed with everything it needs, so it runs the same way wherever it goes. That idea is why it shows up in so much of modern software. If this finally made containers, click subscribe and I'll keep taking the scary parts of tech and explaining them simply.