The majority of us in IT are specialists, with the exception of a few VPs of engineering who are “special” in their own “special” world of being “special.” What I mean by this is that no single person has the skills or experience to do everything well in IT. IT is too big for me to explain or summarize in a few words, other than it requires a lot of different people with different skills to make it tick along. Despite applications being the living breathing entities of the business, a large portion of folk in IT have little context of how applications are built, how they execute, and how they consume resource across the IT infrastructure. Many people simply don’t care as their responsibilities are completely void of anything application related. That’s fine–but the reality is that everyone in IT should have one eye on the business. The whole reason IT exists is so the business can be more competitive and make more money. If this happens, IT gets more budget and is allowed to innovate more. IT and the business need each other to survive, which is why when applications slow down or break, both parties bitch at each other.
Operations need better visibility
Unfortunately for both the business and IT, the people (Operations) who manage the performance and availability of applications in production aren’t application experts. They are also not stupid either; their skills sets are wide and broad across many technologies and platforms that underpin applications. They manage a lot of things that application developers take for granted, like networks, databases, storage and virtualization. While Operations monitor the health of these infrastructure components, they often get bombarded with crap from the business when end users and business transactions are being impacted by slow performance, despite all system monitoring showing everything is fine. This lack of understanding between the Business and Operations is because both parties see things from different perspectives.
Operations doesn’t have the application or business context to pinpoint end users issues with current monitoring software. I know this because I sat in on a DevOps session a few months back and listened to many frustrated Ops folk who stated their lack of visibility/evidence in defending their position to the business when applications were experiencing issues. Simply put, monitoring the infrastructure won’t tell you why the business is slow. The business and its user transactions flow across the infrastructure; the collection of multiple hops across this infrastructure is where response time is accumulated. Unless Operations can see these individual journeys, they’ll always be looking at the response times of infrastructure silos. For example, the average response time of a database server might be 300ms. However, if a user’s business transaction makes 100 calls to the database, then that accumulated response time of going backwards and forwards to the database is hidden from the Operations user. It’s the difference of 300 ms (OK) and 30 seconds (Not OK) when you look at performance from a business transaction and infrastructure silo perspective.
Business Transaction Centric Monitoring
The good news for Operations is that many monitoring solutions now exist to provide this missing business context and visibility. It’s now possible to see how business transactions flow end to end across the IT infrastructure, along with respective response times for each hop and the application components being invoked. So now, when an application slows down, Operations have the evidence to report back to the business why an end users transaction was slow. They also have enough evidence to report back to development and point out which application release and component was responsible. This new visibility might sound like ground breaking stuff or marketing BS, but it’s actually what next generation monitoring vendors like AppDynamics are providing. A key problem today is that most legacy application monitoring solutions require an application expert to configure them, so that business transactions can be defined, service level thresholds can be set, alerts configured and code instrumentation tweaked, all so Operations get the application and business visibility they need.
This all sounds great, apart from the fact that Operations aren’t application experts, and as a result they have no context or understanding of what makes up a business transaction. They also didn’t write the application code, so they don’t know which application components are relevant for monitoring. It’s almost like asking a general practitioner (GP) to perform heart surgery. Sure, they’re medically qualified in the same domain as surgeons, but they have no expertise in how to cut people open. Many application monitoring solutions today offer powerful visibility, but they are only as smart as the user that configures them, which is why most application monitoring solutions add little value and rapidly become shelfware. As Operations push more and more agile releases to production, application code continually changes–which means most application monitoring configuration quickly becomes out of date. I also believe this is why the first generation of Application Performance Management toolsets failed.
We at AppDynamics feel that IT shouldn’t need application experts to configure monitoring solutions. Operations and development both want to be agile, but they simply don’t have the time or patience to continually configure the monitors that monitor their applications and business. Monitoring these days should be smart, and tools should be able to auto-discover business transactions, appropriate thresholds and instrument application code. They should solve application complexity rather than create it. If you’re evaluating application performance management or application monitoring for production you might want to check whether they require configuration, application experts or consultants. I’d also check with your in-house application experts, as I’m sure they’ve got better things to be doing than telling a monitoring solution what to monitor. If you’d prefer not to have those conversations, then simply request a trial of AppDynamics Pro. It’s free for 30 days and you’ll soon see why next generation application monitoring doesn’t rely on experts.