Migrating to cloud native requires seeing shades of gray

A common approach to application migration to the public clouds is to alter the applications to take advantage of cloud-native features. This means that the applications can speak with the native management systems, native security systems, and other native services.

The alternative is lift-and-shift: doing as few modifications to the applications as you can get away with. This means avoiding cloud-native altogether, practically speaking.

Best practices have been emerging around the binary approaches of either go all-in cloud native or don’t go native at all. The reality is that it’s not a binary decision, and the answer you’re seeking may operate across a spectrum.   

First, we know pragmatically that applications are created for different purposes to solve different business problems. We already understand that a one-size-fits-all approach to refactoring applications is just not realistic. I bet you already know this.

Secondly, what enterprises typically don’t understand is how to pick the right refactoring approach for the applications, considering their purposes. This is typically where those migrating applications go off the rails. 

The mistake I see most often is that people opt for a generic approach. Without looking at the application’s functionality they have decided that all of the applications need native security and encryption, but don’t need to leverage native management services or emerging features such as serverless, AI, or machine learning. 

Copyright © 2020 IDG Communications, Inc.

Source link