Personal Bias Disclosure: I started in the pre-cloud area, and have a tendency to over-complicate things, so please comment with contrary thoughts and opinions!
DevOps and Site Reliability Engineering (while distinct disciplines) essentially makes, maintains, and ensures the bedrock on which software runs (the bedrock being made of software itself). It ensures that bedrock is consistent, stable, and performant.
Given the state of infrastructure today, DevOps can mean anything from running servers in a data center or ensuring configurations are scaleable for software deployed to Heroku or even AWS Lambda/Google Functions. It can be very confusing to navigate all these options at first. The upside is there are so many different ways to enter the land of DevOps in 2018.
Some signs that might point to an interest in DevOps:
- Do you love technology but don't relish maintaining mountains of code, or digging through infinite libraries for one function or end-state?
- Are you usually curious about the flow of data through disparate systems rather than digging into all the low-level details of a single software's API?
- Do you enjoy complicated de-bugging processes and are intrigued by hard problems that usually aren't confined to an application's stack trace?
- Is Lorum ipsum as satisfying to see on a web-page as the Wikipedia article on Beyonce? Is it the thrill of the HTTP 200 status code, rather than what's actually on the page that keeps you engaged?
- Do you hate repeat work and often write scripts, .dotfiles, or anything else to automate the hell out of your day to day work flow?
If any of the above or something similar is true, DevOps might be the realm you've been searching for all your life!
2018 is truly a glorious era in which you can enter DevOps for very low cost.
Want to try DevOps using Serverless? Use the Serverless Framework to spin-up a simple application and play around with the AWS Cloudformation template and figure out how everything plays together.
Docker, containerization, CDN's, load-balancers... the list goes on and on. Document it and break it intentionally to see how it holds up.
One key thing when you start out is to not limit yourself to one particular toolset. The entire technology ecosystem is going crazy about containerization. It's very cool and useful, but there's a whole world outside of that. Pick something that intrigues you and play around with it.
There are many others in this space as well, follow the people who resonate with you the most!
- Tom Limoncelli has been writing about Systems Administration and DevOps for a lot of years now, and The Cloud Book he co-authored is a good DevOps read.
- High Scalability has some great examples of high-level systems architectures regularly. Some of this is definitely not newcomer friendly, but can provide some good high-level examples of systems architectures out there.
- There's also the classic SRE handbook, which is about how DevOps is approached by Google, but there's some great high-level approaches to system thinking in there that are useful.
- 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, 3x smarter than I am/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.
Thanks for taking the time to read this, and if you have comments, I'll respond as soon as I can!