AppDynamics the World Leader in APM and DevOps

AppDynamics Blog

Subscribe to AppDynamics Blog: eMailAlertsEmail Alerts
Get AppDynamics Blog via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine, Java Developer Magazine, DevOps Journal

DevOpsJournal: Blog Feed Post

Not Everyone Is an Application Expert

The majority of us in IT are specialists

The majority of us in IT are specialists, with the exception of a few VP 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. Thats 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. Whilst 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 journey’s they’ll always be looking at the response times of infrastructure silo’s. 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. Its 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. Its 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 its 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 Operations aren’t application experts, 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 shelf ware. 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, 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, 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, its free for 30 days and you’ll soon see why next generation application monitoring doesn’t rely on experts.

Read the original blog entry...

More Stories By AppDynamics Blog

In high-production environments where release cycles are measured in hours or minutes — not days or weeks — there's little room for mistakes and no room for confusion. Everyone has to understand what's happening, in real time, and have the means to do whatever is necessary to keep applications up and running optimally.

DevOps is a high-stakes world, but done well, it delivers the agility and performance to significantly impact business competitiveness.