At its core, DevOps is a set of procedures meant to make the process of developing and releasing applications efficient and fast. But this sounds pretty abstract. Let's ignore the technical aspects for now. Instead, let's take a look at the human aspect of developing and releasing apps. It will be easier to understand DevOps if we first look at the problems that it tries to solve.
Let's start by taking a look at an app on our phone. For example, let's consider the YouTube app that lets us easily watch any video we want. How does it end up on our phones? The first step is pretty easy to imagine: a bunch of people writes some code for it. They use a programming language to implement all the features that this should have. But before this app lands on the Google Play Store or Apple's App Store, it has to go through many steps.
First of all, all that code is just a collection of lines of text. And our phone can't just execute that text, as it is. That code has to be transformed into something that our phone can understand and run. Also, we can't just turn any code into an application and deliver it to our customers. What if that code has errors? What if it crashes our servers? So, in a nutshell, the code has to be reviewed, transformed into an executable program, tested, and then packaged and delivered to the app store so that our users can download it to their phones.
Now let's rewind and simplify. We can split this into just two stages.
First, developers write code. This is the development stage, the "Dev" part of this "DevOps" word.
Next, comes the Operations stage, the "Ops" part of "DevOps". So what is this "Operations" thing? Well, simply put, the operations team makes sure that this app has all that it needs to be able to work in the real world. For example, the app might need access to some servers, to store our login details in some database, to remember our favorite videos, and so on. So they make sure that all this infrastructure exists and works properly, to support this app.
It is between these two stages, development, and operations, that a lot of problems can appear. Let's take a look at just a few.
Let's say that our developers did a great job and delivered some well-written code. However, when the Operations team tests this app, it crashes their servers. This doesn't necessarily mean the code is bad. It's just that the developers are focused on their side of things, the code itself. They might have no idea about the exact configuration of the servers that will support this app. So, in a sense, they write code blindly. They aren't sure how to optimize that code for those specific servers. And this is a good example of how a DevOps team can step in and solve this problem. For example, the person responsible for DevOps could do something very simple here. They could review that code and leave a comment like this:
"Great job devs! You rock! We just need a small change on line 127: we should lower the size of allocated memory in this variable to make sure it works well with our current servers." And just like that, the problem is avoided. The devs make the change, the code is then approved by the DevOps team and the app now plays well with those servers we have. So this is one of the responsibilities of a DevOps engineer. They're, in a way, a bridge between the Development and Operations stages.
But now, let's continue and take a look at an even bigger problem. The code for an application changes very often. Developers constantly add, remove, and modify code. This way, they can add new features, fix stuff, improve performance, and so on. Now imagine we have 30 developers working in our company. Every 10 minutes, we get some updated code. Every 10 minutes we need to review code, build the app, do some basic tests on our servers, and so on. Imagine having to write some 20 commands to go through these steps, every 10 minutes, again, and again, and again. It would become frustrating pretty fast. And developers would have to wait until we can confirm their code is working well. This would add up to a lot of wasted time for everyone.
Now we can finally jump to what DevOps is, at its core.
Think of the situations we just discussed. Do we really need a person to step in every time the code of our application changes? Can't computers do this? Can't a computer look at that code and do some general tests to make sure it's valid? Can't a computer take that code and compile it, transform it into an app that can run on a phone? Can't it also test that this app works well with the servers we have? Of course, it can!
A DevOps team can automate all of these steps. Now the developers can see the result of their work faster. They push some new code, and in a few minutes, they get some results. Maybe some tests fail, but now they quickly see what they have to correct. Or everything works just fine, they're happy with the result and they can continue to add even more features. No one has to wait for someone else anymore.
This process brings a lot of benefits to both the employees and the users of our app. The employees can do their work without wasting time doing what computers can do automatically for them. And the users can get their updated apps even faster, getting new features, fixes, or whatever they've been waiting for.
If you ever watched a documentary about how cars are made, you saw the production lines they have. The car body is moved around from robot to robot. One robot maybe paints it, then it's moved to the next robot that inserts the windshield, and another one that adds the chairs, and so on. Piece by piece, step by step, it's automatically built into a functional car. Well, a DevOps engineer does the same thing for software. They build this whole production line to make sure that code is automatically processed, step-by-step. And, gradually, this code that was just some text moments ago, is compiled, tested, packaged, and finally shipped to the customers that use it.
Now we can finally paint a clearer picture and draw some conclusions about DevOps:
- The DevOps team improves collaboration between Development and Operations. Or, in simpler terms, between those that write code and those that build the infrastructure where that code will run: the servers, the cloud services, and so on.
- The DevOps team builds a production line for software. They do this by making sure that anything that does not need human intervention is automated. Step-by-step, code is gradually transformed from simple text to a fully functional application that can be delivered (also automatically) to the users that need it.
- The DevOps team also has other responsibilities to make sure that not only the app was launched successfully, but it also continues to work correctly. For example, they can set up ways to continuously monitor this application and the way it's performing in the real world. This way they can automatically get alerts in case of serious errors which will help fix them faster.
All of these things allow a company to build software fast, test often, and ship the final software product more efficiently.
Hopefully, this paints a clearer picture of the responsibilities of a DevOps engineer. And if you want to take a look at the technical side of things, and what kind of tools are often used in DevOps, you can check out the article "Understanding Essential DevOps Concepts" and also check out this Learning Path to get started with DevOps.