The DevOps concept emerged in the late 2000s – in the wake of agile software development and the cloud trend. As the neologism of development and operations indicates, the goal was to break down the separation between software development and provision. This coincided with the need for software engineers to collect and incorporate user feedback more frequently, which translated into much more frequent updates.

Many companies took the opportunity to bring these two groups of specialists together and solve problems together at a speed previously thought impossible. However, some simply saw the DevOps trend as an opportunity to impose additional responsibility for operational tasks on their developers.

Emily Freeman, Head of Community Engagement at Amazon Web Services and author of “DevOps for Dummies,” speaks from the heart of many developers on Twitter:

I’ve been saying for a while that, for the most part, developers don’t want to concern themselves with operational concerns. And I always get a boost.

But I swear the last dozen consultations I’ve had have been about how to get ops accountability from developers while still being DevOps.

— Emily Freeman ???????? (@editingemily) March 30, 2022

Hundreds of comments show that the AWS manager clearly touched a nerve. Here are a few selected ones:

I’m a developer and I don’t want to deal with operational concerns!https://t.co/ihuHVBu2gj

– Scott Pantal???? (@scottpantal) March 30, 2022

Can confirm. pic.twitter.com/ZgqhNnJ8oB

— James Trott (@JamesTrott) March 30, 2022

My typical analogy is that DevOps would have to remove the wall to replace it with a mesh fencing and gate. IMO, Devs and Ops must work closely with differentiated roles. The empathy between teams is the real point

— Andrew Gracey (@gracey_andrew) March 30, 2022

The concept of shifting operational and security-related matters to the developers’ area of ​​responsibility as part of a “shift-left approach” certainly has its advantages, but can also lead to dangerous bottlenecks, such as James Brown, Head of Product at the Kubernetes company. specialist, explains Ondat, carries out. “If you drag developers into too many other areas, you’re shooting yourself in the foot,” says Brown. Depending on the discipline, different skills are required. Nick Durkin, Field CTO at DevOps platform provider Harness, is even more clear: “Some people are finally starting to understand: You don’t hire an electrician to do plumbing.”

While the number of software developers in the enterprise has never been greater, their expertise has increasingly faded into the background, even as their workload has increased significantly. Like DevOps engineer and ex-sysadmin Mathew Duggan writes in his blog, the operations should still perform their traditional tasks of application availability, monitoring, security and compliance. But today they should also set up and maintain the software delivery pipelines. In this way, they would “create the foundation for the developers to deliver the code quickly and securely.”

Duggan believes these additional tasks require extensive retraining, which should focus on cloud engineering and infrastructure-as-code skills. “In my opinion, the situation has never been more dire than it is now,” Duggan wrote. “The entire software development has been completely overwhelmed by the enormous expansion of their tasks, but also by management’s unrealistic expectations in terms of speed.”

Tyler Jewell, managing director at Dell Technologies Capital, echoes Duggan’s finding in a research note: “Building an organization that can maintain the required high level of iterative harmony over time is an incredible challenge.” The more complex the systems become and the more feedback from end users comes in, the more difficult it becomes for people to assess the effects of constant changes on the overall system.

The situation may not be as hopeless as Duggan, Jewell and others think, although it may require a fundamental reshuffling of development teams and their responsibilities. “The goal should be to provide developers with the right system information at the right time,” says Durkin. They were then able to configure the systems so that operations, security, and infrastructure teams could work properly.

Nigel Simpson, former director of corporate technology strategy at The Walt Disney Company, agrees that companies need to recognize this problem and “work on it.” “Developers can’t worry about how all the machines work. They need to focus on what they do best: writing software.” It is important to remember that DevOps implementation varies from company to company. Just because developers take on some extra work temporarily doesn’t mean they have to do it forever.

“Developer control over the entire infrastructure is not a prerequisite for success”, writes Gartner analyst Lydia Leong. Responsibility can be distributed across the application lifecycle. Companies can take advantage of the “You build it, you run it” DevOps principle without leaving their developers in the dark. “It’s fine if you give your developers full self-service access to development and test environments, as well as the ability to create infrastructure-as-code templates without giving them full responsibility for production handover.”

Ondat manager Brown believes container orchestration with Kubernetes is the invisible line between ops and devs that separates their concerns. This allows developers to focus on their code and operations on infrastructure and pipelines. He calls out, “Let’s not go back to the different teams not talking to each other.” In fact, in VMware’s analysis, they said: “State of Kubernetes in 2022Still, 54 percent of respondents say that adopting Kubernetes has improved developer efficiency, and more than a third (37 percent) said they now want to improve the efficiency of Ops teams as well.

However, container environments have the disadvantage that there are always only a few specialists who are familiar with them. “Don’t make the mistake of trying to make everyone an expert,” recommends Kaspar von Grünberg, founder of the Humanitec development platform. a blog post. In any high-performing team, there are few true Kubernetes experts. “The teams strive to keep the level of abstraction high for everyone so that the cognitive load on the entire team does not become too high.”

If DevOps isn’t the ultimate software development solution, then what is? The approach has proved popular Site Reliability Engineering (SRE) emerged from Google’s DevOps-related growing pains. If you’re wondering what that is, Ben Treynor, Google’s vice president of engineering and godfather of SRE, is often quoted as saying, “What happens when you ask a software engineer is an operational function to design.”

For example, the introduction of an SRE safety net – both at the central operational level and within individual development teams – has ensured that US financial services firms Vanguard and Morgan Stanley helped to strike the right balance between development speed and operational stability. Both companies struggled to balance dev and ops roles as they moved to cloud native methods. However, SRE is also not free from criticism: “The introduction of SRE principles is sometimes misunderstood as a rebranding of the Ops team,” notes Trevor Brosnan, Morgan Stanley’s DevOps manager.

“It’s a differentiated problem to solve,” said Christina Yakomin, site reliability engineer at Vanguard. “The introduction of SRE makes people feel like we want to put the ops back in a silo. In fact, I want to encourage our developers and operations specialists to share responsibility for security and ensure that teams with shared platforms have the full take operational responsibility.”

In order to provide developers with the tools they need for their work, the idea of ​​in-house development platforms or platform engineering has emerged. These give the devs the tools they need while also providing the associated organizational guidelines so they can focus on their core business. Such in-house developer platforms typically offer:

• APIs,

• tools

• Services

• know-how and

• support

So things developers need to make their code productive. This is combined into a company-wide platform maintained by a dedicated team of specialists or product owners.

Against the background of the issues mentioned, software engineer and DevOps specialist Sid Palas already sees DevOps as a phenomenon of the past and relies on platform engineering, as he explains in the following Twitter post:

DevOps is dead??, long live Platform Engineering!

1) Developers don’t like dealing with infra . to go
2) Companies need control over their infrastructure as they grow

Platform Engineering (and Internal Developer Platforms) allow these two facts to coexist. Here’s how:

(1/n)

— Sid Palas (@sidpalas) July 26, 2022

Brandon Byars, chief of technology at Thoughtworks, confirms Palas. The division into platform engineering teams often works well in practice. The friction losses for the developers are low, while at the same time they retain the ability to turn the important knobs. However, the expert qualifies: “If you ask the developers to do all this work without a higher-level platform team and without the right tool support, it will no longer work properly.”

Any company involved in DevOps practices is familiar with the balancing act between software development and operations teams. It’s a balancing act that is increasingly difficult to manage in the age of cloud-native complexity. (FM)

This post is based on an article from our US sister publication Infoworld.