Resources for Getting into DevOps?

I was very recently introduced to using Docker and Docker Swarm, and I got interested in cluster management and horizontal scaling. How the nodes balance the load was fascinating to me. Can anyone provide some resources like books or online courses to seriously get into DevOps?

Comments

[Kyle Galbraith]

DevOps in my mind is much more than just the tools. I would be careful in focusing only on the tooling as there is principles and practices you should know to be successful in the DevOps space. Therefore, my suggestions for resources are actually two books.

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

This book does a great job of laying out the foundations that back DevOps and the principles successful teams buy into in order to deliver code reliably.

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Full disclosure I have not finished this book. However, this one focuses on the organizational aspects of DevOps and why it benefits businesses to use the methodologies.

[Priyansh Jain]

I'd like to have a look at your aws course as well!

[Kyle Galbraith]

Absolutely, feel free to pick up a package or sign up to get a sample chapter.

[Priyansh Jain]

Thanks a lot man! Will definitely go through

[JeffD]

I can just suggest you the awesome-lists at Github, the awesome-docker page list some ressources like developpers, books, blogs.

[Vinay Hegde]

Even I recently learned that it's more of a mindset than a role although in practice, most (if not all) organizations tend to pitch it as one.

Call it an attempt to evolve the industry, glamorize the traditional SysAdmin (who wouldn't be awed if you told them you were a DevOps | SRE as compared to the former :D ) or lack of awareness, this will perpetually be hotly debated by everyone part of the software ecosystem.

Anyway, adding to the insightful comments here - I suggest a few resources I found useful

1. The DevOps RoadMap (scroll to the bottom)

2. Learn Anything - DevOps

3. Zeef - Link1 & Zeef - Link2

Hope these help, cheers!

[Tomas Forsman]

The RoadMaps are awesome and a great starting point for anyone wondering where to go next in their dev journey.

[Vinay Hegde]

Glad to know it helped you out tomas, please feel free to share

[Mike Vanbuskirk]

As @kylegalbraith mentioned, try to avoid the trap of thinking about DevOps in terms of a specific tool or piece of software.

While it is true there are several tools or systems one would expect a DevOps practitioner to have experience with, it shouldn't wholly define the methodology.

"The DevOps Handbook" is a good place to start, as well as the precursor "The Phoenix Project".

If you want to take a rigorous, academic dive into the ideas behind some of the architecture, I recommend: Distributed Systems

I'll give you a short list of what I'd look for in a Senior DevOps candidate right now(this is list is by no means exhaustive):

• Experience in large-scale, distributed ops environments
• Comfortable with at least one interpreted scripting language
• Experience designing/deploying fault-tolerant HA systems.]
• Extremely comfortable with interacting with other teams and groups, including non-technical stakeholders and senior leadership
• Experience deploying in at least one cloud provider

Note one item is in bold, and it's not technical.

It is absolutely imperative that as a DevOps engineer you are comfortable being involved early and often in discussions around system and software design. Knowing your customers, their pain points, and their requirements, are key to being successful. Also being able to advocate for good ops practices, particularly to non-technical stakeholders, as well as senior leadership, is equally important.

[David J Eddy]

"try to avoid the trap of thinking about DevOps in terms of a specific tool or piece of software." Really wish this was the mindset of the general populace. Sadly it seems an automated two step build process is called a 'devops pipeline'. Uggg.

[Priyansh Jain]

Will follow your words. I'd like to be in touch, as I'm at the start of my career. If you're willing, send an email to this ID

[David J Eddy]

Email sent :).

[Josh Brown]

The Shipping Docker course (courses.serversforhackers.com/ship...) helped me to gain a pretty solid understanding of Docker. I'm currently learning about Kubernetes using courses from such sites as Udemy.

[Jess Lee]

@sheyd got any recs?

[Sena Heydari]

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:

1. 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/.
2. 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.
3. Charity Majors (twitter.com/mipsytipsy), Kelsey Hightower (twitter.com/kelseyhightower), and Alice Goldfuss (twitter.com/alicegoldfuss) are three great leaders in the DevOps space I follow, but there are many others.
4. 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:

1. 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.
2. 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 :)
3. 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.
4. 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."
5. 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.
6. 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!

[Priyansh Jain]

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!

[Tomas Forsman]

Like @jess is saying, this would be a great post in itself with just a small rewrite. =)

[Jess Lee]

@sheyd 😉

[Jess Lee]

This could easily be an awesome post 😇
PS if you both follow on another you can literally message on dev.to/connect!