Developer vs DevOps: A Deep Dive into the Discourse of Collaboration and Responsibility

In this episode, programmer Stas Mikhailov and engineer Ilnur Khalilov analyze controversial aspects of DevOps. Within just 15 minutes, they cover various topics, including the role of a DevOps engineer, the depth of infrastructure knowledge needed by developers, whether each service requires its own specific CI/CD pipeline, and much more.

You can watch the episode on YouTube, Rutube, and VK. Choose the platform you prefer.

Below is a transcript of their discussion for those who prefer reading.

Programmer: Not really, but…

I believe there is indeed a profession. Simply put, a DevOps engineer is someone who explains to typical programming engineers how to do things correctly—how to deploy, how to create a pipeline. At least, that’s my hope.

DevOps: Yes, but…

In the past, it was commonly said that DevOps represents a culture or a set of practices rather than an individual. People would remark, “Stop calling admins DevOps!” Initially, there was significant resistance to this idea. However, it has now become a common term. When someone is referred to as a DevOps engineer, a mental model of their responsibilities begins to form. Thus, we can say this profession has emerged.

Programmer: Of course not!

Kubernetes is an excellent tool that facilitates deployments and application rollouts, making it visible to you on your screen! Without such tools, programmers would have to delve into the weeds, and instead of focusing on their business tasks, they would be lost dealing with infrastructure issues.

DevOps: Not exactly, but…

Infrastructure tools are designed to help create quality products for paying customers. Our work with various tools—complex or simple—is all about customer satisfaction. It’s crucial to adapt to the circumstances at a given moment. If we have a team of 10, and none of them know how to use Kubernetes, but a release is needed in a couple of days to ensure some level of customer satisfaction, sometimes it makes sense to prioritize speed over technical elegance, even if it compromises operability.

However, it’s important to recognize that the longer we neglect using ready-made tools and accumulate technical debt, the more complex our situation will become, ultimately leading to our downfall under that complexity. Knowing when to utilize certain technologies is simply a matter of timing.

DevOps: Yes, but…

It would be beneficial since there are often scenarios where we want to deploy something, and the order of service rollouts is dictated by business logic. No one knows better than the service developer how everything works. If something goes wrong, they’ll have an easier time pinpointing the issue.

However, we’ve discussed the vast array of tools used in today’s environment for quickly deploying code to production. A developer may find themselves lacking the adequate knowledge in this area, leading to complications. For instance, if they need to create a proof of concept quickly but are overwhelmed with pipeline details, asking for help is entirely reasonable.

Programmer: Yes, but…

This is when DevOps engineers become essential. When a programmer looks at TeamCity and doesn’t understand how it works, a helpful DevOps engineer can swoop in and say, “Here’s how it operates!” And suddenly, everything clicks.

They then continued their discussion about who exactly a DevOps engineer is and whether it is their responsibility to set up DevOps tools for a company or a specific team.

Programmer: Not really, but…

At Kontur, we have convenient CI/CD templates tailored for C#, Python, and other programming languages. So, we have some foundational tools. However, applying this foundational system across 70+ services seems unrealistic because it’s impossible to accommodate every developer’s request. One change in the database means adjustments to the pipeline.

DevOps: Not quite, but…

If a company develops similar services, particularly web-based ones, it’s feasible to create common frameworks. However, if we see a variety of technologies—like some teams requiring migrations while others don’t—differences will emerge.

Thus, the answer to whether there can be a universal process across all teams depends on the technologies employed. If the teams utilize diverse practices and tools, creating uniform templates will be quite challenging. However, if the type of applications is similar across teams—even with minor variations, like different programming languages—it becomes easier to establish more generalized templates.

DevOps: Absolutely not!

The question implies a tendency to assign the responsibility for the team’s results to just one person. Let’s say, as a product developer, I cut corners and delivered a subpar service, thinking it’s not my issue because system administrator Vasya will be woken up on a Saturday night. This approach is ineffective and disingenuous, shifting responsibility away from collaborative efforts. The entire team should be accountable for the outcomes, ensuring everyone is invested in maintaining quality across all service aspects.

Programmer: No, but…

Waking up at night is certainly undesirable. So let’s strive to do everything right and avoid doing anything poorly.

You can watch the episode on YouTube, Rutube, and VK. Share in the comments how DevOps culture is structured in your company!