How Your Role Changes When DevOps Goes Cloud Native – InApps Technology 2022

CloudBees sponsored this story, as part of an ongoing series on “Cloud Native DevOps.”

The concept is straighforward: Teams achieve DevOps by removing the silos between the different stakeholders to foster a more collaborative environment during the software development and deployment process. But putting the concept into practice requires great shifts in the collaborative culture among the developer, analysis, testing, operations and other teams.

The DevOps framework for cloud native architectures can change that much more compared to traditional on-premise and monolithic deployments. Cultural changes notwithstanding, one such difference is the intensive cross-functionality of the different DevOps team members that is required to make the shift. This difference also has a direct effect on the specific roles of the different devs and ops team members for cloud native patterns and practices.

While automation in the production pipeline and during the deployment and operations processes certainly can replace some job functions, deployments in cloud environments can typically also mean much more cross-functionality and overlap between the traditional development and operations roles.

A potential upside is how, in this way, cloud native deployments can also empower developers. “Cloud native continuous deployments are a tremendous opportunity for corporate IT to upgrade their role from ‘the [people] who keep the lights on’ to the ‘architects behind strategic business success,’” Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. “Every additional deployment doesn’t add to the ops cost, because the operators spend their time coding compliance, security, performance, and SLA metrics and making sure all infrastructure is available via automated self-service.”

In the case of microservices, the development team can “be narrower in focus than in the past,” Steve Herrod, former chief technology officer of VMware and now managing director at General Catalyst, said. Each microservice team can thus develop and deploy their code independently of the rest of the application, he said. “In many cases, the site reliability engineering (SRE) role has grown to bridge the gaps and coordinate monitoring and debugging across the whole application,” Herrod said. “Great SREs thus require great technical skills, but also great interpersonal skills to coordinate across teams.”

In the serverless space, the Dev and Ops engineers still have different roles to play as well. “Let us not forget, that doing serverless at scale entails multiple layers of complex configuration,” Nuatu Tseggai, director of solutions engineering, for Stackery, said. “[It also requires] expertise that relates to networking and distributed systems, of which ops engineers have built up significant experience implementing solutions for over the past few decades.”

The Automation Challenge

Automation, by definition, replaces the human in a process or workflow. In theory, cloud native deployments can thus involve one person selecting from a larger menu of services from a cloud provider and spinning them up for a fraction of the cost that would have required perhaps dozens of engineers and admins for the on-premises equivalent.

And yet.

For cloud deployments, automation does not necessarily replace the role of the DevOps team members. Instead, their roles must change to handle the complexity. In short, automation can be difficult to set up and maintain — while considerable people power is required.

“There is so much to recreate that the automation can be tricky. The expectation is to have zero downtime for deployments layer on the complexity,” Ravi Lachhman, a technical evangelist for application monitoring platform provider AppDynamics, said. “With the increase in those moving parts, the human element has to keep up.”

Lachhman described how his evolution as a software engineer compares to his role a decade ago, when he had “no purview as a JEE developer in 2008 to much of the build — much less the networking and storage that was needed.”

“Fast forward to today, and the dev team can be packaging up connectivity items such as Istio and defining storage mounts inside a container,” Lachhman said. “The traditional system engineering skills are moving into dev thanks to cloud native architecture.”

However, the challenges associated with cloud native deployments and making the necessary changes in the roles of the DevOps team members are not necessarily harder to do compared to traditional environments, Mitchell Hashimoto, founder and chief technology officer of HashiCorp, said.

“I disagree that the systems or general requirements are any (or much) more complex than non-cloud native workflows,” Hashimoto said. “We’ve always had development, deployment, security, networking, etc. challenges and I wouldn’t call traditional non-cloud native datacenters simple.”

One of the primary advantages cloud adoption offers is the ability to deploy more applications quickly and therefore deliver more business value, Hashimoto said. “But this strains the existing systems we’ve had in place, so we must bring all of those along with us: development, security, operations, networking and more,” Hashimoto said. “And to do that right means bringing along automation tooling, cross-functional teams and more people.”

