Definitely 100% agree to not limiting yourself to a specific toolset or discipline. While the world is going crazy with Docker and containerization, that's far from the only news. Pick what interests you and start going down the learning path from there.
A few learning resources:
Tom Limoncelli has been writing about Systems Administration and DevOps for a lot of years now, and this book is a good DevOps read: the-cloud-book.com/.
highscalability.com/ has some great examples of high-level systems architectures regularly. Some of this is definitely not entry-level friendly, but can provide some good high-level examples of systems architectures out there.
There's also a classic SRE handbook (landing.google.com/sre/book.html), which is more for how DevOps is approached by Google, but there's some great high-level approaches to system thinking in there that are useful.
A couple of things that I would recommend from my personal experience in this space:
Make sure you have at least one "real" programming language under your belt. Unless you're in the large enterprise space (and even that's changing from what I anecdotally hear from friends in that world), you need to know how to both understand and write some production level code that outlasts throwaway bash scripts. Bash scripts are very useful, but there are so many services to interact with, that having a language with a good package ecosystem to interface with diverse web and data store services is much preferable to writing custom cURL and variable store functions in bash. Python and Node/Javascript are some DevOps favorites.
Be able to focus in on the small details and out to the big picture rapidly. This skill is also useful in coding, but from my last 1.5 years or so of real coding experience, I've noticed this context switching can be at a more leisurely pace when you're writing code. A DevOps example: if you need to change a header rule at the CDN layer of a stack, you need to be able to trace and capture how that header impacts the entire request stack, from browser -> CDN -> Load-balancer -> Web-Server... Being able to focus in on a particular part of that stack and then zoom back out to confirm it's working correctly and seeing the whole stack working as a snapshot is really useful. It's a practicable skill. Do it frequently :)
Be ready to read heavy documentation that's less "clear cut" than most coding libraries. Laravel, Python, and PostgreSQL are examples of software with beautiful and well written documentation. In the DevOps world, you still might be reading man pages, RFC's, and even AWS documentation that has more high-level architecture diagrams than individual stack samples. Be ready to get your hands dirty setting up local or test environments to validate your assumptions about how things work.
Triple check what you do to a production system. This should be good practice for everyone, but code reverts ideally happen quicker in case of failure or bugs (short of things like DB schema change rollbacks, etc.) Prod outages caused by infrastructure changes can be harder to diagnose, and more subtle in their effects and outcomes. So be careful what you push to Prod when you're tired on a Friday before the weekend but "want to get that one change out."
Being the magistress in the ivory tower who knows all things mystical or what seems mystical to non-SRE's is a bullshit aspiration to have. It was kind of fun and cool in the 90's when the Internet was a kinder, gentler, more innocent place, and servers under desks actually powered some important parts of the Internet. Putting up artificial barriers ultimately makes your life hell. I've worked with people, no joke 3x smarter than I am or genius level, and if they left a place, it took me 6-9 months to reverse engineer their cleverness while not being able to change much since I didn't know what would break, and then simplifying it so it ran in a more stable way that other people could troubleshoot/fix while I was on vacation. Capture your infrastructure to code, commit that code to version control, and have other people see if they can improve it.
Take "automate all the things" to heart as an unhealthy obsession. If you're pressed for time, the one-off script with no documentation in version control is better so you don't have to waste your time recreating a process from scratch. Storage is cheap and plentiful. Don't skimp on saving good ideas or working tools, even if "alpha" version or one-offs.
Apologies for the long post! Feel free to message me and I'm happy to chat more off-post if you have any other questions. Also, the above is a perspective of someone who's been doing systems work since pre-cloud server era. I've racked and stacked servers in quite a few places. Newer people in the space likely have better perspectives for starting out than I do, since out of the box tooling and spinning up of environments is significantly better today than it was when I started 13-14 years ago!
Wow. Thanks for your tips and resources, will definitely follow!
Make sure you have at least one "real" programming language under your belt.
I have been using Python for scripting since I was introduced to scripting, so yay to that!
Be able to focus in on the small details and out to the big picture rapidly. This skill is also useful in coding, but from my last 1.5 years or so of real coding experience, I've noticed this context switching can be at a more leisurely pace when you're writing code.
I think this is synonymous to making modular code, for
A change at one place, will automatically reflect the changes in the other places, and modules are hence defined that way.
Now since you are thinking about the modularity, you're technically viewing the big picture.
Conclusion: Worship modularity ?
Be ready to read heavy documentation
I started with docker docs, and they are just beautiful. 10/10 would read again.
Take "automate all the things" to heart as an unhealthy obsession.
I'm in my sophomore year, and if you check some of my previous posts, you'll see my obsession with automation in college. Yay again!
Currently, I'm reading the books suggested by other commenters on this post. I will let you know if I need any help. Thanks!
@sheyd got any recs?
Definitely 100% agree to not limiting yourself to a specific toolset or discipline. While the world is going crazy with Docker and containerization, that's far from the only news. Pick what interests you and start going down the learning path from there.
A few learning resources:
A couple of things that I would recommend from my personal experience in this space:
Apologies for the long post! Feel free to message me and I'm happy to chat more off-post if you have any other questions. Also, the above is a perspective of someone who's been doing systems work since pre-cloud server era. I've racked and stacked servers in quite a few places. Newer people in the space likely have better perspectives for starting out than I do, since out of the box tooling and spinning up of environments is significantly better today than it was when I started 13-14 years ago!
This could easily be an awesome post 😇
PS if you both follow on another you can literally message on dev.to/connect!
Wow. Thanks for your tips and resources, will definitely follow!
I have been using Python for scripting since I was introduced to scripting, so yay to that!
I think this is synonymous to making modular code, for
I started with docker docs, and they are just beautiful. 10/10 would read again.
I'm in my sophomore year, and if you check some of my previous posts, you'll see my obsession with automation in college. Yay again!
Currently, I'm reading the books suggested by other commenters on this post. I will let you know if I need any help. Thanks!
Like @jess is saying, this would be a great post in itself with just a small rewrite. =)
@sheyd 😉