What is DevOps?

What is DevOps? There are a lot of articles talked about DevOps and also a lot of different concepts given about it.

This article of mine will contribute to you some perspectives on DevOps, you can reflect and experience yourself on your path to becoming DevOps.

The past before DevOps

In the old days, most software companies had a team of engineers in charge of product development (i.e. writing code). Besides, this group will also implement it on the system.

What is the system here? Before, there was no cloud (AWS, Azure, GCP, …) so they had to manually set up server rooms, racks, servers, backup power, fire protection, …

Later, they split into two separate teams, a Developer (Devs) team writing the software and an Operations (Ops) team operating the hardware system.

Normally, the Devs team will write the software on their computers and then send it to the Ops team. The Ops team will rely on that to figure out how to deploy and run that application on the system. And now, a wall begins to form between the two teams.

Before, there weren’t so many automation tools, the Ops team had to install everything manually. And you know, humans make mistakes all the time.

The release and deployment of software to the system starts to have problems, more errors and takes more time. Besides, because of the separation (by the wall) between the two teams, the installation and operation of the system gradually becomes difficult, gradually the servers that the Ops team installs will become a snowflake servers (i.e. servers lack operational documentation, no one understands it 100%, and any change could destroy it for unknown reasons).

As time goes on, the Ops team will tire of implementing new software. Each release of a new version will become longer, from a few days to a few weeks to even a few months. And this, as a result, product development becomes slow and inefficient.

Blame between Devs team and Ops team

In the face of slow product development, of course someone has to take the blame.

And when this happens, conflicts happen and especially when the team is getting bigger and bigger, the company is getting bigger and bigger.

The Devs team will blame the Ops team and say “everything works fine on their computer”.

Meanwhile, the Ops team will say that “the Devs team is not fully prepared and tested on the server environment” making it impossible for them to deploy it correctly.

All of the above comes from the “wall” separating the two teams.

The Devs team do not understand what the system has and how to “code” it to work properly on the server.

The Ops team doesn’t understand how the software is being written and how it is being implemented by the Devs team exactly, hence better preparation.

Cloud and the beginning of DevOps

Today, under the development of cloud services, everything in the “game” has changed.

Instead of having to manage datacenters with a bunch of complicated things, many companies have chosen to move their systems to cloud services like AWS, Azure, and GCP.

Now, they – companies no longer have to worry about physical systems, they don’t need to care about servers, racks, electricity or internet.

Instead, the Ops team spends more time working with automation tools like Chef, Puppet, Terraform, Docker, and Kubernetes. The sysadmins are now writing more code.

They started to understand each other better and blame each other less, which is when DevOps was born.

What is DevOps?

I wrote a lot above so what is DevOps? There are many definitions you can find on the internet.

You can see a lot of companies hiring DevOps engineer positions right? Unfortunately, that’s not entirely true.

Even now, I’m a “DevOps engineer” but I personally feel the name is not 100% accurate.

DevOps is not the name of a team or a specific position in the company. There is also the definition that DevOps is a culture, a set of processes, ideas and tools.

But from the past before DevOps took shape, I can tell you that.

DevOps is a collection of everything that aims to make software development and delivery more efficient.

Efficiency here is both in terms of time and quality, that is: faster, more stable and safer.

And this will lead to the next story.

Who can become a “DevOps engineer”?

Although I gave my own concept of DevOps above, it is still acceptable to be called a “DevOps engineer” to talk about it.

So who can become a DevOps engineer?

There are many courses on the internet that teach you how to use automation tools and through that you can get on the path of a DevOps engineer.

As I said above, “DevOps is a collection of everything“, which means anyone can become a DevOps engineer, as long as they can make software development and release efficient.

A developer can become a DevOps engineer, a sysadmin can also, even a tester can become a DevOps engineer, this is unlimited.

How to become a “DevOps engineer”?

Next, to the second problem. How to become a DevOps engineer?

The second invisible wall

In the past, I believed that just following a DevOps roadmap was enough, but I was wrong and I believe many people are wrong like me.

I started out as a network engineer, progressed to a sysadmin and now a DevOps engineer.

And I have worked through many different systems, perhaps hundreds, from small to large.

I see how important it is to have a network and server knowledge. And how important it is to have a Linux system as a sysadmin. So when I started as a DevOps engineer, I kept that perspective.

But as time went on, I was wrong and found myself flawed. During my work, I come across tasks related to fixing software bugs. Then I need to find a solution and suggest it to the Devs team, even though they haven’t discovered it yet.

I also come across tasks related to application testing, such as Cypress for E2E testing. And I also started learning about testing so that I can support the team faster. Something that should have belonged to the Tester team.

The two examples above show you that, even if it is the knowledge/work of another group. As long as it can make things more efficient, a DevOps engineer also needs to be willing to learn and join other teams. And this is the key point.

Many courses as well as mentors often draw a line for the so-called “DevOps engineer”. But in so doing they have built a second invisible wall as in the past between teams.

What really needs to be done

So how can one become a DevOps engineer in the end? It’s very simple, learn and participate all you can or your teams need.

I emphasize teams here which means that it not only ties you to the team you are directly dependent on, but all the teams involved in software development.

At the same time, it is also important to note that, just because you join the team, it does not mean that the responsibilities of the teams will become ambiguous.

For example, the Devs team will still be primarily responsible for writing the software. When you join them, if you see something wrong based on your inquiry. Sit down with them and propose and discuss the problem. Not that you will do it on their behalf without going through the Devs team, that is not true.

Roadmap is also a good one for beginners, they will have a “skeleton” to cling to.

However, to be a true DevOps engineer, you should not limit yourself. Instead, remember the goal of DevOps. It’s to make things more efficient.

Conclusion

This article represents my personal views, as someone who is currently working in DevOps. I do not represent any other person or organization.

So read it as a reference and have an “industry person’s” perspective. Expand your mind by learning something new every day, instead of locking it up in one title.