Lesson Contents
Migrating applications to the cloud require planning and research. In this lesson, we’ll take a look at five steps to migrate your on-premises workload to the cloud.
Application discovery
Our first step is to discover, analyze, and categorize your on-premises applications. Not all applications are suitable to migrate to a cloud environment. Here are some items you need to consider:
- Specialized hardware requirements: does your application run on specific hardware? Cloud providers offer different CPU types, including x86 and ARM. Most cloud providers also offer GPUs.
- Operating system: Does your application run on an operating system that the cloud provider supports or can you make it work on another operating system?
- Legacy databases: does your application run on old database server software that a cloud provider might not support?
- Security: does the application have any security measures? Older applications might not get updates anymore which might be acceptable in an isolated on-premises situation but not in the cloud.
- Performance requirements: does your application have specific performance requirements? Can a cloud environment meet these requirements? Is your application sensitive to delay?
Application types
There are two kinds of applications. Ones that work in the cloud, and those that don’t. We call applications that don’t run in the cloud legacy applications. These applications were designed to run on traditional (virtual) servers. Let’s discuss the difference between the two application types.
Legacy applications
Most applications are legacy applications but with some modifications, we can make them work in the cloud. This is best explained with an example:
WordPress is a popular CMS. ~30% of the websites in 2018 run on WordPress. Even if you never worked with WordPress before or installed a web server, you can probably understand this example.
If you want to host WordPress yourself in the “traditional” way then we have a process that looks like this:
- Select a (virtual) server with a certain amount of CPU cores, memory, and storage.
- Install a Linux Distribution as the operating system.
- Install all required packages:
- Apache: our web server software.
- MySQL: the database server.
- Download the WordPress files and upload them to your server.
- Add the database name, username, and password to the wp-config.php file.
- Launch your website.
You can perform the above steps manually or use installation scripts to automate these steps.
When your website grows and attracts more visitors, you can scale up and add more CPU cores and/or increase the memory of the server. When your server dies, you have a problem. You can always install a new server and restore a backup.
With traditional servers, our servers are like pets. We manually install, upgrade, and repair them. They run for years so we treat them with love and care. Perhaps we even give them special hostnames.
Cloud applications
Cloud providers offer virtual servers so you can repeat the above steps on a cloud provider’s virtual server. Running your website on a virtual server from a cloud provider is the same as regular Virtual Private Server (VPS) hosting, we end up with a “pet”.
In the cloud, we start new servers on-demand when we need them and we destroy them when no longer needed. Servers and other resources are disposable so we treat them like cattle. We want to spin up servers quickly so there is no time to manually configure a new server. To achieve this, we need to create a blueprint and configuration we can use for all servers.
To create a blueprint, we use a configuration management tool to define “infrastructure as code”. We configure the infrastructure we need in JSON/YAML files. Examples are Amazon AWS CloudFormation or Google Cloud Deployment Manager. Terraform is a configuration management tool that supports multiple cloud providers. To install and configure the servers, you can use deployment tools like Chef, Puppet, Ansible, and Amazon AWS CodeDeploy. Another option is to use containers which we discuss in another lesson.
When it comes to cloud computing, we want to keep cattle, not pets. If you are interested in building cloud-compatible applications, then you should take a look at the Twelve-Factor App Methodology. It’s a baseline that offers best practices to build scalable (web) applications.
Let’s walk through an example of how we can run our legacy WordPress application in the cloud:
Infrastructure as code
We create one or more configuration files that define our infrastructure resources:
- Template for our web server(s).
- Template for our database: we use a SaaS solution like Amazon AWS RDS, Google Cloud, or Azure Database for MySQL for this.
- Template for a load balancer: if you have over one web server then you need a load balancer to distribute the incoming traffic.
- Template for autoscaling alarm: when the CPU load of our web server exceeds 50%, we want to start a second web server.
- Template for shared file storage: our web servers need shared access to certain files. I’ll explain this in a bit. You can use a SaaS solution like Amazon AWS Elastic File System (EFS), Amazon AWS S3, or Google Cloud Filestore for this.
Having your infrastructure as code makes it easy to create and replicate resources.
Version Control System (VCS)
You should store your configuration files in a Version Control System (VCS). The advantage of a VCS is that it keeps track of changes in your files and it’s easy to work on the same files with multiple people. Git is the most popular open-source VCS. Github is a popular website where you can create git repositories to save your files.
We also store our WordPress files in a git repository. whenever you make changes to your website, you add them to the git repository. This makes your application stateless.
Deployment tool
We configure a deployment tool to install required packages for Apache, clone the WordPress git repository and any other configuration files needed. When we launch a new web server, the deployment tool automatically installs and configures the new server.
