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. 

This is done for convenience. It’s just easier to tell developers to consistently use specific features and leave others behind. You can get away with fewer skills in-house, fewer tools, and thus lower dev costs. However, about 75 percent of your applications won’t be optimized for the public clouds they are migrating to.

This lack of optimization is not apparent, by the way. It takes special analysis to identify these inefficiencies, understand the costs, and make recommendations to become something close to 100 percent efficient (you’ll never be at 100 percent). Balance the requirements of the applications with the ability to leverage the correct mix of cloud-native services. This lowers ops costs and significantly increases the value of the applications to the business.   

The reality here is that applications are not to be treated the same when moving to the cloud. Some will want cloud-native everything; others nothing. Moreover, there are no hard-and-fast rules when it comes to doing what when. Each application must be understood in terms of what cloud-native services fit the exact needs of the applications. Shades of gray, I’m afraid.