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
- 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.
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.
- Synthetics: Monitor web frontends and APIs with 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.
Based on the component-product matches you made, deploy agents or monitors across your architecture:
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 APM, check out these New Relic University’s tutorials:
After you define your KPIs, it is easy to visualize them in 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.
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.