I am not a DevOps

The client is king. If he wants to call a cat a dog, it is perfectly fine by me. As long as everyone involved on the project understands what is defined by "a dog", there is no problem. But more often than not calling someone a DevOps, steers the company out of DevOps.

So I am not a DevOps, but nobody is. Some would consider DevOps to be a method, or at least an approach, other would see it more as a culture or a philosophy. But it is not a specialty or a position.

DevOps is a way to manage projects by giving trust, information and tools to all teams. Tools being last on the list.
Let us go over a quick example of ideal DevOps scenario.
(If you are a non-technical person, just know that a vlan is an isolated network environment that can be created on demand)

Example DevOps Scenario

A client opens a ticket for a new functionality, or a bug. One of the developers sees the ticket and decide to fix the bug or provide the new functionality. It is a small problem, or an improvement that should not have any side effects. He writes a bit of code and an hour later he has a version that works on is development environment.

He then calls or messages the network team for a test vlan, and the system team to reserve server resources on this vlan. A person in the network team contacts the system team to set up the resources. Half an hour latter, our developer can deploy his patched version on an isolated environment. After running automated tests, it's time to call quality assurance to validate the new version. If everything goes well, he informs the project manager.

Finding the DevOps

Trying to find the DevOps in the scenario above is quite hard. The developer wrote code, asked for a test environment and tested his code. He also packaged and deployed his corrected version. All things you can and should expect from a regular developer. The network administrator created a vlan, the system administrator allocated resources, and quality assurance did test. Nothing extraordinary here.

The difference is in the process. First no manager was involved until the job was done. Second the barriers that normally exists between teams were ignored. As a result information and requests flowed between teams, blurring the line between development and operational. The test environment was made by the people responsible for maintaining production. Because of this testing was more accurate.

The classical "non DevOps" outcome would be three team managers going in the N+X director's office. All four of them trying to set up a convenient planning. A specific development environment would be created, probably with different hardware and software version. These differences would have to be ironed out in the production environment upon release.

Key factors in DevOps


For the example to work, the first key factor is trust. Trust that the developer decision to work on this ticket is a good one. That solving this ticket is beneficial for the project and the company. Trust that the network admin won't break the network by creating a vlan. Trust that the system admin won't starve production by allocating resources for what is just a test. Trust that quality assurance is competent, and that their validation means the patch is good.

In other words, everyone in the company should be certain that everyone else in the company knows their job.

Manager have to trust their teams. Teams have to trust each other. Directors have to trust their employees. If not, developers won't feel confident enough to tackle a ticket without approval. Network admins won't create a vlan just like that, and system admins won't allocate resources either.


In order to make a good decision employees need to be well informed. They must know and understand the vision of the company. They must know the clients. They must be aware of the expected results of the project and so on.

If one of the teams only has partial knowledge about the project, it will be hard to give trust to it. Common sense will dictate that someone else with full knowledge should oversee its every actions. Just in case one team member is doing something that might negatively impact a part of the project about which he is not aware.

This is a vicious circle, and always a gamble. You cannot trust someone that doesn't know everything. And you cannot inform someone you do not trust. You must take a leap of faith.


Tools are here to make this leap of faith easier. When used correctly, Docker, Ansible, Kubernetes, Chef etc. will reassure higher ups. Automated process with limited rights and access make life easier and simpler for operative and minimize risks.

For example: if a vlan is created using such a process, it can guarantees that it won't alter critical environments. The technician would have to do things manually to actually endanger production. And since the automated way is simpler, he won't unless he really has to. DevOps tools, when properly used, make the easiest way also be the safest way.

Adopting DevOps in a company

For most IT technologies, you can hire a few employee, put them in a team, dedicate some resources exclusively to this team and voila. You now have said technology in house. That is simply not true for DevOps.

That is why I do not like being called a DevOps. To me it implies that you can have a DevOps pole, doing DevOps things on their own. Of course this is not possible. DevOps is a transverse method. Should a company decide to try it, it should be ready to change a sizable portion of its activities. There should be a path, from design to production, where every team involved has adopted DevOps. Unless you are a young startup, it is hard to set up.

It is worth it though. Once in place the benefits are fantastic.

But remember that even someone with a huge experience in cloud, automation and deployment cannot use DevOps, unless everyone around him has also adopted DevOps.


Illustration picture from Annca on Pixabay : here