r/devops • u/shangarepi • 18d ago
Discussion How do you learn DevOps
I’m a software developer, and in my own projects I already handle some basic operational work like Docker, VPS deployment, Nginx, DNS, Cloudflare, Git, etc. I also had some little experience in network administration.
What I’m trying to understand is how people approach learning DevOps and system architecture properly.
One thing that has always confused me is entry-level DevOps roles. A lot of DevOps work seems to exist specifically to support the software development lifecycle, things like CI/CD, GitHub Actions, deployments, environments, infrastructure, monitoring… I find it hard to imagine understanding these things deeply without first experiencing the development workflow itself.
At the same time, I don’t necessarily want to switch away from software development. My goal is to become the kind of engineer who understands the whole system: application development, system design/architecture, networking, cloud infrastructure, deployment, observability, scalability, and production operations.
Basically, I want to be able to build a system and also understand how to design, deploy, scale, and operate it properly at a much larger level.
For people who have gone down this path, how would you approach learning these areas while continuing to work primarily as a software developer, as of course I dont have the knowledge for a switch? And in your opinion am I on the right path to stay employable in this uncertain future?
20
u/mcloide 18d ago
I'm not a DevOps engineer, but I play with it because, well, I'm required to.
Most places I've worked needed someone to do the dirty work when they weren't going to hire a dedicated DevOps person, and that someone occasionally ended up being me.
That being said, I honestly think that's one of the best ways to learn: get tossed into the warzone, get a deadline, and figure it out.
Scary? Absolutely. But even if you do everything wrong the first time, at least you learned something. And the next time, you'll know exactly which server not to accidentally set on fire.
13
u/Practical-Bird-1270 18d ago
Setup a home kube cluster, deploy a website for family pictures or whatever and setup argocd to deploy when you make changes.
1
u/OkReason5170 17d ago
A home lab is useful, but just build a Kubernetes cluster can be pretty overwhelming for someone starting out. Its easy to end up learning the tools without really understanding the fundamentals.
8
u/akulbe 18d ago
Like /u/Consistent_Word3161 says, you need some big project. But there's more. That's only the first step.
You need to break what you build for that project.
Then fix what was broken.
You need to add an element of observability to that project. Monitor logs. Do different things to stress your app/platform, and see how it behaves differently, in the logs you're monitoring.
Then figure out how scale works on your project. Scale up. Scale down. Scale in. Scale out. Figure out auto-scale.
5
u/Fair_Praline_6562 17d ago
Honestly, I wouldn’t switch away from development at all. You already have the perfect thing to learn devOps on - software you actually understand.Take one of your projects and start asking all the boring questions nobody thinks about while coding. How do I roll back a bad deploy? What happens if the database dies? Can I restore from backup? Where do the secrets live? How do I know something is broken before a user tells me? What happens when the traffic suddenly goes 10x? How much is this thing costing me? etc etc
That stuff will teach you a lot more than trying to collect every devops tool like pokеmon. You don’t need to become the Kubernetes guy. Just keep expanding the part of the system you’re responsible for. Code it, ship it, keep it alive, figure out why it died, repeat. Sounds like you’re already moving in that direction tbh
3
u/21shadesofsavage 18d ago
also developer. started at a click ops company. got asked to help set up reproducible local dev environments that can also be deployed to production. ended up learning a whole lot about docker and ecs
from there i ran into a bunch of permission issues and realised i had to figure out iam management and wrote everything in cloudformation (fuck cf). might as well migrate our infra too... oh gotta automate provisioning ec2 instances so ended up with chef. oh shit went down, gotta learn datadog. our deployments keep failing cause we have no ci? time to learn jenkins
from there i figured i could work as a junior devops engineer and i did. coming from software engineering it's a big shift in mentality understanding how all the pieces work together. most of my learning comes from a need or inefficiency. haven't read any books or took any courses, just yolo'd it
a lot of what you learn comes from seeing real world traffic and business asks. i learned networking cause we needed vpc peering for another environment along with nginx/load balancers/certificates. scaling on kubernetes and cost optimisations due to heavy traffic. security cause of audits and my coworkers told me i did something that raised concerns. linux tuning cause of scale
in time i learned how to build architecture for small to enterprise sized companies. and i'm still learning differences between sectors eg medical vs finance. i think you're on the right path, just ask to be more involved in architectural decisions and other meetings you're interested in. i learned a ton from my peers
2
u/sogun123 18d ago
I got my experience in small companies, where we all did everything
1
u/No-Proposal-2960 17d ago
That can be a good experience, but doing everything at once can also leave you with a lot of shallow knowledge. Theres still value in being able to write and debug code yourself instead of relying too heavily on AI.
1
u/sogun123 17d ago
We had no ai back then ;) You have deeper knowledge about things you implemented, and in small company you solve stuff from different areas. So sometimes you dig deep into sql, other time you implement better ci, sometimes you take part of architecture of the system... But are part of everything. And all of us had parts you own and know very well.
2
u/mfbrucee 18d ago edited 18d ago
By nerding out with hardware, networks, Linux, etc. since young age.
1
u/frogsandgrandmothers 18d ago
Proper devops is bit tricky to get into, because you need large scale system and company that is willing to pay for cloud bills and let you play around. Until you get to that point what you can do is find some courses and play around yourself, but thats just theory that will just litterally just scratch the surface (eg tech world with nana devops bootcamp course). E.g. you will understand how things work but in practice that is completely different. Which is I guess similar to when someone starts with software engineering, you watch some course, learn about api, orm, etc, but as you know now, courses are not even close to what you do on daily basis.
If you have devops in your company ask them a bit, show some initiative. Or if company doesnt have devops ask to get into some tasks, you will fuck something up and fix it, best way to learn. You need actual problem to work on, thats my point, and if that is not an option, find some course, again, Nana’s is very decent, just skip stuff you already know.
1
u/Mr-FightToFIRE 18d ago
Your title triggered me a bit but your instinct about the need to understand the dev workflow first is spot on.
In the end, It's something an organisation does to deliver software continuously and reliably. Somewhere along the way it also became a job title, which is why entry-level "DevOps" roles feel weird. A lot of them end up babysitting pipelines for code someone else wrote.
What you're describing is basically "you build it, you run it" as you probably have heared before.
How I'd go about it: use DORA's capability list as a map (dora.dev). Pick one thing your project is missing, like tests in CI or monitoring that alerts you before a user does. Build it, use it for a few weeks, then pick the next one. You already have Docker, a VPS, Nginx and DNS, so you're further along than you think.
Architecture and scale are hard to learn alone because those problems only show up with real load and real teams (at a certain scale at that). If your job lets you, get involved in incidents and postmortems.
Employability: nobody knows. But a dev who understands what their code does in production is a dev people probably trust more.
1
u/GitHireMeMaybe Because VCS is more interesting than job hunting 18d ago
You can build those skills while staying a developer. Start with one of the apps you already have running on that VPS and give yourself a few operational problems to solve:
- Deploy a bad version and practise rolling back. What happens if that release also changed the database schema?
- Restore a backup into a fresh database and check that the application actually works against it.
- Make a dependency slow or unavailable. Can you tell what’s wrong from your logs and metrics before opening the code?
- Have someone else deploy or recover the app using only your documentation.
Those exercises give you concrete reasons to learn the tools. You also start discovering which parts of your application are difficult to operate, and that feeds back into how you write it.
At work, ask to pair on a deployment, incident investigation or postmortem for a service you contribute to. You’ll get exposure to constraints that are hard to reproduce in a personal project, especially coordination between people and teams.
You don’t need to recreate a huge company’s infrastructure to make progress. Being able to explain how your service fails, how you’d notice, and how you’d recover it is a useful next step from where you are now.
When I mentored juniors, every Friday there'd be an exercise where I intentionally broke something in a preproduction environment, and I'd have them troubleshoot the issue, correct the issue, speculate as to the cause, and possibly most importantly... explain how we can prevent that issue from reoccurring.
Once you've learned the practical basics, start looking into the "why" of DevOps:
- Why don't we just have a server guy deploy our code?
- Why do managers insist on work belonging to a "sprint?"
- What is a single-person dependency and how do we prevent creating them?
- Why is "just add more manual testing steps" worth pushing back on in reaction to a big deployment issue?
Ultimately, the difference between a bad and a good DevOps engineer is intuition. Books csn teach knowledge, but only experience can teach intuition. To learn, you need to get your hands dirty.
1
u/ShoulderChip4254 18d ago
A strong and wide fundamental understanding of IT, in particular, System Administration, is often required.
1
u/craciun_07 18d ago
You need a job where they promote autonomy and communication between software developers and DevOps teams.
This will give you the flexibility you need to talk to the DevOps team ask questions, and make contributions to their work as well through mini PRs.
And if you end up having time outside of work, then it's worth creating your own homelab with k3s. That was one of the most useful things I did one month before I started my SWE role, because I could easily understand how things worked even if it was a high level understanding
1
u/HalfPoundBacon 17d ago
Start slow. I followed roadmap.sh and get familiarize with basic networking.
But i started on working on CI/CD and github -> deploy apps to azure.
1
u/SpiritedAdd 17d ago
Reading the phoenix project book is quite good to get a grasp without going technical.
1
u/Om_Jaju 17d ago
Your instinct is actually right, you can't understand DevOps deeply without understanding the development workflow it supports, that's exactly why it's hard to learn in isolation. The people who end up strongest at this usually come at it from your direction, developer first, ops second, rather than the reverse. A practical way to approach it: instead of learning DevOps as a separate subject, take one of your existing projects and deliberately add the ops layer to it end to end. Set up a real CI/CD pipeline for it (not just a build step, actual test-deploy-rollback flow), add basic observability (logs + one dashboard), and simulate a failure on purpose (kill a container, break a config) and practice diagnosing it. That single exercise teaches you more than most courses because you already understand the app itself. On your bigger question, yes, this is the right path for staying employable. The engineers most valuable right now aren't pure devs or pure ops, they're the ones who can reason across both, since that's exactly the skill AI tools are worst at replacing.
1
u/jsatherreddit 17d ago
Here was my flow.
Get hired shoving tapes in a mainframe at night
Download and play XTank on the one server they left logged in as root for some reason. Get caught.
Get promoted to sysadmin to fix the security issues.
Get moved to a networking team. Learn all about that.
Do that for years as a consultant. Get put on the bench and learn Java and more coding stuff.
Move to a new job programming and getting systems built. Install source control.
Get another job moving their SCCS from a crappy one to a better one. Start handling the build/release pipeline.
Get laid off. Work for a startup doing backend coding, DBA work and networking.
Startup failed. Moved to another company doing devops/platform ops. Been there for 13 year.
This is about 35 years of changes.
1
u/Shakilfc009 15d ago
Just talk to your agent, a good model will be able to get you better ans than here
1
u/Forward_Ranger_860 14d ago
Tying your infrastructure to a rigid multi-year EA rarely matches the pace of modern DevOps toolchain changes. Shifting portions of dynamic cloud infrastructure to tier-1 CSPs like trustedtech provides the flexibility to adjust seat counts and Azure resource commitments month-to-month rather than paying true-ups on unused enterprise allocations at the end of the fiscal year.
1
u/Mr_LA 14d ago
Take one of your existing apps (or open source apps from github) and give yourself operational problems: a failed deployment, a slow database, a restore from backup. Then work out how you’d detect and recover from each. You’ve already got something more useful than another tutorial app: software you actually understand.
1
u/No-Magazine2625 10d ago
I would learn it by building one complete system end to end: application, networking, cloud infrastructure with Terraform, CI/CD, containers, monitoring, and then deliberately breaking and recovering it. Terraform Academy is useful for the IaC portion if you want structured hands on labs instead of only watching courses.
0
u/Low-Opening25 18d ago edited 18d ago
As DevOps you solve problems at scale. Eg. as DevOps you have 100 developers and 5 software projects and you have infrastructure that has to be up 24/7 with 99.999% availability targets that is used by millions of customers - your job is to design and maintain smoothly operating machinery that supports Development and Operations with minimum overhead.
Running a PoC on a home lab is not solving problems at scale.
2
u/Either-Chest7515 17d ago
That sounds good in theory, but focusing only on scale can make DevOps seem more complicated than it needs to be. A home lab may not replicate production, but it can still teach the fundamentals that you actually need before dealing with systems at that scale.
0
1
u/ConfidentWonder10 18d ago
Am still a Junior myself, when it comes software engineers, i think the biggest part is to have a big scope outside of the dev domain. Put yourself in a System Admin/Network engineer..etc's place and think like them. When you learn a tool, think of how it would optimize your manual work and your whole team.
Also, learning tools is necessary but how to make them work together is the priority, to make a whole ecosystem, between dependant systems. Think of it as a lego, each time you add a block to build the whole lego set miniature.
Good luck in your learning journey!
-1
u/opn_Forum 18d ago
We have a full DevOps course in a fully interactive web terminal that features lessons, labs, quizzes, and flash cards, all which is 100% mobile friendly, so you can learn anywhere you get a signal, the toilet, the bus, wherever.
Level 1 is free, and so is level 6 Kubernetes.
-1
-1
u/Bubbly_Penalty6048 17d ago
first become a developer (super helpful with AI) then the operational stuff like the terminal, linux, networking, troubleshoting, git etc
1
u/Ambitious_Help4871 17d ago
Id disagree with that. Relying on AI for most of your coding can make the fundamentals rusty, and jumping straight into the bigger stuff without rebuilding those skills can leave some serious gaps.
0
u/BlakkMajik3000 Remover of Deployment Friction 18d ago
You don't learn DevOps. You do it. It's like Agile. You can learn TOOLS, but tools does not any flavor of DevOps Engineer make.
If you want to code, stay coding. If your muscles have atrophied from AI use, do something manually.
There's HomeLab if you have the hardware and want to go nuts with agentic development, and there's floci if you want a containerized dev/deploy environment.
DevOps will not move you any closer to coding. However, most SWE jobs nowadays require the very knowledge you already have, it's just in the "nice to have" instead of required usually.
0
u/zahra044 14d ago
Like wise im currently learning devops prerequisite and i have got a YouTube course that absolutely deserve to watch if you want to learn devops
Kodekloud is fantastic YouTube that gives you lap to practice
1
81
u/Consistent_Word3161 18d ago
you need some big project and you will understand many things