When dev goes DevOps

The DevOps culture has grown so much that it is rare to come across a company without it. I was thrown into this adventure park without realizing it. But what exactly is DevOps? And why is everyone talking about it so much?

DevOps is not job

This is the answer you will get instantly if you ask the question “are you a devOps?” to anyone in the DevOps movement.

Oh yes, be careful, it’s not a joke, they take this matter very seriously. Many of them clicked on this article just to comment that DevOps is not a job. DevOps is not a job and they will remind you every 30 seconds.

It’s funny because almost everyone is abusing the word and defining themselves as DevOps out of convenience. Recruiters are looking for the DevOps job too. We’re bad people. But really, who cares ?

But if DevOps is not a job, what is it then? To really understand what I’m talking about, you need to know where it comes from.

It’s June 2009 and a presentation about cooperation between developers and sysadmins in California is making a lot of noise. It’s making a lot of noise because it shows the reality of two worlds constantly pointing fingers at each other.

Sysadmins screaming at developers because of bad code unable to run on perfect servers. Developers screaming at sysadmins because of bad servers unable to run perfect code.

At the same time, in Belgium, Patrick Debois is watching this conference via the Internet. He loves it. Inspired by all this he decides to create a conference. The famous DevOpsDays were born.

At the same time, the term DevOps became the standard.

What is DevOps?

DevOps is a culture, a mindset, which aims to make the work between the different teams in the production and deployment cycle of a product easy and transparent. A real cooperation between teams to implement deployment pipeline using automation tools. From development to delivery, through testing and monitoring.

So much that we’ll end up with regular, seamless production deployments. No more squabbles between teams, everyone embarks on the same adventure.

To achieve this, teams of developers and sysadmins are no longer isolated. They work together. Sometimes they are even merged. They all have a single common goal : the optimization of the product production and deployment cycles.

Here is a perfect two-minute video that shows before and after DevOps. This is a really good analogy of what we want from DevOps culture.

It’s not magic, you have to train and get everyone to practice. The conditions of these trainings are not all the same. And mine was a little bit special.

Im a dev

A long time ago in a galaxy far, far away, I was only doing code. And it was cool, I had no problem with that. We had a dedicated SysAdmins team that we insulted and that insulted us. It was perfect.

And one day, this team decided they didn’t want to deal with our shit anymore. Too much work in other areas. More urgent work. More interesting than managing our apps.

The problem was that without them, we had no solution for our deployments. And not only they were abandoning us, they were abandoning us fast.Then the news was official : we’re going into DevOps mode !

We were going to have to manage the entire infrastructure ourselves with the support of the SysAdmins. Worse, we were going to completely transform it with new automation tools at all stages. We were going to manage everything in 360 mode. It was a radical change!

I remember, I was eating NodeJS code when I learned that. And the idea of being in charge of the whole infrastructure overnight terrified me.

At the time, I had no idea how much information I was going to assimilate to be operational. I had no idea how much time and money it would take to transform my team.

Spare no expense

Before continuing, I have to tell you some important things. DevOps is not two jobs in one. It’s not even a job like I told you at the beginning.

We didn’t know it yet, but we were going to be trained on tools like Terraform, Kubernetes and many others. These tools help developers and SysAdmins to work together for the deployment of a product. They blur the line between the two professions.

But that’s where it ends. I don’t have the knowledge to do the job of a real SysAdmin.

Then a DevOps transformation is a huge investment for a company. The companies that do this have a medium / long term plan. The time needed is long, the training is expensive.

A study done on 200 companies that have made a DevOps transformation in the United States yields interesting figures. The majority of them spent between 100K and 500K USD over one year of transformation. That’s a lot of money.

And indeed, one year is very close to how long it took my team to make it. And when I say make it, I mean become fully operational. It was a roller coaster ride in terms of experience before we got to this point.

The beautiful adventure

At first it was really cool.

We were learning a lot of new concepts every day. They let us play with it just to learn. It’s paradise for a dev. Everything was new and we didn’t have any stakes yet. We just had to experiment and decide what we wanted to use.

