Dynatrace Reviews

Primary use case would be RUM for real-time monitoring. 

It has performed really well. Earlier, we were documenting how long each transaction was taking, because we had a service which was pinging different sources. Therefore, we had to go into the logs and see what the response time was for each step. Now that Dynatrace is instrumented, we are getting alerts any time the service time is not the baseline. Then, you look at the PurePath, and it really helps you drill down to where. You can work with other managed groups and tell them this is the timeframe when we saw the issue, "Did you see your CPU load go higher?" That is where I am finding it really useful. 

When our service response time was not matching the baseline, we realized that our Oracle TNS was getting too many pings, so Oracle recommended to us to utilize more persistent connections, so this is where Dynatrace really helped us narrow it down. Therefore, we are changing our call to use more data sourcing and connection calling. That is the real business benefit that we have received.

The real-time monitoring, which we are getting, is amazing. 

PurePath: It is really good. You can drill down and see what the baseline is. If it is five seconds and I am not happy with it, I can go into the PurePath and look at each step, then see where I can improve my performance.

I do not like the performance of the UI. It is really slow. I get a problem, but by the time I can drill down and figure it out, it is getting late because the performance is slow. When it is performing well, I know right away and I know how to react. 

Basically, our database list is running out. They have a maximum connection counts per second, and that is where we are running out of count. We were exceeding that count, so Oracle increased it to 200, and that is what Dynatrace gave us. In some situations, I have seen the UI is slow on our end.

Also, we were getting alerts, like the CPU was pinging, and it came in the middle of the night, and it was a development server. So, the next day I wanted to look at it, which process caused it, and sure enough Dynatrace gave me the details, but it does not give the user running the process. Most of the processes are very obvious what is running, like JVM is running, Java, or what websphere is running. But for this process, I had no clue. I involved a Dynatrace consultant, and he had no clue. Then, as a team, we did not know what to do. It was not happening often, so one night I was lucky enough, the monitoring alert came when I was online, and I quickly logged into the server to the top, and sure enough the process was running, and the process was running as route, so I know the groups which can run processes. 

That is how I figured out the process, and they looked into it. They figured out what the issue was, but just looking at Dynatrace I couldn't have figured it out. Therefore, I asked them if when they give these results that when they have CPU consumption in the processes, if they could also have the user. That would help.

Once screen replay comes in, that will be even more useful.

It is stable, but slow. We have a managed solution. We do not have a set solution. 

Scalability is pretty good.

I am more from the development team. We have a monitoring team, which is actually supporting Dynatrace with the help of Dynatrace's guidance.

Feedback about the technical support from our monitoring team has been pretty good. Our monitoring team is totally taking it in well. They are learning on their own. 

We have a lot of siloed monitoring tools; as in, we still have them. They are good alerting tools, but they cannot really measure response time levels and do the PurePath analysis, which Dynatrace is able to give us. This was the real challenge we had. They would say, "Why don't you record the response time for each step in the log file and we can monitor that," but I did not like that way of doing it. Dynatrace has very graphical interface, therefore it beats those tools. 

We used and are still using Nimsoft. The alerting is pretty good, and it integrates well with our issue management tools. Now though, Dynatrace integrate well with ServiceNow, and we are in the process of moving to ServiceNow. 

I am in the development. We just instrumented it on my servers. 

We had major issues, and it was not Dynatrace. It was how Dynatrace and Voz garbage collection were interacting, so IBM got involved and had to upgrade us. Now, it is doing a real good job, but that is how I got pulled into Dynatrace. 

There is a license issue where if we increase the memory we have to up the licenses. I was unaware of that going in. I thought it was scalable without all the paperwork behind the scenes.

I would recommend Dynatrace because I have seen Nimsoft. They do not have this graphical interface, and a graphical interface helps. Otherwise, with CP utilization and memory utilization, you would have to go to capacity planning to have them share their graphics. With Dynatrace, we can just bypass all that and just use it to see all the details. 

I would really recommend this product. 

We are not yet using cloud.

