Making an automated mechanism for building and deploying software workloads onto cloud platforms was a superb idea. Since 2015, the task of building a business around it has, at least on paper, been tackled by the open-source community. Today, its champions are the names we recognize: Google, VMware, Microsoft, Amazon (if reluctantly), Red Hat, and by extension, IBM. Containerized workload automation must be a somewhat viable business, otherwise, those companies wouldn't have swallowed it up.

"Cloud-native computing" is a great idea that would have been poison for any single vendor to have claimed and defended just for itself. Revolutions have always been great (at least the successful ones) as long as someone else leads the charge, and you're not the one getting bloodied. The overall goal of cloud-native is to unseat a dynasty: to eject virtualization from its throne at the center of the data center economy, and in its place install workload automation. From a distance, the task resembles replacing a refrigerator with a washing machine.

Yet witness how Google swiftly and adeptly pulled off this masterstroke: At exactly the time that Docker, a workload deployment system, sought to leverage the gains from the movement it sparked, Google started its own movement at a campsite down the road. It took an in-house workload orchestration project (even its original name, Borg, delivers gorgeous irony); offered it up as an open-source initiative; stewarded its evolution into the raison d'tre for workload portability; marginalized the Docker whale; infused Red Hat, VMware, to a lesser degree Microsoft, and kicking and screaming, Amazon with the workload portability bug; and cemented Kubernetes' place as the axis around which a software ecosystem revolves -- all without ever "pulling a Microsoft" or being accused of monopolizing a market, and all by leveraging other people's efforts.

Minimum investment, maximum payoff, clean shirts. A clinic on influencing an industry. If only all insurgencies could work like this.

But is the scale of this revolution broad enough to have genuinely changed the way we live and work? That's the type of question we've created Status Report to help us answer. It aims to take the ten most important categories for any technology's or platform's capability to influence its users' businesses and livelihoods, examine each one in isolation, score its positive and negative factors separately, then toss them all onto a graph to see if its capacity for change is as great as our proclivity for emotion. Through this cleansing process, we may be able to extrapolate pertinent, relevant facts about whether technology makes a genuine difference.

Today, when I refer to "cloud-native" technologies, there's a general presumption that I'm referring not just to "containerization" (another terrible word) but specifically to Kubernetes, and the ecosystem of open source components that comprise its "stack." The Linux Foundation maintains a project called the Cloud Native Computing Foundation, whose job is to nurture new technologies in this space, as well as promote and support all of them.

Three years ago, I was told emphatically that presuming containerization meant Docker or Kubernetes, or any one name, would be contrary to the spirit of the open-source movement. Openness, I was sternly corrected, was all about choice, and ensuring that customers are never again locked into one way of doing things. Now, of course, it's an all-Kubernetes stack all the time. The CNCF's accreditation program for IT professionals in the cloud-native space is called Certified Kubernetes Administrator. Its competition has been kicked to the curb, then stomped on and flattened, followed by being declared not only irrelevant but never all that relevant to begin with.

The original, and still true, meaning of containerization is the method of packaging any workload with all the tools and dependencies it needs so that it can run on any cloud platform without modification. Think of a camper who carries everything she needs in her backpack, as opposed to a traveler who carries a light briefcase but expects to stay in a hotel. (Actually, virtualization would be like a traveler who drags the entire hotel behind him on chains.)

The problem with the term "cloud-native" is that it implies a software workload stays in one place throughout its lifecycle. That's not what "cloud" is about. A cloud platform is an abstract plane whereby a workload is addressable through the network at all times, regardless of where it is. This is the actual value of the concept: It ensures isolation (for security), portability, and at the same time, accessibility. This reduces the cost of change for enterprises charged with maintaining it. Historically, IT has kept costs low by maintaining system configurations until their platforms can no longer sustain them, and usually beyond that time. "Cloud-native" flips the whole maintenance cost argument on its head: Ideally, it ends up costing organizations less to continually adapt their own workloads to new situations and requirements at a moderate pace, than to constantly pour more effort and capital into maintaining IT systems' stability.

