Dynatrace Reviews

We're a health plan, a health insurer. We're not a big one, we have about a million members. We are growing through adding new business and we're looking to expand into the government programs: Medicare, Medicaid. Right now we provide individual and family, large corporate, self-insured, and a couple other types of health plans. 

We are headquartered in Minnesota, outside of Minneapolis. We have a data center in Minnetonka and one in another suburb. We do most of our work on-premise. We don't have much in the cloud for our core backroom applications. We use a package from a company called HealthEdge in Boston, to do our claims processing, membership, enrollment, etc.

Our main use case is application performance monitoring, right at Dynatrace's sweet spot. First, we wanted to know what the performance of our healthcare and our health claims processing system was. Then we wanted to be able to segment it by where the transaction response time is spent. We also wanted to get into the deep dive of the Java profile, because HealthEdge is a Java application that runs on several JVMs. We wanted not only to get into the Java code but to get into the SQL that's created to call into the database, which is where the response-time problems are. 

We're using Dynatrace SaaS now. It's the newest version.

Since we have the OneAgent feature available, we have real-user monitoring. So not only do we know the response time and availability of the synthetic route, but we know what real users experience on our website. If our service desk gets a call, which seldom happens — but let's say you, as a member, had trouble with something — we can go back and find exactly what you did and why the response was poor. We've used that many times to find errors. JavaScript errors caused by a setting in Internet Explorer were the latest ones that were annoying the members. But members don't call our service desk and say, "Hey, your website sucks." So we have to look at the data and say, "Geez, why does Internet Explorer have these huge JavaScript errors?" And then we find out.

We found an error where developers used a Google API that was supposed to find a Medicare workshop by loading a Google Map and help a member find a place where they could go to a Medicare workshop. The API had so many calls an hour and we saw that, usually, about 45 minutes after the hour, that transaction was failing. It turned out that we'd used the 1,000 allocated calls and, when, the hour turned over, it worked again. It integrates all things monitoring, from an application perspective: synthetic, real users, and Java deep-dive.

Dynatrace provides us with a huge benefit for triage because by the time a Dynatrace problem is open, AI has identified all the components and where the response-time issue is or where the failure is. It's really mindless. We don't have to try to pull out a map and figure out how the application looks. 

And Dynatrace has a feature called SmartScape. I don't use it a lot because their AI is so good that I've never had to go dig through it myself. But if I were to go through it, it would go from data centers to hosts to processes to services and applications, to show how they're all linked together. So it has a topology view. We use that sometimes when we're doing performance testing, which is something another part of my team does. They need to know which pieces are involved and this helps them know that. 

But from a day-to-day event-management and IT operations-center perspective, the Dynatrace AI is what has identified the failing component. The dashboard has all the problems. They open up these problems, which are already events in our ServiceNow environment, and these problems have the call-path and everything else laid out in them. So I've never had to dig into the Smartscape to figure out where my failure is. The Dynatrace AI has done that for me.

What we found early on in our HealthRules environment was that the response-time problems were, 99 percent of the time, in the type of SQL that we throw at the database, because the DBAs would say, "It's not the database, it's the bad SQL." Dynatrace helped us focus immediately on that and get away from: "Is it the network? Is it the server? Is this too busy?" There are all the different things that the vendor wants to throw at you. I went up to Boston to help the vendor a year or two ago. I took them right through the code and the response times and said, "Here's the piece of SQL that makes this particular function slow." Dynatrace was able to do that. We got there in minutes. They said, "Well, your server might be too busy, it might be your network," and I could say, "No, it's none of that. Here's the response time of that transaction and here is the decomposition of it. The thing runs for 13 seconds and spends 12 seconds on this one piece of SQL. I think that's where your problem is." Dynatrace was a huge help there.

The solution has decreased our MTTR by well over 50 percent and maybe by as much as 90 percent. It enabled us to identify some things, first of all. Before, it was endless war rooms, and not really an identification. Dynatrace has driven that almost to zero. When the problem is opened, we know the root cause.

As for mean time to repair, since we know what we need to repair, we can point the developer right at it. It has decreased that by 50 to 60 percent.

It has also dramatically improved our uptime. One of the biggest problems we have with the JVMs, of course, is garbage collection and memory saturation. A memory leak will develop and Dynatrace will show the memory increasing steadily. It will create a problem and they'll work on the problem proactively, and either fix it or schedule graceful downtime. If they have to shut down the environment, they can stage through the three different servers in a type of HA arrangement. So without any disruption to the client, we've been able to fix things that would have turned into major outages of the whole environment. It's a definite help on the preventive side.

In terms of time to market, the guys who work on our web portal interface, who are in-house, were early adopters of the technology on our team and learned what works and what doesn't. Dynatrace has significantly decreased their time to market. They're not really part of the development cycle, but the way they use it and the things they say about it and the reports they've made indicate that it has probably cut nearly 50 percent of the development of their portal code.

It has also helped us with consolidation of tools. We got rid of some New Relic and we got rid of some older tool which was a great, early innovator in this space, but it was acquired by CA or Microsoft. We were still paying licenses for that and were able to consolidate it. We were about to buy a network tool to help us with ACI conversion on our network side, a tool that would mainly tell us who an application is talking to on the and network. We use Dynatrace to do that, so we saved tens of thousands of dollars in not acquiring that tool. We also took the synthetic work that we paid an outsourced company to do for us and we converted all of that. Once we had Dynatrace in the house, we could do it ourselves and that saved $20,000 to $30,000 a year. There's probably more, if I were to look at it, that I could do with Dynatrace. I have to focus on the core system right now, but I think they'll get it in the SNMP monitoring space soon, if they're not already there. And the plugins on the ActiveGates have a lot of capabilities we could use. We already monitor our VMware environment with it now.

We've started to use the Apdex score in all of our communications. It's a standard metric that's used for websites to indicate how they're performing. That idea is baked into Dynatrace and we've built on that throughout our company. The weekly service quality reports that are produced and sent via email to all Dynatrace users are starting to get some notice. They show, from the web portal side, what the Apdex is. Is it acceptable, tolerating, or unacceptable? It shows the percentages of the time of use and where they're coming from. It also shows it geographically and what type of browser most of your users are using. It shows how much of it is mobile versus desktop, which has proved very valuable to our digital experience people. Things like that are a huge benefit, and those are things I didn't even know existed when I bought it.

In addition to just the monitoring of the HealthRules ecosystem — which is typical BusinessWorks, Oracle Databases, and JVMs for transactions — we do a lot of web monitoring. With Dynatrace, we have synthetic checks and real-user monitoring of all of our websites, places where members and providers can interact with us over the web. We monitor the response times of those with Dynatrace, and it's all integrated into one place. We actively synthetically monitor our websites from two or three geographic locations. Our business is in nine States, so we're not international by any means. We sell health insurance to members in Oklahoma, Kansas, North and South Dakota, Wisconsin, Minnesota. We monitor those synthetically.

It also instruments .NET, and BusinessWorks out-of-the-box.

It has an integration with ServiceNow, which is great. Dynatrace creates tickets for things and its AI finds root cause. We have integrated that with our ServiceNow to generate events and incidents, so that all of our event management will be done in the ServiceNow Developer. We're working on that now. In terms of the self-healing aspect, we don't use Dynatrace to do that, although we could. We've gone down the path of trying to use ServiceNow's Orchestration. But we may come back to Dynatrace for that, depending on how that works.

