Cloud Workload Migration

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.

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 s


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:

  1. Select a (virtual) server with a certain amount of CPU cores, memory, and storage.
  2. Install a Linux Distribution as the operating system.
  3. Install all required packages:
    1. Apache: our web server software.
    2. MySQL: the database server.
  4. Download the WordPress files and upload them to your server.
  5. Add the database name, username, and password to the wp-config.php file.
  6. 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.

Another name for pet servers is snowflake servers.

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.

If you want to try git, I recommend Gitlab. Github is popular for public git repositories but Gitlab allows you to create unlimited private git repositories for free.
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.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

510 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Ask a question or start a discussion by visiting our Community Forum