If you take advantage of cloud-native features, you lose some portability. The trick is choosing the right balance.
I hear it all the time: We don’t want lock-in, so we need to make sure our cloud applications are portable. Indeed, competitors (like Oracle and Walmart) to Amazon Web Services, Google, and Microsoft have been promoting their stuff as providing portability precisely to get IT to think of them instead of these three leaders.
Yes, cloud application portability is important. But how much so? The answer depends on the types of applications you’re porting or building, as well as the likelihood you’ll be moving off the cloud platform in the near future.
In reality, cloud application portability is a trade-off, no matter what cloud you pick. Using native cloud services from any provider can bring better performance and cost-efficiency. However, the more native services you use, the less portable your application.
For example, I could port an application from a Linux platform in my enterprise to an analog of that platform on a public cloud. This is a simple lift-and-shift that should compile and run without much effort. But if I rewrite the application to take advantage of cloud-native features, my ability to bring the application in-house, or move it to another cloud, becomes limited without a lot of refactoring or code modification.
Thus, the more I modify the application to take advantage of native services such as scaling, provisioning, and resource management, the less portable it becomes. This is true of all public clouds, no matter how open they claim to be.
The trick is to place the right weight and value of portability on your applications. A 100 percent portable application is not practical, nor is supporting applications that are 0 percent portable. The trade-off comes in native features and portability. You can’t have it both ways.
By David Linthicum