In addition to ServiceNow, there is a CMDB integration, so when a Dynatrace problem is discovered, the Dynatrace ID correlates to a CMDB and that's how we open an incident or event. We don't need to do the correlation. If an event turns into an incident, then the correlation is done automatically with the Dynatrace ServiceNow application, which is in the ServiceNow store. It syncs up the CMDB's entries, the CIs, with the Dynatrace IDs so that all of the different pieces of the response-time puzzle that Dynatrace has, can be assigned to a CI in our CMDB. We are actively working on improving our discovery in CMDB, as it's not the most robust. Dynatrace is a huge help there because the OneAgent discovers all these things for us. So it helps with ServiceNow discovery as well.

The Dynatrace panel generally lets you know how many users it affects, and how many transactions or events in that application it affects. We don't use that a lot. That's beyond our capability right now, but I don't see any reason why it wouldn't be quite useful to assign severity from that.

Around the way licensing works, I would like to put it everywhere in infrastructure-only mode and I want it to be reasonable to do that.

From a technological standpoint, there is the OneAgent versus plugins they have. They called them security gateways when they first came out. They're the way that the OneAgents talk to local active gates, which communicate out to the Dynatrace cloud to store all the performance data. Instead of every agent going out to the cloud, there's just one spot and security likes that. But they've leveraged those security gateways and renamed them ActiveGates, and now there are different web plugins we can run on it. Sometimes the plugins are designed for things where you put in an agent, Like an Oracle instance of Exadata, or an Oracle appliance. We can't put a OneAgent on that. It's not a standard Linux or Windows OS, so the ActiveGate solution is better there. Sometimes the development of those seems to be running very fast and it's not complete. They don't yet function quite as easily as the OneAgents do. But I have hopes that that's going to get better. We have tried the MQ, the Citrix, and the Oracle ActiveGate plugins. They could be sharper. It's the right direction to go. It just seems like it could be smoother.

I have been using Dynatrace for close to three years in my current company, and before that I used the earlier versions of Dynatrace, DC RUM, at a previous job.

I had one problem early on with WebLogic where Dynatrace was not stable and it would actually affect the ability of one of the WebLogic components. It was instrumented because we thought we needed it to be, but it didn't need to be. When we decided not to instrument it the problem went away. 

But that's the only stability issue I've ever had with it. That was the only time it's caused an outage or been responsible for high resource consumption. Typically the OneAgent is well under 1 percent CPU utilization and takes very little memory.

It's used constantly by several teams. They use the Dynatrace mobile app on their phones to get notified of problems in the environment before ServiceNow even notifies them. Our platform services team, which is the team responsible for the HealthEdge environment — if we were a bank, it would be all the backroom functions. It is where you pay claims, enroll members, credential providers and maintain all that stuff. That support team has it on their phones. Our portal team also has the mobile app, so it's used constantly. I hear about it when it's not available, or if there's something odd going on with the mobile app.

It could handle a much larger environment. I add ActiveGates mainly for redundancy. I don't think I need as many as I have. I could scale it out very large. I don't see any limitations. I've never had a problem with that other than my checkbook.

We've tried scaling it to cloud-native environments a little bit. We have a few things that are off-premises, like Microsoft Dynamics and Salesforce, which are in the cloud. We have a cloud-based application that does provider credentialing, as well. We don't have anything that we own in the cloud, so we can't instrument AWS or anything like that with it.

Tech support has generally been pretty good. We get good response. They have a thing called Dynatrace ONE and I find the tech support to be best if I engage it through a chat window on Dynatrace. There's a place, right in the tool, where you can get a hold of a Dynatrace ONE person and they'll look at your problem right away. That seems to work better than the old model of calling support or sending an email, because you would go back and forth. "Send me more doc. What about this? Send me that." The Dynatrace ONE agent gathers everything he needs and, once he has all that, if he doesn't know what the problem is, at something like a level-one triage, he'll open the incident for you and it's done. I like that part. The traditional send-them-an-email, open-a-ticket-online takes too long. The Dynatrace ONE agent available through chat is a great concept. I encourage my team to use that rather than opening a problem. And that's included in the standard licensing.

For our deployment, we did the first 40 in less than an hour. That required a part of one guy, and he maintains it all now. We have close to 200 nodes with OneAgent on them and four ActiveGates, synthetic monitoring, and plugins for MQ and Citrix, among other things. That takes three-fourths of a person on my team. I've federated the support for a lot of the stuff on our portal side. Our portal team developers fell in love with it so much that I just let them run with it and install it as needed. I give them more and more administrative rights. If you add their time, it works out to the equivalent of about a person.

We have close to 100 users. Some of them are just management who use the reports. Some of them are the portal team who are administrators, just like my team, and the majority are in IT. We're starting to take it out to our sales organization, as they're interested in the response time and other things.

We see ROI in performance tuning — improving application performance — big-time. We have teams using it constantly to make our digital experience better, performance-wise and availability-wise. Another part of my group is load testing. They use it as they do their load tests. They use LoadRunner to build a load test and use Dynatrace to monitor after every new release of the HealthRules code to tell them what's better and what's not. There is a huge ROI on load testing and performance testing.

There is also incident response, preventative incident response. We even had the CIO come into my boss's office one day and he was able to say that Dynatrace saw a problem and it was fixed and we didn't have an outage. And he looked at him and said, "That's how it's supposed to work, right?" What the CIO had been promised for 10 years, he finally actually saw an instance of it "in the wild" where we preemptively discovered a problem and fixed it. That's a huge win.

Also, reporting and analytics — to know what the response time is, and how many users use it, just the simple things — are huge.

I'm not sure how to estimate how much Dynatrace has saved us overall. But it's had to have saved us on the order of millions.

We license it for two environments, typically all of production and all of one lower environment, usually our staging environment. If there is a downside to Dynatrace, the only thing I can think of would be the cost. If it were cheaper, I'd have it in all my environments. I don't think they're charging more than it's worth, by any means. It's just that good software costs money.

They have the OneAgent which you buy and install. You can run that in infrastructure-only mode and pay less. The cost is a bit funny, it's calculated based on the memory size of the server you put it on. Sixteen gigabytes of memory, for instance, is one host unit and a host unit costs you, say, $1,000. (I don't recall what the actual cost is, I'd have to look at our contract). There's a switch they've added for infrastructure-only mode, which will cut that cost to about one-sixth or one-seventh of the cost of a full host agent. You won't get the deep-dive response time metrics, but you'll get the infrastructure stuff, which sometimes is all you want.

In addition to the host agent fee, which was the first thing I bought, based on the memory size of the server, the other is in metrics that we collect through the ActiveGate plugins. They charge you per metric.

So the three principle things they charge you for are OneAgent, how many metrics you collect through the ActiveGate, and digital experience monitoring units, or DEM units. Those are basically the cost of the synthetic things, per test. Those things are quite reasonable in cost. The biggest cost is the OneAgent.

The cost to get us up, my first allocation, was under $100,000. My first PO was for about $60,000 and it covered almost our whole production HealthRules environment. We started out with 40 host units and we've grown to 200-plus, and we're a small place. Down the street is a health-related business and I think they have 20,000 host units.

We started by looking at industry reviews and selected the top four or five up in the upper-right quadrant: Dynatrace, AppDynamics, New Relic, and we had a brief look at what at that time was a CA product, or it might've been BMC.

We evaluated the four of them on paper and then brought two in for a trial, a proof of concept: Dynatrace and AppDynamics. Ultimately we selected Dynatrace.

There were several advantages to Dynatrace. Dynatrace was new. Its presence in the cloud was nice, but I could also run it on-prem if I wanted to and, at the time I didn't know which way I was going to go — which way I'd be allowed to go by security. AppDynamics was cloud-only at the time.

For installation, Dynatrace was trivial compared to AppDynamics. AppDynamics had an engineer onsite for two or three weeks and they still couldn't meet all of our use cases, which were pretty simple. I did them first. Then I went to Dynatrace and they said, "Well, download it, install it, and call us If you have any questions." And I thought, "Well, geez, don't I get any hand holding or anything?" It turned out that it was because I didn't need it. It was that simple. You download it, install it, and it injects itself. You can control it. It was just engineered for ease of use, by far. So the installation was night-and-day different. 

