Skip to Main Content

The challenges of choosing an APM tool

How do you choose an APM tool? You search online and you see there is a lot of choice. But you can only choose one. And it's a big decision. You need to find a tool that can monitor your crown jewel applications. You know that the cost of an APM tool is high. And you know that it's going to be a challenging and lengthy process to implement it.

So how do you choose? Will you go for the pure SaaS approach, seen with New Relic, or will you go for a balance between cloud and on-premise, seen with DynaTrace, or will you choose App Dynamics, with their flavour of AI-powered application mapping? Whichever tool you like the look of, you will need to measure its quality and whether it is the right fit for you. Here are five initial challenges to consider when choosing an APM tool, with relevant comments sourced from G2 Crowd.

Initial Challenges

1. What are the ongoing maintenance requirements for your APM tool? Judge whether you will need to hire any staff to keep your tool in shape. Factor these costs into your budget.

2. What do you think of the User Interface? Test the tool with potential users and ask them if it gives them the information they need at a glance, and if they can easily drill down further when needed.

3. Does the tool have the features you need? Research and test the tool’s features - they will range from the basic recording of server metrics through to the measurement of application dependencies and the mapping of real-time transactions. You will also need to choose a tool which supports the programming language your applications are written in.

4. Can you afford it? Ask for a quote from the main APM players and you will realise the need for a business case before you make the investment. Work out your return on investment – from reduced application downtime through to increased developer productivity.

5. What load will the APM tool place on the applications it monitors? Consider how much data you would like your tool to collect from your application. Evaluate how much processing power it will eat up and decide on your acceptable thresholds.

Once you have chosen a tool for review, you will need to security test it, deploy it and build out the business logic to support it. Let us walk through each of these steps.

Security Testing

You might be looking at a stringent security review process, depending on your application and the type of data it processes. If your application uses credit card information, and you want an APM tool to monitor that application, your APM tool will need to be Payment Card Industry (PCI) compliant. If your APM tool is not compliant, you can face significant fines.

You will also need to check who has access to what data when you test your tool. Do monitoring teams have access to sensitive employee information? Does the tool use third-party extensions which expose your data? Can you set security privileges in the tool to match those in your corporate directory?

Deployment

After you have put the tool through security vetting, you will look to deploy it. To do so, you will face different challenges depending on whether it uses an agent or agentless approach to monitoring. Here are some differences between the two approaches:

An agentless approach may be the cleaner and simpler one. But you will only be able to use it to monitor internal applications – third party applications will not support your changes to their product. So, you may turn to agent-based monitoring. However, your new agents can render your infrastructure vulnerable. And if you are working in an organisation which uses multiple APM tools (as many do), their respective agents can compromise each other. This raises an additional barrier to deploying your new APM tool – what if your team already uses one (or multiple) tools?

If your team already use an APM tool, are you going to turn around and tell them to stop using it? If you replace their existing tools, will you deliver a return on investment which mitigates the cost of change? You may find a solution in asking them to use their existing tool/s solely in a contained environment, but you will lose the ability to display your monitoring data in a single pane of glass.

There are several challenges in deploying an APM tool. IT departments are often aware of this, so they choose to deploy tools to monitor just new applications, and not legacy applications. If you choose to follow this path, you will avoid many of the issues we have discussed. You will be able to set a clear and coherent strategy and build a new team that is not hindered by legacy application issues. You will be able to create clear communication processes for your team and ensure they can access the right monitoring data, at the right time, and in the right place.

Building Business Logic

As you build your team and deploy your tool, you will soon realise that your tool does not work out of the box – at least not in the way your business needs. The tool will be able to map out your application, but it will not understand it in the context of a business service. It will not understand that the key purchase action in your e-commerce application is not when a user reaches the order page, but it is when they click on the ‘confirm order’ button. In a nutshell, your tool will build a map, and you will have to label it. Bob Balaban (stackify source) estimates that your proof of concept for a new APM tool will take at least two months. You will spend a significant part of that time inputting business logic into the tool. You could find that setting up your tool and using it to improve end user experience will be the most difficult challenge you face. TRAC research shows that only 4% of organisations have a 50% or better success rate in identifying issues before they impact users.

Wrapping Up

You have read that there are numerous challenges in choosing and setting up an APM tool. You have a large range of tools to choose from, all with different price points, varied feature sets and maintenance requirements. And you have read that any tool will require security vetting and significant employee time to deploy it and make your monitoring relevant to the end user experience. You may decide that choosing one of the larger tools is not the right decision for you now. You may prefer a modular and more affordable tool, such as Foglight. Or, if you already have Microsoft System Center Operations Manager (SCOM) set up and you think that APM might not be for you, you will find that our Enterprise Application Monitoring (EAM) product will transform your SCOM environment into a tool which will monitor hundreds of your applications. EAM will also save you from many of the problems we have discussed above:

---

Want to read more? Check out our complete guide to APM.

Scott Reis

Related content