In this age of falling cloud computing costs and hybrid cloud infrastructures, many businesses are trying to find a path to migrate their apps to the cloud. There are a myriad of reasons why app migration is top of mind:
- Potential cost savings
- Disaster recovery uses
- App refactoring or modernization
- Access to burstable resources
- Integration with SaaS platforms or new cloud-based tools (e.g. Amazon RDS, Azure App Services, and Google Cloud Spanner)
In this blog post, I will explore some of the concepts and requirements needed to migrate an app from an on-premises data center to another location. This secondary location is typically a cloud provider, but many of the concepts apply when moving to a DR site, or even a developer’s laptop. In our example, we’ll use one of the most ubiquitous three-tier apps available: WordPress. The diagram below describes the components of our app.
Understand Your App
Let’s be honest—apps can be complex. If you’ve amassed technical debt in regard to documenting your apps or have little understanding of how they connect with other apps or business processes, you will have some homework to do. You’ll need to document and fully comprehend all aspects of your app, including:
- Platform
- Application state
- Data format and storage
- Networking
- Security and governance
Let’s dig into these topics further.
Platform
The first place to start is understanding your application platform. Some questions you might ask:
- Does your app run on a dedicated bare metal server, on a VM, or in a Docker container?
- What hypervisor are you using for virtualization?
Each of these scenarios presents a different “path” when being moved. Our WordPress example is made up of VMware-based VMs, which presents a bit of a challenge if we want to move them as is to a major cloud provider (i.e. AWS, GCP or Azure) due to hypervisor incompatibility. This is typically referred to as a “lift and shift” approach. There are a number of tool sets available to convert existing VMs to the format your chosen provider uses. You will need to thoroughly digest the documentation for these tools, and be prepared for some trial and error.
Application State
The next principle to understand is application state. This has varying definitions depending on the app behavior or framework, but in general, it represents the places that your app stores information. State may represent a number of things: configuration settings, shopping cart contents, product orders, or a blog post and comments. Without this data, your app is like a blank slate with little value. You need to transfer this data along with your app, otherwise you will be starting from scratch. Frequently, as is the case with our WordPress example, the state lives in a database.
Databases have different methods for moving stateful data around (e.g. replication, backup/restore), so you will need to choose the method that best fits your use case. For our WordPress example, I am using snapshot-based backups via CDM. This can be problematic for databases due to the fact that a snapshot may be taken mid-write, which can result in a non-functional database when restored. This concept is also referred to as “backup consistency” or “snapshot consistency,” and is especially important to understand if you use a snapshot-based backup method.
Obtaining consistent backups for stateful apps, like databases, may require an agent to be installed on the OS or the use of pre- and post-snapshot scripts. This principle applies to both storage-array based snapshots and VM-based snapshots. One way to address this is to use a pre-snapshot script to lock the database tables and a post-snapshot script to unlock them. This is a workable solution for our simple MariaDB database, but there are also app-aware backup methods for popular enterprise databases like Microsoft SQL and Oracle to address this issue.
Data Format and Storage
Once you’ve gained an understanding of your app and its state, it’s time to look at the “mass” of your app.
- How much data will you have to move along with your app?
- How much will it cost in terms of connectivity and storage fees to move and operate?
- Do you need to move all of your data, or is a subset sufficient?
These calculations will help you determine the effort required to move your app, and how much it will cost when moved. Another concept to consider is that of “data gravity.” This ties in with the idea that data has mass. As the amount of data increases, it attracts additional apps and services and becomes more difficult to move. Consider that moving a critical business app with years of important data may drag along several related apps that rely on it. It may be possible to keep some apps in different locations even when they’re relying on the same data, but you will typically pay for this in network egress fees, not to mention added complexity.
Networking
Speaking of network egress fees, this leads to my favorite topic, networking. Let’s examine our WordPress example, which represents a very simple and straightforward networking setup.
Contrast this with legacy apps made up of tens or hundreds of servers or apps without well-documented TCP/UDP port usage, and it is obvious that planning to move a large or poorly-documented app can get out of hand quickly. The takeaway is that you must have a solid understanding of how your app communicates and which ports it uses to communicate. If you have network appliances, such as load balancers, evaluate how tightly they are coupled with your app and if there is a feasible replacement at the destination location for your app.
Security and Compliance
The last piece of this puzzle is security and compliance:
- Are there are any data governance laws or compliance regulations that apply to your app or its data? If so, this may place limitations on where you can run your app.
- Do you have a well-defined security policy for your app? If not, there is no time like the present to create one.
This document should define all security requirements for your app, including authentication, authorization, role-based access control, firewall rules, and encryption needs. If you have an existing policy, you will need to determine what needs to be modified if you move your app. It’s worth noting that enforcing security policy within a cloud provider will require a good deal of research and planning.
I recommend consulting with your security and compliance teams at the beginning of your planning process. They will appreciate being a part of the project from the start, and can provide valuable guidance as you plan. You don’t want to spend time planning an app migration only to have it called off due to security or compliance concerns.
Understand the Destination
From an effort perspective, it will always be easier to migrate an app to a destination that is using a similar technology stack than one that is significantly different. Our WordPress example running in VMware presents a problem because none of the major cloud providers run a VMware hypervisor in their native compute offering. This may lead the app owner to consider one of the many smaller providers that does, or in large use cases, VMware Cloud on AWS. The major clouds offer the best pricing, connectivity, and add-on services, so it’s often worth the trouble to make the switch, but there are some things to keep in mind.
Simply migrating VMs to the cloud is an easy way to get comfortable with the interface and tools, but in some instances, you will be forced into adopting “cloud-native” principals. Cloud-native apps are developed from scratch to take advantage of cloud computing features, and typically subscribe to some or all of the Twelve-Factor App Methodology for web-based apps. Completely refactoring your app to a cloud-native architecture is an option for migrating your app, but it may not be feasible due to time or finances. By migrating your VMs, you can start to adopt some cloud-native principals at your own pace.
The First Big Change
The first big change for most businesses is making the switch from VMs with statically-assigned IP addresses to dynamic addresses assigned by DHCP. This means you will need to use DNS entries to connect to VMs and services. The major cloud providers make this as easy as possible by generating DNS entries for your VMs, as well as managed DNS offerings that can be administered programmatically via API.
In a traditional environment, it’s usually not a problem to hardcode an IP address in the configuration files for MariaDB, WordPress, or NGINX. This is exactly what I did when I configured WordPress in my lab. When I migrated these VMs to AWS, I adjusted the configuration files to use the DNS entries created for each VM, and they functioned exactly as expected. The diagrams below represent a simplified depiction of the VMs before and after migration.
For a large production environment, this is a perfect use case to leverage automation. For example, you could programatically create DNS records that were pointing to your cloud-based VMs. If I had used DNS in the first place, and designed it in such a way that the host names were the same in my lab and AWS, there would have been no configuration changes required. In the end, DNS is a much more flexible solution than hardcoded IPs, but it requires additional planning.
Network Planning and Considerations
Networking configurations such as routing, firewall rules, network address translation (NAT), VPNs, and load balancing will require a good bit of planning to make sure they meet your requirements. All of the necessary pieces are available, but the implementation is going to look and feel differently than it does in a traditional environment. Cloud provider networks are completely software defined, so there is no central firewall or load balancer to configure.
This also means that there are limits on the amount of resources that can be consumed in terms of network prefix routes, public IP addresses, VPN tunnels, etc. Make sure you understand the limits imposed by your chosen provider, as well as what action to take if you need to have the limit increased. Sometimes this can be accomplished with an API call, but in other cases, you will have to open a support ticket. Either way, this is an important design consideration if you are operating at scale.
Once you’ve migrated your VMs and configured various networking and security features, you’ll reach a crossroads. You can choose to leave your app as is, humming away in the cloud, or you can start to evaluate additional services from your provider to potentially save money or reduce administrative overhead. Databases are a great example of a cloud service that is worth considering. Why would I run MariaDB in a VM when I could import my data into a compatible managed database offering at less cost? This is one example of many similar services available from the major clouds.
Easing the Pain
This blog post has highlighted several key points to consider when migrating your apps, and there is no shortage of difficult problems to solve. Luckily, Rubrik CDM can remove a good deal of the pain. Having used other methods to migrate VMs to a cloud provider in the past, I chose to use CloudOn to migrate my WordPress app to AWS while performing research for this post.
Apart from the aforementioned configuration file changes, it could not have been easier. I added my VMs to the appropriate SLA and enabled Cloud Conversion. After the snapshots were replicated to AWS and the conversion from VMware VM to Amazon AMI completed, I was able to painlessly launch each VM in my AWS Virtual Private Cloud. This is an excellent option for businesses that are looking for an on-ramp to the cloud.
As long as you take an approach of understanding your app and the changes that will be required to move it, you will be set for success. Combine this with the power of automation and the resources available at Rubrik Build to craft a solution tailored for your exact needs.