There has been a lot of talk amongst vendors and industry experts in the last year about how APM fits in the DevOps philosophy. There have been many claims that because a vendor is easy to install and use, it automatically makes it a solution catered for a DevOps crowd. This cannot be further from the truth. Most vendors provide simple monitoring solutions that alert on performance degradations.
The problem is that to do performance properly in a DevOps setting you have to transition away from monitoring the performance of an application and start managing it –not just in the production environment, but across all phases of the software development and deployment process. DevOps is also about the equal share of application ownership between development, testing and operations teams. In order to share ownership you have to share a common language – a common set of tools and data – that is automated and integrated in your continuous application deployment process. But what does that really look like? Here is our perspective.
Management Requires Collaboration; Monitoring Does Not.
Application Performance Management involves a level of work and commitment that requires development, testing, and operations teams to work together. This is the minimum level of collaboration needed to accomplish the successful launch of an application. Anything less falls under the alternate “M” – Monitoring.
Monitoring fails because it only serves the Operations group and the other two play damage control by reacting to alerts. Most vendors take an approach that assumes collaboration is the sharing of a screen print, a report, or a log file. This offers no detail of the problem(s) other than the limited information contained in an aggregated view. Imagine someone looking at a picture of the Eiffel tower and claiming they have been there because they’ve “seen” it. Would you collaborate with this person in planning your dream vacation to Paris?
In order to have good collaboration you have to have a platform that everyone can agree on and adhere to. The same is true for application performance. Having the same rich data at all levels enables everyone to work together on solving the problem, without questions about the data or needless and time-consuming requests for more information.
Management Requires Expertise; Monitoring Does Not.
The trend in APM right now is to simplify everything. Less clicks, less data, more answers. That makes sense. You want to simplify things like implementation and management. You need automation around the detection of applications and the components that support them. The problem is that some vendors take it to an extreme focusing on a few key use cases. This limits the power to really solve complex problems.
When a vendor claims that they have made it “so easy that you never need help to install or run it “ it means they have limited functionality and can only find the top 3 use cases that most organizations run into. It has been cooked down to offer a big punch for glaring issues but after the fires are put out you are back to simply monitoring until the next fire.
Doing performance management is hard because you have to work with countless unique use cases and needs. Performance management requires having rich data that can be extracted for the diverse needs of different teams. It requires having performance experts who can educate and advise on how to use a performance platform that can integrate with the tools used along the agile development process. This does not mean the management software is difficult to deploy, that should still be easy. It simply means the management software is a part of the process already observed.
Management Prevents Problems; Monitoring Does Not.
Most vendors rattle sabers around trying to find problems in production. They like to claim how easy and simple their tools are by honing in on those common use cases. In doing so they make themselves into what they really are – just another fire extinguisher arriving too late to the blaze. A monitoring tool will only alert you when a fire occurs and the general neighborhood it happened in. They are no different than the predecessors they claim to replace. They are merely an easier design with an ergonomic grip and do nothing innovative save refurbish the previous generation’s fire extinguisher.
To do performance management you have to have a solution in place that is designed from the ground up to help prevent fires and not put them out. In order to do that the platform must not only integrate with the tools used to develop and deploy software but also help integrate into the processes in which they are managed and positioned.
While you can use this platform in production to put out fires you are not limited to the “damage control” approach. After all, you don’t want to be stuck with putting out fires all the time; you want to prevent them from happening. You can build on success and start to reap the long term value of transforming your performance process which will help streamline the progression and maximize efficiency.
So the real question is do you want to monitor your application or do you want to manage it?