There comes a time in the life of an application when someone asks: "Should we move this to the cloud?" Public and private clouds often breathe life into existing applications with more flexibility, simpler maintenance, and better performance. However, these lift and shift migrations come with tradeoffs.
Should the application be migrated? If so, should you take the opportunity to make changes to the application along the way? How do you make a plan and stick to it? This post answers those questions and more.
Should I migrate my application to a cloud?
As a first step, take notes on the frustrating parts of your current deployment. Is your application running on older, difficult to manage hardware? Could you increase security around the application by deploying it in a more controlled environment? Are you eager to reduce your datacenter footprint? A list of the current shortcomings helps your team make the right decision.
Think about the future of your application. What will it do in a year? Three years? Does it make sense to migrate your application anywhere during these timeframes? Clouds provide some level of future-proofing for deployments but if you don’t see value in the application itself after a year, sunsetting the application could be the best option.
A common misconception is that clouds always provide a cheaper method for hosting applications. They often offer more scalability and flexibility than a traditional datacenter provides, but that comes at a cost. Businesses have more control over these costs when compared to hosting applications in traditional datacenters.
API-driven automation scales networks, virtual machines, and storage at a moment’s notice. That may lead to higher bills initially, but it also empowers you to optimize for performance or cost depending on the needs of each application. Utility pricing in clouds gives you the benefit of "pay as you go" -- scale up and pay more when demand is high and then scale back down afterwards. A common phrase, "own the base, rent the peak," means you have a base level of infrastructure running with the ability to scale up during high demand periods.
Fortunately, Red Hat Enterprise Linux (RHEL) migrates with you to the cloud. You get the same access to RHEL content, updates, and support as you do in your datacenter.
Should I change anything in my application as I move to the cloud?
Absolutely! Simply put: cloud deployments cost less when customers find ways to make their application fit the cloud and not the other way around. These tailored deployments deliver the highest efficiency.
In "The Phoenix Project," Gene Kim wrote, "any improvements made anywhere besides the bottleneck are an illusion." Migrations offer opportunities to crush technical debt, speed up slow parts of the application, and make the application easier to manage.
To do this well, you must know the capabilities and constraints of your specific application along with the destination cloud. Simply hauling the application from a physical server in your datacenter to a big virtual machine in a cloud leads to the same problems you have now (just in a different place).
Clouds offer the usual infrastructure primitives, such as virtual machines, networks, and storage. In addition, many clouds offer additional services that reduce the burden for operations teams. By leveraging these managed services, such as a managed database service, operations teams can focus on the application and its business-critical data rather than maintaining a complicated set of database servers.
One area often gets the least amount of attention but can cause the largest problems: networking. Take time to plan the networking setup for your application to increase security and avoid massive bills. Most clouds allow for strict, fine-grained security controls on the network. Use these to your advantage to limit access to critical infrastructure.
Take care to use private networks between instances whenever possible for security, of course, but also to avoid massive bills when communicating between instances on the public network. Network usage expenses loom as one of the largest costs in a cloud deployment.
How do I plan my migration?
Deploying to a cloud for the first time feels like walking into a candy store. A wide array of incredibly valuable services await you with their catchy names and seemingly affordable price tags. Beware! Everyone is drawn to the massive amount of choice available in clouds, but this can lead to challenging and expensive deployments.
A budget with soft and hard limits provides the freedom to choose the right services but it also applies a constraint to overspending. Consider spending more to make it easier to scale or to increase performance in areas with a big impact. As an example, if your application is storage I/O-intensive but doesn’t need much RAM, you could reduce the size of the virtual machine and use a faster storage medium that allows for scaling up storage performance. This push and pull in the planning process leads to a good starting point for the deployment that can scale up or down later.
Yogi Berra once said: "If you don’t know where you are going, you’ll end up someplace else."
Before migrating, make a plan from start to finish. Ensure your plan includes:
Dependencies between different steps
Go/No-Go checkpoints to ensure everything is on track
Communication guidelines for sharing status with stakeholders
Change management for deployment changes after the migration
Stick to the plan once everyone agrees to it. Document the progress and what the team would do differently for the next migration. These steps, although somewhat tedious, make each migration easier and more effective with less effort.
Consider a cloud migration for applications that benefit from a more flexible and scalable infrastructure with finer-grained security controls. A migration provides an opportunity to analyze the application for its operational challenges and to make improvements.
Although clouds often increase costs, they offer plenty of services that reduce operational burden. The sheer number of cloud services often overwhelms newcomers, but building a solid plan with collaborative touch points and good communication ensures the best possible result.
About the author
Major Hayden is a Principal Software Engineer at Red Hat with a focus on making it easier to deploy Red Hat Enterprise Linux wherever a customer needs it. He is also an amateur radio operator (W5WUT), and he maintains a technical blog at major.io.