Splunk AppDynamics Reviews

We have a complex application. We do payments which are highly transactional in nature. With different kinds of workloads that you see in the production environment, how do you really track down specific issues which your lab testing environment can't really reproduce? Your production environment gives you certain workloads, which basically enable you to look at your application more closely. No lab test could really simulate that sort of a load. APM really helps us in getting down to the bottom of these sorts of workloads; how code responds to these sorts of workloads and how we can make our application deliver better latency and a better end-user experience.

Given an extremely transactional, highly complex workload, you just cannot use your testing lab to stress all of your code parts. First of all, it has made us very agile. What happens is, now, you can actually take any one of your deployments or releases, roll it out into production into a very limited set of servers, look at how the APM works, and it gives you insights onto the how the code that you just pushed out is performing.

If everything is fine over a period of a few minutes or a few hours, you can actually roll your deployment out very quickly. You don't have to have an extremely complicated test harness in your preproduction environment. You don't have to go through extensive testing cycles before releasing something into production. It really makes us agile in terms of releasing to market quicker.

For me, the single largest area with room for improvement that I've been requesting the AppDynamics team to deliver for us is APM support for Ruby on Rails and for HHPM. These are the two language environments that we use quite heavily in production. That's something that I'd like to see support for.

Stability depends on the configuration. We work very closely with our solution architects, with AppDynamics, because there's always this question in the minds of consumers: A tool which can do so much as AppDynamics, how do you ensure that it runs with minimal overhead? You've really got to work with the AppDynamics team to size out your environments; that makes it stable for you. That's been our experience.

I can't comment on scalability because our infra is fairly small. We have a total of around 150 nodes that we could probably end up instrumenting. Right now, we do far less than that, so I can't really comment.

Technical support has been pretty good. In our case, we use a few programming languages which are still not supported by AppDynamics, so we've reached out to them to help us with road map information. They've been pretty transparent about when support could get rolled out to these sorts of languages that we use.

For the more run-of-the-mill sort of tickets, where we have issues with the configuration or using the product, it's been pretty good. We've liked our experience with the tech support team.

We had been using a mix of proprietary tools that we developed in house, along with third-party solutions. We were able to get the job done, no doubt about that, but the problem is never having an integrated view of how your application performs. We have uptime alerting running differently; we have business KPI monitoring being done differently; and we have end-user behavior being tracked differently. It was very hard to find a correlated view across all of these four. To debug specific sessions or to debug specific instances, I think that's where AppDynamics really comes in. The integrated view that it gives of your application.

I was not directly involved in the initial setup but my team was. It's pretty straightforward. I think it's really important that whoever is setting up the application first fundamentally understands what the application does. I think that's critical. The tool is fairly complex and powerful. The setup needs to be handled by someone who, on this side, really knows what the application being monitored can do. If you put a rookie on the job, it's going to be really tough.

We did consider other vendors. We were looking at New Relic. As a developer and as someone who builds and has a team who builds stuff, I feel New Relic is actually a very powerful option. However, as I mentioned, we wanted something that could work on-premise.

We went with AppDynamics because we are in the payments industry and from a compliance perspective, we needed an on-premise solution and AppDynamics was, I think, the best solution that also worked on-premise.

In general, the most important criteria when selecting a vendor like AppDynamics for us is, first of all, from the product perspective. As I mentioned, we had a mix of various proprietary and third-party solutions that we were using earlier. We needed a product that could provide end-to-end visibility into the infrastructure and the application. That was a high priority for us. Beyond that, what we really needed was a global presence with enough strong local support. That was something that AppDynamics brought to the table.

Make use of all of the training material and the university. There's some really useful information in there. Also, the two other things that I’ve mentioned elsewhere:

• Ensure the person who is deploying AppDynamics in your environment is among the top-most performers of your team, someone who knows your application in and out.
• Combine that with good, strong consultation by the AppDynamics team. Get these two in place and you've got a winner on your hands.

The reason why I have not rated it higher is the lack of support for HHPM and Ruby; bring them both and I would rate it higher.