Hey Ala,

Yesterday I gave you the foundation for your career change.

You now have a note‑taking system that will serve you for the rest of your life.

Today we’re going to put that system to work on the next big concept in modern DevOps: containers.

As you keep progressing through the Linux course, you might start to wonder:

“Where is this leading?” “I’m learning Linux, but is that enough to land a job?”

Short answer: Linux gets you in the game. Containers are how the game is played today.

First, I’ll explain what containers are and how they are used.

After that I’ll explain why doing the Linux course is needed to work with containers.

Introduction to Containers

When a software engineer writes code, they’re writing instructions for a computer to execute.

That code has to run somewhere.

That “somewhere” is a server: a machine in a data center that runs 24/7 so users can visit the website or use the app.

To turn code into actual work, the server needs tools:

• Programming runtimes (Python, .NET, Java, etc)
• Libraries and dependencies
• System tools and settings

Think of a carpenter. If he needs to build a wall, he needs several tools, like a hammer and a saw.

If you ask a carpenter to build a wall with no hammer, they simply can’t do the job.

• The carpenter is the application (the code)
• The tools are libraries and dependencies
• The construction site is the server

Now let’s say we have a building company that manages 10 carpenters. We send them to construction sites to do jobs.

Instead of hoping every construction site magically has the right tools, you give the carpenter a toolbox with everything they need and a van to bring it anywhere.

• Carpenter = application
• Tools in the box = dependencies
• Van + toolbox together = container

A container is a way of packaging software together with everything it needs to function.

It doesn’t matter where we run the container: laptop, data center, cloud.

As long as there’s a container runtime, it works, because everything it needs travels with it.

The Problem they Solve

Before containers, teams had to manage all of these tools directly on the server:

• Install the right runtimes and versions
• Install all the right libraries
• Keep everything in sync as apps change
• Avoid breaking other apps on the same machine

When multiple applications with different needs share one server, you get:

• Version conflicts
• “It works on my machine” bugs
• Fragile scripts and manual fixes
• Outages caused by one change breaking something else

Containers solve this by packaging everything each app needs into its own unit and running each unit separately on the server.

Each “carpenter” shows up with their own van and their own tools. No fighting over hammers.

How Containers Became Standard

Containers are a relatively recent development in the industry.

They became popular in 2013–2015 with the rise of Docker, and then “standard infrastructure” by roughly 2017–2018.

This is where most people make a mistake.

They hear “Docker is important,” open YouTube, and jump straight into Dockerfiles and random commands.

When something breaks, they just copy‑paste fixes from ChatGPT because they don’t understand what containers actually are.

What powers containers under the hood?

Linux.

Containers are implemented using Linux features (like namespaces and cgroups). You don’t need to remember those names yet, but this is why I push you to start with Linux and the command line.

If you understand Linux deeply, containers are 10x easier to learn and debug.
If you skip Linux, containers feel like magic and you get stuck.

The Container Market

If you want to land a six-figure tech job in 2026, you need to learn how to work with containers. I don’t make that statement lightly. Containers are used everywhere.

For example, take this public statement from Google:

Another example is Spotify. They have been using Docker containers since 2014.

In other words, containers are used in huge enterprise environments that run critical infrastructure.

But here’s an interesting fact. Even though many companies are already using it, there are still millions of companies that haven’t made the switch yet. There is a lot of work to be done, and this is why learning Linux is going to make you money.

Just look at the market projections. You’re getting in at the right moment.

​

What This Means For You

Back to the questions:

“Where is this leading?”
“I’m learning Linux, but is that enough to land a job?”

By doing my Linux course, you’re setting yourself up to take a slice of that $31B market.

Containers run on Linux and are implemented using Linux features.

To work with containers in a meaningful way (and get paid well for it), you need Linux.

You’re doing exactly the right thing by:

• Reading these emails
• Following the Linux course
• Using your note‑taking system

You’re building foundations most people skip.

Your action for today

Open your note‑taking system and create a new note called "Containers – Big Picture".

In that note, write three short sections in your own words:

1. What a container is
2. Why companies use containers instead of “traditional” deployments
3. Why you need to learn containers if you want to make $100,000,00+ in tech

Don’t copy/paste from this email.

The goal is to practice turning a fuzzy idea into clear writing.

That’s how you actually understand a topic, and it’s exactly what makes container questions in interviews feel easy later.

This is all you need to know about containers for now. You don’t need to study them yet.

Keep doing the Linux course. I’ll walk you into containers step by step when the time is right.

Tomorrow I’ll show you what comes after containers, and introduce you to a skill with a documented average minimum salary of $141,000 worldwide.

You don’t want to miss out on that one.

Keep taking notes,

Mischa

P.S. Don’t get sucked into the containers rabbit hole now. I introduced the topic so you know what’s coming next. For now, all you need to do is keep working on the Linux course. I’m going to teach you all about containers in a future mail.

​