Transition From Developer to DevOps

My professional journey has been a roller coaster ride and in my almost 10 years of experience in the industry, I have donned multiple hats. I started as a trainee then a software engineer, then a co-founder/CTO/consultant. All this while I was developing applications but suddenly I found myself in another country with a completely different role DevOps Engineer. Initially, I hated it big time and now when I look back it was more of my own ignorance than anything else.

Few reasons I did not appreciate my role back then:

1. I thought being a developer was cool and that’s where all the magic happens.
2. I thought it was very uninteresting, but now I realize I found it way too difficult to deal with given my minimal experience with the admin related roles and infrastructure.
3. I found the whole idea way too difficult and I was trying to find development-related work even in the DevOps.

But what gave me hope was my very strong consulting experience with Atlassian Ecosystem and setting up Engineering practices at my previous roles(which was the core reason why I got hired for the DevOps role in the first place). Gradually I started buying the idea of Continous Integration, Continuous Deployment and Continous Delivery concepts. These two specific books were very critical for me to understand the whole concept of Development Operations.

1. Continuous Delivery
2. The Phoenix Project

It took me a couple of years to actually understand how critical this role can be for any organization and how my work can streamline and simplify the complete development and deployment process. This is when I started appreciating my development experience and the whole IAAC concept where I still could write the code but with a completely different perspective. Fortunately, I worked with engineers who were vastly from very strong sys-admin/build engineering backgrounds and the idea of complementing each other than competing with each other worked out really well. This role opened up a completely different horizon of software development experience like System Administration, Networking Concepts, Hybrid Infrastructure, Container Management and Security which I only knew at a superficial level before. What also will work out well if you are making a transition from a development role is that most of the time you would know what will be the expectations of the development team you are working alongside.

I actually love what I am doing right now and take every measure to improve the developer experience at my workplace as they are my primary customers. Spending the last few years as a DevOps engineer has given me an excellent opportunity to learn the various systems in detail.

So coming back to the various skills that are required to be a better DevOps Engineer:

1. Humility: This is very important for primarily two reasons, if you are coming from a development background like me you will need to learn and unlearn many things from a systems perspective. You will end up spending more time on the terminal than you would have done before as a developer. If you are coming from a sys-admin background you will need to write a lot of infrastructure and configuration management related code and quickly it can become overwhelming and at times you may need to write a lot of python and groovy related scripts. And there are more scripting languages people use at different places. So, it’s very important that you respect both the worlds and ready to learn/adapt.
2. Design: Designing is very important and now more and more companies are moving to the cloud and it has become extremely important than ever to design reliable and cost-effective infrastructure solutions.
3. System Administration: No matter how well you design and deploy your applications you will need to troubleshoot at times and that’s when administration experience is very important.
4. Git: What I have realized is much of the time DevOps people are the goto persons to reach out for git related issues and workflow designs. Avoid using GUI tools and get expertise with command-line git client. Struggle to remember those long log related commands → Use aliases ;)
5. Build Tools: No matter what, you will be quite often pulled up in build-related issues and it’s very important to understand build tools like Ant, Maven, Make, Gradle and others. I, in fact, worked on a project recently where most of the build scripts were written in Perl almost 10-15years ago and my previous programming experience was very handy including my knowledge of the build tools. Understanding of the build tool is very important in terms of defining and designing a Continous Integration pipeline from scratch. Good luck if you are migrating a large legacy project and don’t know much about the build tools and how complex dependency resolution can become.
6. Product Owner: Think like a product owner. This is very important if you are looking to understand how development and operations work together. Talk to your developers regularly and understand the pain point and get continuous feedback on the existing infrastructure whether it’s a development, staging or production environment. The place where I work we have set up a model where every DevOps member work as a primary and secondary interface to multiple teams so that we ensure that Development and Operations are working together and helping each other to improve process, tools and infrastructure. This also ensures we have a cross-functional DevOps team which results in better collaboration/communication with the product development teams.
7. Tests: Write tests. Period!! I still have to start practicing TDD but I make sure I write tests and frameworks like ChefInspec, unittest and testing in terraform is very helpful. You can also define your testing strategies if your configuration management is largely written in ansible(choosing what to use and where is altogether a separate topic). There are frameworks like molecule and turf for ansible which I haven’t explored personally. This ensures that we consider our source code similar to an application source code with quality always improving.
8. Tools: The industry is overflowing with DevOps tools right now. There are new tools and new frameworks getting introduced every other day and it’s very important to understand and identify what tools to choose for what purpose. I personally look for community support if I am going for something open-sourced like Jenkins as a CI server, grafana-prometheus for monitoring and analytics, and the experience with support for paid tools, for example, tools from Jfrog and cloud-providers.

Here is one article I recently came across called DevOps roadmap. You will find almost everything that you may need to learn to be an excellent DevOps engineer. But the key aspect is “DevOps is more of a culture” and to embrace it you will need to adapt to that culture yourself first and that can be daunting at times. Since you will be at the forefront of advocating the DevOps culture and the application of the right engineering practices, it’s important to not cut corners and “practice what you are going to preach”!!