Today’s Community Contributor has chosen to remain anonymous. However, they are an enterprise architect with 21+ years of technology leadership experience, driving business transformation initiatives in the insurance, automotive, media & entertainment, and human capital domains.
I am the architect of a Java-based web application and a major part of my job is to ensure that the application meets its performance metrics. If I discover any performance bottlenecks, I suggest remedial measures and have them addressed immediately. I have been a happy Dynatrace user for some time now, and have come to rely on it to monitor my applications.
My organization recently decided to do an enterprise-wide rollout of the new APM kid on the block New Relic. My goal in this post is to capture my experiences and observations concerning both APM tools, bearing in mind that my observations are limited to the context of Java-based web application performance monitoring.
Dynatrace offers two deployment models:
- Cloud (Dynatrace SaaS)
- On-Premise (Dynatrace Managed)
New Relic, by contrast, offers cloud deployment only.
On the face of it, the cloud is the way forward and represents the future. The pay-per-use model is preferred to upfront capital expenditure and the cloud deployment model has come to be the dominant deployment method for packaged applications.
However, there is one area in which the cloud model becomes a constraint. During performance monitoring, developers need the raw details of requests (request parameters, SQL bind values, etc). The problem is that raw data might contain sensitive information like PII (Personally identifiable information) and PHI (Protected Health Information). From a data security perspective, exposing this sensitive data on the cloud is usually not allowed. With on-premise deployments, exposing such data is allowed provided adequate access controls are put in place.
Detailed Transaction View
Dynatrace monitors and provides a detailed, multi-dimensional trace of every transaction in a monitored application providing visibility across web browsers, web apps, mobile apps, web servers, Java, .NET, PHP, databases, middleware, and mainframe apps. (PurePath). However, Dynatrace does not encourage individual request monitoring due to the increased demand for network and storage capacity.
Dynatrace provides the performance engineer with individual transaction visibility. This is a great feature to help application developers understand specific transaction failures. My support team uses trace information to ascertain application code bugs. We do not need any independent application logging tools as Dynatrace provides all the relevant information.
New Relic, on the other hand, samples and reports detailed transaction traces for a few representative transactions and provides an aggregated view. This is perfectly adequate if the scope of APM is limited to the ITOps team. If, however, the end-user is an application developer Dynatrace’s detailed view is worth its weight in gold.
To summarize: Dynatrace allows data capture and traceability at the individual request level while New Relic provides an aggregated view. This essentially means that New Relic is designed for ITOps performance monitoring while Dynatrace also supports application functional testing in the development organization.
An application or a platform is a sum of many parts. It includes multiple software products. Both APM products allow end-users to create a custom product-related plug-in. Dynatrace itself supports an extensive number of plug-ins and has an ecosystem for open-source plugins. New Relic does not have so much out-of-the-box support and depends on its open-source or 3rd party plugin ecosystem.
End-users want a visual depiction of how an HTTP web request flows through the various components, and how much time the request spends in each component. This helps in determining normal or abnormal behavior within the application and quickly identifies bottlenecks. Both tools provide such a view. Dynatrace calls it ‘Service Flow’; New Relic calls it ‘Service Maps’.
Here’s what Dynatrace’s Service Flow looks like visually.
This is what New Relic’s Service Maps looks like.
I like two things in particular about Dynatrace’s visualization. It shows the time spent and % contribution against each component. Secondly, it lists all Dynatrace monitored components. New Relic lists applications, external services, and databases. In a typical web application, the webserver is an important part of the transaction, but New Relic does not show it in its map.
Data Storage location
Dynatrace offers an on-premise data storage option. This allows organizations to decide how much data they want to store and for how long. New Relic provides a pure cloud storage option and its data storage policy is standard. Because the storage location is in the cloud, the application team has to be careful around allowing request parameters, or query parameters from exposing PII/PHI data as noted above.
New Relic provides a feature called New Relic Query Language (NRQL). This allows end-users to store custom information/attributes and query the stored information. This is something new and Dynatrace does not appear to have any equivalent tooling. This is moving from performance monitoring into the reporting/analytics domain. New Relic scores here.
Browser Behavior Monitoring
To summarize, if you want to know how your application is performing, New Relic works very well. On the other hand, if you need to determine why the application is slow you need Dynatrace.
Understand Your Organization’s Requirements
What makes New Relic a compelling offer? In a word: Pricing. Dynatrace has a very hefty price tag compared to New Relic. My advice is to carefully consider whether the more advanced features provided by Dynatrace are required by your organization. Perhaps the less expensive New Relic has strong enough capabilities to meet the needs of your organization.
Was this helpful?