First, we really Docker in depth. Then we went on docker swarm to familiarize ourselves with a first container orchestrator. Then we started talking about CI/CD, reverse proxy, load balancer, infra-as-code, cloud computing and many other concepts. Concepts that we knew from afar, but that we had never approached so closely.

My colleagues and I were like kids in an adventure park.

And then we decided. Our future will be called Kubernetes. It was a good decision. But the problem was not the technology. The problem was that DevOps is not just about using tools and automation. We would soon discover this reality.

You didn’t say the magic word

The problem is that we were using so-called DevOps tools in isolation. We were working as before. Everyone in his corner. Big headphones on, music blasting, trying to automate a stupid cluster with all the automation that goes well.

Obviously, no collaboration or discussion with the SysAdmins team, which was still available. And that’s not DevOps. We were getting more and more problems and errors out of the blue, but nothing was moving.

The first time I was thrown in front of Kubernetes in this context, I cried blood.

I ate the doc, then YAML, then the doc and nothing seemed to work. I had to make my part of the architecture work quickly in my corner.

The general atmosphere was beginning to get tense. The management put a deadline on the table. Time play against us. Things were heating up severely. Gone were the days of butterflies and discovery. A crazy race against the clock was on. And the deadlines were really aggressive.

This is DevOps

Suddenly, things changed. Collaborative meetings were forced on everyone’s agenda. Group workshops with the sysadmins team were organized. We started to spend entire days with them.

We learned what they were doing and more importantly why they were doing it this way. As a result, we explained to them the impossible plans we were trying to put in place. Simple solutions immediately appeared on the table.

In a few hours of collaboration, we were able to move faster than several days of agony between us. And that’s what DevOps is all about, bringing together several skills for a common goal. It’s just that we hadn’t yet adopted this mindset. And without this transformation in the way we work, we couldn’t make a real transformation.

And I’m repeating myself, but it’s important, even with the automation tools we have mastered for our deployments, support for sysadmins is still fundamental.

There is a vision and a hindsight on system administration issues that developers don’t have. It’s difficult to automate something you don’t fully understand. Collaboration between teams ensures that there are no gaps in understanding before automating. And even with all that, it’s not enough.

Fail fast, iterate faster

Fixing the architecture and communication problems was just the beginning. One of the main ideas of the DevOps movement is rapid iteration on its product. Concretely, instead of doing everything immediately, you do a small part, make sure it works well, and iterate on it quickly.

This is exactly what we did with our infra. And the results were spectacular.

I remember very well the first time we ran our product on Google Cloud. We could see it scaling under the weight of our load tests. We had total control over the production, deployment, monitoring and evolution of our product. It was crazy. We had no more doubt about what was going on.

It became like home.

I no longer think my code without its future deployment. When I write code, I need to know in what context it will be used. Because even if it ends up being containerized and exposed on a port, there is always a way to optimize it for its final use.

Since that day, I have officially joined the DevOps cult. So much so that I really find it hard to see the bad sides of it.

DevOps: present and future

It’s been more than 10 years since the DevOps movement started spreading everywhere. After so much time, it would be a bit logical that it would calm down.

No, not at all. 2020 would even mark the beginning of a new DevOps era. Like a good wine, the DevOps movement has matured and improved over time. And everyone seems quite comfortable with this way of doing things.

The DevOps mindset has managed to destroy the silo work, partly responsible for hell in your project. Today, we are in an optimization phase. In the future, the number and above all the quality of the tools will continue to increase as well as the efficiency of the teams to use them.

This means only one thing: reducing time-to-market. Or, in other words, getting the product into the customer’s hands faster and faster. I don’t see DevOps slowing down in the future.

Epilogue

In short, DevOps is not simple at the beginning, but very quickly it becomes life. That was my personal story with this culture. If you want more on the subject, I strongly recommend this book that I loved. And if you are in a company that is still not converted, I strongly advise you to preach it.