In some sections of the IT media, cloud native applications are a big deal. What that actually means is somewhat hazy, as you might expect of a term trumpeted by consulting firms. But in a nutshell, cloud native applications are applications built to use containers and open source software, using known good patterns like “containers are cattle, and not pets,” and hosted in such a way that developers can focus on development, rather than infrastructure.
In a recent survey, researchers from Capgemini spoke to executives to find out “how a cloud native approach was driving change at their organizations.” Apparently, 74% of executives like cloud native because it improves velocity and 70% like its collaboration advantages. As the survey points out, cloud native is associated with concepts like agile and DevOps.
What interests me about “cloud native” is that I don’t see how it necessitates what we usually think of when we talk about the cloud. Public cloud platforms are multi-tenant virtualized infrastructure platforms. Private clouds are a single-tenant variation on that theme. We all know what cloud means in this sense. That’s fine, but what does it have to do with using containers and open source software, or with agile development, or with effective collaboration.
Or to put it another way, why are those things thought of as “cloud” when they’re just as applicable to bare metal servers hosted in a colocation data center? Container systems like Docker are indeed excellent for fostering agile and collaborative workflows based on open source software. They work well on cloud platforms, but they work even better on bare metal without the unnecessary hypervisor layer. The same goes for open source software: it doesn’t have anything to do with the cloud exclusively.
As Forbes writer Adrian Bridgwater bluntly puts it:
“It’s not a cloud. It’s a server running a highly-connected software application with specific storage and networking demands in a data center connected via a pipe that we usually call the Internet.”
It may seem like I’m debating semantics with an organization that goes out of its way to be vague, but what we name things matters. The practices associated with “cloud native applications” are excellent practices, but they’re not limited to what most of us mean by the cloud. They’re independent of the underlying infrastructure platform. They’re organizational and operational practices unrelated to infrastructure choices, choices that should be made on the basis of the needs of specific applications for performance, scalability, availability, and so on.
Another quote from Bridgwater that made me smile:
“Capgemini’s research suggests that many CIOs are facing challenges in building business cases to invest in cloud-native apps from business leaders that see cost reduction as the priority for IT teams.”
In other words, CIOs are having a hard time convincing business leaders that they should choose an infrastructure platform that ultimately works out more expensive than the alternatives: applications developed and hosted on in-house or colocated servers, whether or not they use containers and open source.
My takeaway is that the choice of infrastructure platform — cloud or colocated servers — is independent of the development workflows of the applications that use that infrastructure. An approach made possible by containers, modern tooling, and development methodologies that are largely infrastructure agnostic.