Cloud migrations can take many forms. Some companies choose to port their applications directly from their data center to the cloud (a “Lift and Shift” migration) while others focus on completely re-architecting their applications to take advantage of benefits available only in the cloud. No matter your approach, there are three primary questions you want to answer after your migration:
- Has my application gotten slower?
- Is my application less stable than before?
- Am I losing customers due to either of the previous questions?
To answer these questions, start by performing some basic testing to establish a baseline for the performance and availability of your systems. A baseline is a measurement of the current performance and availability of your application, which you then use as a comparison after your migration to validate your business case. In some cases, you may change a baseline when you perform migration acceptance testing. You can also use a baseline as a comparison point during your migration to make sure that you are on track.
1. Identify components
Before you begin a cloud migration, identify all the tiers of your entire application stack. List all of the components (applications, services, etc.) that you want to migrate. Segment the application stack as follows:
- Application (backend/microservices/cron jobs)
- Dependency services, such as the message queue
- Underlying server and infrastructure
Make sure that you have access to applications and instances before you start creating application baselines. Engage your application owners, DevOps engineers, and product managers for access.
- Example: List of components
Here is an example of the list of components in an application stack:
Component Name Owner Language Stack Accessibility (Internet, Intranet) Operating System Service 1 John Doe Java Internet RHEL 6 Service 2 Maya Wiz .NET Intranet Win2003 R2 RabbitMQ John Doe Java Intranet AIX Website Maya Wiz Classic ASP Internet Win2000 MS SQL Dave Z NA Intranet Win2003 R2
2. Determine compatibility
Once you identify the applications that you want to migrate, it is time to verify which application tiers to monitor with the New Relic platform. Work with stakeholders in your organization to determine the amount of instrumentation that is possible–or allowed–within your organization. This is an important step and one that will pay off, as the more you can instrument, the better your baselines.
Here are the New Relic products to use for baselining, depending on the components that you identified:
- New Relic APM: Monitor your web apps with New Relic APM. See Compatibility and requirements for New Relic agents and products to learn precise compatibility details for each supported language.
- New Relic Infrastructure: Monitor your hosts with New Relic Infrastructure. See Compatibility and requirements for New Relic Infrastructure for supported operating systems and environments. You can also instrument other products and services with on-host integrations.
- New Relic Synthetics: Monitor web frontends and APIs with New Relic Synthetics. Sometimes, you may not be able to instrument your on-premise environment with APM or Infrastructure. For example, maybe your organization's policy forbids installing an agent behind a firewall. In these cases, if the application has a web frontend, use Synthetics, as it offers non-agent monitoring while still providing the ability to establish a baseline.
- Example: Components matched to New Relic products
Match the components that you identified with their corresponding products:
Component Name Tier Owner Language Stack Accessibility (Internet/ Intranet) Operating System New Relic Products Service 1 John Doe Java Internet RHEL 6 APM, Infrastructure, Synthetics Service 2 Maya Wiz .NET Intranet Win2003 R2 APM, Infrastructure ActiveMQ John Doe Java Intranet AIX APM, Plugin Website Maya Wiz Classic ASP Internet Win2000 Synthetics MS SQL Dave Z n/a Intranet Win2003 R2 Infrastructure, On-host Integration
3. Deploy monitoring
Based on the component-product matches you made, deploy agents or monitors across your architecture:
- Deploy New Relic APM
Install the APM agent on your application stack. The steps to install the APM agent are different based on language.
- Deploy New Relic Infrastructure
After reviewing the requirements for New Relic Infrastructure, follow the instructions to install the Infrastructure agent on your hosts:
- Deploy Infrastructure on-host integrations
To gain extended visibility into applications that your code depends on, deploy on-host integrations. Available integrations include Apache, MySQL, NGINX, and others.
- Create New Relic Synthetics monitors
New Relic Synthetics is a suite of automated, scriptable tools to monitor your websites, critical business transactions, and API endpoints. To get started add a monitor.
Make sure to verify that your website URL is accessible from the public network. You may also need to add New Relic IPs to your allow list.
4. Gather metrics
After you deploy the agents and monitors, identify which metrics are the most important to your business and use these metrics to define your KPIs. Some recommendations include:
- Response time: Time taken to respond to a request.
- Throughput: Number of requests that came in through the application.
- Requesting queuing (Apache, IIS, NGINX): Duration of time taken for a request to reach your application.
- Database call duration: Duration of time taken to complete a database call.
- DB call counts: Number of calls made by application code to the database.
- Error rate: Percent of errors reported.
- Apdex score: An industry standard to measure user satisfaction with the response time of web applications and services.
- DNS setup timing: The time it takes to connect and receive data from DNS.
- SSL setup timing: The time it takes to establish an SSL connection.
For more detailed information about navigating, interpreting, and using New Relic APM, check out these New Relic University’s tutorials:
5. Set up Dashboards
After you define your KPIs, it is easy to visualize them in New Relic Dashboards. Dashboards provide a single location to view all the data that New Relic products gather. Dashboards data consists of events, and each event has an event type, a timestamp, and key-value attributes.
- Example: Component performance compared against baselines
Continuing the examples in this document, the following table illustrates the maturity of your application performance over a period of time based on deployment milestones. Each milestone will serve as a new baseline for your applications:
After your migration, compare these baselines against your migration acceptance testing baselines.
If you find that you need data that is not captured by default instrumentation, New Relic makes it easy to capture custom data:
- APM custom instrumentation
- Browser custom data
- Infrastructure custom attributes
- Custom event data
- Mobile custom data
- Synthetics custom attributes
You can also learn more about APM custom instrumentation with the New Relic University Custom data tutorial series.