Our group handles a multitude of applications using Dynatrace. In my experience, I have used a lot of different tools, and Dynatrace has been pretty awesome with handling all the various issues that pop up.

PurePath is pretty awesome. The amount of data that the tool exposes compared to a lot of other agent-base suites is dramatically different. A plethora of people  embrace a lot of the topology views and various different things. I am primarily doing DC RUM, so on that side there are a lot of awesome abilities where people who can't implement an agent are able to still monitor a lot of their apps and decodes.

We are not using the ServiceNow integrations. We have to go through this event engine, so some of the data and the alerts get taken out. We have a script that pulls in some data around what the alert is dealing with, but maybe there is more data that could be exposed there. Besides that, in regards to Diffie-Hellman encryption stuff, it is a hurdle with what we are doing with DC RUM, where everyone is embracing stronger security suites, but the whole point of DC RUM is to get that data between the tiers.

We have big data solutions now coming in, so we are being asked to export some of that data into Tableau and various different platforms, so anything that makes that easier is welcome. DC RUM has an API that they can call, and Dynatrace can stream out to it. Those APIs are welcome.

More than five years.

There have been problems, but nothing that we could not figure out. There have been a couple issues where agents have caused issues with applications, but you could chalk that up to QA testing or other stuff. Overall, it has been a good product.

I hear it is supposed to be improving. My impression is mixed. We have a lot of Dynatrace servers with a lot of agents, so we are pushing the capacity of some of those servers. At the moment, we are not doing any cross-server stitching between the agents, so we are missing out on that piece a little bit. However, that will improve with the next version. Therefore, we are managing the capacity, but currently it is decentralized.

Technical support is awesome. I primarily do DC RUM, but all of that is in Poland, and they are phenomenal.

I have used CA, Wiley, CA CEM, and a little BMC stuff; those are the main ones.

They were good in their own silo. They just did not bring everything together in one central view. That was the difficulty. A lot of teams did not embrace it as much as we have seen the Dynatrace platform be embraced.

We switched from CA to Dynatrace, because limited data that was being exposed from Wiley. You get similar response time volume and error rate for instruments and components, but it is a lot more manual to get those components instrumented. Whereas a PurePath is right in front of you, so it is really easy to see what areas you want to alert on and catch.

Initial setup is straightforward. I have stood it up at multiple companies. I did it at Verizon Wireless, PNC, and Merck Pharmaceuticals. I knew what to do, so it was easy. 

When I first did an install, there were some hurdles. However, everything was well supported by our site rep, who came on site frequently in New Jersey, and was helping me out. It helped.

I was in for onboarding DC RUM. We did a PoC with BMC, CA, Dynatrace, and AppDynamics. There are some other competitors who are always being looked at, but the data exposed was dramatically better from Dynatrace, so that is why we went with Dynatrace.

Look at Dynatrace. Having worked with it and recommended it for approximately eight years, it has been a great platform.

The role of AI when it comes to IT's ability to scale in the cloud and manage performance problems is very important. We must embrace the AI overlord. There is a lot of data that comes into Dynatrace, and anything that makes it easier to arrive at the end resolution of a problem is welcome. There is always more analysis that needs to be done, but I think it is important to start using AI to get there more quickly.

If I had just one solution that could provide real answers, not just data, the immediate benefit I would like to see is anything that helps the app team know how to get the answer more quickly and save us time in the middle of the night. 

We get woken up all hours of the night for issues. You would hope that app teams would start to use the tools themselves, when it comes down to it, we know the tool best because we manage it. 

Most important criteria when selecting a vendor: 

The two main things I would say are critical:

1. Obviously, the technology cannot fall behind competitors, but at the same time, they have to remain pretty agile in developing the tool. 
2. They need a large enough support staff where any issues which arise, we get support on them. 

Primary use case would be exposing application performance, and incidents and errors within the application. It has performed exceptionally well.

Understanding and visibility, and the ability to provide the same answers across the different archetypes of support personnel, maintenance personnel, business personnel, executives, middle managers like myself, where we're all telling the same story and we're all working off of that same story, to understand what's going on.