We have a lot of TIBCO BusinessWorks code around that that we wanted to instrument, and with AppDynamics we had to go into every business process and change the startup. We had hundreds of them and that was a real pain. We had to select which ones and do the work, whereas with Dynatrace, it would discover. Dynatrace has a concept called OneAgent, which you install on the server and it discovers things that you can monitor. You just click on them and say, "I want these monitored," or "Don't monitor these." It takes care of all that work and that was a huge difference. I didn't need a huge staff to maintain it. I didn't need a lot of time from the support teams — because they don't have it — to help me with monitoring. We were able to do the monitoring ourselves.

Then, once it was up and running, the use cases were pretty simple. One was to create a business-level dashboard of response time, and I don't think AppDynamics ever got that out for me. 

Dynatrace is easy to use from that perspective. It's easy to install and maintain. I have a small team and one person is my Dynatrace SME, but he does other things as well, so it's not even a full-time job.

I've been doing this for close to 30 years. I've worked for software vendors and I've worked for major companies and now I'm at this small healthcare organization. The "holy grail" has always been the ability to decompose response time and Dynatrace has done that and integrated all of my APM needs in one tool. That is the biggest benefit to me. I can do application performance, from web to Java deep-dive, in one place. That's probably why it costs so much.

If you're thinking about Dynatrace, consider how easy it is to install and maintain. It has broad coverage and it's easy to use. I don't know how the rest of the market even competes anymore; it must be on cost.

As an APM tool, I'd probably rate it at nine out of ten. There are a few rough edges, but I think that's mainly because they're trying to do the right thing too fast.

It's used in two major use cases:

1. Monitoring and our own internal IT operations. 
2. We provide our customers access to Dynatrace tenants so customers can also leverage developing their code running on our platform.

It does full stack monitoring for internal operations, problem diagnostics, APM use cases, and performance management for our customers.

We have multiple instances of Dynatrace running, where about half of them are running in our data centers and the other half are running in the public cloud. Therefore, it's a hybrid deployment. We use a mixture of cloud providers, including AWS, Microsoft Azure (running Kubernetes), and Google Cloud Platform.

We have traditional deployments on VMware virtual machines as well as running stuff in the cloud. We have a couple hundred Kubernetes clusters monitoring using Dynatrace. Dynatrace's functionality in this area is unmatched combined with its full stack visibility, ease of deployment, and completely dynamic changes. The container environments are also dynamic since you have microservices spinning up and down as you go. I have never seen another tool doing this with the same reliability. 

Dynatrace has improved our organization through operational support. We also have a large services organization which directly works with customers, and sometimes you run into situations where customers ask how they can improve their applications. Traditionally, these service teams would go for assessments. Eventually, they would even go onsite and through performance workshops with them to find some low hanging fruits that could address, and this was very tedious work. By introducing Dynatrace, you suddenly have real-time data. Then, the process of doing performance reviews switches from workshops or a defined time frame analysis (and then taking actions) to a more continuous approach where you constantly have Dynatrace performance data of the landscape. 

Service engineers save a lot of time because they can just go in look at the data and share it with the customer, who has the same view, and say, "Here's an improvement which can be immediately implemented." It's not like a collection of big, multiple findings that are consolidated into one results presentation, then the customer needs to do something. It's more like a continuous performance analysis and improvement process, which is more efficient than those workshops approaches. That's one of the biggest of the advantages that our services team sees because it helps DevOps to focus on continuous delivery and shift quality issues to pre-production.

Dynatrace is tightly integrated with ITSM. It's integrated with ServiceNow, which our support team is using.

We provide a platform, then the customer ships the code and deploys it. Therefore, we rely on testing by the customer, and sometimes, they miss something and it breaks. Then, it doesn't work as expected so we have to step in, and say, "Yes, your site is down," or "It's not functioning properly." We do the analysis because typically the customer says, "Okay, it's not us. It must be you as the service provider." This is where we gain a lot of efficiency. The support team is the first line of defense there. They get the information to determine if they are able to quickly pinpoint the problem. E.g., the customer deployed, then two hours later, issues were occurring. This is when you don't want to waste time. Our support engineers need the visibility so they can immediately be able to communicate to the customer, saying, "Yes, it's on our side," or "It's on your side." If it's on the customer's side, they can let them know exactly where they need to go. This is where we gain most of the time.

It helps our operations that the solution uses a single agent for automated deployment and discovery. If you think about all the work in the past where we had different agents, tools, or scripts deployed to monitor specific aspects of an environment and different tools, then having one agent definitely helps. For example, for our rollout, when we migrated all the different tools to Dynatrace, we did this over the weekend. We installed the agent, then just watched the data and findings coming in, which was a huge benefit. We installed one thing an it discovers everything.

I suppose the solution has decreased time to market for our individual customers with new innovations/capabilities. Dynatrace helps them gain better insights, allowing them to do another deployment faster.

It has auto detection of almost everything. The full stack capabilities to get one agent deployed allows you not to worry about anything else because the agent detects everything. This is in combination with the AI so you don't need to worry about any baselines or setting up any thresholds. This is all done automatically, which brings us the biggest benefit.

Configuration as code integrating through APIs is really important when automating at scale. If you think about the tens of thousands of hosts that you deploy to, then APIs are key when automating deployments, the management of those instances, and configuration as well as integrating with other systems without sophisticated or far reaching APIs. 

Dynatrace easily integrates with our infrastructure or applications, then reliably triggers self-healing actions or remediation actions. This is something that we really love to use because it definitely removes a lot of human interaction. You just let the machine to do the job and can trust it, and that's the most important. I have seen systems where the users were very reluctant to trust the system to take actions where typically a human would do the job manually. Dynatrace considers all the information that it gathers, then triggers self-healing actions which are quite reliable. It doesn't need a lot of human adjustment to make it work.

We use real-user monitoring a lot to get insight into end users and our customers, e.g., customer behavior. 

While the integrations are great, sometimes our customers are not as far as long in Dynatrace concepts from a technical perspective as they need to be, whether it's a cultural thing and educational thing. Thus, some of our customers are not as advanced as Dynatrace would like them to be. From a technical perspective, all the capabilities are there but the concepts are not yet spread out within the ecosystem to their fullest extent. Therefore, Dynatrace is ahead of its time.

Documentation could be improved. E.g., you don't know how to properly use Dynatrace because documentation is almost lacking behind the features being deployed.

On very large deployment scenarios, the APIs for configuration and configuration management came in slowly. This is something that is good already but could be better.

In the product, I am missing some configuration automation APIs.

The company has been using Dynatrace on different occasions for the past eight years. The current product of Dynatrace has only been out for four years.

We operate services for our customers with pretty high SLAs. We guarantee the systems we run are reliable. We also guarantee uptime. In the past three years, we have run up to 50 updates with Dynatrace and had only one or two issues where the system had to be brought down. There are almost no issues at all with stability. It is rock-solid.

They are improving constantly with every release and adding new stuff. We have updates about every two weeks.

We have about 2,500 people using it.

We currently manage seven Dynatrace clusters with several thousand Dynatrace tenants, then in total almost 30,000 hosts are monitored with Dynatrace. We're not reaching the limits of Dynatrace's scalability. This is probably one of the largest deployments, but we have not seen any limitations so far.

We want to leverage even more services:

• Real-user monitoring
• Possibly look into session replay.
• Expand the footprint of synthetic monitoring.
• Build more integrations by leveraging all the data Dynatrace captures for custom metrics into our BI reporting, billing systems, internal cross charging functionality, and scaling/optimizing our environments in terms of resource usage. 

