How to know when to customize your apps for the cloud

A lift-and-shift approach to migrating your applications to the cloud is the easy choice: You achieve the quickest migration with almost zero migration costs. But if you're doing that with all of your applications, you're probably missing out on key performance benefits and long-term cost savings associated with refactoring key applications to take full advantage of all that the cloud has to offer.

But when should you customize applications for the cloud? Here are the factors to consider as you debate when to customize workloads to leverage cloud-native capabilities, and when to go with the less expensive choice of just migrating them as-is and hope for the best. 

The State of Analytics in IT Operations

Add up the cost advantages of going cloud-native

Applications customized to leverage cloud-native features lead to smaller public cloud bills. The applications are purpose-built to run in a specific cloud and so are better at spinning up resources in a way that’s more fine-grained than are unmodified applications that you port to the cloud from on-premises platforms.

Compute resources are a prime example. Native applications leverage cloud-native provisioning APIs to spin up only the compute resources needed to complete a task, and then return those resources to the pool once the task is completed. With non-native applications, you must allocate the resources ahead of time. Because those applications think they are running on a single server instance, they don’t have any capabilities outside of that instance to access cloud-native features.

But this idea goes way beyond just compute resources. Customizing an application for the cloud means you can also leverage cloud-native databases that may be more cost-effective versus traditional database analogs in the cloud. The cost-effectiveness of cloud-native also extends to other application resources, such as security services, and integration with other cloud-based applications that leverage common cloud-native communications mechanisms, such as cloud-based message queuing.

Consider how cloud-native will affect performance 

Performance is typically better with cloud-native applications because they have more fine-grained access to resources, including the ability to allocate more resources directly from your applications. Non-native applications don’t have such capabilities.

For the most part, these are really the same benefits as the cost-of-operations advantages discussed above. Applications written to be aware of cloud-native features can also leverage these features to find better performance. How much better? It can be up to a factor of three when the refactoring for cloud-native features also includes application optimization and some redesign.

That said, performance impacts are application-specific, so your mileage can vary a great deal when customizing applications to leverage cloud-native features. Factors that come into play include I/O optimization, the use of caches, and network communications, which are all things that become part of your application performance chain.

Is integrating cloud with your DevOps a plus?

DevOps and clouds are linked to the point where it makes sense to leverage some cloud-based DevOps tools within your DevOps processes. That means you access the entire application development lifecycle using approaches such as value chain mapping (VCM).

With VCM, you review the entire software development lifecycle (SDLC), including all groups involved, the responsibilities of each, and the duration of tasks in each group. This gives you a jumping-off point when looking at DevOps features that exist in the cloud and considering how to leverage those features to optimize your VCM.

With VCM, applications customized for the cloud are easier to manage within a cloud-based DevOps process. These applications leverage cloud-native features such as microservices that are specific to the cloud and integrate with cloud-based DevOps features such as configuration management, release management, staging management, and systemic security integration.

Testing is also an advantage when leveraging cloud-native development. Automated testing systems that are a part of cloud-based DevOps are purpose-built for testing and deploying cloud-native applications. They can test for cloud-native subsystems that traditional testing tools cannot address.

Other advantages to consider

Of course, the reasons to customize applications for the cloud include many other, smaller advantages, including:

  • API-based architecture is systemic to most cloud-based applications, which generally makes it easier for the application to interact with other applications and data stores.
  • Container dev, test, and runtime management is a part of most clouds. You have the option to build cloud-native applications to natively leverage containers.
  • Going cloud-native forces you to rethink the design and architecture of the application for the cloud and leverage best practices. You end up with better-designed, better-performing, more service-oriented applications.

Does it make sense for you?

There are many reasons why customization for the cloud might be your best choice, but there are also some downsides. The biggest is not properly assessing the cost and risk of changing applications that are core to the business. A good rule of thumb: Plan on refactoring approximately one third of the cost of building the original, non-cloud-native application.

While some applications customized for the cloud can save hundreds of thousands of dollars per year, thus justifying the cost of rewrites, others won't provide anywhere near the business benefits and could become an expensive folly. So consider the benefits above, understand the tradeoffs for your applications, and choose wisely. 

What makes sense for your organization? Post your questions and comments about going cloud-native in the comments below.