Today, a friend of mine called me up and said, "I have an interview for a DevOps role in three days. I have no idea what it is—can you share some YouTube playlists? Also, what should I deploy to make my profile stand out?"

Quick background: He has zero experience in DevOps or even software development beyond some basic DSA. And this company came to our college for placements.

That got me thinking—there's a serious gap between what people think DevOps/SRE is and what it actually is. And a big reason for this gap? The way it's portrayed online, especially through YouTube tutorials.

Let’s talk about it.

Who should read this?

People at the same experience level as me.

1. Freshers (<1 years of experience.)

2. Trying to get into DevOps/SRE as their first job

3. You are a fresher in another role, thinking of learning DevOps.

This is an Opinion, not an Advice

I’ve myself started my first job as an SRE. And yes, I know very little about a lot of things. What I'm speaking about, is stuff, I learnt by trying to identify my gaps.

Every day, I sit with SREs who are much more experienced than me and I'm awestruck each time, I see how well they understand problems. They understand networking, databases, software architecture and Linux well. It humbles me every day, my day starts with “I know nothing” and ends with “I need to learn this.”

And, yes it's pretty exhausting as a fresher, as you come with zero or little experience in software engineering in general.

So, this is more of an opinion I've developed after reality checks and I'm writing with the hope that it clears a lot of misunderstandings, and doubts and gives a true..er picture of DevOps/SRE.

The Problem with Most YouTube Tutorials

YouTube is filled with beginner DevOps/SRE tutorials. While they serve as a great starting point, they often fail to represent real-world work. Here’s why:

1. End-to-end DevOps Projects – These usually cover setting up a simple CI/CD pipeline, maybe some Infrastructure as Code (IaC), and a basic observability stack. But that’s just a fraction of what DevOps is.

2. Corporate Pipelines – These tutorials just add extra tools (like SonarQube) and claim they’ve implemented "shift-left security." In reality, good security is more than just adding a tool—it requires deep planning.

3. Observability Tutorials – They focus on setting up a Prometheus-Grafana stack, configuring some alerts, and calling it a day. But real observability is about understanding what’s going wrong in a system before it impacts users.

These tutorials are toy projects—good for getting a taste of DevOps/SRE, but far from what we actually do in the industry.

A good analogy is “Building an e-commerce website with no users doesn’t mean you understand software development.”

What DevOps & SRE Actually Do

Real-world DevOps and SRE work involves a lot more planning, standardisation, automation and firefighting than just setting up tools.

Firefighting Examples

I'll keep the discussion around firefighting as it is the one that is easier to relate to.

The most crucial skill for both roles? Debugging and identifying bottlenecks. This is especially important during:

- Incident management

- Root Cause Analysis (RCA)

- System downtimes

Here’s where concepts like Monitoring, Telemetry, and Observability come in. And no, they are not the same thing (despite what some YouTube tutorials claim).

Why "Signals" Matter

Signals are important!

But how do you make sense out of them ?

Imagine your team sets up an alert for high latency on an e-commerce checkout service. One day, an alert triggers—latency has spiked to 5 seconds! Engineers panic and start debugging.

After 30 minutes, they realised it was a false alarm. The issue? A bot was hammering the system with malformed requests. The alert didn’t account for outliers, so valuable engineering time was wasted.

Or take another example:

A ride-hailing app deploys an update. API health checks are green, latency is low, and error rates are normal. But users start complaining—drivers can’t accept rides, and bookings are stuck.

The problem? The API health checks weren’t actually testing the database connections. The system looked healthy, but the connection pool was exhausted due to a misconfiguration.

In both cases, the issue wasn’t lack of monitoring—it was lack of understanding the system’s failure modes.

But, a YouTube tutorial will probably stop at creating a Grafana Dashboard and will not explain you about:-

1. Why a specific metric was chosen?

2. Why were alerts set to a specific value?

3. How do they correlate their telemetry signals:- metrics, logs & traces?

4. Most importantly, Can you use them to detect and prevent failures?

5. How does Observability differ from Monitoring?

The Messiness of Real-World DevOps

Here’s a real story. A senior of mine works at a company that scaled massively over the last five years. They now have:

1. 21 on-prem data centres

2. 50+ microservices

3. No standardization between teams (one uses Tool X, another uses Tool Y)

4. Some teams still on JDK 8, others on JDK 17

5. A mix of build tools: some using Maven, others still stuck on ANT.

Now, they’ve hired DevOps engineers to "fix" this mess. But how do you even begin?

• How do you standardize across teams?

• How would you ensure, that your standardisation does not limit the choice of teams to choose particular tools? It should only mandate some best practices and provide boilerplates, tools or processes to ensure easy compliance.

• How do you handle security across inconsistent pipelines?

• How do you automate without breaking things further?

That’s what real DevOps/SRE work looks like—it’s not just setting up CI/CD but solving large-scale, messy problems.

DevOps vs. SRE: What’s the Difference?

People often confuse DevOps and SRE. Here’s a simple way to understand the difference:

- DevOps is about fast and efficient software delivery. The focus is on building CI/CD pipelines, automating deployments, and breaking down silos between developers and operations.

- SRE (Site Reliability Engineering) is about making systems reliable. The focus is on observability, incident response, failure analysis, and ensuring smooth production operations.

Think of it this way:

