DevOps Transition December 29th, 2019
In the Spring of 2019 I had the opportunity to transition into a challenging role on the DevOps team at When I Work. What is DevOps? Well, it’s really a practice and not a title even though there are no shortage of “DevOps Engineer” job titles in our industry. From my view, the purpose of the role is to provide systems and guidance that will allow our engineering team to deliver our product with as little friction as possible.
This new role continues to be an awesome challenge, and was just what I needed to inject some more excitement back into my day-to-day work. In my former role as a Full Stack Engineer on the Growth Team within the same company, I was focused on product. Mostly through pricing, packaging, introducing new features, a/b testing, and data analysis.
While I had managed web servers early in my career, that experience was a far cry from the needs of today. So I needed to study up on a lot of new topics in a hurry, namely cloud computing, container orchestration, build automation, infrastructure as code, and monitoring.
My own personal bootcamp
I treated this process as if I was going back to school. I laid out a plan of which specific technologies I wanted to learn, and how much of my personal time I was going to dedicate to it every week. I didn’t need to go too deep on all of them at first, I just needed some basic competancy to feel comfortable in the new landscape I found myself in.
My plan of attack included Gitlab CI, Kubernetes, Terraform, Prometheus, Grafana, and misc bits of AWS. The main source of information first came from Udemy and then I switched to Linux Academy for video courses. I also used kindle books to supplement the video courses, as sometimes just having an alternate voice explaining the same topic can be a big help to fully make sense of things.
One criticism I have for these sources of information is that since everything tends to be in an introductory context, the assumption is always that you’re just hacking around on your personal computer or cloud computing account, and there is rarely any discussion of how to set things up for a team, no mention of security concerns, no mention of how the solution looks different at high scale, etc.
It should go without saying that vendor documentation is always a good option for learning materials. Some projects have better doc than others.
Putting it into practice
Video courses and books are great for learning things in isolation, but I really needed to put it all together in order to learn by doing (and struggling). I have been able to do this two different ways. One is that I have a few side projects that I continuously iterate on when I learn some new tricks, which helps me to learn by doing and allows me the freedom to do things however I want to try them. The other is of course my day job.
After completing lots of smaller projects on my new team for a few months, I was assigned a substantial responsibility of establishing a new pattern for our kubernetes clusters going forward, with the pilot project being a rebuild of our internal build tools cluster which has numerous system level services as well as apps that support the daily operations of the engineering team. I have great mentorship for this project, I am by no means running the show myself. I am getting an opportunity to practice what I’ve learned and run into all kinds of real-world road blocks that don’t normally show up in a carefully crafted online course.
Overall I’m really happy with my career move, and enjoy the challenge of shifting my focus to solving different types of problems. Most of all, I feel fortunate to have an employer who is willing to invest in me and allow me to gain new experiences on the job.