Best of 2021 – Seven Reasons You Shouldn’t Hire a DevOps Engineer

As we head into 2021, we at wanted to highlight the most popular articles of the year. Here is the fifth in our Best of 2021 series.

DevOps is a culture, not a title. Therefore, companies should follow the principles of DevOps, rather than hiring a single expert to fix the entire enterprise delivery model.

I recently spoke with Uri Zaidenwerg, Head of DevOps at Replix, to understand the current state of DevOps. With the emergence of more powerful DevOps tools and the spread of practices across organizations, developers are now better equipped to own their applications from start to finish, including deployment, security, and even cloud costs.

Extracting DevOps from the development cycle may invalidate the purpose of developing silos and operations. Below, we’ll outline some reasons why you should focus on building an inclusive culture rather than taking on the role of a DevOps engineer.

1. DevOps is a culture, not a role

The first reason is also the most comprehensive – DevOps is not a title; It is a culture. DevOps works best as an IT mindset. Instead of assigning a custom role, Zednwerg said, “all developers should do processes.”

This means giving developers better insight into DevOps KPIs, such as deployment frequency, deployment time, failure rate change, discovery time, and availability, which we’ll detail below.

2. Developers know their app code better

Developers know their code better than anyone else. Diagnosing errors in an unfamiliar environment is difficult, and only programmers really understand the ins and outs of their code. Armed with DevOps skills, they can tackle problems more efficiently than outside eyes.

Zaidenwerg served as a DevOps systems administrator, describing “what it’s like to monitor the availability of an application that you haven’t coded or created.” it’s hard; He explained that simultaneous diagnosis of multiple applications that you don’t know intimately is also a major challenge.

If you can’t quickly associate errors with application processes, it can damage availability and SLAs. Alternatively, encouraging developers to diagnose problems can reduce processing time because they have more context, Zaidenwerg noted.

3. Developers see the surrounding environment

In addition to understanding how individual applications work, developers also have a unique perspective on the surrounding environment – they understand the complex network of dependencies and interdependencies that make up the microservice system.

To know what’s going on, you really need to know how to program. “DevOps engineers need to be software developers,” Zaidenwerg said. Handing over DevOps tasks to an administrator who has no coding knowledge can severely limit their ability. They won’t be able to dig into the code to address real issues or make pull requests with confidence.

4. Separation of roles keeps operations in silo

Delegating DevOps responsibilities to a central team goes against a fundamental principle: separating departments from silos. “DevOps was invented to narrow that gap,” Zaidenwerg said. Thus, having a separate role appears to contradict one of the fundamental principles of the methodology.

“The point of practicing DevOps is to enable developer teams to control their own processes, not that you have specialists who know how to write process scripts,” Tom Marsh, lead developer at Novartis, said on Quora.

5. No DevOps engineer can handle a flood

As it stands, there are not enough DevOps engineers to navigate. According to the answers on Quora, the ratio of DevOps engineers to developers tends to stand between 1:10 to 1:12. Zaidenwerg said he saw worse – from 5:50 to 6:120. Instead, he said, “Zero to zero is the optimal number.”

One DevOps engineer in the face of a tidal wave of requests and application deployment pipelines is not sustainable. “Can you imagine the amount of features and code that has been written?” asked Zaidenwerg. “The amount of fires they need to put out is huge.” And what happens when a lone DevOps engineer goes on vacation? To avoid delays, developers are encouraged to have their own CI/CD process from start to finish.

6. What happens when DevOps engineers automate their jobs away?

Another tenet of DevOps and SRE practices is to introduce automation – with the ultimate goal of automating their jobs away. But, if this really happens, what happens to the DevOps engineer? Do they sit back and take a profit from some prior business for years afterwards? It would make sense for programmers to introduce automation into their workflows.

7. K8s + Other DevOps Tools Empower Developers

