How Culture Will Make or Break Cloud Native DevOps – InApps Technology 2022

CloudBees sponsored this story, as part of an ongoing series on “Cloud Native DevOps.” Check back through the month on further editions.

Software delivery cycles are becoming faster thanks to DevOps-backed continuous integration/continuous delivery (CI/CD) as production pipelines are increasingly ported to scale with microservices on cloud-native environments. But the organizations that are able to achieve this rapid development and scaling must first embrace a DevOps-backed culture — which most organizations have yet to adopt.

According to a report by Forrester Research, for example, only roughly half of all organizations had implemented DevOps in 2017, roughly 10 years after DevOps as a concept and practice emerged.  The essential security component of developing products and services for cloud native architectures is lacking most of the time, according to analyst firm McKinsey. According to a McKinsey study published this year, 78 percent of over 100 firms surveyed were not modifying their security tools when moving from on-premise to cloud deployments migrating to the cloud — continued siloed security teams disconnected from DevOps was mainly responsible for the lag.

It can thus be assumed that those who make the cultural shift are at a strong competitive advantage — at least for now. This is because most organizations have either not fully optimized DevOps to support cloud native architectures, or in many cases, have not yet adopted DevOps, as mentioned above. In short, an organization’s DevOps culture will either make or break its shift to cloud native deployments.

This was the consensus during a recent DevOps World | Jenkins World 2018 in Nice, France. There, InApps Technology spoke with thought leaders and executives who have played an instrumental role in helping foster the requisite culture within DevOps teams for massive-scale cloud native deployments.

They agreed that creating the culture that removes the walls between all stakeholders within an organization, including business, operations, teams, operations and developers; may not be easy — yet is increasingly seen as the essential framework on which to build cloud native applications and architectures.

Business or Else

The cornerstone of an inter-organization cultural shift for the adoption of cloud native DevOps culture begins on the business side. Someone from the IT department will obviously likely initiate the concept of applying DevOps to shifting software development from on-premise data centers to microservices, running on cloud native platform. But without the business teams playing their role, nothing much will happen, Brian Dawson, a DevOps evangelist at CloudBees, said. “Business has to be involved,” Dawson said. “The whole idea is you want to go from ideation or concept to customer.”

Dawson said when working with an organization’s DevOps to help them build their cloud native deployments to scale, he first determines who the developers, QA, operations and business team members are. “I make a point that, “‘now, all of you guys are part of the business, because at the end of the day, we’re doing what we do to deliver functionality to support the business,’” Dawson said. “For your standard cloud native application, there will be operations and security guys, for example, asking ‘okay, how do I inject myself into cloud native development?’”

In many cases, getting the business team’s backing requires making the case to a board of directors at a large organization, which represents one of the first challenges. When moving platforms from on-premise to cloud native deployments at HSBC, a large European bank, Cheryl Razzell, global head of platform digital operations for HSBC Operations said she began playing a lead role in the project by realizing within an organization as large as HSBC that “there are very different ways of working and I don’t think there is a right way or wrong way.”

“So, there’s been a massive cultural shift and to adopt agile working DevOps, but I think the bank really wants change so it’s embracing this change so it’s open to challenging new ideas,” Razzell said.

HSBC also made the cultural shift by acquiring people from outside of the banking sector “because they want to change their culture from within and they want to bring out that new ideas,” Razzell said.

HSBC’s hires included those with backgrounds from startups, as well as from established tech leaders, such as from Google, Amazon and Microsoft, Razzell said.  “They’ve taken people from different backgrounds and different sectors to bring in a new way of thinking alongside [hires] from SMEs and the teams who already understand how the bank networks had been,” Razzell said. “There’s synergy between the teams with new ways of working versus some of the banks legacy products and some of the bank’s [existing] processes. I think, you need both to complement the journey.”

Startups that have embraced cloud native DevOps culture from the outset also have their share of challenges compared to larger organizations. “Many might assume startups that based their business models on streamlining software production with continuous delivery practices directly on cloud native architectures normally have fully embraced DevOps culture,” Dawson said. “But while these types of software-development startups probably do not have to worry about porting legacy on-premise platforms to the cloud, they may likely lack key DevOps teams that established organizations will likely have.”

A greenfield organization practices will probably, for example, lack a business analyst team, Dawson said. To compensate, a successful startup “tends to have a highly network process where the product manager/owner has a good understanding of the business,” Dawson said.

The CI/CD Assembly Line

A shift from on-premise deployments to cloud native DevOps teams will also mean different roles for team members. A good example is cloud native DevOps will also the end of job tickets as developers have direct API access to spin up stateless containers on a cloud native platform.

In other words, cloud native deployments could serve as the beginning of the end to job tickets, which have long served as a mainstay in IT culture and practices. “It’s kind of a DevOps thing transitioning from, let’s say, a job ticket mess before,” James Strachan, senior architect at CloudBees, the project lead on Jenkins X, said.  “I think the whole idea behind the cloud is everything is self-service. So, whether you automate it with a pull request or you click a button on a UI, it’s a way everything should work now really, by no longer raising a ticket and waiting three months for a VM to show up.”

Cloud native DevOps also means “giving more autonomy back to the engineers and developers” so that the “onerous of support” is on the development team to build their own Jenkins masters in AWS, for example, which they will support themselves, Razzell said. “So rather than having a centralized team to support Jenkins, you give teams the autonomy to build their own Jenkins,” Razzell said. “They’ll have automatic monitoring, so every time we spin up the Jenkins on AWS instance, it will spin up the monitoring dashboards, which they can monitor” to see if and when they need to scale up their deployments.”

At the end of the day, the culture of cloud native DevOps involves a shift from the traditional practices associated with monolithic deployments and platforms. “We’re generally seeing the emergence of smaller, product-focused teams,” James Governor, co-founder of analyst firm Redmonk, said. “And if we’re going to break down the monolithic platforms, and have a product focus, we’re also breaking down the monolithic teams so that they can support their products.”

Feature image via Pixabay.