The Dev and Ops Overlap

The facility and speed at which software can be deployed on cloud native platforms also require a shift in roles, so that operations-related tasks do not get in the way of delivery cycles.

“It is the mission of modern IT operators to get out of the critical part of the continuous release process. This requires adopting a declarative paradigm to managing data center and cloud infrastructure, instead of manually responding to ad hoc requirements,” Volk said. “This declarative management approach also requires IT operations to understand the basic principles of coding, without becoming a pure-blooded software developer.”

For the developers, cloud native patterns and practices shape their roles as well.

“Instantly and continuously validating new software features on a small group of production customers, without causing significant user experience deterioration becomes the most critical skill for cloud native developers,” “Volk said. “Exactly defined and comprehensive user experience metrics and exact monitoring instructions for these metrics are becoming part of each build. This enables developers to validate that customers are actually using their software in the intended manner and that they are completing their desired transaction in an efficient manner.”

DevOps or NoOps

Another change in DevOps roles involves the shift to make all parties involved in the development and operations process. “We used to have a separation between operations and development teams that are no longer there. I attribute this to what I call a ‘NoOps’ approach that’s come in response to complexity,” Andreas Grabner, DevOps activist for Dynatrace, said.  “NoOps means we’re shifting who’s responsible for things, as automation comes into play. We’re seeing traditional ops teams moving more toward helping modernize their organization, providing more services to the rest of the organization.”

However, Tseggai disagreed with the concept of NoOps, at least how the nomenclature applies to serverless. “The role of ‘ops’ hasn’t been eliminated, but rather, it’s been shifted. Exactly how and where is a matter of the engineering culture and vision within the organization,” Tseggai said. “For teams with strong culture and leadership, ops has been shifted left — as a result of more time and energy that ops has to focus on product concerns such as disaster recovery, continuous delivery, feature flagging, chaos engineering and performance engineering, to name a few. If an engineering org were to foolishly rebrand DevOps into NoOps, they would be running a real risk of alienating engineers whose skills are in high demand.”

Down in the Trenches

The shift in roles obviously implies a shift in culture as well, as DevOps becomes honed and focused on cloud native deployments.

In the case of HSBC’s shift to cloud native deployments, Cheryl Razzell, global head of platform digital operations for HSBC Operations, described during the recently held DevOps World | Jenkins World 2018 in Nice, France, how the banking firm’s DevOps embraced a new way of thinking. “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 acquired people from outside of the banking sector on purpose because they want to change their culture from within and they want to bring out that new ideas.”

HSBC, for example, recruited people from Google, Amazon, and Microsoft, from startups and from different backgrounds and different sectors from outside of the banking sector to complement the teams that already understand how the bank’s networks worked. “There’s synergy between the teams with new ways of working versus some of the bank’s legacy products and some of the bank’s processing,” Razzell said. “I think you need both to complement the journey.”

In practice, cloud native DevOps is also developer-centric, Brian Dawson, a DevOps evangelist at CloudBees, said. “Those involved in cloud native development lifecycle patterns and practices assume they’re operating in the silo-less environment,” Dawson said. “But many organizations are still trying to figure out how to properly integrate all of the teams within DevOps. “For your standard application, there are operations and security [people], for example, who haven’t yet figured out how to inject themselves into cloud native development.”

However, at least semantically, DevOps does not define a team, but instead, represents a culture, or a set of practices. A “team does both development and operations,” Marko Anastasov, co-founder of Semaphore, said.

“You need to have easily repeatable processes and fast feedback loops because every developer needs to be able to contribute, [and] deploy a new microservice very quickly,” Anastasov said. “If we’ve decided to build the product as a composition of many unique components — responsibility needs to spread out as well. On the other hand, when you’re dealing with a large entity like base infrastructure and networking which uniformly covers the whole organization, this is when responsibility is naturally centralized into dedicated ops roles.”

AppDynamics, CloudBees, Dynatrace, Semaphore, Stackery, and VMware are sponsors of InApps Technology.

Feature image via Pixabay.