The main benefit has been time, definitely. Over my career I've spent hundreds, if not thousands, of hours in war rooms picking problems apart, over-analyzing issues, chasing red herrings, and this type of solution, or solution set, not just AppMon but Dynatrace, and even the Synthetic portion, really helps us narrow down what we're looking for.

Capture of 100% of the traffic. Exposure to downstream services, that might not necessarily be new, to everybody who's using applications. It triggers them and captures them and it gives visibility to some pieces that might be forgotten or even obscured.

If it is AppMon, I would really like ease of integration developed into Logstash. The business transaction data doesn't have a natural feed through the GUI, through the configuration. We have to do a little jiggering in between to get it to feed, so I'd like to have that out-of-the-box. That'd be great. We have now, out-of-the-box UEM integration, I'd like to have the rest out of the box as well.

And if it's Dynatrace we're talking about, I really think they're on the right track as it is, because of all the AI and all the session replay and all these fantastic things we've been shown.

And if it's the Dynatrace Synthetic which we also use, I would love to have higher-level analytics across the tests. Where today we get errors and generate them per test, but we have clusters of tests that are for the same application, I'd love to see a little bit more analysis done across series of tests, so that we can have higher roll-ups of actionable information.

This is an interesting question. We've had our challenges in the past because our primary tool over the five years has been AppMon, and AppMon has had a series of evolutions. We started with the 4.2 version and we've come all the way to version 7 at this point. It was never intended to be a high-availability solution or a clustered solution, and some of those improvements have been made more recently. But historically, it was fragile. 

Like I said, I have a very large implementation. Over six thousand agents with AppMon. Some of our servers are very highly loaded, over a thousand agents, and when we talk about our online banking, mobile banking platforms, we drive significant load and it can really impact the viability of the servers.

To be fair, we were pushing the product to its limits, and it even prompted some of the architectural changes within Dynatrace itself, and within the AppMon tool, to allow for larger footprints. But generally, and lately, it's been extremely stable.

The AppMon product hasn't been historically as scalable. That is one of the reasons we're really excited about Dynatrace product, because it was redesigned for scalable environments with scalability itself in mind.

The technical support has been fantastic, even getting right up to third-level support and getting changes overnight. 

A small anecdote: We needed some changes to the UE mobile agent and we needed them in a hurry. And support turned that ask around in two days, which was phenomenal.

And then, I started talking to some of the guys in Boston, Detroit about some of the exciting changes they're making for their support model where they can have off-site guardians. I actually employ two guardians myself at a time. I have them on a one year contract. Putting them in-house has been invaluable.

The idea of other organizations being able to use Dynatrace guardian hours, and doing it piece meal as they need it, is great because not everybody needs as much hand-holding, but everybody needs a little help some time. The response time and the knowledge has been tremendous.

We've used a number of tools. We've used SCOM and Wily Introscope and Groundworks. We've used Nagios, Zabbix. We've used HPE RUM which was terrible. It cost a lot of FT overhead. There have been a few others, I just can't remember them offhand.

A lot of them were siloed, very siloed approaches to monitoring. Some of them have similar approaches, DC RUM is the same as HPE RUM, but the manpower overhead is significant. The challenge there is they just don't talk to each other. And they're not providing the same information to the same people because people craft the output to what they want, and they're not trying to tell the same story. Dynatrace just attempts to tell the truth.

To be honest, I wasn't part of the board of smarty-pants that brought the solution in, but I can imagine the criteria they looked at included breadth of coverage of technologies, the cost, and ease of use. Either way, I thank that team because it changed our lives.

When it comes to the nature of digital complexity, the role of AI when it comes to IT's ability to scale in the cloud and manage performance problems is absolutely crucial. Last year I spent a large portion of my time doing an investigation into AI capabilities for IT operations, and I evaluated several products in the market space. I found they're all very, very immature, but it's an absolute necessity for us going forward. 

