It’s good to be cloud-native, or at least that’s what everyone is telling you. The idea is that you refactor (meaning partially recode) your applications to take advantage of the native features of the host cloud, such as its native APIs, storage systems, database systems, or security systems, depending on what that host cloud services offers.

The promise you’re being given is that being cloud-native will provide enhanced performance, lower operational costs for your applications, easier operations, and a bunch of other benefits as the cloud platform improves over time.

However, there is a dark side to being cloud-native, and it’s worth some consideration before you spend a significant about of time refactoring your code. The considerations include:

The lockin issue. You’re not going to make an application cloud-native application without giving up some or all of its portability. If you’re localizing an application for , , or , you’re coding to the native APIs of those clouds. By using native APIs, it will be difficult to move that code to other clouds, or back to on-premises systems, without refactoring again.