In the end, this is why Kubernetes won. (I expect to be told once again, it's not about winning or losing. The people telling me this will, without exception, be the victors.) Yes, it's the packaging of the workload that enabled its system of orchestration. But it's in the orchestration that customers find value.

The software industry is, first and foremost, about intellectual property. The open-source movement is largely an effort to neutralize the legal, financial, and other natural advantages a competitor may attain by having thought of the idea first. It forces its market to be about something else.

In a market where the incumbent is the leader by way of ingenuity, that something else is usually an effort to drive the value of that advantage down through product homogenization, and substitute service and support as value-adds. This is how Linux first gained a foothold in the enterprise. However, in an infrastructure market, where the incumbents reinforce their value propositions by stifling change instead of driving it, an open-source player has the unusual opportunity to reverse the situation: to encourage the developer community to foster ingenuity among themselves, as a tool for disruption.

As Docker, and immediately afterwards Kubernetes, proved, this plan can work out rather well at the outset. But then suddenly it hits a wall. It takes tremendous human effort to sustain even a moderate pace of change for any technology that has established itself in its market -- an effort that has traditionally been supported through vendors' IP license fees. When IP is at the core of a market, its incumbent has the luxury of slowing down ingenuity to a pace it can comfortably manage (see: Apple, Microsoft, Qualcomm, Amazon). That method doesn't work anymore if the incumbent is a shared entity: It must evolve or die. And since the benefits of that ingenuity are shared by design, it takes even more effort to spark the incentive that encourages ingenuity in the first place, especially when everyone knows ahead of time that such ingenuity must be short-lived (see: "Union, Soviet").

A successful business is all about minimizing risk. Information technology is the most volatile component of any business. The types of organizations that take a risk here are often the newer ones, or perhaps the very old ones for whom casting off their mortal coils has become a mandate -- companies with very little pre-existing baggage that's not worth losing anyway. Early adopters are the groups that have calculated the potential for significant gains, either through disruption or just pure innovation.

But the earliest adopters of Kubernetes and cloud-native technologies include public cloud service providers (of which there are few), communications providers (of which there are few), small businesses, and startups. Although they're arguably reaping benefits, they have yet to lay down the kinds of patterns for success that other industries can follow. In financial services, healthcare, government, and incredibly, logistics, there remain highly placed individuals in IT, including at the CIO level, who have never heard of Kubernetes or "cloud-native" or containerization. Not that they've rejected them, or would want to do so -- they don't even know what these things are. Such individuals tend to be myopically focused on other institutions less risk-averse than their own. Until these other firms take the plunge, they won't know a plunge can be taken.

Now let's score each component of our evaluation individually:

What the cloud-native ecosystem (CNE) intends to do is give vendors, both old and new, something amounting to a freeze-dried infrastructure kit. They can get into the business of producing products and services, so long as they don't make their involvement about intellectual property or exclusivity. [+7] What its benefactors do not do -- perhaps because they cannot -- is provide instruction or guidance about how to provide distinguished services around this business [-4], which is one reason why the earliest open-source trailblazers, such as Red Hat, have come out on top thus far. [Net: +3]

From the outset, Kubernetes' engineers have said they'll know their efforts have pierced the envelope into the realm of permanent success once everyone finds it a dull and boring topic already. Their experience comes from Linux. Linux is dull and boring. Take it from a journalist who has been paid to come up with reasons to make Linux exciting again.

But Linux established itself through homogenization -- by driving down the advantages gained through ingenuity. Kubernetes actually took the reverse route: It disrupted a market that could have comfortably fed off of the first-generation virtualization until the end of time. From the outset, however, no single player has attained a native competitive advantage -- no one has "come out on top." This is a problem for prospective customer organizations that typically wait for someone to emerge from the rubble, before investing in IT. [+2 | -7, net: -5]

This is Kubernetes' present dilemma: For the CNE to thrive, it must continually spawn new entities and innovative projects. Because Kubernetes is the axis of the ecosystem, those projects cannot be another orchestrator, but rather another service mesh, logging analytics tool, or key/value store. Because the axis of the ecosystem is strong, you can build a business around a product or service that orbits it. . . for a while. [+5]

Actual map of the CNCF's Cloud-native Ecosystem. Magnification available from CNCF.io

As the CNCF's own landscape map reveals all too clearly, even without a magnifying glass, this leads to dozens of startups essentially competing for the same market spaces. Venture capitalists will find it difficult to invest in a project that, by design, must compete with dozens of other projects that appear on the surface to be functionally identical. While we may call this a meritocracy, Charles Darwin would have called it something else. [-7, net: 2]

As noted in the Executive Summary, the components of the CNE must evolve or die. That's not necessarily a bad thing; indeed, it leads to consistent improvements. [+8] But it requires a long-term vision -- for 10, 15 years down the road -- that few, if any, have yet articulated. To withstand a threat from a future disabler, Kubernetes and its satellites cannot afford to become, like Linux, dull and void. They must continue a level of sustained pressure just to remain relevant. They are, in a word, hungry. Over time, this creates a vulnerability, increasing the likelihood of a future competitive challenge. [6, net +2]

At a certain point, a product or service becomes so fundamental to a market that its existence as an enabling factor is mandated. The Kubernetes model of application deployment is now a fact of the public cloud. [-7] It has yet, however, to significantly penetrate the small enterprise data center, and not even its integration into the latest VMware vSphere appears to be changing this fact measurably. So if you're in the cloud services business, and your customers include medium to large enterprises, you have to position yourself differently than you would for a small company that's starting fresh with the newest tools and methods. [-5, net +2]

The shift to a cloud-native operating model can, and has, revolutionized corporate IT [+7]. . . for those organizations capable of understanding it, and meeting its requirements. Kubernetes is a hungry beast. As of yet, there has yet to be a single, successful, persuasive initiative to educate the organization as a whole, including the C-suite, as to the end value of cloud-native, outside of IT departments and software developers who have already been convinced. [-6, net: +1]

Through having infiltrated the mindsets of the leading data center virtual infrastructure vendors, the CNE is now a measurable contributor to the world's gross domestic product. [+7] While some effort and capital continue to be expended toward buttressing pre-existing systems and methods, most of those expenditures have yet to be directed specifically against the advancement of the CNE. [-3, net: +4]

.

Perhaps the best measure of whether a concept has thoroughly permeated the fabric of a society is the degree to which its peoples benefit without their having to pay attention to it. The public cloud sustained the tremendous surge in user demand brought on in the onset of the global pandemic. No other industry has fared as well in the face of potential economic peril. [+8] What has yet to materialize, although it still could, is a sustainable system of education and certification around cloud-native IT, beyond just a bunch of YouTube videos and TED talks. [-2, net +6]

Has this integration helped advance people further forward, making them more capable? Through the enablement of real-time video communications that were not feasible with the first-generation virtualization, undoubtedly yes. [+6] Through the incidental enablement of certain negative aspects of social media that would not have been feasible otherwise, no. [-2, net: +4]

.

The cloud-native ecosystem is the strongest collective community of software developers and IT engineers ever assembled. [+9] Granted, it did not metastasize under its own power -- it required leadership and, certainly at the outset, a positive vision. It also adopted a mandate for personal empowerment and even betterment that no other information technology initiative has ever achieved.

Yes, there are pockets of community initiatives to reinforce those resources devoted to maintaining old, and admittedly dated IT systems. But these pocket communities do not form an ecosystem themselves. What's more, we're seeing evidence that these efforts are at last collapsing. [-3, net +6]

As technologies fare with this new series, a score of +2 or above is very strong. As a geometry teacher may point out, it's possible for an evaluated technology to post weaker net scores in one or more categories, and end up yielding stronger final influence scores. This is intentional. These categories are not intended to represent cumulative virtues. Should Kubernetes ever find that magic formula that guarantees its vendors revenue for the long-term, as it very well may, that final score could be pulled closer to 0, or at least toward the centerline of the X-axis?

But if a technology cracks the customer value barrier, so that not only is it necessary but desired, then that final influence score could skyrocket. What company has ever sustained itself in business for an extended period of time, earning value for its shareholders and also benefitting communities and society as a whole, without also generating products and services that have high perceived value? And what industry has ever come to fruition with a plurality of organizations that could successfully accomplish the first two, but not the third?

Here for the first time, we have enough background data to render a comparison between evaluated technologies. Notice in this comparison, we've zoomed in somewhat, narrowing our scale from 10 points in both directions to 3 points. Our benchmark is the World-Wide Web as of September 12, 2001, when that new technology faced the opportunity to bring a society together. It posted a strong positive score that leaned somewhat toward societal benefits, and away from corporate benefactors. 5G edge computing has nearly found that balance between altruistic and self-serving interests and could post a much stronger influence score if it can make a stronger value proposition.

The CNE is highly slanted toward the altruistic, self-sacrificing, part of the chart. That's a good thing, but only for a short time -- which is why the metaphor for this series is a pendulum.

More:

Is cloud-native computing as influential as its stacked up to be? [Status Report] - ZDNet