We're a very large bank and we have hundreds of thousands of users, thousands and thousands of applications. When you start scaling up to the cloud with microservices, the sheer volume of data is so massive that human beings can't evaluate it anymore. It's not possible. AI is the only way that we're going to be able to move forward into the future with these types of architectures, and still get the value out of the data that we're recording.

I've definitely used so many siloed monitoring tools in the past. The challenge is when it comes to clustering and high-availability - that type of solutioning where we look at strict node-based siloing and then application based siloing. Even then you're limiting yourself to the purview of what's in that container or what's in that application, and if you're not looking outside of yourself then you're really just looking for a culture of "not me," instead of fostering a culture of this is what it is. Let's work together.

If we had just one solution that could provide real access and not just top line data, I think it would probably free us up in terms of manpower and work hours, to allow us to do more value-add things. If all we're doing is working with top level data, then you have to spend a lot more time digging deeper to find your cause or to find actionable insights into the applications, and that chews up manpower. In this day and age, IT overhead really has become "Let's look at the employee first and cut that first." So, if we need to move in that direction, having something that provides real answers helps us to make that adjustment.

I rate Dynatrace an eight out of 10. I never want to give a perfect score because there's always room for improvement. But it's been a great journey for me and I look forward to many more years with it.

I'd recommend you look at Dynatrace. It's really the only one worth looking at.

Currently, we use Dynatrace to monitor the PCF Cloud Foundry. We just started using it. So far, so good.

We do not have an effective tool to monitor the PCF Cloud Foundry. Dynatrace closes that gap. We have tried using different tools to monitor Cloud Foundry, but they were all ineffective. 

It helps to show you the performance. It also shows you where the problem is, automatically trying to find the problem. It helps to show where the problem is and isolates the issue. 

The installation and configuration were very straightforward and nice.

There was one issue with the installation, but the we resolved the issue. It was some issue with the proxy, and we resolved it.

An additional feature that we could use is the rollover. If we could rollover to different datacenters, then it would satisfy our requirement. I.e., if one datacenter fails, then we could rollover to another datacenter.

Right now, they can rollover to a multi-node cluster. Generally, they require a multi-node in the same data center. Our requirement is because we want something in case of a catastrophe, like an earthquake, and the data is possibly wiped out. We need a way to automatically roll it over to another datacenter. 

This is not offered at the moment.

Still implementing.

So far, stability has been very nice, and Dynatrace runs on the Linux system.

It scales well. 

The only thing is we do have requirements where if one datacenter fails, you need to switch to another datacenter. On this front, Dynatrace was not built. They have active to active standby, but from our talks with Dynatrace, they are not built between datacenters. They need to be logged in at the same datacenter, and if they are logged in at different datacenters, there might be some issues. That is one thing they need to improve on: Datacenters which are geographically located. So, when there is a issue in the datacenter, they can just automatically rollover to another datacenter. 

We used technical support. We just start configuring the system and the initial installation. We had one issue when we tried to enter one agent and it just does not work. We got to work with the highest level of support, but it took a while to get there. Initially, we did not get to that level. This is considering maybe it was just after the New Year, and it took a little bit longer than we expected to get to the highest level of support. 

We do use multiple monitoring tools in our organization, including size scope, BPM, and CA APM. We also have RUM and several different monitoring tools. 

We chose Dynatrace, because it is good at monitoring the PCF and also the performance platform is very nice. 

The initial setup was straightforward, very easy and nice. 

AI is very important with the increased complexity of the IT system. IT is very hard to pinpoint the root issues of a problem with AI. It would help you to analyze the issues and let you get to the root issue faster, because people with experience are rare, and with AI, it helps bridge this gap. 

If I had just one solution that could provide real answers, not just data, the immediate benefit would be using only one tool where you do not have the complexity of managing more tools.

Most important criteria when looking for an APM solution: 

1. I need it to monitor all the different applications. We have a diverse suite of applications, and it needs to support all the different applications. 
2. It has its own stability and is well supported.
3. It needs to be scalable. 

