These days, enterprises are ramping up for the migration of massive amounts of applications to hybrid clouds. Some are new applications, but the majority are more than 10 years old.
So, how do you make the move to the hybrid cloud?
The trick is to select the right applications in the first place. To do that you must understand what each application does, assess the business case for migration, and then select the right approach. Determining which applications will bring the most value in a move to the cloud should be the starting point. From there you move on to address the technology trade-offs, such as selecting the best approach to migrate the application and deal with important issues such as security, governance, and disaster recovery. In this way you can modernize your application development processes and technology to make the most out of your newly deployed hybrid cloud.
Making the hybrid cloud jump
Before migrating legacy applications to a hybrid cloud, make sure you understand the difference between traditional legacy application architectures and hybrid cloud platforms. Hybrid clouds have at least a private and public cloud side to the architecture, but multicloud architectures include more than just one private and one public cloud.
Hybrid clouds are desirable because they can deliver the best of both the private and public cloud worlds by letting you move workloads back and forth between the two platforms. You can also partition applications so that components can reside on both the public and private cloud.
With a hybrid cloud, enterprises can host the applications and the data on the platform that delivers the optimal mix of cost efficiency, security, and performance. For example, a big data application that requires expensive storage systems may run more cost effectively on a public cloud, while sensitive data or data that needs to be close to the end user for performance reasons remains hosted on a private cloud for risk management reasons.
The trick here is to analyze the source applications with a complete understanding of the types of workloads involved. Armed with this information, you’ll be ready to make an informed decision as to what changes each application requires and what approach will work best when rehosting on a hybrid cloud. You have three options: to lift and shift, partition, or refactor the application.
Lift and shift
In this approach, you move the application and its data without making any significant changes to the application itself. This means picking either the public or private cloud as the destination for the application. You select the best host based on workload requirements.
For instance, let’s say you have an inventory control application, written in Java, that runs alongside a relational database on a Linux system. The application is “chatty” with the user interface, so any network latency will be noticed by the end user. In order to provide the best performance, the application should be lifted and shifted to the private cloud components of the hybrid cloud, where it can run relatively unmodified.
The advantage of the lift and shift method is cost. Since you don’t need to redesign or modify the applications, your costs are limited to moving and testing the application on the private or public cloud.
The disadvantage is that you are still using a single platform—either public or private. You are not taking advantage of the distributed capability of a hybrid cloud by distributing the workload.
To partition an application for a hybrid cloud, you separate the workloads within the application to run on the public and private cloud sides of the hybrid cloud simultaneously. You can usually do this with minimal modifications to the application, minimizing the cost and risk.
Let’s say your inventory control application has a transaction layer that costs less to run on the public cloud, but the data and the user interface run best in the private cloud. You partition the application between your private and public cloud, but the partitions are in constant communication, as though each were running on a single physical system.
Applications can be partitioned to best take advantage of your hybrid cloud, but to do this effectively you must understand the application in great detail and be prepared for some modifications, as well as testing and deployment.
For these reasons, the cost of partitioning applications is higher than with the lift and shift approach. However, this method makes sense when the cost savings from running the appropriate workload on the appropriate cloud outweigh the costs of modifying the application.
Refactoring an application means doing a complete (or almost complete) rewrite of it to take full advantage of the features of your hybrid cloud. In leveraging so-called “cloud-native” features, you optimize the application to use your underlying private and public cloud resources most effectively. For example, you may want to modify legacy applications in this way to increase performance.
Typically, you access these features in layers. These include the topmost virtual platform or operating system; underlying resources, such as storage and data; and cloud-native services, such as provisioning and tenant management.
Refactoring also lets you access the native features of public or private cloud services to provide better performance than non-native features. For example, if you are working with an input/output (I/O) system that works with an auto scaling and load-balancing feature, you can drive this dynamically from within the application.
What’s more, cloud-native applications can use cloud-native features and APIs to more efficiently use underlying resources. You can better manage the application’s impact on the underlying hardware and software and get better performance as a result. Additionally, you can usually reduce the cost for public and private cloud resources.
As with partitioning, you distribute the components of your application between the public and private cloud, but refactoring lets you break the application apart in a much more precise manner. This usually involves rewriting it as sets of services or microservices that can reside on either the public or private cloud so that you can relocate them as needed to maximize operating cost and performance.
The big trade-off with this approach is cost. Refactoring typically means redesigning and rewriting the application from the ground up. You will need to pay a development team for several months or more while they rework the application, so make sure the benefits outweigh the costs before proceeding.
Business continuity and disaster recovery
You have a couple of options when business continuity is a concern for applications running in a hybrid cloud. You rely on the hybrid cloud service itself to provide resiliency services, but it’s up to you to ensure that the public cloud provider maintains redundant services as part of its infrastructure so that outages on primary cloud centers will failover to secondary centers without an interruption in application services. You should replicate the same services on the private cloud side as well.
Alternatively, you can build business continuity services directly into the application. This means investing the time and money required to modify the application to provide these services. This might require storing data in two places at the same time, keeping backup instances of the application running at all times, and even distributing the application geographically to avoid geographically oriented disruptions, such as weather events.
Security and governance
You have two primary choices for security when moving legacy applications to a hybrid cloud:
- Leave the application unmodified and retrofit cloud security services around your application and data. This often means restricting access at the machine instance or storage levels. This approach is a “you’re in” or “you’re out” type of security solution.
- Modify the application to use application-level security services, such as those that are entity-based. This allows fine-grained access to application services and data and restricts how the application is used. However, this typically requires modifications to the application to leverage this type of security, such as using Security Assertion Markup Language (SAML), the open standard for federated identity.
Much like security, governance can occur at the legacy-application resource or machine level, at the application or service level, and at the data level. However, when you’re implementing governance at the service level, the application may need to be modified. Cost and risk issues come into play again and may change the business case.
The idea here is to order legacy applications in terms of importance to the business, ease of moving to the hybrid cloud, and the cost of any changes that should occur in moving the application. Using a ranking system, you can then determine which applications should take priority over others and even determine which applications should not be moved or replaced.
It is important that the people who choose which applications to move to the hybrid cloud properly analyze those applications in terms of benefits, function, architecture, technology, configuration, and so on. They must understand enough about the application to make a proper assessment as to whether and how each application should move to the cloud. Typically, mistakes occur when the enterprise does not take the time to understand the breadth and depth of each legacy application. That leads to improper conclusions.
Now is the time to start looking at your application portfolio as you consider the best ways to leverage your hybrid cloud. Many things will need to change before you can begin, including the application development processes and tools and your organization’s cultural acceptance of public and private clouds.
You have many options when porting to a hybrid cloud, and you can hedge your bets in terms of determining the best location to run the application workloads, whether public or private. The cloud can provide a path to improve performance, security, and resiliency. It’s not easy, but the payoff is worth it. Done right, legacy applications migrated to hybrid clouds run faster and at a lower cost.