Two months ago, “Cloud Native” was something of a new term, adopted most visibly by the Cloud Foundry project; a term both aspirational and unburdened by legacy at the same time. As of this week at OSCON, it’s a statement, borderline manifesto. As if it wasn’t enough that Google and a host of others adopted the term as well, it now has its own open source foundation – the imaginatively titled Cloud Native Computing Foundation. In the wake of its relatively sudden emergence, the obvious questions are first what is cloud native, and second what does it mean for the industry?
As far as the term itself, the short answer is a new method for building applications. The long answer depends in large part on who you ask.
There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to deployment. High uptime. Ephemeral infrastructure (cattle not pets). And so on.
Bigger picture, the pattern Cloud Native platforms have in common is that they are a further abstraction. Individual compute instances are subsumed into a larger, virtual whole, what has been referred to here as a fabric.
Where the consensus breaks down is what software – precisely – one might select to achieve the above.
One of the most interesting aspects of OSCON in the year 2015 is what may be taken for granted. In the early days of the conference, attendees were the rebel alliance, insurrectionists waging war against the proprietary empire and desperately asserting their legitimacy at the same time. Today, open source has won to the degree that you hear phrases like “single-entity open source is the new proprietary.” As Mike Olson once put it, “you can no longer win with a closed-source platform.” This victory for open source has many implications, but one much in evidence at OSCON this year is choice.
With open source rapidly becoming the default rather than a difficult-to-justify exception, naturally the market has more open source options available to it. Which on the one hand, is excellent news, because more high quality software is a good thing. Choice does not come without a cost, however, and that’s particularly evident in what is now known as the Cloud Native space.
One of the biggest issues facing users today is, paradoxically, choice. In years past, the most difficult decision customers had to make was whether to use BEA or IBM for their application server. Today, they have to sort through projects like Aurora, Cloud Foundry, Kubernetes, Mesos, OpenShift and Swarm. They have to understand where their existing investments in Ansible, Chef, Puppet and Salt fit in, or don’t. They have to ask how Kubernetes compares to Diego. Bosh to Mesos. And where do containers fit in with all of the above, which container implementation do they leverage and are they actually ready for production? Oh, and what infrastructure is all of this running on? Bare metal? Or is something like OpenStack required? Is that why Google joined? And on and on.
Even if we assume for the sake of argument that the Cloud Native vision will be an increasingly appealing one for enterprises, how to get there is an open question. One that, with rare exceptions such as the Cloud Foundry Foundation’s OSCON slides, few of the participants are doing much to help answer concerned as they are with their own particular worldviews.
Beyond the problem of choice, Cloud Native is, as mentioned previously, deliberately and explicitly exclusionary. It posits that there are pre- and post-cloud development models, and implies that the latter is the future. Certainly it’s the recommended approach. Traditional packaged applications or legacy three-tier architectures, in other words, need not apply.
But if we step back, Cloud Native also represents the return trajectory of a very long orbit. Decades ago, early mainframe virtualization capabilities notwithstanding, the notion of computing was a single large machine. When you deployed a mainframe application, you didn’t decide which mainframe, it went to the mainframe. With the subsequent mini-computer and client-server revolutions came a different notion, one further propagated and accelerated by Infrastructure-as-a-Service offerings: individual servers – physical or otherwise – as the atomic unit of computing. Instead of hosting an application on a large machine, as in the mainframe days, architectures were composed of individual machine instances – whether measured in the single digits or tens of thousands.
This has been the dominant computing paradigm for decades. While the primary obstacle to using the first wave of PaaS platforms like Force.com and Google App Engine was their proprietary nature, their break from this paradigm was a secondary obstacle. PaaS, like Cloud Native today, implies a fundamental rethinking of the nature of infrastructure. Where once applications would be deployed to a forest of individual instances, these platforms instead would have users push them to a single fabric – one large, virtual computer. Almost as if we’re back to the mainframe, if the mainframe was a federation of large numbers of individual instances integrated via systems software with scheduling capabilities.
The current Cloud Native crop of software isn’t the first time we’ve seen this “single virtual computer” concept made manifest, of course. There are many examples of this extant today, the most familiar of which may be Hadoop. There are no individual Hadoop servers; there are instead fleets of machines linked via distributed filesystems and schedulers to jointly execute large scale data operations.
In that respect, Cloud Native can be thought of as Hadoop for modern applications. Applications aren’t pushed to a server or servers, they’re deployed to a fabric which decides where and how they are run. Running an application on a single large computer requires that it be constructed in a fundamentally different way than if it were run on lots of traditional instances, which is why Cloud Native is deliberately and explicitly exclusionary.
Many applications will never make that jump; it won’t be technically feasible or, more likely, economically practical, to become Cloud Native. But the trajectory at this point seems clear. Just as organizations today take their hardware cues from internet pioneers like Facebook, Google or Twitter, so too will they be following the internet pioneers’ lead in software infrastructure. If a company builds its datacenter like Facebook, why run it differently? Not in the binary, all-or-nothing sense, but rather that the idea of Cloud Native, virtual single-computer infrastructures or fabrics will become a mainstream deployment option in a way that they are not today. The question is: on what timeframe?
That question is incredibly important, because Cloud Native going mainstream would have profound implications for vendors, open source projects and hosted offerings alike. Cloud Native becoming a first class citizen, if not the default, would be a major opportunity for the projects branded around projects such as Cloud Foundry or Kubernetes, the vendors that support those projects and the companies that offer them as a service – the likes of Google, HP, IBM, Pivotal or Red Hat, in other words. Any transition that impacted standard notions of infrastructure, meanwhile, would require projects (e.g. OpenStack) or vendors (e.g. Amazon, VMware) focused on that paradigm to adapt, and potentially implement one of the Cloud Native projects themselves.
To date, in spite of the long term availability of fabric-like PaaS products – Force.com debuted in September of 2007, some thirteen months after EC2 – infrastructure models that resembled traditional physical architectures have dominated the market. Nor should we expect this crown to be surrendered in the near term, given Amazon’s comical growth rate. But an increasing number of datapoints suggest that the traditional infrastructure paradigm will be at least complemented by an alternative, whether it’s called Cloud Native, a fabric or a platform. The question is not whether Cloud Native will be a destination, then, but rather how one gets there.
Disclosure: Amazon, Ansible, Chef, CoreOS, HP, IBM, Pivotal, Red Hat, Salesforce.com and VMware are customers, as are multiple OpenStack participating projects. Facebook, Google, Puppet and Salt are not currently RedMonk customers.