There is a lot of data in Dynatrace at the moment that we do not fully utilize.

The technical support is great. We have a pretty good contract with Dynatrace for contacting support. They are pretty responsive and very knowledgeable. You get a DevOps engineer from Dynatrace jumping on immediately with very high expertise. You don't get the typical Level 1 automated standard reply: "Yes, we will take care of it," but then you have to ping back.

We came from a former product of Dynatrace, which was called AppMon, and not really sold anymore. Though, there are customers who still use it out there. We used it for the traditional APM scenario, then migrated to Dynatrace to extend the visibility for hybrid cloud deployment.

We had been using a mixture of Opsview, Splunk, SolarWinds, and other tools. We switched because of the complexity of managing all these tools. It became unmaintainable. E.g., historically, people would write scripts for Nagios Opsview, then maintain them. If we lost the people who had been maintaining those scripts, then nobody knew how the checks worked for those custom scripts. Also, the maintenance overhead was pretty high.

From the perspective of the end users using different monitoring solutions, you had different teams who had to go to different tools and contend with data in one tool not being exactly the same data as another tool. While the overlap between tools was there, the complexity in accessing those tools and knowing how to use those tools became a big organizational and maintenance overhead that we decided to pull them all into one tool to harmonize it. We wanted one tool where the interface and data are the same regardless of whatever you're monitoring.

The initial setup was straightforward. We looked into Dynatrace and were able to roll it out to 12,000 hosts within four weeks. 

From the Managed version, you can have it installed and up and running in less than an hour. This is on the condition that you have the hardware to install it on and access to the systems/services that you want to monitor.

Initially, some people were skeptical about the one agent really working, so we did test it. Now, we have had so many good experiences that when we deploy, build new services, or spin up new instances, Dynatrace is one of the first things that is always there. We don't even even test the agents anymore. We completely rely on this mature product that is solid and stable when we deploy staging, development, QA environments, or playgrounds. There is no deployment without Dynatrace agents.

We deployed Dynatrace ourselves as we have a lot experience working with it. Deploying Dynatrace depends on the environments that you run it on. Since that was all orchestrated with things like Puppet, Chef and Ansible for us, it just was a matter writing a bit of automation code that it wasn't already in place. One person was needed to do this properly, and it is not that hard of work because it applies to almost every environment that we deploy. For new services that we provide, it's done within the development teams writing those services. Therefore, there is no dedicated Dynatrace team responsible for integrating Dynatrace with services.

There is almost an API for everything. If you run it Managed, this means you have to administer Dynatrace's installation yourself. You run it and take care of some prerequisites, like sizing. Any system updates, back fixes, or upgrades to the whole cluster have almost zero maintenance. All you need to do is confirm it or let Dynatrace update itself. In the past three years, we had almost 50 updates or installations where we didn't even need to touch anything. We just had one or two occasions where an update broke functionality, and those were fixed with next update and within hours. It's almost self-maintaining.

We do have a dedicated staff for maintenance, but this team is not spending a lot of time on actually managing Dynatrace. They do the integrations of Dynatrace and other tools as well as development of custom integrations and configurations. This team is also responsible for the infrastructure and ensuring the machines Dynatrace runs on are scaled or adjusted properly. However, this is minor effort for them. We have a dedicated team of 20 to 30 SRE engineers and their responsibility is not only to Dynatrace. They are responsible for the whole infrastructure and surrounding tools.

As we use it internally, our internal operations have gained a lot more efficiency. The time to resolution and triage problems in different environments has been reduced by 50 percent, if not more. When Dynatrace raises a problem, the team does not need to bring together experts from other teams to look at the problem, log files, etc. You almost have Dynatrace training our support engineers because it's so easy to pinpoint the root cause of problems.

The solution has decreased our mean time to identification by approximately 50 percent.

There has been a positive impact on the instances run for our customers. Overall, uptime got better because we became faster at fixing the problems causing downtime.

The solution has saved us money through the consolidation of tools. With a hybrid landscape, we had multiple tools. When we consolidated, we removed four or five other monitoring tools with one. For the last ROI calculation that I did, Dynatrace was saving us up to $500,000 per year. 

In addition, our speed is up 40 to 50 percent. Therefore, our human cost and licensing savings together are one to two million.

We are a very big customer. We obviously have a special price point. 

If there are no corporate requirements to run Dynatrace Managed (operating it yourself), I would definitely go for the size option. For small and medium-sized companies, the size option is probably the cheapest one. You don't need to look into operating it. You don't need to run hardware. It is pay as you go. 

We looked into what can Dynatrace could actually replace. If the price point is high, think about the impact it would have to the entire organization to constantly replace monitoring tools. If implemented correctly, then it has a lot of saving potentials for the organization. That is something that should go into any ROI calculation.

We looked at the other big player in this space: New Relic and AppDynamics. Looking at the cloud, full stack capabilities, ease of deployment, and scalability that Dynatrace has, they definitely stood out in comparison. The full stack story was pretty compelling, where you have one agent deployed and it provides everything.

Trust what it's doing. Don't question what it's doing. If you don't understand it yet, take the time to try to understand it. Do not implement or force the old ways of monitoring onto a completely different approach, like Dynatrace. That's definitely that the biggest lesson a lot of people in our organization had to go through. 

Be curious and embrace the different approach. It is definitely worth it. The different approach that it does is a good one. It's different but it's something that actually works. Those guys know what they have built and what they are doing.

It is partly integrated with CI/CD. We are operating a platform with our applications, but our customers are responsible for testing and CI/CD deployed into our environments. Internally, some of our teams use it. The majority of our CI/CD deployment is our customers' responsibility, and while we do provide them Dynatrace for CI/CD, we do not control how they integrate it.

We are in the process of rolling out synthetic monitoring at scale to replace other tools. 

We are not yet using session replay, which is mostly due to data compliance restrictions. We have very hard data privacy protections. We do have customers who are highly interested in using the feature, but we are not using it at the moment.

Overall, I would give the solution a clear 10 (out of 10).

My use case for Dynatrace is monitoring, including server monitoring. I use the tool to analyze what's wrong with the server, detect high memory utilization and any IO network problem, and monitor network traffic.

I use Dynatrace to find errors and the root causes of the errors, including information on which carrier is giving slow response times.

Dynatrace has multiple features that I need, but I love that you can analyze traffic, including any bottlenecks. I also find the tool user-friendly and has an easy-to-navigate interface.

Dynatrace is also easy to integrate with other tools.

For a new user of Dynatrace, the tool is not easy to understand, so this is an area for improvement. Initially, you'll need an expert to advise you on monitoring and analyzing data. Before using Dynatrace, you need to learn from an expert.

I've been using Dynatrace for three years.

Dynatrace is a stable tool.

Dynatrace is a scalable tool. In terms of scalability, it's an eight out of ten.

I consulted the Dynatrace technical support team one year ago and had a pleasant experience with the team. I'm rating the support a ten out of ten. It was excellent.

Positive

My company went with Dynatrace because it's a very popular tool in the market for server monitoring. Most of the companies where I'm based use it.

The initial setup for Dynatrace was easy, though it was the client who installed it, and I only accessed the URL. Deploying the tool took two to three hours.

I have no information on the cost of Dynatrace.

At the moment, I'm using Dynatrace.

More than fifty people use the tool within the company.

I'd tell anyone planning to use Dynatrace for the first time to review the tutorials and check how to analyze data on the tool.

I'm giving Dynatrace a score of eight out of ten because it's not easy to understand the tool entirely if you're a first-time user.

I'm a Dynatrace customer.

