So you wanna be a DevOp, eh?
Maybe you're early in your career as a software engineer. Maybe you've been around the block a few times, but you've seen all this DevOps stuff and wanted to add it to your résumé for your next career step. There's always a big question looming: "How do I ever get started with this?"
Not gonna lie to you - you're embarking on a big change. If you learned the traditional Way first, DevOps principles will challenge almost every assumption you make in the practice of creating and shipping software! (Personally, I found this to be liberating; it's good to know that there are different ways to do something, and there are costs & benefits to each.)
This post, which closes out my series "Let's become a DevOps... or Something", is a quick-ref guide for you as you start your journey - you'll find some resources that you can draw on as well as some tips and tricks that can help you navigate as you become a DevOps Jedi.
NOTE: It's critical to realize up front that there's no destination on this journey. If you think getting some certification will make you an "expert DevOps" or something, you're mistaken and it's vital to your success that you disconnect from that idea ASAP! These are tools. They are ONLY tools - nothing more. I want you to know how to use them, but ultimately it's up to you to go and build.
There's a concept in Japanese Martial Arts (particularly Aikido) called Shu-Ha-Ri that describes the stages of learning a skill:
- Shu is when you follow the rule. Learn to do it exactly as instructed.
- Ha is when you begin to bend the rule. As you've gained experience you start to understand when the rigidly-followed rule isn't as effective and you can do better by "fudging" the "proper form" a bit.
- Ri is when you begin to write the rules yourself. As you progress far enough, your learning shifts from being mostly "learn from others around you" to "learning from your own practice and experimentation".
Applying Shu-ha-ri to the DevOps world, you'll find it alluring at first to adhere to the "official" DevOps way. But just as we are breaking from traditional practices to implement DevOps, you'll ultimately find that you have to bend -- and break -- some of those "DevOps" rules in certain situations. And that's OK... what matters is that you know when to do it and when not to!
Ok, that's enough of an intro - Let's dig in and learn how to DevOps!
Step 1: Feed your 🧠
In your "Shu" phase, you'll find the following books extremely helpful to get started. I recommend starting with the top of this list and reading your way down it - generally speaking, the books are in the order you'd probably want to encounter them if you're coming into this concept cold.
(And yes, I earn a small commission every time you use one of these links to purchase! Support a fellow DevOps nerd who's posting some free content to help you grow your skills!)
The Phoenix Project, by Gene Kim, et al. - Quite possibly the best way to fundamentally grok what DevOps is all about, The Phoenix Project is a work of fiction that illustrates DevOps principles and shows how they work. If you ever read Goldratt's The Goal about just-in-time manufacturing, you can think of Phoenix as "The Goal" for Software Engineering.
The Unicorn Project, by Gene Kim - Several years later after the wild success of The Phoenix Project, Kim wrote the same general story, but from a different player's perspective. Whereas Phoenix follows an executive, Unicorn is following a lead engineer. It's a fascinating peek into the mind of the software engineer and seeing the same story from two perspectives is a great way to expand your own viewpoint... learn empathy by practicing it in a fictional sense! This is great for folks who might be in a neighboring professional space like DevRel because it spends so much time with the Engineer persona.
Making Work Visible, by Dominica DeGrandis - Particularly if you're living in the space where Agile practices are being introduced alongside your DevOps transformation, you'll find this to be a great guide for finding unplanned work in your environment, which is a "silent killer" of organizations.
Thinking in Systems, by Donella Meadows - One of the hardest skills you'll have to learn in your DevOps journey is Systems Thinking - when you can mentally hold enough of your organization in your head to anticipate how a small process change will affect the greater organization.
Team Topologies, by Matthew Skelton & Manuel Pais - If your organization was optimized for the old way of working, DevOps is going to disrupt your organizational structure just as much as it will disrupt your process & procedure! In fact, I think you might find that the two are inextricably linked by a guy named Mel Conway... but no spoilers, go pick this one up to learn how to think differently about the teams in your organization and re-optimize your people for success.
Sooner Safer Happier, by Jonathan Smart - This book will help you understand the why as well as the how for adoption of more agile working practices. Full of research results and stats that tell you why it's important to make the shift, Sooner Safer Happier will help you form the Executive Pitch for making such large-scale changes to your organization's working practices.
I heartily recommend these books - each of them lives on my own bookshelf and has helped me in my understanding of better software delivery!
Also, if you've never watched it, this video from Velocity 2009 is considered by many to be the beginning of DevOps. Take the time to watch it and listen carefully to how the two perspectives merge and align!
Step 2: Tool Immersion
The next step in your journey is to figure out how to start doing some DevOps. You can read every book ever written and while I don't doubt you'll learn some things, part of a DevOps transformation is establishing credibility with the other people you're going to be transforming with... and we've all met those folks who read all the right books but couldn't execute, haven't we?
So - what are some valuable technical skills you can work on to help you gain that credibility?
Source Control
Start. Using. Git.
I'm not going to be picky about which company's offering - GitHub, GitLab, BitBucket, Diversion, and many more... everybody's got their flavor and they all have pros & cons but under the hood, it's all git. Make it a habit to version control everything you write; you can make the repo private if it's something you don't want to share, but making the tool use into muscle memory is a critical step to your growth!
Containers
If you're a front-end dev who's looking to shift into DevOps, hopefully you've been far enough in your journey to realize that you're going to have to go deeper in the stack than you've gone before. Indeed - DevOps likely gave rise to the concept of the "Full-stack engineer": someone who's as comfortable working on the website's stylesheet as they are on building docker containers and writing helm charts for Kubernetes pods.
And if you're not a front-end dev... you're likely already somewhat acquainted with containers. For DevOps, containers are a key concept and you will need to go sharpen those skills. As many backend engineers who came from more of a traditional infrastructure background haven't had a deep meaningful relationship with git yet, managing your container configs in git would be a great way to work on those version control muscles with something you're already used to using.
Containerizing your code
If you're a developer, you've likely got some code you've written lying around (hopefully in Git after the last couple paragraphs ☺️ !). Your next step should be to learn to deploy it in a container on your local machine. Docker has great tools to help you experiment locally and (at least for testing purposes) it's easy to run on your development machine. Once you've figured out how to make your app run in a container, you can make that available by sharing the dockerfile right there in your source control.
Side note, stay connected with The Adventures of Blink and you'll see an exploration of this soon!
Using tools in containers for fun & profit
The next step on your container journey is to use your newfound knowledge to run some of the other DevOps tools you'd like to experiment with. Nobody likes running a bunch of different tools on their system - you run into port conflicts, configurations that might collide with each other, and general clutter that makes it hard to operate. But... if you're running each tool in its own container, you have the ability to have lots of tools running in their own independent spaces! You can continue improving your Docker understanding by making the various containers interoperate, but you do it in a space that's easy to clean up afterward.
Want a Jenkins workspace to play with CI/CD pipelines? Run it in a container and it's one command to turn it off & on. Want to work on your software supply chain skills with Artifactory or Nexus? Spin it up and don't worry - it will be easy to tear down if you change your mind later.
Step 3: Knowing your surroundings
Technical skills are critical, for sure - but DevOps also requires some strategic thinking and "softer" skills in order to be successful. You see, DevOps focuses heavily on collaboration... and who are you collaborating with?
Everybody.
Other devs. Testers. Project Management. Infrastructure/Platform Teams. Marketing. Security. Sales. Legal. I mean everybody.
It's important for you, as an individual in this space, to think about your surroundings.
How does your organization use DevOps principles already? Are they brand-new to it and trying to learn? Are they seasoned professionals and you're trying to fit in with their implementation?
Is your organization resistant to change or do they embrace "new"?
What are your personal career goals? Do you like to be part of blazing the trail or being part of the well-oiled machine?
These concerns will affect how you approach DevOps thinking. For example, if your organization is more resistant to change, it can be helpful to take on the persona of a "benevolent pirate" - someone who's going to break rules but uphold the common good. If the company already has a mature DevOps mindset and you're just skilling up to take on a new role, you need a little less pirate and a little more willingness to accept the company's perspective on what works for them. Every combination of
(DevOps practitioner) + (Company culture) + (Shared goals)
is going to need a tailored approach - it's important to customize your thinking to the situation!
Wrapping Up
I want you to know I'm excited for you - embarking on a DevOps journey is a huge exciting step and while there are lots of dangers along the way, it is one of the coolest things I ever got to do. I hope that you find it as rewarding as I do 🎖️ and that your career takes off! 🚀
My last bit of advice for the road: Get used to being uncomfortable! Things are going to feel complex, or contentious, or scary. I have learned that when I feel like that, I'm GROWING. Keep up the good work!
Top comments (0)