Based on my comments in Priyansh Jain question about starting in DevOps, and encouragement from Practical Dev's own Jess Lee, here are a few thoughts on entering DevOps in 2018.
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!
What is DevOps/SRE?
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!
Pick A Spot and Dive In!
2018 is truly a glorious era in which you can enter DevOps for very low cost.
Curious how servers work? Digital Ocean and Linode provide $5/month cloud servers with various operating systems you can play around with.
Want to bring up an actual hardware server? Try your hand with a Raspberry Pi and install Raspbian on it.
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.
A Few Good DevOps/SRE Folks I Like to Follow
There are many others in this space as well, follow the people who resonate with you the most!
Some Light-to-Heavy Reading
- 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.
Grab Bag of Biased Advice from My Time in DevOps
- 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, Node.js/Javascript, and Go 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, 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!
Top comments (2)
Thanks for the post ! So true about the documentation and the checks before do a change in production. I have 6 years of programming and now 3 managing production on AWS and you related very well the real situations.
I have to say that it's a different world from developer to interact with production, one bad decision, and the uptime go off.
Thanks for the twitters suggest and book's, I think the key is every day add something different, even a new word.
This post help's me to add new sources of information in my starter career to be a devops.
Thanks !
"...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...." Amen.