We use Dynatrace for a number of internal applications that we track in addition to API calls associated with the API engine. We have a partnership with Dynatrace and I'm a project manager.

We monitor critical internal applications including some public-facing applications. Internal transactions are being tracked and we get immediate feedback from the solution's monitoring which makes a big difference to us.

The value of this solution is in terms of the functionality, and every aspect of the hardware and connection-oriented signals that we get. We use most of the features on a daily basis.

Network monitoring doesn't seem to be a key focus of the company and if that were improved this could be a one-stop solution that would monitor the application. It would be quite useful in the data center environment as well.

I've been using this solution for four years. 

The solution is stable.

The solution is scalable, we have around 50 users. 

I am unaware of licensing costs. 

It's a wonderful product and I would definitely recommend it. I rate this solution eight out of 10. 

It tells me everything I need to know. It tells me what the transactions are. The AI provides you with advancements or degradations in what is happening. 

It gives me visibility into everything, from transactional logs to services and processes to the OneAgent installed on the box, which tells me it's talking to systems that are in development and it shouldn't be.

The most important takeaway is simply the compute. Simply understanding how much, or, the resource adoption across the board. Back in the day, for example, I would need 128 gigs of RAM to run SQL. You don't need that any longer. Having the performance and true metrics of what's going on, as well as scaling your environment to its optimal performance.

Dynatrace works perfectly.

Having OneAgent is the most valuable feature of Dyantrace, as well as the monitoring.

What is web interaction as it relates to Synergy, or when it comes to using web-based, phone-based, or apps published on end-user devices, it's fantastic in terms of performance, and code. Even if you run the release and discover that the update you just released is causing a degradation in performance, auto-release will restore the old code without missing a beat.

I believe that something related to IoT devices should be improved.

I have been using Dynatrace since 2018. It's been four and a half years.

We are using both a SaaS and an on-premises version.

It is both on-premises and hybrid.

They are hosted by Google, Microsoft Azure, as well as AWS.

Dynatrace is a stable solution. It's rock solid. We have never had an issue.

Dynatrace is scalable. I would rate it a nine out of ten.

We have an application, management, and support teams looking into things. We have our help desk and service desk looking at various dashboards. Certain dashboards are being examined by our developers. It is frequently used by between 60 and 80 people.

I believe we are currently using all of the functions and features. It's operational, it's production, it's living and breathing.

I would rate the technical support a four out of five.

Positive

We were looking at Dynatrace at the time, and then there was AppDynamics or something like that, I believe, which Cisco eventually purchased. Dynatrace's maturity level at the time far outstripped that of anything else on the market.

In 2018 it was a superior product.

The initial setup is straightforward. I'll be up and monitoring in four hours. The on-premises installation was a little more difficult due to network firewalls and so on. Overall, it went well.

This solution can be deployed and maintained by four people.

For us, the most important thing was to get OneAgent out everywhere. Once we had the OneAgent in place, we began building out, and understanding what applications are present, and start developing the monitoring aspects. Not just from conventional RAM CPU calculations, but truly looking at the applications, and examining the Java functions, as well as the MongoDB functions.

Having all of that information and being able to create dashboards to communicate it not only to the higher-ups but also to the developers doing the development, who must understand that they must be very smart with their code.

We are a consulting company. Within our organization, we have a Dynatrace division. However, for this installation, in particular, we collaborated with Dynatrace on product implementation.

We saw a return on investment. The downtime has been reduced, which is significant in and of itself.

I would rate the return on investment a five out of five.

I am not aware of the licensing fees.

We evaluated AppDynamics.

I would recommend following the instructions. It's easy to understand.

Nothing is very perfect. I would rate Dynatrace a nine out of ten.

We are using the solution in the operations space.

Our primary use case is production monitoring of complex business critical systems. Another use case would be performance testing of critical releases.

The solution uses a single agent for automated deployment and discovery, which helps our operations. It reduces the cost of ownership of managing Dynatrace as a tool set, ensuring that we're able to maximize the value from Dynatrace and monitoring is available. That's a big plus.

An example of how it helps is we are more proactive than we were previously, though we're not quite where we want to be. Engineers are talking more with the operations people, which is closing the loop. Our teams are becoming more customer centric.

The platform is very good at identifying potential issues, but each problem that surfaces in most cases still needs to be qualified and quantified by somebody who understands the system. Complex application problems, not infrastructure, surfaced by Dynatrace still need to be reviewed by somebody who understands the application logic or system architecture. For somebody who understands the platform though, issues can resolved in minutes as opposed to hours.

We have the ability to detect user action response time slow downs and their consequences, along with the back-end calls to third-parties. We are heavily dependent, for a number of products, on back-end service calls to other suppliers. Using Dynatrace, we are able to measure the performance of those third-parties. 

We are also using Dynatrace to right-size the infrastructure, especially on private cloud where we have to provision the resources upfront to save costs. Dynatrace helps us by finding how many resource we are utilizing and identifies how many resources we need to maintain for the level of performance and scalability that's required. This has helped us right-size in about 50 percent of our cases, leading to a reduction in cloud resources by 50 percent.

The solution helps DevOps to focus on continuous delivery and shift quality issues to pre-production. This helps with performance testing because our performance test teams are more aware of how product features are performing, which helps to prioritize our testing. It creates test cases so we're able to do more testing. Because Dynatrace helps us define the cause more quickly, this speeds up the time between test cycles.

The end-to-end trace is valuable for us to be able to assign responsibility to the right resolver group very quickly.

The user experience allows us to be able to gauge customer experience and understand the performance impact of our platform.

It has a very nice interface with an easy way to visualize the data that we need, making it quickly accessible. It is very easy to use.

As a platform consolidating tool, it covers 90 percent of the needs for most applications. In that respect, it presents a very high value for us.

We have used synthetic monitoring functionalities to poll. Mostly, it's around service availability and key functionality of a website from different geographic locations. 

The real-user monitoring is mostly used to gauge the difference in performance for multitenant applications, This is so we can discern if there are any local network or client-facing issues when we do a comparison between each customer. It is quite important for us to be able to identify a client-side issue, as opposed to a feature managed problem, because we're essentially providing managed services of business applications.

Dashboarding and having different templates available for more business reporting, or even other metrics, would be useful.

With Dynatrace, we use one tool where we would have used many, but we still have had gaps.

Three years.

It has very high availability.

When we started, we were measuring uptime in a different way, and then Dynatrace started measuring uptime based on services, as opposed to infrastructure. Initially, because we started using different metrics for availability, it showed us that we weren't available as much as we thought we were. This helped us to have better conversations with customers and improved availability from the customer perspective over time. 

We have 115 users, which includes Level 2 and 3 supports, service design, product management, cloud infrastructure management, software developers, software testers, and product architects.

We are only in an early phase at the moment regarding the use of Dynatrace. Currently, we are only using it on two critical platforms. Going forward, we're looking to expand to nine critical platforms.

Our adoption rate across the portfolio is low because we're still in a pilot phase trying to build out our business cases.

The technical support is excellent and very fast. Not only do I get a quick response, but they're also able to close the request off very quickly and satisfactorily with a fix.

Some of the feedback I get from our team, who are familiar with other tools: "Compared with other tools, Dynatrace support is excellent." 

The feedback that I get from people is that the initial setup was very straightforward and easy. It was amazing what information we got in such little time after deploying the agent.

In most cases, the deployment is quick. It takes a couple of hours.

For high-risk applications, which are business critical or high complexity, we would deploy Dynatrace. For medium-risk applications, we would consider using Dynatrace. It comes down to cost qualification for medium-risk applications.

The solution has decreased our mean time to identification. It has saved us from 10 minutes to a couple of hours.

Consider volume because that is where you will get the most benefit. Doing a point solution is not cost-effective.

