Cloud Native versus Native Cloud apps

I've been spending a lot of time lately thinking about the next evolution of the cloud, and more importantly, what the developer experience looks like. A few years ago, I think that most of us in the serverless ecosystem thought that the path forward seemed quite clear. Serverless-first was obviously "the way." Small, discrete, single-purpose functions interconnected through a series of planet-scale, self-upgrading, managed services with built-in redundancy was the holy grail of cloud development.

Of course there were some gotchas in there, and not every use case was a perfect fit, but over time we figured these would be addressed as the technology evolved. For the most part, that has come to pass. Even if AWS hasn't quite yet solved some of these issues, other cloud providers and startups have certainly tried. But while serverless was slowly preparing to cross the chasm, another already widely accepted technology was gaining traction in the cloud: containers.

To be perfectly clear: I really like containers. They solve a number of problems that traditional VMs don't. They're highly portable, they're (mostly) lightweight, and they make an excellent packaging format. There are also lots of advantages to using them for code execution in the cloud. They can handle multiple concurrent connections, they're better for stateful workloads, they're not limited by arbitrary timeouts, and they are much cheaper for high volume workloads. But for just about anything beyond application code execution, using containers in the cloud...seems crazy to me!

Kubernetes is a marvel of engineering, and you can run robust implementations of popular software systems like Apache Kafka and PostgreSQL on it with relative ease. But just because you can doesn't mean you should. Unless your business is literally running a database service, why would you even think about trying to support something like that? Between all the different cloud provider offerings, or the myriad of startups building serverless databases, queues, caches, and more, what is the advantage of managing these services yourself? The answers I hear the most are customization, cost, and portability. I call shenanigans.

I need more control

If I've said it once, I've said it a hundred times: control is an illusion. Customization typically boils down to performance tuning, something that can go wildly wrong in the cloud, even for highly-knowledgable engineers. The cloud isn't just "someone else's computer", it is a complex system that requires optimizations you don't know how, or have the ability, to make. If your application gets to a point where you've reached the limits of a cloud service, reach out to the service team and they'll be more than happy to work with you to make their service better. It's happened several times to me.

The cost of portability

Cost can be a valid concern, but look at the overall TCO. It takes a really, really large cloud bill to offset even a small team of specialized engineers. But the one that really gets me is portability. If you built an application that can be ported back to a local datacenter, then you have NOT built an application that is NATIVE to the cloud.

The CNCF defines "Cloud Native" as "technologies that empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach."

The majority of CNCF projects follow the "write it once, and run it anywhere" mantra. But the public cloud, and the services that were built for it, had a very different vision.

Allan Vermeulen, one of the original creators of S3, has said that they built these services to achieve things that could NEVER be solved by the datacenter. The types of applications that can be built on a public cloud CANNOT be ported back to the datacenter because they don't have the primitives to support it. The cloud introduces new levels of scale and capabilities that the on-premises environment is simply not capable of providing. This incredible power is available to you right now, on-demand, and you generally only pay for what you use.

The future is Native Cloud apps

So perhaps "Cloud-native" makes sense when you very loosely define the term "cloud", but let's not pretend that portability to massively subpar alternatives is a good strategy. Especially when the public cloud providers give us not only the primitives, but also the operational excellence that is impossible for most others to achieve.

A serverless-first mindset is a step in the right direction, but the public cloud is bigger than that. Edge compute and containers will play a massive role in the future of cloud, as will security, compliance, sustainability, and more. We need a way to classify the applications of the future. The ones that are BUILT FOR THE PUBLIC CLOUD and all its awesome power, not the ones that are still chained to the data centers of the past. For now, I'm calling them native cloud applications, and I firmly believe that this is the path forward.