When you move your applications to the cloud, there are a lot of ways to do it. Cloud migration can mean rehosting, refactoring, or rearchitecting. Your needs dictate your path, and your path affects how you update your infrastructure and applications. In this blog post, we’ll examine a few choices.
- Rehost: lift and shift
- Refactor: move applications to the cloud without major changes, but take advantage of benefits of the cloud environment
- Re-architect: modify applications to better support the cloud environment
Rehost
Lift and shift – it’s just how it sounds. Your applications continue to operate the same as when they were on premise, carrying all their components in their VMs, only now they’re hosted on the cloud.
Why rehost? Rehosting is the most basic, least risky move to the cloud. It relieves you of the need to keep the resources running on your expensive servers and puts the onus on the cloud hosting providers. You get redundancy, consistency, and guarantees of all the resources AWS, GCP, Azure, Alibaba, or another provider can offer.
What do you have to do? If your application is running well on your servers, it should run well in the cloud. Just make sure it’s still properly pointing to any resources it needs from your own premises.
Rehost
| What it is | Benefits | Requirements |
| Moving applications to the cloud with no changes | Very little risk Saves local resources Redundancy and resources from the cloud |
Cloud hosting platform Testing |
Refactor
Refactoring is the next step, updating some application components to take advantage of cloud services in a Platform as a Service (PaaS) model. This could include relatively minor changes, but could also involve replacing a monolith with a microservices-based, containerized architecture. New components can be part of refactoring applications for the cloud – such as replacing older Oracle databases with modern AWS Aurora.
Why refactor? Application refactoring can make an application more resilient, make it more agile, add new functionality, or even add mobile support. Refactoring can be a bridge to more complete cloud-native applications, and it can mean the difference between sunsetting an application and extending its life. Refactoring can make code more readable, making it easier to understand and update. The benefits may be moderate in the beginning but can pay off big later. Optimized code can make finding and fixing bugs easier and less time consuming.
Refactoring is the first level that requires careful consideration because it can cause your cloud billing costs to spiral. if your existing application is resource intensive, it may cause larger cloud billing because it involves big data processing or image rendering.
What do you have to do? If cloud costs are rising, you can redesign your application to use resources more efficiently before moving to the cloud.
Application refactoring usually applies to three areas:
- Source code: Change your application’s structure to gain efficiency, agility, and resilience without losing functionality
- Database: Update database schemas to improve design, improve logic and speed, raise performance, and scale
- User interface: Improve the UI to improve consistency across enterprise applications while retaining functionality, improving usability
Refactor
| What it is | Benefits | Requirements |
| Updating some application components and moving to the cloud | Resilience Agility Can extend the life of an application Can make an application easier to update |
Update the source code Update database schemas Improve the UI |
Re-architect
Rearchitecting an application means to modify code to become cloud native. Cloud native means having a cloud architecture, using cloud resources. In other words, built in the cloud. Rearchitecting applications offers more benefits, but it also requires more time, effort, cost, and resources to execute. Rearchitecting without downtime is even trickier.
Rearchitecting an application, is a long, difficult, resource-intensive process. There’s a reason most companies piecemeal their way to the cloud rather than moving all at once. Moving to the cloud often pays immediate dividends, but as you use more cloud resources, monthly charges from your cloud platform provider can skyrocket if you take your eye off the ball. The ongoing charges can soon cost more than the price of the expensive servers, defeating the purpose of migrating to the cloud in the first place. So if you’re going to rearchitect an application, it had better pay off, right?
Why rearchitect? The promise of rearchitecting includes the agility and resilience that the cloud provides, reducing the load from on-premises or private cloud servers, and almost unlimited scalability. Paring down the number of servers you own can also save millions of dollars. A Java runtime can be a resource hog, but an optimized runtime from a partner focused on Java can reduce that footprint, reducing infrastructure costs use by 50% or more.
What do you have to do? Every cloud provider is a little different, and every company’s situation is a little different. Take the time to carefully model your transition to the cloud so it goes as smoothly as possible.
Document what you’re moving to the cloud and ensure you have the resources to run them as you scale up and down.
Migrating to the cloud sometimes means keeping services available to users during the move. Team leaders should present a detailed timeline of what gets moved, when, how long it will take to migrate, and where end users will access services before switching over to the cloud version. Enabling end users to work uninterrupted is the biggest reason migrations are done in a piecemeal, iterative approach rather than in one big, atomic cutover.
Ensure your tools and systems in the cloud can communicate with each other and communicate with your tools that are still on-premises or in the cloud.
Build cloud security into your cloud migration strategy. Have a security layer anywhere sensitive or personally identifiable information exists. Secure both the cloud application and any gateways where this information is being shared between environments.
Re-architect
| What it is | Benefits | Requirements |
| Modifying code to be more cloud native | Agility and resilience Scalability Reducing the load from private servers Reduction in hardware and associated costs |
Plan to keep the application available during migration Communication between cloud services Cloud security |
How Azul Can Help
Once you have moved to the cloud in any capacity, you will have a new set of issues to deal with. As noted above, your cloud environment could get expensive as you consume more cloud resources. There are also standard performance issues that come with all the great things (like agility and stability) of Java-based applications. Here are a few mitigation strategies.
Spiraling cloud fees: A cloud-based Java platform like Azul Platform Prime limits cloud costs by reducing IT hosting costs and easing the burden on your engineering team.
Poor application performance: Slow bytecode is a performance killer, and Azul Falcon JIT (Just In Time) Cloud Native Compiler (CNC) turns slow bytecode into fast machine code improve performance without driving up costs.
Application pauses: Java uses a Garbage Collector to dump memory as it runs. Unfortunately, each time it runs, it pauses the application. The Azul Pauseless Garbage Collector clears memory without pausing the application.
Long warmup times: Java applications have to warm up until they reach optimal performance. The ReadyNow Warmup optimizer accelerates warmup until the application achieves peak performance.
Learn More About the Cloud Paradox
There are ways to solve the Cloud Paradox. Java can – and in most cases should – run in the cloud. If you’re migrating to the cloud for the first time, a partner like Azul can help you navigate the risks and take advantage of the functionality the cloud can offer. Visit Azul.com and learn more about Azul Platform Prime.
