Home Cd software Devs and Ops: Can this marriage be saved?

Devs and Ops: Can this marriage be saved?


DETROIT — Are we still going left? Is it realistic to expect developers to bear the burden of security and infrastructure provisioning, as well as writing their applications? Is platform engineering the answer to saving the DevOps dream?

Devs and Ops: Can this marriage be saved?

Conclusion: do developers and operators really talk to each other? Or are they just swapping Jira issues passive-aggressively?

These are some of the topics explored by a panel, “Devs and Ops People: It’s Time for Some Kubernetes Couples Therapy,” hosted by The New Stack at KubeCon + CloudNativeCon North America, here in the Motor City on Thursday.

Panelists included Saad Malik, chief technology officer and co-founder of spectral cloud; Victor Farcic, developer advocate at Rising ; Liz Rice, open source director at Isolalent, and Aeris Stewart, community manager at Humanitec.

The last TNS pancake breakfast was hosted by Alex Williams, The founder and publisher of The New Stack, with Heather Joslyn, TNS feature editor, answering questions from the public. The event was sponsored by Spectro Cloud.

Lighten the cognitive load of developers

A big problem in the DevOps structure – the marriage of frontend and backend in cross-functional teams – is that not all developers are necessarily willing or able to take on all of the additional responsibilities that are asked of them.

Many organizations have “cut and pasted this unique approach to DevOps,” Stewart said.

“If you look at the tooling landscape, it’s growing rapidly not only in terms of the volume of tools, but also the complexity of the tools themselves,” they said. “And developers are expected to support an increasing part of the software delivery process at the same time. And all of that together is too much of a cognitive load for them.

This situation also has an impact on operations engineers, who must help ease the load on developers. “It’s causing a lot of inefficiencies for these organizations,” they added, “and a lot of the same inefficiencies that DevOps was supposed to get rid of.”

Platform engineering — in which operations engineers provide developers with an in-house development platform that removes some of the complexity — is “a sign of hope,” Stewart said, for organizations for whom DevOps is proving difficult to enforce.

The concept behind DevOps is to “empower teams, so they have full control of their application from ideation until it’s run in production,” Farcic said.

But, he added, “you can’t expect them to have 17 years of Kubernetes experience, and AWS And so on. And that’s where platforms come in. This is how other teams, who have some expertise, provide services so that these … developers and operators can actually do the job that they are supposed to do, just like operators today use the services of AWS to do their job. So what AWS for Ops is for Ops, to me, is what in-house development platforms are for app developers.

Consistency versus innovation

Platform engineering has been a hot topic in DevOps circles (and at KubeCon), but the definition remains a bit fuzzy, panelists acknowledged. (“In many organizations, ‘platform engineering’ is just a fancy new way of saying ‘Ops,'” Rice said.)

The audience posed questions to the panel about the limitations of the DevOps model and how platform engineering fits into this discussion. One audience member asked about balancing the need to provide a consistent platform for developers across an organization while allowing developers to customize and innovate.

Malik said consistency and innovation are possible in a platform engineering structure. “An organization will decide where they want to be able to provide this abstraction,” he said, adding, “When they think about where they want to be as a whole, they might think, Hey, when we provide our platform. form, we’ll provide everything from security to GitHub’s CI/CD, repository management, that’s what you’ll get whether you’re using our IDP or the platform itself.

But “there will be unique use cases,” Malik added, such as developers building a new blockchain technology or run WebAssembly.

“I think it’s okay to give these development teams the ability to run their own platform, as long as you tell them those are the areas you need to be responsible for,” he said. “You are responsible for your own security, your own backup, your own retention capabilities.”

A member of the public mentioned “Team topologies”, an engineering management book 2019 by Manuel Pais and Matthew Skeltonand asked the panel if platform engineering was related to DevOps as it was more of an engineering management approach than a destination.

“Platform engineering is at the nascent stage of its evolution,” Stewart said. “And right now, it’s really focused on solving the problems that organizations face when implementing DevOps.

They added, “I think as we see the community come together more and get more best practices on how to develop a platform, you’ll see it become more than a different approach to DevOps and will become something more distinct. But I don’t think it’s there yet.

Check out the full roundtable to learn more about our DevOps “counselling session”.

Band Created with Sketch.