Discussing DevOps with a colleague
Some time ago, I was exchanging with a “non-technical” colleague from our Digital Studio. She had recently picked an interest in the development side of things and came to me to discuss what software engineering was about. The topic of DevOps came up and the conversation went pretty much like this:
- “By the way, do you know about DevOps”?
What a weird question to ask! I am a developer, of course I know about DevOps! How could I not?
- “Uh yes, I do know about it. Why?”
- Oh great! Because I have a bit of trouble understanding what it is all about. Could you briefly explain to me what it is?”
- “Yeah sure! Well, you see, first, you use Git for CI/CD, then err, you package the software if needed then err it goes through a pipeline like Jenkins and…”
Needless to say, my explanation did not make it clear for my colleague!
While I thought I knew about DevOps, it was only superficial knowledge! I then remembered the saying “You do not understand something until you can explain it to someone else so that they understand it”. As it turned out, I did not completely understand the topic!
I hope that through this article I can make amends to my colleague by providing a clear and simple explanation of the concept that is DevOps.
DevOps: the basics
Let’s dive in!
At its core, DevOps is a way to deliver software with shared responsibility, pain, and rewards.
To better appreciate this sentence, it is required to grasp that, generally speaking, software delivery consists of two teams: developers and operations.
The roles at play
Developers are the ones in charge of writing code, implementing new features, and fixing bugs, whilst operations are the ones carrying the responsibility of managing and monitoring where/how the software is run.
It appears that these two teams have quite opposite incentives!
As a developer, my goal is to deliver as many features as fast as I can, but each of these introduces a risk (inherent to any change), which someone from operations would like to reduce as much as they can. To put it another way, developers are driven by business needs and want to make changes as much as possible whereas operations are driven by non-functional requirements and want to keep down the frequency/number of changes.
DevOps was born as a result of this opposition to bring together what is the two sides of the same coin: rather than have two teams with misaligned objectives; the two groups unite as one, sharing the full responsibility of building, deploying, maintaining, and monitoring the application.
More than just a role
From this explanation, you might get the idea that more than a role, DevOps is a way of working… and you would be right! But what about the “DevOps Engineer” then? What is this specific role about?
Well, every methodology needs people who are knowledgeable about it and are aware of the best practices. A simple way to put it is that the DevOps engineer is to DevOps what the Scrum Master is to Agile/Scrum: he enables the team to work efficiently by providing (and configuring in this case) different tools and techniques.
I hope I made the idea behind DevOps clearer! Is your team using DevOps to streamline the production of an application? If so, how did it go and what are the changes that took place within your team?
We will learn more about the expertise and tasks of the DevOps engineer in an upcoming article! If you already want to learn more about this topic you can watch this video:
We have a great team of developers to work with and we couldn’t be luckier to have them write articles for this blog! If you are curious about their daily life, we invite you to have a look at what the life of an experience developer is like in our Digital Studio, and drop us a line.
