What Do You Hope to Get by Going Cloud-Native?

“Cloud-native” is a surprisingly vague and open-to-interpretation way of describing a software architecture or application. Let’s get what it isn’t out of the way first: We can probably all agree that lift-and-shift of your 20-year-old Oracle databases and IIS web servers onto virtual machines is not cloud-native.

As you might imagine, Amazon has a nice working definition:

The term cloud native refers to an application that was designed to reside in the cloud from the start.

From a technical standpoint, I’m personally inclined to prefer cloud-native applications that use serverless and elasticly scaling compute, networking, and storage. But I’m open to approaches that use containers or virtual machines, and we can build cloud-natively using all of those things.

A number of authorities define cloud-native in terms of speed and agility. Here is where things get a little bit more interesting.

The Cloud Native Computing Foundation, for example, is the home (and lovefest) for the Kubernetes ecosystem, and you might be forgiven for getting the idea that if only you build containers and run them on Kubernetes, you have achived cloud-native nirvana.

If you have ever set out to install and subsequently babysit Kubernetes, Istio, Prometheus, Helm, and friends, “speed” and “agility” are probably not the first things that come to mind. There are good reasons why AWS ECS and Google Cloud Run remain popular even with competition from their own hosted Kubernetes offerings.

When deciding whether to go cloud-native and if so, what platforms to build on, ask yourself what you want to achieve. Is it cost savings? The DevOps way of working? The ubitquitous “speed and agility”? Simply retiring a bunch of old hardware?

You can certainly reach those goals with modern cloud platforms. But it’s not a given, and the extent of your success rests with doing your research and making wise and informed technology choices.