| title | tags | metaDescription | redirects | freshnessValidatedDate | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cloud migration: Create application baselines |
|
Use New Relic to establish a baseline to use for comparison during your cloud adoption process. |
|
never |
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.
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
- Database
- Website
- Underlying server and infrastructure
<table>
<thead>
<tr>
<th>
Component Name
</th>
<th>
Owner
</th>
<th>
Language Stack
</th>
<th>
Accessibility (Internet, Intranet)
</th>
<th>
Operating System
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Service 1
</td>
<td>
John Doe
</td>
<td>
Java
</td>
<td>
Internet
</td>
<td>
RHEL 6
</td>
</tr>
<tr>
<td>
Service 2
</td>
<td>
Maya Wiz
</td>
<td>
.NET
</td>
<td>
Intranet
</td>
<td>
Win2003 R2
</td>
</tr>
<tr>
<td>
RabbitMQ
</td>
<td>
John Doe
</td>
<td>
Java
</td>
<td>
Intranet
</td>
<td>
AIX
</td>
</tr>
<tr>
<td>
Website
</td>
<td>
Maya Wiz
</td>
<td>
Classic ASP
</td>
<td>
Internet
</td>
<td>
Win2000
</td>
</tr>
<tr>
<td>
MS SQL
</td>
<td>
Dave Z
</td>
<td>
NA
</td>
<td>
Intranet
</td>
<td>
Win2003 R2
</td>
</tr>
</tbody>
</table>
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:
- APM: Monitor your web apps with APM. See Compatibility and requirements for New Relic agents and products to learn precise compatibility details for each supported language.
- Infrastructure: Monitor your hosts with infrastructure. See Compatibility and requirements for infrastructure for supported operating systems and environments. You can also instrument other products and services with on-host integrations.
- Synthetic monitoring: Monitor web frontends and APIs with synthetic monitoring. Sometimes, you may not be able to instrument your on-premise environment with 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 synthetic monitoring, as it offers non-agent monitoring while still providing the ability to establish a baseline.
<table>
<thead>
<tr>
<th>
Component Name
</th>
<th>
Tier Owner
</th>
<th>
Language Stack
</th>
<th>
Accessibility (Internet/ Intranet)
</th>
<th>
Operating System
</th>
<th>
New Relic products
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Service 1
</td>
<td>
John Doe
</td>
<td>
Java
</td>
<td>
Internet
</td>
<td>
RHEL 6
</td>
<td>
APM, infrastructure monitoring, Synthetic monitoring
</td>
</tr>
<tr>
<td>
Service 2
</td>
<td>
Maya Wiz
</td>
<td>
.NET
</td>
<td>
Intranet
</td>
<td>
Win2003 R2
</td>
<td>
APM, Infrastructure
</td>
</tr>
<tr>
<td>
<DNT>
ActiveMQ
</DNT>
</td>
<td>
John Doe
</td>
<td>
Java
</td>
<td>
Intranet
</td>
<td>
AIX
</td>
<td>
APM
</td>
</tr>
<tr>
<td>
Website
</td>
<td>
Maya Wiz
</td>
<td>
Classic ASP
</td>
<td>
Internet
</td>
<td>
Win2000
</td>
<td>
Synthetics
</td>
</tr>
<tr>
<td>
MS SQL
</td>
<td>
Dave Z
</td>
<td>
n/a
</td>
<td>
Intranet
</td>
<td>
Win2003 R2
</td>
<td>
Infrastructure, On-host Integration
</td>
</tr>
</tbody>
</table>
Based on the component-product matches you made, deploy agents or monitors across your architecture:
[Install the APM agent](/docs/agents/manage-apm-agents/installation/install-agent) on your application stack. The steps to install the agent are different based on language.<Collapser id="deploy-infrastructure" title="Deploy infrastructure"
After reviewing the requirements for infrastructure, follow the instructions to install the infrastructure agent on your hosts:
* [Install for Linux](/docs/infrastructure/new-relic-infrastructure/installation/install-infrastructure-linux)
* [Install for Windows Server](/docs/infrastructure/new-relic-infrastructure/installation/install-infrastructure-windows-server)
* [Install on AWS Elastic Beanstalk](/docs/infrastructure/new-relic-infrastructure/installation/install-infrastructure-agent-aws-elastic-beanstalk)
* [Install with a configuration management tool](/docs/infrastructure/new-relic-infrastructure/config-management-tools)
<Collapser id="deploy-infrastructure-on-host" title="Deploy infrastructure on-host integrations"
To gain extended visibility into applications that your code depends on, deploy [on-host integrations](/docs/infrastructure/host-integrations/host-integrations-list). Available integrations include Apache, MySQL, NGINX, and others.
<Collapser id="create-synthetics-monitor" title="Create synthetic monitors"
Synthetic monitoring is a suite of automated, scriptable tools to monitor your websites, critical business transactions, and API endpoints. To get started [add a monitor](/docs/synthetics/new-relic-synthetics/using-monitors/add-edit-monitors#adding-monitors).
<Callout variant="tip">
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](/docs/synthetics/new-relic-synthetics/administration/synthetics-public-minion-ips).
</Callout>
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.
You can find some of these metrics in service maps, as well as on APM, and browser summary pages.
For more detailed information about navigating, interpreting, and using APM, check out these New Relic University's tutorials:
After you define your KPIs, it's easy to visualize them in dashboards. Dashboards offer 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.
For more information about events, see Data collection and Default events for New Relic products.
You can locate your KPIs and business metrics data in New Relic using metrics and events and the NRQL query language. You can also build dashboards to track the performance of those KPIs:
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:<table>
<thead>
<tr>
<th colSpan={2}>
Component
</th>
<th colSpan={3}>
Milestone 1
</th>
<th colSpan={3}>
Milestone 2
</th>
<th>
Milestone N
</th>
</tr>
</thead>
<tbody>
<tr>
<td style={{ width: "250px" }}>
<DNT>
**Environment**
</DNT>
</td>
<td style={{ width: "250px" }}>
<DNT>
**Component Name**
</DNT>
</td>
<td>
<DNT>
**Response Time**
</DNT>
</td>
<td>
<DNT>
**SLA**
</DNT>
</td>
<td>
<DNT>
**Apdex**
</DNT>
</td>
<td>
<DNT>
**Response Time**
</DNT>
</td>
<td>
<DNT>
**SLA**
</DNT>
</td>
<td>
<DNT>
**Apdex**
</DNT>
</td>
<td>
<DNT>
**Response**
</DNT>
</td>
</tr>
<tr>
<td>
On-Prem
</td>
<td>
Service 1
</td>
<td>
1.5 secs
</td>
<td>
80%
</td>
<td>
70%
</td>
<td>
1.5 secs
</td>
<td>
68%
</td>
<td>
0.65
</td>
<td>
1.4 secs
</td>
</tr>
<tr>
<td>
Cloud
</td>
<td>
Service 1
</td>
<td>
0.9 secs
</td>
<td>
96.8%
</td>
<td>
95%
</td>
<td>
0.9 secs
</td>
<td>
98%
</td>
<td>
0.99
</td>
<td>
0.7 secs
</td>
</tr>
<tr>
<td>
On-Prem
</td>
<td>
Service 2
</td>
<td>
0.7 secs
</td>
<td>
73%
</td>
<td>
68%
</td>
<td>
0.7 secs
</td>
<td>
80%
</td>
<td>
0.78
</td>
<td>
0.85 secs
</td>
</tr>
<tr>
<td>
Cloud
</td>
<td>
Service 2
</td>
<td>
0.6 secs
</td>
<td>
90%
</td>
<td>
92%
</td>
<td>
0.6 secs
</td>
<td>
89%
</td>
<td>
0.90
</td>
<td>
0.5 secs
</td>
</tr>
</tbody>
</table>
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, we make it easy for you to capture custom data:
- APM custom instrumentation
- Browser custom data
- Infrastructure custom attributes
- Custom event data
- Mobile custom data
- Synthetic custom attributes
You can also learn more about APM custom instrumentation with the New Relic University Custom data tutorial series.