Migrating Applications from the Data Center to the Cloud

by Samir Mehra

So, you want to migrate your business-critical application from your aging data center infrastructure to the public cloud? The migration will consist of three main phases:

  1. Discovery
  2. Recommendations or Assessments
  3. Migration

In this blog post, I’ll look at the first two, focusing primarily on the discovery phase.

Phase 1: Discovery

There are numerous aspects to discovery, and numerous ways to discover infrastructure.

Discovery can range from determining the configuration details of a single server, or the performance details of multiple servers. It may consist of discovering a business application and determining configuration and performance details of all the servers running the application. There are a plethora of ways that discovery information can be collected, including integration with existing management tools (such as VMware vSphere), an agentless approach for highly dynamic workloads or good old agents.

One such agent is AWS’s Application Discovery Service. Let’s take Sharepoint as an example of an application that a team may want to migrate out from the data center to the public cloud. Sharepoint’s typical configuration includes a simple Web farm with two front-end Web Servers and a database server.

As part of the discovery, the team must determine:

  • All the servers that are part of Sharepoint
  • The purpose of each server.

So, how do you figure out the above dependency using AWS’s Application Discovery Service? The process is fairly straightforward:

  1. Install the agent on the Database server (it could be any of the Web Servers, too).
  2. Initially, the agent provides 2 pieces of information that will help build the application discovery map:
  • A list of connections that includes source and destination information (processes, IP’s, etc.) that are communicating with each other
  • A list of processes that are running on the server. For example, if the agent was installed on the database server, it would show that SQL server is running on this DB server.

3. Steps 1 and 2 will repeat until all the servers are discovered and their purpose (web server or database server) has been determined.

4. With the application dependency determined, you now want to tag these servers with the following key-value pairs:

  • Application:Sharepoint (Apply this tag to all the servers that are part of the application)
  • WebServer 1; Server:Sharepoint_Web1
  • WebServer 2; Server:Sharepoint_Web2
  • Database Server; Server:Sharepoint_Database*

5. While the agent is helping you determine the application dependencies, it is also collecting configuration details and performance information which will be useful during the next phase of application migration.

* Note: Step 4 is an important aspect of the discovery; later phases of the migration process benefit greatly from this step.

Phase 2: Assessment/Recommendations

To recap, the discovery phase yielded the following information:

  • Application dependency (via connections and process information)
  • Configuration details of all the servers that are part of the application
  • Performance metrics for all the servers

Using the information above, along with an assessment or recommendation engine, can help you determine the following:

  1. TCO of running the application in the cloud.
  2. TCO of each server that is part of an application
  3. Type of machines or instances to purchase in the cloud. (When moving to AWS, you have the opportunity to determine on-demand costs vs. costs incurred if you purchased Reserved Instances.)

You have now completed 2 important phases to migrate your application to the cloud! Stay tuned for more discussions on continuing your journey in Phase 3.


Originally published at www.cloudhealthtech.com.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.