Powerful DevOps tools like Kubernetes, ELK stack, and cloud infrastructure solutions are now more realistic to delegate more responsibility to the programmer themselves. The democratization of “as-a-service” solutions for monitoring, load balancing or storage enables everyone to “share the DevOps workload,” said Zednwerg.

Many organizations are starting to treat Kubernetes as a source of truth. Zaidenwerg wholeheartedly encourages this practice. “Everything has to be run on K8s, from K8s,” he said. “Experiment and think of K8s as your lower tier.” He added that standardizing microservices around K8s helps keep the multi-cloud platform from unaware.

How to get there? Track DevOps KPIs

So, if we don’t delegate DevOps tasks to a DevOps engineer, how can we encourage developers to embrace DevOps principles? For Zaidenwerg, the answer boils down to how we define success. Instead of measuring success using traditional development output metrics like productivity, scrum, or the number of tasks completed, we need a culture that measures developer work using Key DevOps Performance Indicators (KPIs).

There are several DevOps KPIs to consider. Some could be:

  • Posting frequency: How often do you commit?
  • Publication time: How long does it take to commit to the living environment?
  • automation: What is the mechanism of the construction process?
  • Availability: Is the software globally available and high-performance? What is latency and uptime?
  • watching: Do you proactively monitor and fix problems in live environments?
  • improvements: Is the application cost-effective? Could it be more efficient? Are there idle resources running?
  • Politics as a symbol: Are security policies automated as code? “Security has to be written in code… if it’s done by hand, you’re crazy,” Zaidenberg said bluntly.
  • DRP: Is the application flexible? What is a Disaster Recovery Plan (DRP)?

Among the above KPIs, optimization stands out, as rising cloud costs are a permanent obstacle these days. Zaidenwerg encourages developers to keep track of expenses in the cloud. When you have a daily graph of spending, you can use this insight to “create supportive systems to automatically shrink idle resources,” he said. Others describe this as BizDevSecOps.

Encouraging DevOps Culture

Our cheeky title is not intended to devalue those who have DevOps in their address – on the contrary – hiring someone with this rare experience can greatly help organizations deliver DevOps principles. They can serve as a model to help develop this culture.

In addition to tracking KPIs, Zaidenwerg recommended a top-down approach to spreading DevOps principles. The methodology should be validated and led by the chief technology officer, architect or technical officer, depending on the size of the company. DevOps culture is of paramount importance to SaaS or IaaS companies, whose architecture must be more than error-resistant — “it must succeed every time,” Zaidenwerg stated.

Deploying modern cloud best practices is also critical to building a DevOps culture. When you move from hardware to the cloud, you often encounter similar technology (load balancers, firewalls, availability zones, etc.), but with different names and implementations for each function, complicated by nuances between cloud service providers (CSPs). All of this will require “translating on-premises best practices into cloud best practices,” as Zeidnwerg described.

Another important problem arises from the fact that DevOps is not really taught in college-level computer science courses. Looking into the future, I hope we will see more focus within the education system. Inculcating a DevOps mindset early on will better prepare developers for more realistic settings that include deployment, availability, and security as code.

Whose house is this?

Zaidenwerg is like a software app in someone’s house. The homeowner knows all the details – where the tools are, how the shower nozzle works, what day the garbage is picked up, etc., invite a stranger to a new house, and they will be at a loss.

Likewise, inviting overseas operations to manage a foreign infrastructure will leave them at a loss. “If you let someone else handle the infrastructure, then you have two parties and no one really knows,” Zednwerg said.

To summarize – DevOps is a culture, not a role. Treating DevOps as a role, rather than an exercise, can kill the target and cause isolated, slow-moving teams. Alternatively, tracking KPIs and empowering developers with DevOps tools can help With them Keep their house in order.

Of course, this is an evolving practice, and each organization will have its own understanding of what it means to implement DevOps. Now, do you still think it guarantees the title? Let us know in the comments below!

Leave a Comment