DevOps roles are not only one of the hardest roles to fill, they're also one of the fastest-growing roles in demand. This is good news if you're looking to shift your career trajectory, but it also means that the definition of this role is still actively changing. So, before we dig into how to get a DevOps job, let's focus first on what DevOps is.
There are a lot of definition for DevOps, but at Stackery we like to compare DevOps to full-stack engineers. Where a traditional full-stack developer might have expertise in both backend and front-end application development, a DevOps engineer is full-process. They have expertise in the entire lifecycle of an application, from architecture to implementation to deployment and upkeep.
If you already have strong developer chops, you've probably already begun to tackle some of the application lifecycle duties of a DevOps engineer, including improving integration testing, automating and accelerating deployments, and monitoring system and application health and performance.
If some of these duties are unfamiliar to you, you'll want to start here. A great way to familiarize yourself, in a low-risk way, with these skills is to use them on a side project. For once, there's a great case for over-engineering. Let's say you maintain a blog. Even though it doesn't need integration testing, automated deployments, or production-grade application monitoring, it's a great playground to test and learn without jeopardizing your current role.
Pick a place to start, and then choose an open-source tool and get to work. For example, you could rebuild your blog to run all of the upstream framework tests each time you create a post. By setting up an automated testing workflow, you'll get hands-on experience with real-world tools and issues. Once you have that working well, move onto another tool or focus on another stage of the application lifecycle, like performance monitoring.
While nothing beats hands-on experience with real-world DevOps tools, another great set of skills to develop would be some of the theory and application of how and when to choose a tool for a problem.
One way to master DevOps theory is to learn from the best. Google recently open-sourced their book on scaling their production systems, written by front-line engineers, called Site Reliability Engineering. Even though your side project may not suffer from production-scale issues, you can still learn to identify them and see how the world's largest site has dealt with theirs.
If you're finding it difficult to make the leap directly into a DevOps role, try creating a "transition role" within your organization. Pick an area of focus and build your reputation as someone with expertise in this area. For example, maybe you become the go-to person for application performance bottlenecks. By picking a specialty, you can start to re-brand yourself as a pseudo-DevOps, even if you don't have the official title (which can be varied anyway: Site Reliability Engineer, DevOps Engineer, Systems Engineer, Automation Engineer... the list goes on).
Once you've established your reputation as someone doing DevOps work, even without the title, you may find it's much easier to reapply for the job that you want and make the leap.