The content in this blog is outdated and we cannot reliably say it is still accurate with the speed in which the cloud industry moves. But don’t worry—below are more recent, up-to-date blogs.
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:
- Recommendations or Assessments
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:
- Install the agent on the Database server (it could be any of the Web Servers, too).
- 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.
- Steps 1 and 2 will repeat until all the servers are discovered and their purpose (web server or database server) has been determined.
- 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*
- 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:
- TCO of running the application in the cloud.
- TCO of each server that is part of an application
- 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.)