There are additional Professional Services costs which ensure the solution is configured with meaningful names so you're getting the most money for your investment.

It is the easiest platform to manage in comparison to the competition, like Elastic Stack, New Relic, AppDynamic, Nagios, or Prometheus.

Without a doubt, I'd recommend Dynatrace for business critical applications and anything that's driving revenue.

Biggest lesson learnt: To recognize the most value from the information that Dynatrace provides, you need to make it available to everybody in the DevOps group. There is a wealth of data which can be exposed, manipulated, and consumed by other systems, not just what's visible in Dynatrace. This can also be used for inputs into other upstream platforms.  

Understand the demands within your environment and plan a pipeline, then discuss with Dynatrace. 

We're aware that there are use cases for notifications that can be used for triggering self-healing or autoscaling, but we are not using those yet.

I would rate this solution as a nine (out of 10).

We have several uses for Dynatrace. Most of the time, we use Dynatrace for looking into potential site problems, investigating reported issues, and trying to replicate those problems in a test environment using the information provided by Dynatrace. 

We use Dynatrace for performance monitoring. Quarterly, we will specifically see if there's anything that we can optimize on the front-end of our website, so that's what you see and interact with on the web page. 

We also use it to get ahead of any potential problems in our stack. E.g., if Dynatrace is indicating a problem, we will look into it and determine if it's affecting users. Depending on its impact, and usually if it's impacting customers, we can use that information to decide on what we need to work on next to benefit the customer experience.

I use the tool as more of an analyst. I will use Dynatrace to show where systems need to be fixed, etc.

This solution is SaaS. We use Google Cloud Platform, where we just use their compute engines as far as our hosts. We also have a few services that are on-prem. Dynatrace works fine with both of them. 

The solution helps our DevOps to focus on continuous delivery and shift quality issues to pre-production. We recently got a staging environment implemented with Dynatrace. We are mainly using it for load testing at the moment. Dynatrace has been detecting failures, letting us know immediately what types of failures are occurring so we can catch them before releases. Our developers have been able to identify bottlenecks and other types of problems that they would not have been able to before by just using standard logging and analytics tools.

The solution give us 360-degree visibility of the user experience across channels, which is a great benefit. We're in eCommerce as a retailer. We are selling across multiple channels and platforms. We have a mobile app and a website. We even have other services which we may instrument with Dynatrace in the future. As far as our website and mobile app that we have instrumented with Dynatrace, it has all been very positive. 

The solution has decreased our time to market with new innovations/capabilities because we have been able to quickly identify areas that we can improve for new features and gather that data from Dynatrace. Then, we have been able to verify that our new features and releases are working as expected.

The User Sessions Query language has definitely been the most helpful with its key user actions and user session properties. Using those together, that has completely transformed how we're able to identify customers and their problems on our site. It has made a very big impact over the year.

Using synthetic monitors, we monitor our websites. We have two main domains. There are several plain HTTP monitors, then there are actual browser based monitors that emulate browser behavior. We use both of those types. We have several mobile browsers emulated under synthetic monitors that we use. Those ping our website every 15 minutes. On some of these synthetic monitors, we use multiple data centers to get an idea of geographic availability. We also monitor some of our third-party providers using our synthetic monitors. We monitor our customer support live chat server, which is hosted by a third-party, where we are given alerts if that system were to go down. We are also monitoring an email capture API that's a part of our website.

With user session queries, the main thing that we use that for (and the most valuable), is when we get a problem. If we get some type of a report, obscure problem, or Dynatrace reports a problem, we go straight to using the User Sessions Query Language to find sessions with Session Replay, then we replay those sessions to figure out exactly what the customer did and what conditions may have caused the problem to gauge the impact of the problem itself.

We also save user sessions queries into dashboards, then create different dashboards based on different projects to try and gather data. E.g., last year, we redid a part of our website and used Dynatrace sessions queries and Session Replays to verify that our customers were not having any problems or being confused by their experience. We wanted to verify that, which is one way that we've used the User Sessions Query Language along with the dashboards. We've also created some other dashboards that return custom metrics for us, which goes along, in some cases, with user session properties and user action properties. In that way, we're able to get a very granular look at certain statistics where it would be more difficult to get those numbers from our traditional analytics suite. 

The solution’s ability to assess the severity of anomalies based on the actual impact to users and business KPIs is a bit off. I have found that even though Dynatrace detects a problem and gives you a count and estimate of impacted users, this number is usually much higher than is actually the case and not fully accurate. E.g., I recently noticed an error. Every time someone would experience this error, Dynatrace would create a new problem and it would say, "Several hundred people were impacted." However, using Dynatrace's own tools (user Session Replay), then going back and actually tracing through these requests, we found much fewer people were actually impacted. In some sessions that Dynatrace said were impacted, when you view the Session Replay videos, you could see that the customer was not impacted in any meaningful way.

The solution’s ability to visualize, understand our infrastructure, and to do triage is helpful. I wish that you could do user session queries with those host level metrics and be able to create custom graphs the same way you could with user session data. They're both part of Dynatrace, but they don't feel like they're integrated together well. E.g., we're having an issue that has to do with just HTTP codes and we would like to marry that up with a user session query turning that into a dashboard. We can't currently do that because the User Sessions Query Language does not have access to the HTTP errors or HTTP status code data that is part of the hosts and infrastructure package. Otherwise, if you're just focusing on the infrastructure part it, I think it does a good job.

I have been using Dynatrace since February 2019.

I have noticed a few times where data collection did get interrupted. It was two or three times within the past year. Obviously, it's our monitoring system and we don't want that to go down at all. However, three times for no more than 30 minutes each time is pretty good.

The scalability has been able to meet all of our needs. We have not encountered any limitations when scaling Dynatrace with the Google Cloud Platform.

In the past 365 days, we have two websites that we monitor with Dynatrace, including mobile apps. We've recorded over 23 million sessions for Rack Room Shoes and 8.1 million sessions for Off Broadway Shoes. 

There are three users who are active users of Dynatrace:

1. The user experience architect, who is designing new interactive features and studying customer behavior
2. The product owner, whose focus when using Dynatrace is on the metrics, dashboards, and the user experience as far as using user sessions, queries and Session Replay. They may troubleshoot or look into problems as well.
3. The back-end architect, who looks into certain problems and figures out with Dynatrace where they're coming from. They use information from Dynatrace for writing more detailed support tickets.

I have noticed a few problems with the service before. I reached out to support and the system did appear to resolve itself on its own (after there was a problem). Then, the support staff couldn't see any further issues. The solution’s self-healing functionality works.

We ran into a problem where the Dynatrace JavaScript agent is returning errors, and it's very apparent that there's a problem. However, the customer support will ask us for seemingly unnecessary details instead of looking at our dashboard through their account to see what the problem is. They ask us for a lot of details not really related to solving the problem. As a result, we still have a few issues that were never resolved. They're not major issues, but they're frustrating.

The technical support is below average. They've solved some of the problems that we had, but it took several weeks to resolve almost each problem we had when they probably should have been fixed within a day or two.

There was an initial implementation of AppMon (another Dynatrace offering) before the current Dynatrace SaaS offering.

Dynatrace has definitely made an impact. We were never able to get granular data with any of our other solutions. They were all very disconnected and separate, whereas Dynatrace seems to have good integrations with our entire stack. There haven't been any problems getting additional data now that we have Dynatrace,

It is very easy to use and set up. It did take some customization to get it working for our sites, but after that, it's been pretty easy and straightforward.

The initial setup is complicated, but it's much less complicated than similar systems that I have used in the past. For Dynatrace's setup, maybe there were problems with how our web application was initially developed before I joined Rack Room, because there were a lot of features related to error reporting. It would report errors for things that weren't actual problems, etc. You have to configure it to get around those types of problems, but it's usually fine afterwards.

