Why Today's APM Solutions Aren't Optimized for DevOps
July 21, 2014

Denis Goodwin
SmartBear

In my previous blog, Two APM Takeaways from Velocity Santa Clara 2014, I talked about fragmentation of solutions as a major trend in the APM space. Most vendors are providing a singular solution for some part of performance management, but yet, very few are able to provide a unified solution. In this post I want to extend this discussion to focus on what this means for DevOps.

I believe the lack of solution unification is an epidemic in the tech industry. Something that particularly stands out is that while more and more organizations are beginning to adopt the DevOps model by embracing continuous integration and collaboration, when it comes to the APM market serving these folks, some fundamental ideals of DevOps are thrown out the window — namely, the efficiency and collaboration aspects.

The Fragmentation of Tools is the Fragmentation of Teams

In the ever expanding vortex of value propositions and fragmented solutions that make up the APM market today, simplicity is getting lost. Everyone is so busy fighting to get or stay in the picture that they forget to take a step back to look at the big picture, and realize that all we are doing is collectively building an incomplete solution model. If it feels as though you are trying to integrate solutions that never were meant to integrate in the first place, it's because they weren't. And if the tools are disconnected, the teams that use them are much more likely to be disconnected as well. Or at least, not as connected as they could be.

When something breaks or a bug makes it into production, development and operations like to play hot potato with the blame — until everyone eventually tires and points their fingers at whichever one of their tools is most suspect for having failed them this time. However, the issue is often not the tool's fault either — the fault is shared by the assembly of tools that are collectively failing to support and encourage developers and operations to work together and collaborate.

Wait, Isn't DevOps About Efficiency?

It's natural to fix something after it breaks, but we are often not as good as we want to be at setting up prevention mechanisms to stop the issues from ever happening in the first place — perhaps if this weren't the case, APM vendors would have been building unified solutions from day one. This leads to businesses buying new tools for each part of a larger mission in order to alleviate some previous mishap and prevent it from happening again. The worst part is that by doing so you often can end up creating a much larger problem for yourself in the long term, as a result of opting for the quick fix in order to step around a small one in the short term.

Businesses are using an arsenal of tools that integrate (or don't integrate) with each other in attempt to assemble a complete APM solution. And then you have a whole other assorted toolbox for things like code review, functional testing, API testing and load testing for maintaining quality and superior user experience while continuously delivering applications. While these different solutions may be used by different functions, they are still all part of a single process. The more these silos are broken down in the future the more fluent and efficient that process will be.

Unified APM = DevOps

Perhaps the best approach is not about finding and filling the gaps with more and more tools as problems arise, and instead starting from square one with a single, unified platform for DevOps — one which fully supports collaboration between dev and ops, and enables ultimate efficiency by eliminating the need for added complexity and integrations.

The idea of eliminating the amount of time and energy spent evaluating, integrating and implementing all of these different tools makes the idea of unification worthwhile in itself, but of course this would only be the tip of the iceberg in terms of value.

In order to fully embrace the culture of DevOps and continuous integration, the tools that teams use need to support their fundamental principles and not dangle one leg over the fence. The days of patching a different piece of software onto every different part of the process are numbered.

Denis Goodwin is Director of Product Management, APM, AlertSite UXM, SmartBear Software.

The Latest

March 23, 2017

Mature development organizations ensure automated security is woven into their DevOps practice, early, everywhere, and at scale, according to Sonatype's 2017 DevSecOps Community Survey ...

March 21, 2017

When it comes to food, we all know what's considered "good" and what's "bad". We can all understand this simple rule when eating. But for many, when it comes to software development, simple rules and advice from nutritional labels aren't always there for us ...

March 20, 2017

Monitoring and understanding what software is really doing, and maintaining good levels of software quality is increasingly important to software vendors today. Even a minor bug is capable of shutting down whole systems, and there is a real risk that development cycle pressure competes with quality assurance best practices ...

March 16, 2017

More than half (54 percent) of IT professionals surveyed indicate they have no access to self-service infrastructure, according to a new DevOps survey of 2,000 IT industry executives by Quali.This means that more than half of respondents take a ticket-based approach to infrastructure delivery, impacting productivity and increasing time to market ...

March 15, 2017

Driven by the adoption of cloud and modernization of application architectures, DevOps practices are fast gaining ground in companies that are interested in moving fast – with software eating everything - between "write code and throw it across the wall" to creating more pragmatic mechanisms that induce and maintain operational rigor. The intent behind DevOps (and DevSecOps) is quite noble and excellent in theory. Where it breaks down is in practice ...

March 13, 2017

There might be many people across organizations who claim that they’re using a DevOps approach, but often times, the “best practices” they’re using don’t align with DevOps methodologies. They can say what they do is “DevOps”, but what we’ve found is that many are actually not following basic agile methodology principles, and that’s not DevOps ...

March 09, 2017

The velocity and complexity of software delivery continues to increase as businesses adapt to new economic conditions. Optimizing and automating your deployment pipelines will dramatically reduce your lead times and enable you to deliver software faster and with better quality. Here are three more most common areas that generate the longest lead times ...

March 08, 2017

Every enterprise IT organization is unique in that it will have different bottlenecks and constraints in its deployment pipelines. With that being said, there are some common problem areas that typically produce the longest lead times in your software delivery process. Here are the most common areas that generate the longest lead times ...

March 06, 2017

The findings of an independent survey of IT leaders, application developers and database administrators, conducted by IDG Research for Datical, indicate that database administrators are unable to keep up with the pace and frequency of database changes caused by the accelerated pace of application releases, thus creating a bottleneck and delaying digital transformation initiatives. An overwhelming number of databases administrators (91 percent) and application development managers (90 percent) cited database updates as the cause for application release delays ...

March 02, 2017

A "Boost Caboose" is a secondary engine pulled on a trailer for the explicit purpose of increasing the output of the primary engine. In many ways, DevOps is its own form of Boost Caboose for application of agile methodologies within the modern software factory and SDLC/ADLC processes ...

Share this