Should you go all-in on cloud native?

We’ve all heard about “cloud native” databases, security, governance, storage, AI, and pretty much anything else that a cloud provider could offer. Here’s my definition of cloud native applications: Applications that leverage systems native to the public cloud they are hosted on.

The general advice is, “Cloud native: good. Non-native lift-and-shift: bad.”

This makes sense. By using native services, we can take advantage of core systems that include native security using native directory services, as well as native provisioning systems and native management and monitoring. Using non-native applications on public clouds is analogous to driving a super car on a gravel road.

Now we’re taking this notion of native services to new platforms, including container orchestration—namely, Kubernetes. Kubernetes has a nice big ecosystem of “native” purpose-built systems that include databases, storage, security, governance, devops tools, and many more. There are two schools of thought here:

First, native is good. These tools will likely provide better performance. A Kubernetes-native storage system can scale to thousands of nodes and thousands of concurrent operations per minute. This due to the fact that it’s an insider, working with native Kubernetes applications using native interfaces.

When you need to reach out to the outside world with non-native systems to deal with needs such as database, storage, or security, the communication translation alone drives a great deal of latency. To this way of thinking, Kubernetes native is always better, and is typically preferred.

The second school of thought is that we might add too much complexity by going all-in native. Although there are advantages, moving to Kubernetes-native systems means having at least two of everything. Enterprises moving to Kubernetes-driven, container-based applications are looking for a common database system, one that spans applications inside and outside Kubernetes. Same with security, raw storage, and other systems that may be native to the cloud, but not Kubernetes.

What’s the correct path? One of the lessons I’ve learned over the years is that best-of-breed and fit-to-purpose technology is typically the right way to go. This means native everything and all-in native, but you still need to be smart about picking solutions that will work longer term, native or not.

Will there be more complexity? Of course, but this is really the least of your worries, considering the movement to multiclouds and IoT-based applications. Things will get complex out there no matter if you’re using a native Kubernetes solution or not. We might as well get good at complexity, and do things right the first time.