Do we need a DevOps Engineer?
In the modern world of software development becomes normal to hire more and more engineers with “buzzword” title DevOps. But nobody cares why it is so trivial. Moreover, on the web, you can find a lot of formulas on how to better calculate how much DevOps engineers you need to hire based on how much developers and testers you have in your team.
Let’s take a pause and return to origins. All of us know that the DevOps is not a human and even not a team. This is another methodology in the software development world, which should increase the speed of delivery, destroy the gap between development and operations and blah blah blah.
However, where is this difference between the new DevOps Engineer and the previous world has known System Administrator. This position is more known in the world, but when you call yourself DevOps Engineer it gives you more glory, money, and abilities. Previously I felt this as a release of new specialization in World of Warcraft for your character or like class evolution in Lineage 2.
System Administrator is able to cover a lot of tasks that right now relies on DevOps engineers. Infrastructure configuration, network configuration, web apps configuration, monitoring, alerting and much more. Moreover, most of such administrator knows more deeply networking, than newcomers or even middle DevOps engineers.
Where is the difference and does it helps to speed up the process? Not sure.
With this, not so new so far, methodology, came to our world new terms. They are more known as responsibilities which should cover DevOps engineer. For example, continuous integration, continuous delivery and thus given the opportunity to appear such tools as Jenkins, Terraform, Ansible, Docker, which should ease these processes.
We all forgot the most important things that are important when you do DevOps, namely to remove the gap between development and operations, build the aligned process and good communication between departments.
On the other hand, there are more important things, such as trust, ownership and knowledge sharing. Although just to build a communication bridge in the team will boost your performance as well.
Let’s analyze separately each mentioned above principles of building DevOps in your team, this is what will give us the opportunity to understand do we still need a DevOps engineer.
Knowledge sharing
In the process of software development, we are faced with such a common problem as a lack of documentation, as well as the fact that most companies are not given special attention to this problem.
Criticality can show itself in the following:
- slow restoration after an emergency shutdown or breakdown
- the speed and timing of the onboarding of new employees in the workflow
- the creation of expensive and difficult to replace employees in the company.
In the DevOps methodology, documentation is on a pretty high level in the requirements list and you should pledge time for this process as well. Moreover, code without documentation is worthless in some cases.
I want to share with you another practice, knowledge sharing sessions allow you to speed up the development process, continuous integration, and continuous delivery by revealing things from under the hood of the build and deploy process. Or how the infrastructure was built and what is the Docker for example.
Another way to do such sessions is in parallel with breakfast. Just create another team gathering point, where someone will be a speaker and others will eat their tasty food and gain new knowledge. At this point, you will empower your team, because they will be able to understand how things going in the operations and also they will be able to improve their presentation skills. For instance, if you are a Ukrainian speaking or Russian company with clients worldwide you can even do this session on English, which will also improve your language skills.
In order, your developers will ask questions which they might be interested in the Operations side, but previously they hesitated to ask. Moreover, some of the information which you can cover, developers will not be able to find in the documentation, because it will be based on your experience.
Ownership
A pretty important point is the involvement of the team in the main process, as the main way to show an employee that he has the same responsibility to the project or product as his colleague on the right or left.
Lay on the shoulders of the developer the ability to penetrate and change the build process, he will begin to feel responsible.
By investing in employees this way, we will get not just developers who write good code, but also employees who understand the whole SDLC process, and this will give you the opportunity to get fast feedback and improve this process. Because DevOps is also based on continuous improvement. Moreover, the developer will not have to wait ten minutes or for instance two hours until someone from the operating team will be free to help you in order to change the version of the collector, add parameters to the application assembly, or simply add other tests.
Moreover, in the modern world everyone tries to ease all processes, for instance in DevOps, we have tools, which tries to reduce all to code — infrastructure as code, configuration management as code, pipelines for assembly and delivery, this is also as code. You do not need to go through 10 tabs and enable or disable more than 100 checkboxes and fill out 20 forms. Everything is much easier.
I think if a developer can write algorithms, he will be able to handle the small changes in the pipeline for code delivery.
Trust
The last but not least point is trust. Rely on trust inside of the team and you will build the smooth process. Trust in that if you will be on vacation, the team will be not blocked until it finishes or in your most busy day when your DevOps Engineer is too busy to cover all tasks, he will feel, that someone from development or testers team can cover him and resolve some issues by themselves.
You should trust each other, otherwise without trust is not a team at all.
Conclusion
Based on all the above written, you can see how all these three principles depend on each other. After all, judge for yourself, there is no knowledge sharing — there is no opportunity to perform certain operational tasks by the developer, and there is no confidence and of course, there will be no responsibility to each other.
So how can you understand, do you still need a DevOps engineer an employee or not?
According to my expertise, I have met many companies that operate in completely different ways. Some hire a DevOps engineer if they already have more than 3 developers and developers already began to build the infrastructure by googling everything and later we should re-configure a lot because there was a mistake in the configuration.
There also companies that make team expansion at the expense of consulting firms or outsourcing, there a lot of companies on the market that can provide a full range of services — from development to DevOps, companies such as EPAM, Opinov8, SHALB, and many others.
There is also a mix when your company is assembled with freelancers, consulting employees and in house employees of the company and it works well!
What is bad and what is good?
In fact, the main aspect of this all is, again is trust, trust in the fact that all these people have one goal. When everyone has one goal and one passion, the product will evolve fast.
Many consulting companies, freelancing employees or contractors pay less attention to the fact that their participation in this product is not just another way to make money, but a chance to bring something into this world.
The market is now a very large range of different companies that need engineers DevOps, do not be lazy and pay attention to whether you can love this product. Otherwise, you will just do your job without passion and every day for you will be just another day.
And if you are a CTO, choose a model by which you will expand your team and please pay attention to what these companies or engineers are trying to sell you.
Try to not hire engineers with “buzzwords”, try to hire members which you can trust and if this is just a system administrator which you trust, and you think he can cover all requirements, give him a try.
And of course, try to empower your team. Developers can write Pipelines for Jenkins and even able to create a local environment and development environment with Docker.
