It’s hard to argue with facts. That’s probably why AppDynamics’ spin machine has been hard at work lately, trying to find distorted angles and mis-representations about our capabilities. This is an attempt to distract from their own shortcomings and the fact that this year again customers on the market for a new generation APM, favored Dynatrace over anyone else. I thought it was time to give you the facts and set the record straight. And unlike our competitor, I welcome comments and different points of view:
Single Agent vs. Multiple
One of the most obvious spins is about which agents are the simplest to deploy. With Dynatrace you only have to install a single native agent on your system, which gives you everything you need: application, process, host and virtualization insights. To my knowledge, AppDynamics, require you to install a second agent to get those host metrics. So – what’s easier?
Overhead & Depth: There are several other good reasons why we decided to go for Native vs. Java as explained by our Chief Software Architect, Christian Schwarzbauer, in Pros and Cons of a Native Java Agent. In short.. Overhead & Depth!
On Going Management & Upgrades: Our bootstrap mechanism makes rollouts as easy as restarting your application. The latest version of the agent will automatically be downloaded to your target system. No manual copying or configuration files on the target system you need to maintain.
As a Service: Secure, Complete & Regional
Dynatrace has been available as a service for quite a while now and many customers are thrilled with it. The reason why it is so successful is because we have the collector architecture allowing companies that need 100% transaction visibility to secure and compressed data transfer into the cloud. We use regional AWS Instances to ensure optimal performance for our global customers. We take care of running the server, the performance warehouse and session storage. You use our Rich Client, HTML Dashboards or REST Interface to get access to all your data.
Visits vs Actions
Understanding your end user is critical – especially when they start complaining. That’s why we capture every visit, all actions and analyze the data based on every single visit. This enables you to find an individual visit calling in to complain about bad user experience including all actions until they experienced the problem. Here is a great blog post from one of our customers: Fixing Real Problems with Real User Monitoring.
Just capturing Actions without the context of the visit doesn’t give you the important context information such as: what did the user do before hitting this problem? Does this problem occur for all visitors only for ones with a certain access pattern?
PurePath vs. SnapShots
PurePath means full End-to-End visibility (from Mobile and Browser to Database) for EVERY (100%) one of your end user’s interaction with your application. We do not sample – nor do we only start recording these PurePaths at the time when we think the PurePath is problematic. It is ALWAYS ON. From experience we know that performance management is not just about slow or failing transactions. Once you solve the low hanging fruit and you get real about APM, check out our technical blogs on common performance and architectural problem patterns.
Always On vs. Sampling: As far as I understand Snapshots they are either taken periodically (several per minute out of millions of transactions) or when transactions have a problem from the time on when the problem was identified by one of the agents involved in the transaction. Happy to be corrected here if this is a wrong assessment on Snapshots:
Business Transactions vs. Entry Point Detection
Business Transactions are not always identifiable on the Entry Point such as URL, Struts or Spring Beans. Single URL Apps where the actual business context is buried deep in the transaction is a good example.
Business Context is not always on the URL: For that reason we built a flexible Business Transaction concept that allows you to define BTs on ANYTHING that we capture along the PurePath. Whether this is the URL, a Parameter, a Struts Action or something buried deep in the transaction such as a method argument of a business API, a Web Service Return value, a log message or exception. The sky is the limit.
One transaction provides more than 1 Business Case: We also believe that a single technical transaction can map to multiple business transactions, e.g: “Trade Currency”, “Trade Type”, “Trades by Premium Partner”, “User Group”… – the following screenshots show how some of our customers use Business Transactions in real life. The business context doesn’t come from the entry point but from method arguments, return values or web service calls:
Rich Client vs. Flash Client
Many of our customers use our Rich Client via the Web Start Technology which means no installation hurdles. We also offer HTML Rendered Dashboards for those that don’t want the Rich Client. Granted – there is more we could do for Web – but – having a Flash-based Web UI is also not as flexible as it may seem. More on Web UI is coming as our customers know.
Collaboration made easy with offline data analysis: Our Rich Clients (which are not licensed) allow our users to share PurePaths with each other and analyze offline. No need to give too many people access to the production system.
Here are some screenshots from dynaTrace showing some of the great analysis capabilities as well as awesome dashboarding:
Alerting vs Alerting
Well – we do not just send Emails and SNMP traps as it is claimed. We have a long list of Incident Actions that allow us to integrate with SMS, PagerDuty, HPOO, CitrixNetScaler, Growl, JIRA, Nagios, SCOM, Execute Commands (scripts), Memory & Thread Dumps, Extract Data, Trigger Web Services. More can be found on our community for free download:
Free Trial vs. Free Trial
Now it’s up to you to decide. The good thing is, all the competing products offer a Free Trial. Here is ours: dynaTrace Free Trial.
May the best choice be with you!