Many enthusiastically chant “cloud, cloud, cloud” but haven’t thought about what it takes for a successful application migration to the cloud.
The cloud is a wonderful place. But cloud migration isn’t easy. Most enterprises are burdened with a lot of legacy and technical debt. Think of transitioning to the cloud as moving to a new home with a king-size bed and a grand piano in tow—not to mention deeply entrenched technology that needs extracting like a jacuzzi or TV frame mounted in the wall.
Looking at a new house and imagining your life in it is fun and exciting. But simply buying a house doesn’t make it a home. You need to figure out how to move all your belongings and make sure they fit. Will your mattress clear the tight hallway turn? Is there a spot for your grand piano that doesn’t block electrical outlets and is far enough from the window to avoid sun damage? Who is going to pry the TV mount from your old wall and reinstall it in the new place?
The same questions can apply to your technology when you select a cloud provider. Answering those questions requires an application-centric strategy to maximize what the cloud offers. After all, applications are now the lifeblood of IT organizations. Simply acquiring resources from a cloud provider is far from realizing the promise of full application migration to the cloud. Enterprises must first undergo a digital transformation where they modernize their applications and application services.
Evolution of Application Deployment Methods
To create an application-centric cloud migration strategy, we must first understand the evolution of app deployment methods from bare metal environments to virtualization to containers. The moving analogy applies.
- Bare Metal - These deployments are deeply embedded in your infrastructure and difficult to move. Think of the jacuzzi tub. It’s great to have but is locked in place (unless you want to go through a painful and expensive remodel). With bare metal environments, the apps are directly installed and run on a specific piece of hardware for a single user group or organization. This deployment method has the advantage of being very stable and secure. But you can’t quickly spin resources up or down because everything’s rigid. Bare metal application deployments can not migrate to the cloud without a significant modernization effort.
- Virtual Machines - These run on servers. They’re movable with some effort. They symbolize items like your bed and piano. Virtualization solves the inflexibility of bare metal environments by breaking up individual servers into many smaller virtual machines. This helps improve efficiency so you’re getting more value from the infrastructure your VMs run on. Virtual machines also make it easier for users to request more computing resources during peak traffic when they need it and drop the excess after the rush is over. Currently, virtual machines are the primary deployment method for cloud-based environments. Data center-based virtualized application migration to cloud can be achieved with a modest modernization effort.
- Containers - They are the lightest and most portable of deployments. They are the boxes you can carry by hand to your new home. Containers were developed to take the resource distribution offered by virtualization to the next level. Rather than creating endless unique copies of an operating system, multiple containers can be run under a single OS. Each container is designed to run a application or microservice and already carries the necessary parts of the application and its dependencies. This lightweight approach means far more container-based apps can run on a single machine than would be possible with virtualization. Yet this vast capacity comes with increased complexity. The interdependencies of each container have to be monitored and controlled so the changes to a specific container or the traffic between containers don’t bring the flagship application to grinding halt. A smart load balancer can help with that. Containers are extremely portable. Containerized application migration to cloud is trivial in most cases.
Evolution of Application Architectures
The methods of deploying applications aren’t the only thing to have evolved. The applications themselves have also changed over time. At first, most applications were architected as monolithic entities. Then, service oriented architecture (SOA) was developed. Today, many organizations are beginning to employ microservices architectures for their applications.
- Monolithic Architecture - Monolithic architecture refers to applications that are typically built as a single unit with a database, business logic, and a client-facing user interface. Each component has a set operation. These applications tend to be more simple and easier to manage, but are difficult to scale and complicated to modify or redeploy.
- Service Oriented Architecture (SOAs) - SOAs break applications into coarse-grained pieces. This architecture corresponded with the rise of virtualization. Similar components are kept together, creating a loosely connected work unit for the application. These components can communicate over a network, which allows them to function when hosted in different environments.
- Microservices Architecture - Microservices break an application into many, fine-grained pieces. Typically, microservices are deployed on containers. By breaking everything down into smaller independent components, IT organizations can modify and upgrade the application quickly. This super-modular approach, while increasing complexity, provides unprecedented speed and flexibility.
How to Modernize Your Applications
Marching towards the cloud requires modernization efforts unless, of course, you plan on leaving your applications behind. Continuing on with the moving analogy, you need to decide what is going to be left behind (perhaps the jacuzzi or your old refrigerator). And for the things you plan on taking with you, you need to decide how to safely remove it from your existing home as well as how to safely set it up in your new home. In the context of cloud migration, this can be exceptionally complex. It’s critical to not blindly adopt the latest technology without thinking through the application modernization process.
The size, spacing, and layout of the new home is different. The neighbors, lighting, and locks are different. Some of these changes offer a vast improvement. Others require modification to your "stuff" or the new environment to get the desired result.
The “Six Rs” of Application Modernization
Back in 2011, Gartner first outlined the “Five Rs” of application migration to cloud. These “Rs” represented application modernization strategies. Technology and processes have advanced since then and, today, there are six application modernization strategies. Here is the updated list of the modernization strategies you should consider to determine which approach is best for your applications:
- Rehost — Sometimes known as “lift-and-shift”. Simply take the existing application and application architecture as-is and do the bare minimum to get the application to run in a cloud environment. It won’t take advantage of cloud features like elasticity, but it can run in the cloud. Think of it as placing your grand piano in the garage of the new home. May not be the final destination, but it’ll do for now.
- Refactor / Re-architect — This requires significant changes to the code and architecture of the application so it can take advantage of the cloud environment. This is the most expensive, but can provide the most beneficial to enterprises seeking performance and scale. This is like taking your existing custom cabinets with you to your new home. Each needs to be removed, refinished, and refit to work in the new home. It’s a lot of effort but the end result is designed exactly to your liking.
- Rebuild — Starts with a clean slate. Old code is discarded and replaced with new code. Design the application as you need it to run in the cloud, and carry nothing over from the original application. Similar to refactoring or re-architecting your application, rebuilding is an expensive option but will deliver more value in the cloud. This is like bringing in all new appliances to the new home. Their size, shape, color, and functions are tailored to the new home.
- Retain — There are some applications that provide a lot of value in your existing environment. The costs to rehost, refactor, or rebuild are great and the return is small. These should be retained. In other words, do nothing and leave them where they are. Maybe you don’t take your jacuzzi tub with you.
- Replace — Completely discards the current application in favor of using a Software-as-a-Service (SaaS) solution. Enterprises can save a lot of money when they don’t have to build, deploy, and scale applications in-house. Instead of packing your vacuum, mop, and broom, you hire a cleaning service.
- Retire — You may realize there are some applications that provide little value in your existing environment and wouldn’t provide much value in the new home. Don’t spend effort on migrating these applications. Retire them. It’s like that box of college textbooks you keep in the attic. They were useful once, but you don’t use them now and you won’t use them in the new home. It’s time to say goodbye.
The best way to determine which strategy makes the most sense for each of your applications requires you to determine the target state of each application. Ask the following questions:
- What is the purpose of the application?
- Which environment is best suited for the application?
- What resources (people, budget, tools) are available for modernizing the application?
- Is the return of the modernization effort worth the investment?
Considering these questions should help you identify which application modernization strategies are realistic and feasible. When considering the these modernization strategies, be sure to think about more than just your immediate bottom line. The strategy you choose should also consider how it will affect your customers, future earnings, and flexibility.
For example, what if the vendor supplying you with a container management platform suddenly surges prices (or goes bankrupt)? Would you be able to extract yourself from that company’s solution and move to a new one quickly? Are there any vendor-specific functions or features that won’t carry over? Do you have an alternate solution already lined up just in case? Being prepared is the key to future-proofing your organization and avoiding vendor lock-in.
The cloud is a draw that offers many wonderful opportunities, as is a shiny new house. Just bring your measuring tape when checking out new properties. Before embarking on a major digital transformation, be sure the grand piano fits.