From System Administrator to DevOps

Software development and IT operations, two parts of the systems development life cycle that are the pillards of said life cycle. For many years, each of this activity was separated from the other: we needed one team to build the product (the software) and one team to operate and maintain it. Below, we can take a look at the traditionnal methods before the DevOps Theory.

It's not a bad thing to say that, by the time the developers (let's call them devs) came with a new software update, the operators (let's call them ops) barely finished to make the original product up and running. Now, whose fault is that ? The devs for delivering products without giving a single thought on how the software could operate on the technical stack ? Or the ops for creating technical stacks without giving a single thought on how the software could be developped ? The answers are: none, both and dropthesuspense.

Let's review these answers and we will see that we are pointing to the same direction: None, because no one will take the blame and (most probably) will shift it to the other team and Both, because it is obviously their fault each for taking decisions inside their own scope without looking at the bigger picture. This is where the problem lies, why these two teams working on the same product and needing each other for the product life cycle are separated ? Because management said so.

I'm not going to address the "dropthesuspense" answer, for suspens purpose.

Just imagine there is a team of let's say, DevOps, that is made of devs and ops working on the product life cycle alltogether, wouldn't it be great ? Might be exciting to say it like that, while the idea is indeed interesting, we should take a look at what makes it appealing for productivity and what makes it a huge challenge for some people.

Atlassian DevOps ressource

Datascientest DevOps resource