A Better Way to Learn SRE & DevOps - An Interactive RoadMap

TL;DR

• I made a progressive, interactive roadmap for DevOps/SRE/Infra : https://roadmap.esc.sh/
• It is Open Source : https://github.com/MansoorMajeed/infra-roadmap
• Planning to make free, long-form videos (no promises though) : Leave a comment here on topics / suggestions, and subscribe to the YouTube Channel I am planning to revive.

Intro

Let's get one thing out of the way: for the sake of this article, we are going to ignore the classic gatekeeping phrase, "SRE/DevOps is not a junior role." As much as some might agree with the history of that statement, the reality of the modern industry is very different. There are junior SRE/DevOps roles out there, and there are plenty of new engineers who are genuinely fascinated by the field, but they are absolutely overwhelmed by it.

DevOps / SRE Field is Too Wide

When a new engineer learns frontend development, the path is reasonably clear (one could argue that modern JS frameworks make this more complicated, I agree, but you could still get started fairly easy) : You learn HTML, CSS, JavaScript, a framework like React. You write some code, you immediately see what you built. The feedback loop is immediate and rewarding

Now compare that to SRE/DevOps. Feedback loop is non-existent most of the time, especially for new engineers. You are expected to understand OS internals, networking, pipelines & an entire dictionary of jargons. To make matters worse, what a "DevOps Engineer" actually does at Company A might look completely different from Company B.

Where does one even start? The industry's usual advice sounds something like this:

Problem With Normal Roadmaps

I am not dissing on roadmap.sh, I actually like it for what it is. But lets take a look at the DevOps roadmap from the perspective of a junior engineer – it is essentially a giant web of alien words.

A better Way to Learn

If we want to build better infrastructure engineers, we need to completely change how we teach the subject.

1 - Understand the End Goal: Running Software at Scale

I think this is the biggest missing piece for most new engineers. Before we dive deep into Kubernetes, we need to understand what we are even doing all of this for. To do that, you need a conceptual understanding of the Software Development Life Cycle (which is just a fancy way of saying how web apps and services are designed, built, and run).

Keep this end goal in mind at all times, and things will magically start to make sense. It is crucial to understand how software is written, tested, packaged, delivered, and executed. You don't necessarily need an in-depth mastery of every single aspect, but you absolutely need a high-level understanding of the full flow.

2 - Always ask the "Why" - Learn Concepts Over Tools

The actual problems of running software are basically permanent. Tools are just temporary answers to those permanent problems. Instead of blindly learning a tool, figure out what problem it was built to solve, and approach it from that perspective.

For example: instead of just memorizing kubectl commands, truly understand what Kubernetes solves first. Once you understand the problem space (container orchestration, self-healing, scaling), the tool itself makes sense. Plus, it makes it infinitely easier to learn the next tool that does a similar thing.

Without the foundational "why" behind it, you will just be repeating the learning process over and over. You will inevitably forget tools (that is totally expected) but you will never forget the concepts if you truly understand the core problem.

3 - Make Connections to What You Know

This ties heavily into the last two points. When you have to learn something new, figure out how it connects to what you already know—the concepts, the problems, the potential solutions, and exactly where this new tool fits into the big picture.

When you do this, your brain automatically categorizes the information and makes the connections. As you learn more, you will start connecting more dots, eventually building a robust mental model rather than just a list of tools and commands.

4 - Use AI to fill in the Gaps

In my opinion, this is the absolute best use of AI for learning. Pick your favorite LLM and ask it questions based on what you already know. Ask it to conceptually explain your knowledge gaps, and have it explain exactly how a new topic fits into your existing mental model.

I built an interactive Roadmap tool

I wanted a tool that actually reflected this learning philosophy. Since I couldn't find one that didn't immediately overwhelm the user, I built one: roadmap.esc.sh.

You can start at any "Zone". Click on the "Where do I start" if you are not sure

Starting from Foundations

Instead of jumping straight into SRE principles, let us start with baby steps and start from the very beginning.

• Each Node gives a short overview, you can save the progress as well. Of course the goal is not to give you all the information you need straight fro here, but it acts as a starting point with links to other resources for you to deepen your understanding.

Connecting the Dots

The map is expanded progressively as you click the + on the nodes that you find most interesting. It reveals a bunch of path that you can take

The "Why" Nodes - Your Questions and Thoughts

These are the questions or thoughts you may have when reading a concept or a tool. These questions allow you to pick the path that you find most natural to you.

Next Steps : Long Form Video Series for SRE

As I mentioned earlier, the fundamental problem with standard roadmaps and a lot of tutorials is that they show you what exists, but give zero context on why it exists or what actual problem we are trying to solve. This inadvertently trains beginners to focus on memorizing tools rather than understanding concepts.

I am thinking of making a free, long-form video series based on the exact flow of this roadmap. The idea is to keep the focus on the why

We would start with the absolute basics and progressively introduce modern infrastructure tools to scale it to millions of users. Obviously, that is a highly ambitious goal and will take a ton of effort to produce, but I think it's the best way to actually see these concepts in action.

If you would be interested in watching a series like this, let me know! Drop a comment below with specific topics or problems you’d like to see covered, and go ahead and subscribe to my YouTube channel. And yes, I know I haven't posted a DevOps video in 5 years 😄 but we are fixing that! – Maybe (But no promises)