Ha! That’s not all that different from my experience. I was going to ask if we’ve collectively given up on arguing against DevOps as a title, role, department, etc.
Yeah, pretty similar. The difference would be that a Systems Administrator mainly "Administrates" (maintenance, toil, etc), which doesn't have to involve an Engineering discipline. An IT Operations Engineer would take on more Engineering work and not necessarily "Administrate". And the "Operations" part can relate to either Business Operations or Operations Management.
Folks tend to get so upset about the title of "DevOps". I am unsure if it is because of:
- just dealing with bad Ops engineers at work that "don't do much"
- employees taking advantage of the DevOps movement to make more money
- System Administrators complaining that 'this is what we have always done'
System Administrators, though skilled, had a much different mindset in the 90s when I worked closely with them. They were more focused on keeping Sun hardware running and keeping the SAN from filling up. That server room was their 'production'. They were still on call for when a server went down and it took days for a new server to be rebuilt. The best of them wrote scripts to make their lives easier but that wasn't often the focus. They were too busy keeping the systems running to automate much of it.
I find that DevOps is a different level of abstraction compared to Sys Admins. In general, they do not need to know how to build a server and fight with the OS as they can use tooling to spin up 100s of machines in the cloud. The amount of knowledge they need is much broader and less specialized than a System Administrator. Where the Sys Admin would need to know the ins and outs of Cisco Routers, the DevOps engineer only needs to know how to use a Load Balancer. If lucky, there is a tool that makes it easy to create them.
I find the list in the guide to be quite accurate but you do not need to be a master of everything in the list.
I'm not sure if this is the exact curriculum I'd pick but I do think it's one of the easier jobs to 'learn' and get a well paying job doing. If you want to get hired at Google (for example), one thing I think that is overlooked is that the SRE-SE interview is actually a lot more sane than the puzzles you see in the software one in terms of practicality, relationship to actual work, and 'learnability'. To have a pretty solid shot you need to learn a scripting language and be able to do practical things with it -like opening files, regex, string manipulation, sets/maps, etc. Next is trouble shooting and linux internals (what happens when you boot a system or run a command at a relatively low level) - this may require dedicated study or just some brushing up depending on your background and general natural 'computer nerdiness' (i.e what OS are you using right now?). The design question needs a bit of preparation - it'd be helpful to read popular distributed systems white papers from the last couple of decades like the DynamoDB paper and understand some 'modern' primitives like RAFT/PAXOS or LevelDB/RocksDB and practice doing some back-of-the-napkin system sizing if you aren't great with mental math.
So it's definitely a lot but at the end of the day it's just knowledge you can self study. A focused course could probably teach it in 6-8 months and give you a pretty solid chance at landing the job vs the algo-puzzle coding path which has a high false negative rate even for talented software engineers. Plus once you have your foot in the door you can always look into a ladder change if you find you don't enjoy the SRE-style work.
12. Learn DevOps
What is Scrum?
Ways To Learn About Scrum
Software Development Life Cycle (SDLC) Phases & Models
The Beginner's Guide to Agile in Jira: Course description
Learn SAFe
Learn Automation Testing
Well. That list is certainly something. But whatever it is, it's not DevOps. It's like "certified agile"? Which is also not agile.
To be fair, that's the last bullet point after all the other (pretty relevant) topics.
And I agree, that's "certified agile". Pretty useless. You can pick whatever "agile" processes are being done in your company in 15min and just go with the flow. A "devops engineer" (whatever that is) hardly needs to know more than that to deliver.
That a fair point, but the whole thing is "learn yourself some devops". If that list ends up building up to that, then you've not gotten the point of any of it and you can't honestly call that last section "devops". There's also some weird excursions on that list, like securing a CI/CD pipeline before we've even gotten to that or getting to k8s way too early.
As someone that has never worked at a startup before, this seems to be the list of skills a startup might find reasonable for a 'DevOps Engineer'. Every other place I've interviewed or have worked has DevOps Engineer and Site Reliability Engineer being distinctly different roles (SRE focusing on monitoring and logging and DevOps engineer focusing on pipeline and build).
There are also other places like where I am now where every team that works on backend infrastructure (Windows, Linux, Virtualization, Networking) also works on their own automation for their platform. We do have a Platform Engineering team that focuses on K8s and Dev tools such as Artifactory, Gitlab, Puppet.
I have an opinion that if a company has a specific role of 'DevOps Engineer' they are doing DevOps wrong. Also Jira and Scrum are absolutely not needed at all to do DevOps.
As a careerlong DevOps guy, I’ve heard many times that “if your job title has DevOps in it, your company is doing DevOps wrong” – overwhelmingly from people with “DevOps” in their job title, delivered with a mordant laugh.
SRE is a software engineering position -- someone needs to write the software (such as Kubernetes) that sysadmins use. It also requires a good understanding of lower-level languages, since someone who only knows Python will have a difficult time debugging a kernel panic or weird mutex issue in multi-threaded C++.
Professional devops/infra/ops whatever we're called these days engineer here. I have feelings about this.
1. Learn a programming language first. Pick something common. Ecosystems are more important than the quality of the language. If you feel overwhelmed by choice learn Python. The ideal learning path is high-level -> low-level -> low-level (advanced) -> high-level (advanced). You want the language to get out of your way at first so you can learn concepts, then get in your way as you learn how things really work, and then back out as you learn real software development. Learning version control first will feel completely unmotivated without knowing why the tools the way they are.
2. Absolutely 100% learn Linux. The best infra people have a strong strong background in sysadmin work. And learn networking through the lens of the kernel/low level userspace. Don't try to learn network protocols in a vacuum, learn how they're actually used on real systems.
3. From this point skip right to IaC. You are at the point where this will make the most sense. And unless you have quite the setup this is when you're gonna learn a cloud provider. Pick AWS. This isn't a bias toward them -- knowing AWS will make learning other clouds easier, the reverse isn't true. And tooling, guides, and documentation for AWS is more plentiful. Explore using the console but don't do anything except play around. Assembling the Cloudformation/Terraform will teach you much much more about how the pieces fit together.
4. Now learn CI/CD, and you'll find yourself reaching for containers here because it's such a huge pain without them. Now you have a real motivation to learn them that isn't contrived. Once it "clicks" you'll understand why you might want to deploy other things with it.
6. Don't bother learning "devops the process" -- it's worthless, nobody agrees what it even is, and every company will do it differently anyway. You want your "knowledge" about the process to be as rich as the flavor in a La Croix. All these processes are at their best when everyone only vaguely knows what they are because any sort of strict adherence only makes you lose sight of your real goals.
7. Do not learn k8s until the very end. It is literally the final boss that combines all the other knowledge you acquire in your devops journey and you genuinely cannot understand the architecture, the tools, and decisions until you experience the pain points of not using it.
8. If you can swing a job as a junior then don't bother to learn how to run production systems, you will learn so much better and faster on the job than anywhere else. Have a "homelab" running some semi-production services to play around with and talk about in the interview but be ready that the big leagues will be a lot more involved. Once you are reasonably self-sufficient at your job and ready to move from maintainer to architect then look toward sre books.
This will get you ready to work at shops in the cloud. If you want to do on-prem work it's a different path.
Readit News
2. Become an IT Operations Engineer
3. Years later, find out what DevOps actually is
4. Never actually practice DevOps
5. Become a DevOps Consultant
Most of the people I’ve worked with called like that stopped their professional development somewhere around the year 2000 and are now coasting along.
For the new title, I feel like they completely ignore the Dev part of DevOps.
I find that DevOps is a different level of abstraction compared to Sys Admins. In general, they do not need to know how to build a server and fight with the OS as they can use tooling to spin up 100s of machines in the cloud. The amount of knowledge they need is much broader and less specialized than a System Administrator. Where the Sys Admin would need to know the ins and outs of Cisco Routers, the DevOps engineer only needs to know how to use a Load Balancer. If lucky, there is a tool that makes it easy to create them.
I find the list in the guide to be quite accurate but you do not need to be a master of everything in the list.
2. Start implementing tools into existing workflows
3. Pad resume with new buzz words
4. Leave for a more lucrative gig while midflight with current projects
5. Rinse and repeat
So it's definitely a lot but at the end of the day it's just knowledge you can self study. A focused course could probably teach it in 6-8 months and give you a pretty solid chance at landing the job vs the algo-puzzle coding path which has a high false negative rate even for talented software engineers. Plus once you have your foot in the door you can always look into a ladder change if you find you don't enjoy the SRE-style work.
Seriously tho, I stepped to next level when I started doing Boto stuff in Python.
And I agree, that's "certified agile". Pretty useless. You can pick whatever "agile" processes are being done in your company in 15min and just go with the flow. A "devops engineer" (whatever that is) hardly needs to know more than that to deliver.
Spivak's approach is much more in line with what I'd suggest folks do: https://news.ycombinator.com/item?id=33398284
There are also other places like where I am now where every team that works on backend infrastructure (Windows, Linux, Virtualization, Networking) also works on their own automation for their platform. We do have a Platform Engineering team that focuses on K8s and Dev tools such as Artifactory, Gitlab, Puppet.
I have an opinion that if a company has a specific role of 'DevOps Engineer' they are doing DevOps wrong. Also Jira and Scrum are absolutely not needed at all to do DevOps.
Deleted Comment
1. Learn a programming language first. Pick something common. Ecosystems are more important than the quality of the language. If you feel overwhelmed by choice learn Python. The ideal learning path is high-level -> low-level -> low-level (advanced) -> high-level (advanced). You want the language to get out of your way at first so you can learn concepts, then get in your way as you learn how things really work, and then back out as you learn real software development. Learning version control first will feel completely unmotivated without knowing why the tools the way they are.
2. Absolutely 100% learn Linux. The best infra people have a strong strong background in sysadmin work. And learn networking through the lens of the kernel/low level userspace. Don't try to learn network protocols in a vacuum, learn how they're actually used on real systems.
3. From this point skip right to IaC. You are at the point where this will make the most sense. And unless you have quite the setup this is when you're gonna learn a cloud provider. Pick AWS. This isn't a bias toward them -- knowing AWS will make learning other clouds easier, the reverse isn't true. And tooling, guides, and documentation for AWS is more plentiful. Explore using the console but don't do anything except play around. Assembling the Cloudformation/Terraform will teach you much much more about how the pieces fit together.
4. Now learn CI/CD, and you'll find yourself reaching for containers here because it's such a huge pain without them. Now you have a real motivation to learn them that isn't contrived. Once it "clicks" you'll understand why you might want to deploy other things with it.
6. Don't bother learning "devops the process" -- it's worthless, nobody agrees what it even is, and every company will do it differently anyway. You want your "knowledge" about the process to be as rich as the flavor in a La Croix. All these processes are at their best when everyone only vaguely knows what they are because any sort of strict adherence only makes you lose sight of your real goals.
7. Do not learn k8s until the very end. It is literally the final boss that combines all the other knowledge you acquire in your devops journey and you genuinely cannot understand the architecture, the tools, and decisions until you experience the pain points of not using it.
8. If you can swing a job as a junior then don't bother to learn how to run production systems, you will learn so much better and faster on the job than anywhere else. Have a "homelab" running some semi-production services to play around with and talk about in the interview but be ready that the big leagues will be a lot more involved. Once you are reasonably self-sufficient at your job and ready to move from maintainer to architect then look toward sre books.
This will get you ready to work at shops in the cloud. If you want to do on-prem work it's a different path.