Let’s build great apps together | Docker.

This story is the beginning of a long and exciting journey to build real applications together and gain a deep understanding of many modern and advanced concepts.

This is the first part of our FREE course on learning Docker in depth, featuring numerous practical examples and hands-on app-building projects.

I’m waiting for you on my amazing blog, and I promise we will learn useful things together and my Medium stories.

Why do we need to containerize our apps?

First of all, why would we need Docker at all? Simply put, it’s to build and manage containers. But wait… what exactly are containers?!

When I say ‘containers,’ the first image that might come to mind is a massive cargo ship 🚢 carrying huge containers stacked on its deck.

But why do people place their cargo inside containers instead of directly on the ship?

Back in the time before containers were invented, traders used to place their goods directly on ships without the need to containerize their goods, which led to many issues. 

Goods would get mixed up and sometimes even lost among other items. Additionally, it took a lot of time and effort to load and organize the cargo on the ship, then unload it piece by piece once the ship reached its destination.

Many items would either get damaged during loading, lost at sea, or, at best, get mixed up with the goods of other traders.

This is where containers came in to solve the problem. Each trader could now place their goods in a dedicated container, and the containers would simply be stacked side by side on the ship’s deck, without needing to arrange each item individually. This protected each trader’s goods from mixing with others and also safeguarded smaller items from falling into the sea during transport.

The loading and unloading process became much easier as well. All that was needed was a single crane on the ship’s deck to lift and lower the container, with all its contents, without any hassle.

Not only that, but since containers are standardized, they can be transported on any vehicle without needing to rearrange the contents. For example, a container can be unloaded from a ship, then loaded onto a train, transferred to a truck, and finally placed directly into storage as-is.

We apply this same philosophy in software. Either we place all our requirements in one container and deploy it anywhere or on any type of server, running it seamlessly, or we risk letting our assets mix with others’ assets, leading to conflicts and spending a lot of time arranging everything to suit the environment where our application will run.

Using containers offers the following advantages:

1. Complete isolation of our software assets without worrying about them mixing with others’ resources.
2. Saving time and effort in setting up the runtime environment; we simply deploy our container as it is.
3. Ensuring that the runtime environment is identical to the development environment.
4. Just like traditional containers, software containers can be unloaded from one server and deployed directly onto another platform without any need for reconfiguration.
5. Enhanced security, as unauthorized users cannot directly access our personal container.

Real-life examples

Let’s look at some simple real-life examples that we encounter daily in the world of software.

Imagine someone asking you to complete a tiny project, which involves writing simple content in a Microsoft Word document. This project is so simple that it will take only a few minutes to finish. However, you might face a huge problem that isn’t easily solvable.

After completing the project perfectly and sending it to the client via email, they call you to say that the program isn’t working.

After testing it on your side, you respond with the famous phrase, “But it works on my end.”

The client insists that the program isn’t working, while you insist that you completed it perfectly.

Of course, the reason the project isn’t working on the client’s machine is simply because the environment they are testing in is different from the one you developed the project in.

For instance, they might be using an operating system that doesn’t support running Microsoft Word. Or, if they have a Windows system, they might not have installed the Office package. Even if they installed it, they might not have chosen Word as part of the package. 

Even if everything was installed successfully, we can’t guarantee software versions — perhaps they installed slightly older versions of the software you used, which don’t support opening that specific file because it was created with a newer version.

And even if everything is installed with the exact same versions, we might discover after a lot of searching that the language package used in the file is missing from their system. After installing it, we may realize that we need to install the required fonts. After installing the fonts, we might find… oof, so much effort and so much time wasted just preparing the environment to work.

Let’s think about possible solutions…

The first solution might be to give your personal laptop, along with the program, as a gift to the client. Of course, you wouldn’t sacrifice your laptop worth thousands of dollars for a $10 project, so let’s explore cheaper solutions. Think with me.

What if we tell the client to set up an environment that matches the one on our laptop to ensure the runtime environment matches the development environment?

This solution might not work at all. What if the client has a MacBook and doesn’t want to replace their system with Windows?

Even if they are open to using Windows, they might lose access to other applications if they change software versions.

Let’s assume they are a very kind person and open to all solutions. Would you be willing to waste hours reinstalling the operating system, then reinstalling all the required programs and packages, just to run a simple file?

While this solution may seem impossible in many cases, it requires an immense amount of effort.

So, let’s rule that out as well. Let’s think of easier solutions.

Virtual machines (VMs)

For this purpose, engineers came up with a very clever idea: virtual machines. The concept behind virtual machines is to create a virtual device within your real device. This allows you to run an entirely separate operating system that is completely isolated from your original system, preventing any conflicts between the system files and packages.

With this, you can run a Windows operating system on a MacBook completely independently without altering the original system files.

This solution is great because it doesn’t require the client to delete their original system in order to run our program. However, we still need a lot of time and effort to install the necessary programs and packages required to run our application.

Aside from this significant effort, VMs have another problem: they consume a lot of system resources. As a result, running virtual machines is very limited.

What if we wanted to create dozens of systems and run them all at the same time without consuming too many resources from the host machine?

Containers

What if we borrowed the concept of containers from ships and brought it into the world of software?

This is what we will discuss in detail, step by step, throughout this course.

Think more …

Let’s quickly look at another example.

Imagine you’ve been working on a huge project for years, and this project has accumulated many dependencies over time. What if several new developers join your team to work on this project?

You’ll need to set up each of their machines to exactly match yours. Every time, you’ll discover that there are some dependencies you forgot to install or that you installed the wrong version by mistake.

Once the project finally works after much effort, you’ll need to repeat the same setup work on the other developers’ machines.

What we need is a way to provide a development environment identical to the one where the original project is running.

Of course, the container concept solves this problem, as we simply “ship” the container with all its contents to each developer’s machine. And that’s it.

Similarly, what if you’re asked to work on another project alongside your huge one, but the two projects have conflicting dependencies? We need a way to isolate each project with its dependencies, so that each one runs in the environment that suits it.

This is another problem containers can solve, as they provide the feature of isolating each container from the rest of the system and preventing any interference with its contents.

Ready?

Are you ready to embark on an exciting journey to deeply understand containerization and practice building amazing applications together? Let’s gooooooo!