The Switch from Dev to DevOps

What's the Difference?

Before even settling on the idea of switching careers, please, please, please...find out what you're getting yourself into. Haha! I was a true-blooded "Developer" for close to 10 years before I got "hacked?" to the world of DevOps. I initially thought, ok...DevOps is just Dev + the responsibilities of Ops. I was wrong!

Team Composition and Scope of Work

A Development team is usually composed of a Product Owner, Scrum Master, Development Manager, Business Analyst, Architects/Developers, Quality Engineers. They normally work on an MVP, feature work, fix bugs, and hand it over to the Ops team to build and deploy. Then, there might be a Problem Management team that handles maintenance of the software too. How the software gets delivered to production (in layman's terms -- the customer) is unknown to the software developer.

A DevOps team has a Product Owner, a Scrum Master, and the DevOps Engineers. The role of the DevOps Engineer encompasses that of the Business Analyst, Developer, Quality Engineer, and the Ops Team (as they are also responsible for creating the builds, handling the release documentation, deploying the builds and maintain the infrastructure to be live 24/7 too). A Platform DevOps team is different in a way that they do not really create software (sometimes they do), but rather, maintain a platform, and provide support to the Software DevOps team. You might think, how does a DevOps Engineer do the job of at least 4 people? The keyword is "automation". This is also how DevOps is different from just Ops. We know that our time is very essential (uso itong word na ito ngayon) and we have to automate close to 100% of our work, even service desk requests! So yes, we still "code", but our "code" is to develop the pipeline for builds and deployments (CI/CD), create automated tests, create builds and do deployments of our own infrastructure. We also create automation for monitoring the platform -- we develop code that constantly run "health checks" to send out alerts when there is a problem, so that it's the only time we need to open our laptops and check something manually. And that is why I love cloud...cloud has enabled us to eliminate some "pain points" of our job.

I won't go into more detail, but hopefully I've captured the essential differences of the two. A few weeks in to DevOps, and I was talking with my manager about my 9+ years of SQL experience and he told me...forget all about it! (That day was so memorable...I said goodbye to SQL, hahaha!). Once I realized the scope of work of a DevOps Engineer, I understood the level of expertise required to be successful in it, and had a sudden big respect to those who have been doing this for a long time.

Tech Background

A Developer is usually knowledgeable of a programming language of the software he/she is working on. C#, HTML, CSS, Java, Javascript, and many other options. DB knowledge (SQL, MySQL, Postgres, NoSQL) is also good for full-stack developers. Of course, tools like Postman, Fiddler, Swagger for debugging...and, SVN knowledge for code maintenance.

For a DevOps Engineer, knowledge of all those programming languages (not in depth) is also helpful, as most of the time, you're also helping feature teams figure out that the error is on their application, not on the infrastructure. On your own work...I've created a list further down on what are the "nice to have" technical knowledge for this role.

What does it require?

Technical Skills

This article is not about the specifics, but let me just list out a few things I know that can definitely help you on your job if you know it.

1. Cloud Knowledge - AWS / GCP / Azure are the big three. Take your pick.
2. CI/CD - Jenkins, Bamboo for pipeline deployment, GitLab.
3. Source Control - Subversion, Git, GitHub, BitBucket
4. Scripting - most of the time, you are writing procedural scripts that does very minor things in the Linux world, so shell/python/powershell knowledge is a must-have.
5. Ansible, Chef, Puppet - for configuration deployment and automating tasks.
6. Terraform - don't know a lot about this yet, but it's about IaC (Infrastructure as Code).
7. Testing and Debugging Tools - JUnit, Postman, Swagger, Gatling, Selenium, DevTools - basically to trigger requests and monitor them, Gremlin.
8. SumoLogic, Splunk, AppDynamics, Raygun, Catchpoint - dashboard, monitoring and alerts.
9. Kubernetes, Docker - container platform.
10. SonarQube, Aqua - security scanning tools.

I got overwhelmed at the start trying to learn all these, but very happy to be a part of a team that really cares about "newbies".

Domain Knowledge and "Confidence"

About 99% of the time, your work is checked by "you, yourself, and...yourself". You might need to ask for Peer Review for your code change, but you have 100% ownership of what you do. You do the code, test it out, create automated tests for next time, create a pipeline to deploy that, do a release, and handle bugs in case it comes back with issues! So yes, I used to hand over 80% tested code because I can rely on my fellow QA Engineer to ensure quality, but as a DevOps Engineer, I am more "careful" of what I put out there because I know that if it comes back, it will be back on my plate. Hahaha! Being confident of your work is essential as you also write out the details of your Release ticket so that business testers understand what the change is all about and how to test it. Of course, your documentation skills plays a role because your "test evidence" is what you can always go back to, to say that "hey, this was the test done on it and I'm sure it worked before, so it's broken now but not because of me!".

Project Management and Communication Skills

A lot of your work requires having to speak with multiple teams, aligning people, and ensuring everyone is available at multiple phases of a project. So yes, being organized and thorough is a big requirement of this role. You setup meetings, write a lot of emails, talk to other team's engineers and sometimes even with the PO's and Scrum Masters to explain stuff in a non-technical manner. I'm always challenged at my job to think like a non-technical person, especially when talking to management.

When I was a developer, I usually just talk to our Business Analyst to get requirements of what I'm doing, talk about it with other developers, and support the QA when I finally hand over my code. Then we usually do some demos of our work for POs or the business team. Being in DevOps is very different because I need to understand the team composition of the whole organization. There were times when what I did required some review from the Security team so I had to talk to them, something required a DNS change, so I had to talk to some network engineers, something needed to be tested by multiple feature teams, so I had to talk to them and explain what they will be testing. All these in different languages as I have to be mindful of how they understand the technology (at times, it's them explaining stuff to me in my language).

Calm under Pressure

Incident Management is part of your job, and you may be called in to an actual production issue. Normally, it requires you to listen about the "problem brief" from the incident manager, know what to look for or what the root cause may possibly be, fix it right then and there. All these in a very tight deadline as you are expected to bring the production environment to work again in the least amount of downtime, so not getting rattled is very important too.

Learning Mindset

Technology is always changing, and being in DevOps require that you are always up to speed with the latest in technology in terms of addressing security vulnerabilities as well. There's certainly a lot to learn in DevOps and it is not a boring job!

Automation is part of your job and in order to do this, you have to learn a lot of things about getting things to work together (integration) thru automation. I once developed a part of a pipeline where I learned about webhooks, Ansible, scripting, Sumo queries and triggering an API. I only worked on a part of it. If I worked on the whole thing, I might have to learn about three more technologies. Really exciting.

Summary

So yes, there's a lot more to write but I hope I already captured the general idea of developer vs. devops. These are stuff I wanted to write for the brave ones wanting to transition to DevOps. For me at least, I think DevOps is a more challenging job, as most of the time, stuff I'm working on is always "new" but it's really exciting to know about the whole picture and not just software. It's certainly scary and overwhelming in the first few months, but once you get the hang of it, it's very, very interesting.