As you map out your cloud migration strategy, cloud-native applications can prevent the need for rewriting applications.
As enterprises delve more extensively into cloud computing to achieve greater agility, speed and innovation, they often run up against a challenge. Retooling applications to work in cloud architecture can be time-consuming, costly and unsuccessful.
Many applications, particularly older ones, aren’t designed for a multitenant cloud computing architecture. While enterprises have moved some of these applications, they experience mixed performance results and invest time migrating applications that aren’t geared for the cloud.
The alternative to retooling these apps is to work with native cloud applications (NCAs). These applications are written for cloud architecture, so they may require less work to migrate them there. Let’s explore some of the pros and cons of using NCAs for cloud migration strategies.
With cloud-native applications, enterprises can migrate existing or build net-new applications on cloud platforms, then exploit the native services of those platforms, including security, storage and database services.
Designed for multitenant cloud architecture and the ability to run on different servers, NCAs work well with a multitenant architecture designed for redundancy. Accordingly, enterprise appetite for NCAs has grown. Last year, Capgemini published research that indicates an increase in enterprise cloud adoption through the increased use of cloud-native applications, with 15% of new enterprise applications being cloud-native in 2017 and will explode to 32% by 2020.
There are tradeoffs with cloud-native applications, however. A major one is provider lock-in versus better application services and performance.
When companies use cloud-native services via application programming interfaces (APIs), it can be difficult to move an application to other platforms where those APIs don’t exist. If you decide to shift the application from an existing cloud provider to a new one, you’ll have to rewrite the application to take advantage of cloud-native features on another public cloud.
Nonetheless, cloud-native advantages are compelling and becoming more so. Cloud-native features provide better application services, including storage, compute performance, security, governance, user interface development and operations. As public cloud providers continually add services, the benefits only increase.
The cost of moving to cloud native is the cost of refactoring. This process requires that applications or portions of an application be rewritten in ways can exploit the native cloud services using (APIs). Depending on the complexity and age of the migrated applications, refactoring can entail complicated and expensive overhauls in some cases or only a few changes to API mappings in others.
For net-new applications, the NCA scenario is even more compelling because we have yet to write the application. If we’re building it on a public cloud, it makes sense to leverage the cloud-native features and write the application around those features. Developers may opt for cloud-native development tools as well, including the use of platform as a service (PaaS) systems that are imbedded in most of the three largest infrastructure as a service public cloud platforms. It’s important to note that with PaaS tools comes additional concern about lock-in. If apps are developed with cloud-native tools, the application becomes so closely tied to the cloud platform that it’s not economically viable to move it to another cloud.
Given the advantages and disadvantages of cloud-native applications, there are other cloud migration methodologies to consider as well, including these methods:
Lift and shift. Most enterprises were told that application and data migration would involve lift and shift: a strategy for moving applications from one environment to another without a redesign. It’s the cheapest and fastest way to put points on the cloud migration scoreboard.
The idea is to port directly to a public cloud platform analog, such as Linux on-premises to Linux in the public cloud.
But there are downsides to this approach. Migrating to the cloud with lift and shift means you don’t exploit cloud-native features. The application isn’t optimized for public cloud services, and companies won't see the best performance. With lift and shift, many enterprises are left to wonder whether the move was worthwhile.
Containers. Containers—packages that rely on isolation to run applications that access a shared operating system (OS) kernel without the need for virtual machines—are a double-edged sword when it comes to cloud migration strategies. Containers are self-contained environments that enable IT to test apps more quickly, more securely and in a more on-demand fashion than is possible with virtualization. This isolation makes containers solid candidates for cloud testing and development.
At the same time, containers require migrating applications to be refactored and redesigned. Even net-new applications may require additional work.
The metrics are still coming in on containers, but best practices suggest that containers make sense for cloud migration strategies when the applications don’t require much work to “containerize” them. Containers are indeed the way to go and can leverage cloud-native features as well as cloud portability.
Unfortunately, many enterprises find that their applications are not a good fit for containers without a great deal of costly and risky modifications and design changes.
Serverless application development. These deployment systems are the newest weapon in the migration arsenal. You don’t have to think about infrastructure, such as storage and compute to create the environment. The infrastructure is automatically provisioned for you, used, and then de-provisioned. No more guessing the size of the object storage system, or the amount of memory and core that you need to attach to an application.
But as with containers, there are tradeoffs. Depending upon the application, you may have refactoring work to do to exploit a specific serverless platform. Thus, serverless is a better fit for net-new applications rather than applications that are migrating from traditional systems.
Stay-put methods. In about 20% to 40% of application portfolio cases, the application and attached data does not move to the public cloud. While applications and data could be moved with enough time and money, they aren’t economical to move.
This means that the cost of migrating the applications, including all of the refactoring required, is unjustified given the value of the application to the business. This scenario may also apply to legacy applications that have no direct platform analogs on the public clouds. Although these applications are not viable cloud candidates today, they could be in a few years as cloud technology matures.
Given today’s pace of cloud migration, most enterprises are in the process of application migrations and will be for the next three to five years. Once everything is migrated, new methodologies including CloudOps, DevOps as well as new cloud security systems will saturate everyone’s time.
Hopefully, you’ll learn as you go with cloud migration strategies. Change your path based on best practices and technology. That’s the only way to win this game.
David Linthicum is the chief cloud strategy consultant and a longtime contributor to a variety of technology publications.