- A DevOps engineer asks: “How do I ship this as fast as possible?”

- An SRE asks: “How will my code run in production?”

Both perform the same work but think differently.

DevOps views delivery from left to right (from development to production). SRE views software delivery right to left (starting from production, ensuring reliability, then making sure it's taken care of right from the development phase.)

While DevOps and SRE share automation and operational concerns, SRE is more rooted in software engineering principles (e.g., SLIs, SLOs, error budgets, and toil reduction). DevOps is a philosophy or culture, while SRE is a concrete implementation of reliability practices.

Also, the SRE role is more about ”measuring everything that can be measured” and ” automating everything that can be automated” (toil reduction).

SRE practices at Google influenced the formation of the DevOps Research and Assessment (DORA) program in 2015. The DORA team developed the DORA metrics to help organizations measure and improve software delivery performance, it acts as a litmus test to determine if you are ”Actually implementing DevOps”.

DevOps Never started as a role.

You’d be surprised to know that, while the term ”DevOps” was coined in 2009, and the first DevOps Manifesto was released in 2010, it was not until the next 5-6 years, that it became a role.

The beauty of ”DevOps” is it never described ”How to do ?” instead it focused on “What to do ?“. Let me mention the core principles of DevOps (check out The CALMS Framework) -

1. End-to-End Responsibility: "Everyone is responsible for delivering value to customers, from development through to production."

2. Cross-Functional Collaboration: "We value individuals and interactions over rigid processes and silos."

3. Continuous Improvement: "We must continuously experiment, learn, and adapt to change."

4. Automate Everything: "Wherever possible, we should automate manual processes to improve efficiency and reliability."

SRE is “same-same but different“

Image Sourced From: https://cocolyze.com/en/blog/how-to-create-an-effective-google-adwords-campaign

The key tenets (or principles) of Site Reliability Engineering (SRE) are derived from Google's SRE practices and emphasize reliability, automation, and engineering-driven operations. Here’s what they are:

1. Embracing Risk with Error Budgets – 100% reliability is not the goal; instead, reliability should align with user needs and business objectives. Error budgets define the acceptable level of failures within a service, balancing reliability with innovation.

2. Service Level Objectives (SLOs) & SLIs – Measure and enforce reliability through well-defined performance metrics.

3. Reduce Toil via Automation – Automate repetitive, manual tasks to increase efficiency and focus on innovation.

4. Observability & Monitoring – Use logs, metrics, and traces to proactively detect and resolve system issues.

5. Incident Response & Blameless Postmortems – Handle failures systematically, learn from them, and improve resilience. Focus on “What failed and Why?“ instead of “Who was the person responsible for failure?“

6. Capacity Planning & Demand Forecasting – Ensure systems scale efficiently while optimizing cost and performance.

7. SRE as a Software Engineering Discipline – Apply software engineering principles to operations and reliability.

8. Everything is as code – codify infrastructure (via IaC — Infrastructure as Code), policies (ex. OPA Policies in Kyverno), and workflows for automation (CI/CD, GitOps etc.) and repeatability.

9. Change Management & Release Engineering – Implement safe, automated deployments with minimal disruption.

10. Work closely with Developers – Integrate reliability into the software development lifecycle from the start.

SRE implements DevOps in an opinionated way

The core tenets of SRE embrace DevOps at its core, it just defines an ”Operational Framework” to achieve it. It adds or better focuses on how to implement DevOps, this is the reason why there is a lot of overlap in the day-to-day work done by both DevOps and SREs.

SRE as a practice, started way back in 2003 at Google, way before DevOps was born. SRE has influenced DevOps in various ways and for good.

OOP Analogy —

“Think of DevOps as an Interface, SRE as a concrete class that implements it“.

The Ground Reality

But in reality? Most professionals wear both hats depending on the company’s needs and structure.

So What Should You Actually Learn?

If you’re new to DevOps/SRE, don’t get stuck on flashy tutorials. Instead, focus on fundamentals first:

• Linux Administration

• Networking

• Basic Web Development (Backend preferred, frontend is a bonus)

• Databases

• Automation (Bash, Python, etc.)

• Containerization (Docker, Kubernetes, etc.)

Once you’re comfortable, run real projects. Take existing projects, deploy them, modify them, and introduce:

• CI/CD

• Infrastructure as Code

• Observability

• Scaling strategies

The Hard Truth: You Need to Read

No YouTube tutorial will prepare you for real-world DevOps/SRE work. There will be times when you won’t find a tutorial or documentation. That’s when you need to read technical books, RFCs, and whitepapers.

Here are some great starting points:

• The DevOps Handbook.

• Google’s SRE Book.

• AWS Whitepapers.

Key Takeaways

I learned these lessons the hard way—through internships, freelancing, trying to contribute to open-source projects and managing college servers. I failed at many things before I got into DevOps. And even now, I have so much more to learn. It was the constant cycle of failures and reinforcement that shaped me.

The key takeaway? Master the fundamentals. Get hands-on. Read deeply. That’s the real path to becoming a solid DevOps/SRE engineer.

And most importantly — don’t blindly rely only on YouTube tutorials.

That's all, Folks!

That’s it! Hope this blog helps you see what DevOps & SRE are really about. If you’re just starting, take your time and go beyond the surface-level knowledge. The real learning begins when you start solving problems that don’t have easy answers.