Over the past year, we've been tweaking Dynatrace. It's been a slow phase-in rollout as far as how much we rely on the data it's giving us back. 

I was involved in the initial implementation.

The solution has decreased our mean time to identification by about three days.

The solution decreased our mean time to repair by around a week.

There has been a huge increase in uptime. It's hard to say by how much for certain because we've made other development practice changes.

It is a great platform. We found a lot of value in setting up user session properties and user action properties, then being able to use them to identify individual problems/customers. We use that to sort of streamline the whole process of finding and fixing problems.

Biggest lesson learnt: Customers do not always behave as expected.

I would rate Dynatrace as an eight (out of 10).

We use it to follow up user experience data. It's all banking applications. For example, when you're viewing your account, you open up your mobile app and the click you do to view your account is measured in Dynatrace. It's stored and we are checking the timing at each moment. 

We are also following up the timing differences between our different releases. When we have a new version release, we are already checking within our test environment to see what the impact of each change is before it goes to production. And we follow that up in production as well.

In addition, we are following up the availability of all our different systems. 

And root cause analysis is also one of the main business cases.

So we have three main use cases:

1. To follow up what's going on in production
2. Proactively reacting to possible problems which could happen
3. Getting insights into all our systems and seeing the correlation between these different systems and improving, in that way, our services to our end users.

We use the on-prem solution, but it's the same as the SaaS solution that they are offering. They have Dynatrace SaaS and Dynatrace Managed, and our is the Managed. Currently we're on version 181, but that changes every month.

The dynamic microservices for Kubernetes is really value-added because there is a lot of monitoring functionality already built into Kubernetes Docker. There are also free things like Prometheus which can display that. That's very good for technical people. For the owner of the pod itself, that's enough. But those things don't provide any business value. If you want business value from it, you need to extract it to a higher level, and that's where you need the correlations. You need to correlate what is between all these different services. What is the flow like between the services? How are they interconnected? And that's where Dynatrace gives added value. And the fact is that you can combine these data, which are coming from Kubernetes, and include them in Dynatrace, meaning you have a single pane of glass where you can see everything. You can see the technical things, but you have the bigger business value on top of it, as well.

Before Dynatrace, we were testing just by trying out the application ourselves and getting a feeling for the performance. That's how it very often would go. You would start up an application and it was judged by the feeling of the person who was using it at that moment in time. That, of course, is not representative of what the actual end-user feeling would be. We were totally blind. We actually need this to be able to be closer to the customer. To really care about the customer, you need to know what he is doing. 

Also, incidents are resolved much faster by using Dynatrace. And that's for front-end, because we actually know what is going on. But it's also for server-side incidents where we can see the correlation. Using this solution our MTTR has been lowered by 25 percent. It's pinpointing the actual errors or the actual database calls, so it goes faster. But, of course, you still have to do it. It still needs to be implemented. It doesn't do the implementation work for you.

Root cause detection, how the infrastructure components interact with each other, helps. We know what is going wrong and where to pinpoint it. Before, we needed to fill a room with all the experts. The back-end expert would say, "I'm not seeing anything on the back-end." And the network expert would say, "I'm not seeing anything on the network." When you see the interaction between the different aspects, it's immediately clear you have to search in your Java development, or you have to search in your database, because all the other ones don't have any impact on the performance. You see it in Dynatrace because all the numbers are there. It really helps with that. It also helps to pinpoint which teams should work on the solution. In addition to the fact that it's speeding up the process of finding your root cause, it's also lowering the number of people who need to pay attention to the problem. It's just a single team that we need to work on it. All the rest can go home.

It has decreased our mean time to identification by 90 percent, meaning it only takes us one-tenth of the time it used to, because it immediately pinpoints where the problem is.

Dynatrace also helps DevOps to focus on continuous delivery and to shift quality issues to pre-production because we are already seeing things in pre-production. We have Dynatrace in our test environment, so we have a lot of extra information there, and DevOps teams can actually work on that information.

Finally, in terms of uptime, it's signaling whenever something is down and you can react to the fact that it is down a lot faster. That improves the uptime. But the tool itself, of course, doesn't do anything for your uptime. It just signals the fact that it's down faster so you can react to it.

The most valuable aspect is the fact that Dynatrace is a correlation tool for all those different layers. It's the correlation from the front-end through to the database. You can see your individual tracks.

One of the aspects that follows from that is the root cause analysis. Because we have these correlations, we can say, "Hey it's going slow on the server side because a database is having connection issues," for example. So the root cause is important, but it's actually based on the correlation between the different layers in your system.

Dynatrace is a single platform. It has all these different tools but they are actually all baked into the OneAgent technology. Within that OneAgent — which is growing quite large, but that's something else — you have the different tool sets. You have threat analysis, memory dumps, Java analysis, the database statements, and so on. It's all included in this OneAgent. So the management is actually quite easy. You have this one tool, and you have server-side and agent-side which are ways of semi-automatically updating it. We don't have to do that much management on it. Even for the quite large environment that we have, the management, itself, is quite limited. It doesn't take a lot of time. It's quite easy.

The solution's ability to assess the severity of anomalies based on the actual impact to users and business KPIs is great. It's exactly what we need. The severity impact is based on the users, the availability, and the impact it has on your business.

We also use the real-user monitoring and we are using the synthetic monitoring in a limited way, for the moment. We are not using session replay. I would like that, but it's still being considered by councils within the company as to whether we are able to use it.

We are using synthetic monitoring to measure the availability of one of our services. It's a very important service and, if it is down, we want business to be notified about this immediately. So we have set up a synthetic monitor, which is measuring the availability of that single service each minute. Whenever there is a problem, an incident will be immediately created and forwarded to the correct person. This synthetic monitoring is just an availability check in HTTP. It's actually a browser which is calling up a page and we are doing some page checks on this page to be sure that it is available. Next to the availability, which the synthetic monitoring gives us, we also measure the performance of this single page, because it's very important for us that this page is fast enough. If the performance of this single page degrades, an incident is also created for the same person, and he can respond to it immediately.

Real-user monitoring is a big part of what we are doing because we are focusing on the actual user experience. I just came from a meeting, 15 minutes ago, where we discussed this issue: a slowdown reported by the users. We didn't see anything on the server side but users are still complaining. We need to see what the users are actually doing. You can do that in debug tools, like Chrome Debugger, to see what your network traffic is and what your page is doing. But you cannot do that in production with your end-users. You cannot request that your end-users open their debug tools and tell you what's going on. That's what Dynatrace offers: insight like the debug tools for your end-user. That's also exactly what we need.

Most of the problems that we can respond to immediately are server problems, but most of the problems that occur, are front-end problems, currently. More and more, performance issues are located on the machine of the end-user, and so you need to have insight into that. A company of our size is obliged to have insight into how its actual users are doing. Otherwise, we're just blind to our user experience.

Dynatrace also provides a really nice representation of your infrastructure. You have all your servers, you have all your services, and you know how they communicate with each other.

While it gives you a good view of all the services that are instrumented by Dynatrace — which is good, of course, and that's what it can do — in our case, our infrastructure is a lot bigger than the part that is instrumented by Dynatrace only. So we only see a small part of the infrastructure. There are a number of components which are not instrumentable, like the F5 firewalls, switches, etc. So it gives a good overview of your server infrastructure. That's great, we need that. But it's lacking a bit of network segmentation and switches. So it's not a representation of your entire infrastructure. Not every component is there.

The solution's ability to assess the severity of anomalies based on the actual impact to users and business KPIs is great. In my opinion, it could be extended even more. I would like it to be more configurable for the end-user. It would be nice to have more business rules applicable to the severity. It's already very good as it is now. It is based on the impact on your front-end users. But it would be nice if we could configure it a bit more.

