7 Promises, and Potential Pitfalls, in Adopting a Cloud Native Approach to DevOps – InApps 2022

This post is part of a series, sponsored by CloudBees, exploring the emerging concept of  ‘Cloud Native DevOps.’

The cloud, at one level, is the problem. From the perspective of the people at the right-hand side of the DevOps portmanteau, “the cloud” is that part of an enterprise’s information technology that resides outside the organizational model of the data center. It’s the part they don’t manage, and if they don’t manage it, then it’s just “Dev.”

I’ve had the good fortune in recent months to conduct DevOps research from the other side of the pond, with  AFCOM, an organization that supports data center operators, analysts, designers, and administrators. What I’m learning from these Ops-centered folks has been eye-opening, and in more than one situation, mind-blowing. These are people who are embracing DevOps just as much, if not more, than the software development community. But when one compares the DevOps ideal as they perceive it with the way devs present it, there are profound differences, some of which the Ops side clearly perceives, and most of those they characterize as serious obstacles.

When I took the liberty of introducing some of their ideas to people you know from reading InApps, many of their reactions illuminated what I will portray as a deep division between each group’s comprehension of the role of the other. That division becomes fractious when I bring up the possibility of an emerging set of principles in the DevOps tools community: cloud native DevOps.

What am I talking about? Recently I drafted seven possible definitions of the phrase, based on discussions I’ve been involved with, interviews I’ve conducted, presentations I’ve witnessed, and a number of projects with which I’ve recently been involved — including one that became an epic journey into the realm of “Middle Ground,” in the motif of Lord of the Rings. And I shared some of these ideas with DevOps experts, with whom I’m consulting for the production of a forthcoming ebook for InApps.

What I learned from this exercise is that DevOps may not be what any of us think it is. While we’ve often talked about the goal of DevOps being “software delivery” or “service delivery,” from the Ops side of the automation chain, “delivery” is where the maintenance and re-integration work begins, not ends. Delivery of software, I’m told, is the start of something. And the danger of an approach that ends up meaning the same as “cloud native” does to many enterprises is that it outsources the Ops process to someone else.

Sure, DevOps is really easy, said one fellow, if the Ops part were just imaginary.

What follows is a list of some of the glossary definitions I’ve been trying out for the definition of “cloud native DevOps” for purposes of InApps, along with a summary of the feedback I’ve received from all sides, including some vendors, as well as some folks in both the Dev and Ops spaces:

#1: It deals with cloud native development

Cloud Native DevOps is a methodology for planning and automating the development of applications intended to be designed, staged, and deployed on a public cloud platform.

What’s Wrong with That: DevOps is only DevOps, I’m told, when it automates the development and operation of all applications. If we go subdividing our processes into the cloud native ones and the not-so-cloud-native ones, then we run the risk of rebuilding the silos we thought we had already disassembled.

Put another way, it would be wrong to create a DevOps for only one pool of development. Now, maybe it’s feasible to implement such a methodology if and only if the organization will develop only cloud native apps throughout its entire existence. But to restrain the organization to any single platform, I’m told, is antithetical to another of the goals of DevOps: to decouple processes from infrastructure.

#2:  It has to do with where the pipelines are staged

Cloud Native DevOps is a means of implementing DevOps throughout an organization by staging its platform in a cloud native service, where it may be equally accessible by all stakeholders.

What’s Wrong with That: For DevOps to be trusted by everyone in the organization, it needs to be manageable by the Ops team just like every other part of the organization’s software platform. Moving it to a public cloud separates the automation process from the people in the organization who, at least ostensibly, are charged with managing automation. What’s more, it sends the signal to those people that they should not be trusted with managing and overseeing the automation toolchain at the heart of their business.

#3:  It speaks to the goals of cloud native development

Cloud Native DevOps is a way of implementing the principles of DevOps in a way that enables everyone in an organization to move toward a better means of automating their software development processes, with principles that are not bound or tied to their existing infrastructure.

What’s Wrong with That: Organizations are moving away from implementing every component of an application (even cloud native apps) in the public cloud. While their apps may be hosted on platforms like GKE, PKS, and AKS, their databases, data streams, and data stores are moving back on-premises. In many cases, new government regulations are actually mandating these data stores be moved back on-premises before the end of this year.

Therefore, I’m told, any software delivery automation process must exist outside of the public cloud. Indeed, it may not be legal for certain US-based and Europe-based industries to operate a process that manages personally-identifiable information (PII) through a cloud native process. Of course, our present administration may elect not to enforce that regulation, but that’s not enough to make enterprises here take the risk.

#4: It doesn’t mean “public cloud” but all clouds

Cloud Native DevOps is a set of principles that enables organizations to better automate their software delivery and servicing processes through the implementation of cloud-inspired methods, the adoption of which creates opportunities to provide more valuable services to customers.

