Cut Through Daze and Confusion of Cloud Native DevOps – InApps 2022

The Cloud Foundry Foundation sponsored this podcast.

#168: Cutting Through the Daze and Confusion of Cloud Native DevOps

Listen to all TNS podcasts on Simplecast.

Successful cloud native deployments largely hinge on DevOps’ ability to break down silos and other inter-organizational barriers by directly engaging all stakeholders, including business teams, developers, operations and other otherwise separate groups throughout the entire process. But aside from the general description, DevOps can mean a lot of different things to many different people.

In some extreme cases, DevOps’ role in cloud native development and operations might just represent a job ticket for some organizations, such as when a developer discovers a security vulnerability in an application’s code in a cloud native deployment. He or she then merely delegates fixing the security hole to an on-staff security staff while their responsibility ends there.

What cloud native DevOps really means, as well as its future, was a main theme of this podcast, hosted by InApps editor-in-chief Alex Williams during InApps pancake breakfast held during Cloud Foundry Summit Europe 2018. Devin Davis, vice president, marketing, for the Cloud Foundry Foundation, served as the co-host. The panel consisted of the following guests:

• Abby Kearns, executive director, the Cloud Foundry Foundation;
• Chisara Nwabara, technical program manager, Pivotal software;
• Dieu Cao, director of product management, Pivotal software;
• Frederic Lardinois, analyst and journalist, TechCrunch;
• Julian Friedman, the Cloud Foundry project lead, IBM.

According to Kearns, DevOps might not even be the right term to describe continuous delivery and continuous integration. “There’s so much more involved. It’s not just the developer and operations. It’s the line of business, it’s the product owners, it’s architects, it’s security — it’s just so many other things,” Kearns said. “I think DevOps is an oversimplification of a larger cultural shift that is necessary to develop integrated software quickly.”

IBM’s Friedman agreed. “I think DevOps is a term that’s slotted to me in everything and therefore nothing. I think one of the things that is genuinely interesting is you want developers to more and more be able to operate their stuff and keep it running,” Friedman said. “But I think the confusion has been that that means they should do an awful lot of ops. So, they should do this whole stack and that gives them the practical thing.”

By “doing the whole stack,” Friedman said DevOps should mean every stakeholder is “responsible for keeping my application running.” “But the only way that that’s practical is if we’ve made the operations simple enough and repeatable enough for a developer to actually do it. So, it’s not, ‘I don’t need ops now because my developer is going to do all the ops. I need great ops in order to make it so that the developer can keep that application running themselves,’” Friedman said. “I think that’s a different mindset and the term DevOps can cause some confusion down the wrong path.”

Pivotal’s Nwabara described her role as a “glorified process engineer that looks at both technical processes, people and communication channels who works to shorten feedbacks between those components.” “I think right now… an example that I would use is like if all the teams are muscles, then a TPM is kind of like the ligament that connects the muscles and you need different levels in different places in the body, depending on what the muscle is trying to do,” Nwabara said.