Track and tracing of each individual end user transaction throughout a complex Core Bank financial chain. Within 5 clicks you got the evidence why the performance is lacking. Also a problem could be analysed from different angles. One dashboard that provides the information and you can work independently (you don't need the presence of OPS people, and other tooling except Tibco EMS monitoring)

Our customer base is too immature on performance matters. Besides that, they are now working with Dev/OPs teams (more than 180!) where there is no governance overall. Every team can decide what they want to use with respect to tooling. There is no Business or Operational chain owner.

Message Bus monitoring: it is not possible to deep dive into the the Tibco EMS bus. The consequence is that we depends on EMS monitoring tools like RTView, Tibco Hawk, GEMS etc. These tools are lacking the functionality to track and trace individual Tibco messages, something you really need to do trouble shooting; Deployment of dynaTrace agent fixes per selected agents instead of all agents. Consequence is that if an Agent fix is corrupted or whatsoever, all agents are off-line; Eco system like AppDynamics (external parties can develop plugins). On the other hand, it has an disadvantage because your quality control must be very good to not jeopardize the tool stability.

I have been using this solution for 2 years.

Not at all. This product is developed by guys who perfectly understand that a quick and seamless install is part of the customer experience. It is heaven if you compare this with IBM or HP stuff.

Not at all. No crashes whatsoever.

I can't answer this question, because it is not deployed in a broader way. I'm not convinced to deploy a large scale solution, because it consumes an enormous amount of data resulting in a decrease of retention time. So I advise to deploy more DT instances where every Dev/OPS is responsible for their own DT instance.

Customer Service: Could be improved, but has everything to do with the merge of Compuware and dynaTrace. There is a local office in the Netherlands, but available FTE is under par.Technical Support: It is good.

7 years ago I used HP Diagnostics. This was not an out-of-the-box instrumentation (1st gen diagnostic tooling). It took too much time to get added value out-of-it, too much interpretation. dynaTrace is installed in half-a-day, fully operational (including the dynaTrace agents, dynaTrace server and Collector). This is why this tool with all its functionalities is a preferred tool for performance troubleshooting, performance tests, test automation and full coverage production monitoring. It also works with a lot of performance test tools. I'm not impressed by the Dell Foglight diagnostics; I never see it working with SOA technology. AppDynamics: despite the fact that I didn't work with a full deployed installation of AppDynamics, you need a lot to do to get the information like dynaTrace provides.

Straightforward

We don't to depend on vendor PSO.

Can''t answer this question. The performance organisation is too immature to answer this.

Tool investment (initial 50 JVM agents, increased to 80). One time investment with yearly maintenance costs Total Stitching activities 20 days (due to Tibco wired /unwired mechanism and old JMS version usage); 5 days per week performance testing

No, I didn't evaluate other options. Reason: I'm not totally convinced about the products provided by vendors like IBM, CA, HP, BMC etc. Way-too-much consultancy, it takes a lot of time to generate added value, too difficult to work with etc.

Use it as fast as you can. List prices are negotiable. You get instant success!

I primarily use the solution for mobile monitoring and service management. 

The monitoring is very good.

We like that the solution has the ability to drill down so that you can see your payload. 

The solution is ideal for large companies. 

I'm not sure if there are improvements needed. I don't work actively with it. I sit at the management level.

The solution is a bit pricey. As a result, you can't shift quite so easily, and you always are testing in production.

It's not the best solution for small-scale companies. 

I've been using the solution for five years.

The cost model for developers, et cetera, is too expensive. It's not very affordable for small companies. 

I am just a customer and an end-user.

I'm using the latest version of the solution. It updates regularly.

I'd rate the solution eight out of ten. I'd advise users to try it out. However, it's more for large-scale companies and not really the best for smaller organizations. 

Public Cloud

Amazon Web Services (AWS)

We use this solution for end-user experience, infrastructure monitoring, analysis of bounce rates, service calls to the database, root cause analysis, and problem management. For end-user analysis, I can monitor where the connections come from, the time, the number of navigated pages, bounce rates, and finally, if the usage was satisfactory or not.

This solution has improved our organization in several ways, including the speed of detecting problems, predictive maintenance, root cause analysis, and alert generation. We are also better able to understand trends with respect to user behavior like time zone connections, and the times when there is less usage of the system by users.

Our organization is too IT oriented. I think with Dynatrace, it has helped to bring value to the business because now we can speak using the same language.

The most valuable features for me are end-user analysis and problem detection. I am responsible for adoption, availability, and performance. In the case of adoption, the number of new users coming to the system is a good metric for management. For problem management, problem detection is a good feature to save time.

I have reported a bug where a CI was not reflected in the dashboard, yet it was detected in the problem management.

On the side of the end user experience, I would suggest adding a new service for analyzing the backtrace of users.

Also, I would like to see an option to export the dashboard to create better reports and avoid copy/paste.

Between one and two years.

In terms of stability, it is ok and we have had no issues reported so far.

We cannot properly address scalability yet.

Prior to this solution, we used Gomez. It was part of the original solution that was installed. We had many problems with synthetic monitoring because it was down most of the time.

The tools were installed before I joined the company.

There are long term benefits in using the monitoring tool. There is also strategic value added, as is the case of transforming the internal language of the technical teams.

Currently, primary use case for the usage of AppMon is what I will call our flagship applications across the bank. We have had it about three years. Adoption was over time, one app at a time. then more and more. All of our major flagship applications now have AppMon dashboards. We do have some SaaS, but that is because the applications are cloud-based solutions. The use case frankly is about improving monitoring, system uptime, and preventing of events. If you have thresholds set correctly, along with alerting, and all the other stuff, your operational teams can find things before the field even notices.

We have substantially lowered incidents in our organization. It is hard to really measure it exactly from a percentage of how many have been lowered. As a general statement, there is no question that the number of incidents and the duration of incidents have dropped. Even if we do get caught blindsided by some infrastructure failure or something, our ability to pinpoint the problem through things like PurePath have dramatically reduced incident time. Whether you want to argue about AppMon, SaaS, or cloud from a business value point of view, that is tangible even for our non-technical people at the bank. They get this.

• The threshold alerting is what makes the difference. 
• The PurePath stuff for deep dive analysis on problems. That is massive as far as having a benefit. 

The dashboard is eye candy, because it's just a screen. It looks nice but the thresholding and alerting is what makes it meaningful because we are a 24/7 operation. As you can imagine, 2:00 AM in the morning, you can't necessarily afford to have a bunch of people staring at glass. We have to have the mechanism of the alerts, which is tied into our others systems, like xMatters. That is how it works for us.

I do not know everything that is in the hopper. What I am about to say could already be in the hopper. I am learning more about so called 7.1, be it SaaS or AppMon. Setting up the thresholds and alerting, it is complicated to understand their use cases. In other words, as a business perspective, you want to say, "I want this to alert under these conditions." However, you have to translate that in terms of all the various settings in Dynatrace. Whereas, it would be easier if Dynatrace just had a button that said, "I want this alerting use case," and I just pushed a button, then it set the 17 values behind the scenes. That would probably be a more user-friendly way. It does not require the user to understand what a threshold is or even what the different intervals of thresholds are. It is just a black box. It is like, "I want this experience," and it just figures out what to set.

Three to five years.

The product is evolving, maybe too fast; maybe it is a little bit fragmented of an evolution. It is sort of expected in a way because the company, in my impression, is spending a lot more money. It is a function of the fact that they are growing as a company and revenue is growing, so there is probably a lot more emphasis on R&D and different product development. My expectation is that over time it will become a more unified, stable product. However, generally, from the product itself, we have not had issues with it, like something that monitors the monitor. We have not really had to worry about it.

I have not been aware of any limitations. I know that the older version of AppMon, the so called classic version, had some limits on number of agents per server. However, those limits never really caused a challenge for our particular topology.

As our adoption was in its infancy, we had the physical Dynatrace guardians, local from local areas, if you will, in our city. That was like our support because they were physically onsite. As our own staff became enabled and just basically knew the product, we frankly did not really need support, unless it was a product defect or something like that. In which case, we had a team within our company that was the interface for them.

We have used siloed monitoring tools in the past. A lot of products have obviously been around for years, even before Dynatrace. Typically, they are technology or topology specific. You have got a certain operating system or environment which is the product of choice for that environment: different operating system, different environment, and different product. You will also end up with a whole lot of tools sets, even depending on if you want a synthetic use case, something like Foglight as an example. You just wind up with too many tools. Even this morning, Dynatrace's CTO talked about this very problem. I guess Dynatrace is trying to solve this with one-shoe-fits-all. Which as an organization, who would not want a multi-supported application product that can go across all the topologies, cloud, and everything else?

There was a product we used before Dynatrace. We are a big mainframe shop, so it was a mainframe product. It was really built for the IBM mainframe. Because we were heavily in mainframe and this is going back a few years now, that was the product for choice for mainframe. Then, with web-based solutions, all these applications, cloud, and everything else coming, we needed something else. I do not really quite know how it happened exactly, but somebody talked to somebody who talked to some Dynatrace person. Then, I remember actually going to the very first ever meeting where a Dynatrace person came on our site. They asked me to attend because I'm a big stakeholder and I guess it just went from there.

At the decision time, we did have a senior executive emphasis on the business that there just appeared to be too many incidents and we are a major financial institution with 40,000 employees in the field essentially generating revenue on practically a 24/7 basis. If one of the systems that they use is even down for 10 minutes, that is like $1 million lost. So, there were a lot of events and the timing was right. Whether that was good timing on Dynatrace's part, because we had a problem that we needed to improve, they came into our location, we had a marriage, and we have been with them since. 

I was involved in one of the very first implementations, but I did rely on an infrastructure team that did the physical installation and acquisition of virtual servers, as far as the agents and the nodes. I was physically involved on a team that wrote one of the very first dashboards. This is three to four years ago. It was more about just learning the product, frankly. I look back now and I can close both eyes now. At that time, it took some time getting used to it, but I would not call it overly complex.

There may have been minor things, but that was more our own people trying to understand it. We may have had it, such as, "Let's install this agent on this server," then it didn't work. Then, "Oops." You have to back it out, then three days later, put it back in. A lot of that is teething. I do not see that as a product limitation. It is just sometimes you don't necessarily know what you don't know and kick the tires a couple times. Now, whether the product could have maybe been a little easier? It's hard to say in hindsight.

I don't want to bring up Apple, but you can think of the Apple example. Apple has this idea that you just take it out-of-the-box and turn it on. That's it. That's your extent of configuration. Dynatrace isn't quite like that, but probably for a reason, because the idea that it could just work as is doesn't make sense, because the individual customer environments are just so different. You couldn't possibly have one-size-fits-all. It is almost impossible.

We had Dynatrace guardians onsite. 

I would definitely recommend Dynatrace. I would say not to be fearful and embrace it. It is a combination of personal comfort level in your staff, so I would probably recommend you start with a medium to low profile application and just aggressively implement Dynatrace. Once you get accustomed to it, then go with the all-in adoption. 

It is a great product, but your staff and your people, unless you are completely turnkeying it for someone else, they have to understand it. You implement it, and if people don't understand it and use it, then you are really not getting anywhere. That is probably the key part I would make to any recommendation, make sure you train your people or bring in the guardians or use the guardian for six months.

Our technology is constantly evolving. Obviously, the tools like Dynatrace we do hope and expect, frankly, that they will continue to evolve the AI element. I still think there is room in AI technology. Obviously it is getting better all the time. Voice assistant products are obviously the new thing now. So, there are a lot of changes in that technology. My expectation is that we will get way more sophisticated AI alerting and monitoring capability in Dynatrace and we will be happy to embrace it as it becomes available.

If I had just one solution that could provide real answers, not just data, the immediate benefit to my team would be to reduce human interpretation where you have to log on and interpret data. Any automated interpretation on a user's behalf, or operational team, it will be better.