What’s Wrong with That: Even if it is the ultimate goal of the organization to move all of its applications and services onto a cloud platform — even a hybrid cloud platform like OpenStack — for the foreseeable future, a significant chunk of workloads will remain where they are. DevOps, I’m told, is not just about automating the building of new applications but the maintenance of existing and old ones.

Cloud-inspired methods, people on the Ops side tell me, are the wrong methods to be inspired by. They suggest the outsourcing of operations and oversight to a third party that has no direct interest in the delivery of value to the organization’s customers. That, in and of itself, is antithetical to the goal of DevOps as well as, I’m told, running opposite to the ITIL lifecycle, in which new value is generated through the re-absorption of the lessons from implementing methods rather than the elimination of those methods.

Or, as one DevOps advocate from the Ops side told me, all this cloud-centered stuff is bull [hockey]. If everyone started relying on Amazon to handle their methods for them, I’ve been told, there would be no DevOps.

#5: It’s the seed from which a greater DevOps may grow

Cloud Native DevOps is a way to jumpstart your DevOps journey by letting the experts in the field set you up with best practices and methods that are already tried and proven by organizations that have already succeeded in their digital transformation.

What’s Wrong with That: There is no single “DevOps template” that can represent a “one-size-fits-most” approach. DevOps, I’ve been told very explicitly, is a journey that all organizations should undertake, but which will yield unique methods for each one, and will result in the creation of pipelines and automations chains that not only fit each organization exclusively but which will grow and evolve along the way.

What’s more, I’ve been given reason to believe there is statistical evidence that will show that, when an organization attempts an “instant DevOps” approach to jumpstarting its journey, more times than not, it will fail. It would be a mistake for me, it was said, to present any DevOps methodology as though it could be adopted by a multitude. The best DevOps journeys, I’m told, have in mind the goals of improving performance and generating value for customers. There is no cookie-cutter approach to attaining either of these goals.

#6: It’s the fast track to DevOps, wherever it ends up being hosted

Cloud Native DevOps provides you with a platform that can guide you and your organization along your way to developing the unique and principled automation approaches that will benefit your developers, operators, and eventually your customers, in a more rapid, self-provisioning fashion.

What’s Wrong with That: During more than one demonstration of DevOps-oriented platforms at VMworld 2018 in Las Vegas last week, folks in the audience spoke up — maybe not fervently or passionately, but certainly assertively: DevOps, they said within earshot of the presenters, is not a tool and is not a platform.

Maybe there are ways in which a provisioning system, similar to a cloud native approach like Amazon’s, can help you create pipelines for part of the automation chain, I’m told — or, in a different context, for a pipeline that pertains to a limited span of the application lifecycle. But no cloud native chain, I’m told quite emphatically, can apply to all parts of that lifecycle, especially when an application artifact emerges from testing. You may be jumpstarting something with a cloud native, self-provisioning pipeline, and you can’t exactly say that’s not a valuable thing, but it’s not the entire toolchain — and thus, it’s not really Dev + Ops.

What’s more — and this is extremely important — Just because a tool or platform does not encompass DevOps end-to-end, or that both departments use the same tool in different ways (I thought those little butler guys looked familiar), does not mean that DevOps itself is not end-to-end.

#7: Oh, just shut up and apply the lessons of cloud native to DevOps already

Cloud Native DevOps is a flavor of DevOps where the principles of automation, faster iteration, and timely software delivery, become applicable to an organization whose entire IT operation seeks to become more tight-knit, agile, and competent in their work.

Developers, I was warned once, seem to think nirvana is only possible when everyone else in the organization things like developers. It’s not DevDev. No platform can teach us how to work better. It’s our job as developers and/or operators to instead build platforms that adapt to the best way we work together, not to rethink who we are and how we work to meet the needs of the platform.

(There’s a wonderful digression I could apply here about the urgency for “culture change” just so everyone can be more receptive to a particular tool, but I’ll leave that for another piece.)

Besides, there are principles such as service transition, service transition, and service operation that derive from the era of ITIL and IBM’s “Yellow Book,” which remain at the core of IT operations. These are cyclical components that proceed once service delivery puts the proverbial ball in play. If anything, it was suggested to me, we should be applying the principles and practices that we learned from the 1980s onward to the platform we use to automate our service chain. If we outsource the management of that chain to someone else, some folks implied to me, it would be as good as selling out to Microsoft or Amazon or Google outright.

“Think of DevOps,” I wrote for ops professionals, “as a successful demonstration of the principle of trust.” Just as software is the product of the Dev side, infrastructure is the product of the Ops side — and this truth becomes more and more evident with the success of infrastructure-as-code. Outsourcing the construction and management of that infrastructure to anyone else places that trust in jeopardy, and risks relegating DevOps to being a fancy word for “hackers.”

Title photo of International Astronomical Union Crater 302, photographed by Apollo 10 in May 1969, in the public domain.