The Shifting Nature of CI/CD in the Age of Cloud Native Computing – InApps 2022

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

All along, the idea of the cloud has been one of abstraction. Moving storage to the cloud not only means you can’t point to the physical drive where your data is stored, but storage available is theoretically limitless and available on-demand. Similarly, moving compute to the cloud means your processing power can be increased exponentially, without the need to procure and provision physical servers.

At the same time, while the move to cloud has solved some problems, other problems have inevitably come to take their place. Now, with the move to cloud native technologies, we are again seeing a new level of abstraction where technologies previously reserved for non-cloud scenarios are moving to the cloud and experiencing the increased capabilities and complexities that come with it. At its core, the move to cloud native DevOps means yet another transformation to undergo and a new set of ideas to incorporate. In practice, this means new tools and workflows, and the shift has wide-ranging implications.

The move to “cloud native,” however, is a further level of fragmentation beyond much of this last decade’s move “to the cloud”. Whereas virtual machines were basically that — abstracted servers running much as a server would, with complete environments and often entire applications within it — microservices have come along to break down virtual machines into even smaller components. Nowadays, an application may comprise tens, hundreds, even thousands of microservices, each performing its own task, and deploying such an application comes with new benefits and challenges.

Defining Cloud Native

According to the Cloud Native Computing Foundation’s (CNCF) definition, “cloud native” is a paradigm wherein organizations “build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds” and is exemplified by tools such as “containers, service meshes, microservices, immutable infrastructure, and declarative APIs.”

Brian Dawson, DevOps Evangelist at CI/CD automation engine CloudBees, explained that cloud native involves a full spectrum shift.

“Not only are applications deployed to the cloud, but they are built, tested and staged on the clouds, and the tools driving that workflow also tends to be cloud-based versus traditional on-premise solutions,” said Dawson. “To fully embrace cloud-native development developers and organizations have to adopt cloud-centric tooling, as well as develop new muscles to use those tools.”

While the move to “the cloud” is central to both of these definitions, Dan Garfield, chief technology evangelist for cloud-native CI/CD platform Codefresh warns that the tools themselves, and the intent with which they’re used, matter more than the location when it comes to “cloud native.”

“A common misconception is that ‘cloud-native’ means ‘on the cloud.’ It might be a bit of a misnomer. Lots of organizations have ‘on prem’ data centers that use Docker, Kubernetes, Helm, Istio, Serverless and other cloud-native technologies,” said Garfield. “Cloud native is more of a mind set for how application definition and architecture looks than a description of where those services are running.”

Not to get too caught up in definitions, but they are critical to understanding how the shift to cloud native technologies are affecting CI/CD, an integral component of cloud native DevOps.

Increased Speed, Increased Complexity

The first effect of moving to a fully cloud-native strategy on CI/CD, explains Garfield, is the increased complexity from handling singular applications to vastly more multifaceted microservices.

“The impact of cloud native on CI/CD is profound. As engineering teams adopt microservices the number of pipelines they need is growing exponentially,” said Garfield. “Now instead of needing to support a release process of a single monolith, they need to support a release process of dozens of microservices.”

According to Ravi Tharisayi, director of solutions strategy at New Relic, the shift to cloud native can be a double-edged sword and adapting your continuous integration and continuous deployment (CI/CD) tools and practices is mandatory to keep pace.

“Overall, cloud-native offers opportunities in terms of velocity and scale but also increased complexity. The lines across the stack are increasingly blurred, there are more dependencies and more layers,” said Tharisayi. “As cloud-native approaches gather steam, CI/CD practices have to evolve to maintain stability as you increase speed. Because without the right guardrails, it’s like attaching a rocket ship to a go-kart. It’s not a very fun ride.”

One way to handle the increased speed is through increased automation, which Tharisayi points to as critical for cloud native CI/CD.

“A culture of instrumentation, automated as much as possible, is critical to ensure a high-functioning CI/CD pipeline,” said Tharisayi. “Given the complexity for cloud-native environments, experimentation becomes a core capability that your CI/CD pipeline must enable. Whether it’s canary deploys, A/B tests, blue-green deploys or a combination of these, the right deployment strategy can help test new features with velocity to improve the customer experience.”

Cloud Native Automation Shifts Responsibilities

Increased automation not only means increased deployment speed, but also an expanded role for developers who contribute to automation via GitOps, as Codefresh’s Dan Garfield explains.

“Cloud native applications universally put configuration into code which puts how an application runs much closer to the application developer than before,” said Garfield. “In the old world, operations would worry a lot about how an application would run and how it would be deployed. One side-effect of cloud native is that developers take more responsibility how their application will run and how it gets deployed.”

Brian Dawson further characterizes the expanding the role of the developer as part of a “no-ops” approach.

“Cloud native applications are built for (and encourage) an Agile/DevOps team on steroids, meaning the cloud native lifecycle very much emphasizes a ‘full-stack’ developer-centric ‘no-ops’ approach, by conflating traditional siloed functions into a short, automated lifecycle,” said Dawson.

The Expanding Spectrum of DevOps

In the end, Tharisayi explains, the move to cloud native DevOps is one that, like any technological adoption, happens along a spectrum and is ever-ongoing.

“The very nature of DevOps should empower teams to logically adopt new technologies that help deliver increased engineering velocity and customer value. Thus, in this sense, your DevOps efforts are never ‘done’, but are constantly evolving to exploit new opportunities including the use of new technologies. So the popularity and adoption of cloud native approaches by DevOps teams in many ways represents a continuation of this spirit rather than a reset,” said Tharisayi. “There’s a tendency to think of things like migrating to the cloud or adopting CI/CD as some kind of end state, but the reality is there’s never an end state. The pace of technology is moving so fast that DevOps teams are constantly challenged to evaluate new approaches to remain competitive and must develop a core competence in adapting quickly — both in terms of process and technology.”

The Cloud Native Computing Foundation is a sponsor of InApps.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.