DX SaaS Reviews

DX isn't something people use all day, every day. In some cases, the application teams use it when there is a problem in their application. It allows them to identify the core issue causing the problem in the application. 

Any application team in the use case environment can access DX if it's integrated. Every application rolled out in the use case environment could be APM-enabled. We aren't sure how many people are using it at a time.

We are using the SaaS version, but we were previously on-premise. There was no DX. It was known as Application Performance Monitoring at the time. Now it's DX APM, and DX means "digital experience." The cloud version is known as DX APM SaaS or DX SaaS APM.

DX allows you to customize and gives you a high degree of control. 

DX SaaS is a latecomer to the APM market. Some things that are straightforward in Dynatrace are complicated in DX. For example, upgrading the agents is a seamless process in Dynatrace, but it's a pain in DX SaaS. You should be able to upgrade in the Application Command Center. However, it is not working correctly.

They upgrade the product every 15 to 30 days, and the process isn't seamless. It's like implementing the solution all over again. We monitor around 1,000-plus applications and have more than 100,000 agents, so we require a smooth upgrade process. It's nearly impossible to stay updated on the latest version.

Upgrading the Dynatrace agent is smoother. You don't need to worry about it. If the agent is on the Dynatrace server, you only need to push it. After that, you will be notified to reboot the APM or CLM. That's it.

It took us three years to deploy the agent on 1,000-plus applications across 40,000-plus servers. Now, they are saying they are ending support for 7.0.49, and we need to upgrade. The path to upgrading isn't straightforward. The first process is manual, and we can push it to different servers so it is visible. What's our configuration? Who is going to do the configuration?

It's not typical or practical. I don't understand how product teams don't see that. That feature is not there. We hope they add this feature to the new product called DX Platform, which consists of net apps. All those network monitoring tools will be combined into DX Platform. 

All the monitoring functionality is moved to DX Platform. You can't see a trend of your metrics grouped according to the last month, six months, one year, etc. The resolution is not there. I want granular visibility into data captured in the last 15 seconds. Those are essential features. 

I am not saying that DX lacks solid features, but they need to consider it. Some core functionality of the product is missing. We have around 50-plus requests to add previously available features in the on-premise version. That is one reason application teams are reluctant to go to DX SaaS. We are struggling to make them understand and trying to find alternatives for the existing features.

We've had many discussions with the product team, telling them we need this functionality. However, they tell us it's not on their product roadmap. They are gradually adding other features, but we need our requirements to be a priority. You cannot say you will try to add those requested features that aren't on your product roadmap. 

There is always a catch in the product. We use around 10 tenants in production and six in the test run. First of all, there is nothing in the pane. If we are trying to see the data from an application, how do we know which tenant and application are reporting? There was a feature called Enterprise Team Center, but that functionality has been removed.

All the applications are connected to the manager, which is connected to ETC. If you go to ETC, you can find the server and see your data, but that functionality was not there. Every product should have a management feature, but that is missing, and they are saying that it is not there in the roadmap. It is a basic requirement. You need to understand that. That is not there, manager, and they are saying that is not there in the roadmap as well.

They have created a new tenant page temporarily. It is not there currently. It is not a required thing. There is a feature called Domain, but that concept is gone. We've struggled a lot, and what they provided in the initial migration stage is no longer working. We were delayed for two months because we didn't give them the correct input. They don't know their product. We tell them there is a problem, and they say they're fixing it. Are we their Guinea pig? You cannot treat your customers like this.

I have used DX for more than two years.

We were using the on-premise version and moved to DX SaaS. A lot of metrics were clamped when we were on-premise. There is a limit to the number of agents it can handle. You will get a clamp once that's exceeded. That agent will not be able to pull the latest metrics from the application.

There is no feature to tell us which agent is clamping and why. What actions can we take to reduce clamping? Suppose that agent selects unnecessary metrics that won't be useful for the application team. We must stop them and tell the agent not to pull the metrics.

Finding that information on the dashboard was challenging when we were on-premises. They still had the same problem when we moved to DX SaaS. They cannot fix it, but they are tweaking some of the hardware sizes of containers. Sometimes they increase the JVM heat styling. 

Scalability isn't a problem. If you are paying for an enterprise-level product, it should be able to handle around 1,000 agents successfully and provide end-to-end visibility of application transaction processes. It may work for a smaller environment with 50 applications or 5,000 agents. 

A customer may be happy with the outcome of the product or the value added. Still, you need to have a different approach for a big implementation like it is here where we have 1,000 agents and 30,000, 40,000 deploying the application agent. We are also using the APM manager. You need a different approach altogether. It's not that this product is terrible, but it is not built for our requirements. There is a performance issue now and then. 

I rate Broadcom customer support six out of 10. I have stopped submitting tickets because every time they say, "We can't do anything else. Our product team will handle it." They will raise a feature request that will be tracked separately. I need a resolution when I submit a case.

Why should I struggle? I know it's an issue, and support should fix it, but their priority is showing their manager how many tickets they have closed. I have been working on this product for the last 15 years. I know what support and operational services can do. I understand that, but I need the support engineer's intent to be precise. If that isn't clear, I will not open a new ticket. Why should I go and raise a support ticket for every issue I have encountered. 

I sincerely think they have released a good product, but they haven't tested it properly. They are updating the product to keep pace with their competitors. We use it to identify the missing features and tell them to add them. I think that is not the right way to develop a product.

I have worked with Broadcom for many years, and I appreciate its technical support. They always respond quickly, but the outcome is often unsatisfactory. There have been many changes since Broadcom acquired CA. The strength of their support has been reduced. There are significantly fewer people, and they're handling more tickets. 

I understand all these things, but I still interact with some of the top-notch Broadcom support. They will resolve the issue, then get off the call. I don't care if it takes three hours or 24 hours. I appreciate them, but, I am not seeing that approach with the technical support team I am currently working with.

Neutral

We did the initial setup a while ago and then migrated from on-premise to DX SaaS. That process was relatively easy because we laid the groundwork well. We spent two months preparing ourselves and planning our strategy. Our deployment team includes around eight members offsite and one person on site. 

Resources aren't a constraint. We have had this solution for five years, so we know the process in and out. We have a good team with the experience needed to handle the implementation and provide application support when needed.

It took us around three years to deploy. It's more than simply deploying the agent. The whole goal of an APM in our environment is end-to-end transaction tracing. In the first year, we deployed all the agents. The second phase is end-to-end tracing, but we are unable to activate this for many applications. 

Implementing APM aims to provide added value to the application team and the customer. If you want to show that, you need to have end-to-end visibility. Out-of-the-box end-to-end tracing isn't possible in Broadcom APM. You need to do a lot of configuration and identify missing components during the deployment. 

I don't know the precise cost, but the licensing is based on the number of agents.

I have attended some presales presentations and training sessions for AppDynamics and Dynatrace.

I rate DX SaaS seven out of 10. I have worked on DX APM for many years, and they are lagging behind the leading APM products. Many of the features readily available in other products are not there. At the same time, I am not saying it's a bad product. Every solution has its pain points. By that same token, I can't say Dynatrace is without issues. Unless you spend time working hands-on with a product, everything is theoretical.