Coming to DevOps? Learn how to code

Let's talk about DevOps.

DevOps is, of course, about culture.

But if you like it or not, DevOps is also used to describe a profession.

Job descriptions often include skills like system administration, programming, using cloud native technologies and infrastructure improvements and automation.

Another profession that requires a similar skill set is called site-reliability engineer.

You might be very opinionated about what devops or site reliability engineer does, especially if you classify yourself as one of them. I certainly do have my own opinion about it, based on my experience of working in the field. But opinions aside, there is one activity performed by most of the people with this specialisation: writing code.

DevOps consulting: DevOps is a cultural and technological journey. We'll be thrilled to be your guides on any part of this journey. About consulting

Let's step back a little.

There are two ways to enter the DevOps field.

First one is when a developer gets interested in the infrastructure.

Instead of writing the application code, this developer learns a lot about things like networking, system administration, security, various server tools and so on.

On top of that go modern infrastructure management tools and concepts, like, let's say, configuration management systems, service discovery, container orchestration and many others, that were created by other developers, who got interested in the field a bit earlier.

After learning all of this, developer still remains a developer, but might be writing in CV something like a "DevOps Engineer" or "Infrastructure Engineer" or "Site Reliability Engineer".

And, of course, this developer from now on develops not the applications, but the infrastructure for this applications.

The second way to enter the so called DevOps field is when the system administrator or the operations person gets interested in levelling up the tools and practices she or he uses to manage the infrastructure.

Instead of doing everything by hand, a configuration management system might be learned.

Instead of working with bare metal servers, virtualisation or even containers could be adopted.

At some point, this system administrator starts writing Terraform or CloudFormation templates to provision AWS resources.

This is the moment sys. admin can safely update the CV to the aforementioned DevOps or SRE title - and, quite often, update the salary expectations upwards.

This two ways to enter the modern infrastructure world are very different.

Final result, though, is the same: both groups of people start developing the infrastructure, instead of merely configuring it.

Different background gives you two different perspectives on how the job should be done.

There is a lot to learn from regardless if you are coming from development or from the operations.

In this article, I'd like to talk about one critical skill that people coming from systems administration and operations must acquire.

If you want to see which skills and topics a developer has to learn, leave a comment below.

This critical skill, as you might have guessed by now, is programming.

There are many reasons why you, as a DevOps engineer coming from operations should learn how to code.

Reason 1: You can work better with developers

This one is partially about culture, because if you know what being a developer feels like, then you and your company developers can work better together.

But also, if you know how to code, you can actually help application developers to adjust the code, or work with them together to make it work best with the infrastructure.

You can also support them with proper tooling, because you know what kind of tools they need, which brings me to...

Reason 2: You can develop your own infrastructure tools

Sometimes your job might be about configuring existing tools. But every now and then you can't just configure something - you need to come up with your own system and software to solve the problem.

Being able to code in Python or Ruby will allow you to quickly create small supporting utilities, and at some point one of the might grow to a complete internal infrastructure product.

Reason 3: You can improve or fix the existing tools

If you can read the code, then you will also understand how your tools work on a much deeper level, down to the, of course, particular code line involved in this or that task.

Knowing the details of how every tool you are using works allows you to fix it, improve it or, at least, come up with a proper workaround.

On the contrary, without this knowledge, all you can do is to submit a support ticket and hope that someone replies to you on time.

This troubleshoot and fixing skills, enabled by knowing how to code, are especially useful in ever-changing and evolving cloud native landscape.

Reason 4: Infrastructure as Code is about code.

You will quickly learn, that the best practice these days is to do infrastructure as code. And if you do anything as code, then, naturally, you need to learn how to code.

Your infrastructure becomes a software product, and this product needs to be developed, tested, deployed and maintained the same way as any other application.

Infrastructure as Code is, of course, not only about writing code, but also about all the best practices for packaging, releasing and deploying this code - all of this you should also learn to really excel in the field.

The one skill I think is essential for anyone working with the infrastructure in upcoming years, I would say its programming.

If I would have to recommend particular programming languages, I would say: Start with Python or Ruby.

Both of them are very friendly to beginners and they are also a joy to write code in.

In the future, it will also help to be able to read Java and Go and JavaScript, but of course you don't need to become an expert in every language.

You don't need to become an expert developer, but being able to read and write the code in at least one programming language is a must.

And you should also learn all the surrounding terminology and best practices, like writing tests and setting up a CI/CD pipeline for your code.

Even if you don't consider yourself a developer, believe me, you are.

Here's the same article in video form, so you can listen to it on the go: