One question has been occupying my mind recently:
If someone wants to learn DevOps, where should they actually begin?
The internet offers thousands of answers.
Some recommend starting with Docker.
Others suggest Kubernetes.
Many point directly to AWS, Azure, or GCP.
As someone currently learning DevOps, I've been trying to understand the subject from a more fundamental perspective.
And the conclusion I've reached—at least for now—is this:
Linux and networking seem to be the foundation upon which many DevOps concepts are built.
I may be wrong, and I'm still learning, but this line of reasoning has helped me make sense of what initially felt like an overwhelming field.
The Problem with Starting from Services
Cloud providers offer an enormous number of services.
AWS alone provides hundreds of them.
For a beginner, this can create a feeling that DevOps is simply about memorizing services:
- EC2
- S3
- VPC
- IAM
- Route 53
- CloudWatch
And many more.
The challenge is that learning services without understanding the underlying concepts can sometimes feel like memorizing buttons in a user interface.
The service names may change.
The concepts usually don't.
Looking Beneath the Cloud
When I started looking past the service names, I noticed something interesting.
Many cloud services ultimately provide access to concepts that already exist outside the cloud.
For example, consider a virtual machine.
In AWS, that service is called EC2.
But what is an EC2 instance really?
At a high level, it is a computer running somewhere else.
It has:
- An operating system
- Storage
- Memory
- Networking
- Processes
The same concepts exist on a personal Linux machine.
The environment changes.
The fundamentals do not.
Why Linux Feels Important
A significant amount of modern infrastructure runs on Linux.
Servers.
Containers.
Cloud workloads.
Many of them are Linux-based.
This means concepts such as:
- File systems
- Permissions
- Processes
- Services
- Package managers
- Logs
appear repeatedly across different technologies.
Learning Linux does not teach a specific cloud provider.
Instead, it teaches the environment where many cloud workloads live.
Why Networking Appears Everywhere
The second concept that keeps showing up is networking.
Every modern application communicates with something.
Examples include:
- A browser talking to a server
- A server talking to a database
- Containers communicating with each other
- Services communicating across networks
Without networking, these systems become isolated.
Concepts such as:
- IP addresses
- DNS
- Ports
- Protocols
- Routing
appear constantly throughout DevOps workflows.
Even many cloud services are ultimately abstractions built on networking concepts.
A Simple Mental Model
The way I currently think about it is:
Linux → Understand the machine
Networking → Understand communication between machines
Cloud → Understand how those machines and networks are managed at scale
Whether this model is perfectly accurate, I'm still not sure.
But it has helped me organize my learning.
Why This Approach Appeals to Me
One reason I find this approach attractive is that the knowledge feels transferable.
If a cloud provider introduces a new service tomorrow, understanding Linux and networking still remains valuable.
The terminology may change.
The foundations usually remain.
Learning fundamentals first seems to reduce the feeling of constantly chasing new tools.
What I'm Learning Next
As part of this journey, I'm currently exploring:
- Linux internals
- Network interfaces
- MAC addresses
- IP addresses
- Packet analysis using Wireshark
- DNS and routing
My goal is not to become an expert overnight.
It is simply to understand the systems beneath the abstractions a little better.
Final Thoughts
I don't yet know whether Linux and networking are the best place to start learning DevOps.
But they increasingly feel like a reasonable place to begin.
The more I explore cloud technologies, the more I find myself returning to these fundamentals.
Perhaps the fastest way to understand complex systems is not to start with the most advanced tools.
Perhaps it is to understand the layers beneath them first.
And right now, Linux and networking seem like two of those layers.
Top comments (0)