First, it was “cloud-preferred” policies, then “cloud-first” policies, now it’s “cloud-native” policies. They all mean pretty much the same things, just at different degrees of mandatory public cloud usage.
What cloud-native means is that you’re all in with a particular public cloud provider, the single provider of those cloud-native services, with the goal of making the most from your cloud computing investment. As a result, you’re using only the cloud-native services from a single provider for security, governance, storage, databases, compute, etc., and doing so using whatever native interfaces the cloud provider provides.
The core benefit is simplicity. Because you’re using only the native interfaces from a single cloud provider, there is no heterogenous complexity to worry about for your security system, database, compute platforms, and so on; they are uniform and well-integrated because they sprung from the same R&D group at a single provider. As a result the cloud services work well together.
A cloud-native policy limits the cloud services you can use, in return for faster, easier deployment. The promise is better performance, better integration, and a single throat to choke when things go wrong.
The downside is pretty obvious: Cloud-native means lockin, and while some lockin is unavoidable, the more you’re using cloud-native interfaces and APIs, the more you’re married to that specific provider. They got ya.
In an era where IT is trying to get off of expensive, proprietary enterprise databases, platforms, and software systems, the lockin aspect of cloud-native computing may be an understandably tough sell in most IT departments.
My advice is simple: Your business requirements set the stage for the technology you use, and that technology should be best of breed. While a cloud-native approach should in the running, it’s not a policy that everyone must follow. I have a feeling that in five to ten years, I’ll be consulting for enterprises trying to undo a naive move to a cloud-native policy.