Another area for improvement is that I would like the alerting to be set up a little bit more easily. Currently, it takes a lot of work to add alerting, especially if you have a large environment, and I consider our environment to be quite large. The alerting takes a lot of administration. It could be a lot easier. It would not be that complicated to build in, but it would take some time.

I would also like the visual representation of the graphs to be improved. We have control of the actual measures which are in the graphs, but we are not able to control how the axes are represented or the thresholds are represented. I do know that they are working on that.

I have been using the Dynatrace AppMon tool for six years and we changed to the new Dynatrace tool almost three years ago.

We haven't had any issues with the stability of Dynatrace, and it's been running for a long time. We use the Managed environment, so it's an on-prem service, but it's quite stable. We are doing the updates pretty regularly. They come in every month but we are doing them every two or three months. First we do them in the test phase and then in the production phase. But we have not experienced any downtime ever.

For us, Dynatrace is scalable and we haven't seen any issues with that. We did need to install a larger server, but that's because we have a managed environment. You don't have that problem if you go with the SaaS environment. We don't see any negative impact on the scale of our products, and we are already quite large. It's quite scalable.

In terms of the cloud-native environments we have scaled Dynatrace to, we are using Dynatrace on an OpenShift platform, which is a Docker Kubernetes implementation from Red Hat. We have Azure for our CRM system, which Dynatrace monitors, but we are not measuring the individual pods in there as it is not a PaaS; it's a SaaS solution of course.

As for the users of the solution, we make a distinction between the users who are deploying stuff and those who are managing the Dynatrace stuff. The latter would be my team, the APM team, and we are four people. The four people are installing the Dynatrace agents, making sure the servers are alright, and making sure the management of the Dynatrace system itself is okay.

The users of the tool are the users of the different business cases. That includes development and business. There are about 500 individual users making use of the different dashboards and abilities within Dynatrace. But we see that number of users, 500, as a bit small. We want to extend that to over 1,000 in near future. But that will take some advertising inside the company.

I use Dynatrace technical support on a daily basis. They have a live chat within the tool and that comes for free with the tool itself. All 500 of our users are able to use this chat functionality. I'm using it very frequently, especially when I need to find out where features or functionalities are located within the tool. They can immediately help you with first-line support for the easy questions and that saves you a lot of time. You just chat and say, "Hey, I want to see where this setting can be activated," and they say, "Just click this button and you will be there." 

For the more complex questions, you start with tickets and they will solve them. That takes a little bit longer, depending on how complex your question is. 

But that first-line support is really a very easy way to interact with these people, and you get more out of the tool, faster.

We purchased the Dynatrace product because we had some issues with our direct channels, our customer-facing applications. There were complaints from the customer side and we couldn't find the solution.

There were also a number of our most important applications that needed more monitoring. We had a lot of monitoring capabilities on the server side and on the database side, but the correlation between all these monitoring tools was not that easy. When they came up with a problem they would say, "Hey, it's not the mainframe, it's not the database, it's not the network." But what was it? That was still hard to find out. And we were missing some monitoring on the front-end. The user experience monitoring was lacking. We investigated a number of products and Dynatrace came out as the best.

We kind of grew into Dynatrace. Our initial scope was quite small, so it was not that complex. Currently, our scope is a lot broader, but it is not complex for us because we have been working with the tool for such a long time. Overall, it's quite straightforward. If you're starting with this product from scratch and you have to find out everything, it can take some time to learn the product. But it's quite straightforward.

We started with the AppMon tool, which was the predecessor to the current tool. Implementing that went quite fast because it was a very small scope. When we changed to the Dynatrace Managed it took us half a year. And that's not including the contract negotiations. That was for the actual implementation: Finding out all business cases and all the use cases that we had, transforming them into the new tool, and launching it live for a big part of our company. That took half a year.

We hired some external experts from a company in Belgium, which is called Realdolmen. They really helped us in the implementation. They had experience in implementing Dynatrace for other companies already, so that really helped. And I would advise that approach. If you're doing it all by yourself, you are focusing on what your problems are, while if you are adding an external person to it, who is also an expert in the product itself, he will give you insights into how the product can benefit you in ways you couldn't have imagined.

The issue of whether Dynatracec has saved us money through consolidation of tools is something we are working on. There are a number of things that we are replacing now by things that are already present in Dynatrace. If you currently have a lot of different tools, it will save you money. But Dynatrace is not the cheapest tool. Money-saving should not be your first concern if you buy Dynatrace.

It depends on your business case, but as soon as you are at a reasonable size and you have different channels to connect within your company — mobile and web and so on — you need to have a view into your infrastructure and that's where Dynatrace provides real benefits. It's not for a simple company. It's not for the bakery store around the corner. But as soon as you hit a reasonable size, it gives enough added value and it's hard to imagine not having it or something comparable.

"Reasonable size" depends a bit on your industry. But it is connected with the number of customers you have. We have about 25,000 concurrent customers, at a given moment in time. As soon as you have more than 1,000 concurrent customers, you need this tool to have enough analysis power. It gives you power for tracking the individual user and it gives you the power to aggregate all the data, to see an overview of how your users are doing. This combination really gives you a lot of benefits.

It is quite costly. Dynatrace was the most expensive, compared to the other products we looked at. But it was also a lot better. If you want value for your money, Dynatrace is the way to go. 

In my opinion, the product is extremely good and comparable. We did compare it to AppDynamics and New Relic and we saw that Dynatrace is actually the best product there is. If you are looking for the best, Dynatrace will be your product.

The biggest lesson that I have learned from Dynatrace is that application performance monitoring is very complex, but the easiest part of it is the technical aspect. The more complex thing is all the internal company politics around it. We see a lot of data and if you are targeting some people and say, "Hey, your data bridge is going slowly," they will respond to it very defensively. If they have their own monitoring tools, they can say, "Oh no, my database is going very fast. See my screen is green." But we have the insights. It's all data, and gathering the data is the technical aspect. That's easy. But then convincing people and getting people to agree on what is obvious data is far more complex than the technical aspects.

The way to overcome that is talking. Communication is key.

I'm a little bit skeptical about the self-healing. I have heard a lot about it. I have gone through some Dynatrace instances where they have this self-healing prophecy. I think it's difficult to do self-healing. We are not using it in our company. There is a limited range of problems that you can address with it. It's only if you definitely know that this solution will work for this problem. But problems are always different, every time. And if you have specific knowledge that something will work if a particular problem arises, most of the time you can just avoid having the problem. So I'm a little bit skeptical. We are also not using it because we have a lot of governance on our production environment. We cannot immediately change something in production.

We are using dynamic microservices within a Kubernetes environment, but the self-healing is a little bit baked into these microservices. It's a Docker Kubernetes thing, where you have control over how many containers or pods you want to spin up. So you don't need an extra self-healing tool on top of that.

In terms of integrating Dynatrace with our CI/CD and ITSM tools, we are working on both of those directions, but we are not there yet. We have an integration with our ITSM tool in the sense that we are registering incidents from Dynatrace in our ServiceNow. But we are not monitoring it as a component management system.

We are not doing as much as I would want to for these Quality Gates. That can be improved in our company. Dynatrace could help with that, but I would focus on something else like Keptn, or something else that integrates with Dynatrace, to provide that additional functionality. Keptn would be more suitable for that, than the Dynatrace tool itself, but they are closely linked together. For us, that aspect is a work-in-progress.

I would rate Dynatrace a nine out of 10, because it has really added value to my daily business and what I have to do in performance analysis. It can be improved, and I hope it will be improved and updates will be coming. But it's still a very good tool and it's better than other tools that I have seen.