TAG | Application Performance Management

Interest in the Application Performance Management (APM) category is very high right now.   To stay one step ahead of their clients, the Industry Analysts who cover the category and write research to advise their clients have been very busy.  In December alone, there were six different analyst reports being researched by the major analyst firms.

Forrester published the results of their research in the 2nd week of December with the report: Market Overview: Application Performance Management, Q4 2011.  Forrester clients can access the report at www.forrester.com. In this report, Forrester provides very sound advice on why APM exists and what it should do for clients. Forrester has created their own “Reference Model” for APM and evaluated the vendor landscape against those criteria.

Raison d’etre for APM

Forrester VP and Principal Analyst, JP Garbani, gives readers very pragmatic advice on the raison d’etre for APM.  Simply put, APM’s job is to:

1) Alert IT to application performance and availability issues before a full-scale outage occurs

2) Isolate or pinpoint the problem source

3) Provide deep-diagnostics to enable IT to determine the root cause

For several years now, JP Garbani has been on the forefront of proclaiming that modern APM solutions should enable IT organizations to manage apps not by gauging the heath of their servers or servlets, but instead by assessing what the customer or end-user cares about most – whether their Business Transaction completes quickly and doesn’t make them wait.  He states that this has become even more critical as applications have gotten more distributed and complex.

Read the Full Post…

Link to this post:

, , , , , , , , , , , , ,

AppDynamics vs CA Wily vs DynaTrace2011 was an amazing year for AppDynamics. We experienced tremendous growth and success, largely down to the many customers around the world who believed in our vision, technology, and ability to help Dev and Ops teams better manage application performance in production. The Application Performance Management (APM) market isn’t an easy market to succeed in, with well over 30 vendors competing against each other. In just three years we’ve managed to take on the big players like Compuware DynaTrace, CA Wily, HP and IBM to change the industry perception that APM is expensive to own and difficult to deploy/use.

We feel APM should be for everyone. It should be affordable, it should be easy to deploy, and easy to use. APM should not be a luxury that only an elite group of enterprises can afford. Today, we have customers who monitor applications with 5 nodes, 50 nodes, 500 nodes and 5,000 nodes. Application performance impacts organizations of all sizes; that’s why we wanted our APM solution to be accessible to the masses over the web via our free download and SaaS trial. We wanted to be transparent with our buyers and demonstrate that they can evaluate and use our solution all by themselves with no account manager or technical consultant by their side. We really wanted prospects to see for themselves that APM can be simple to deploy and easy to use.

A major validation of this market disruption was when a customer called Karavel in France was looking for an APM solution and evaluated CA Wily, Compuware dynaTrace and AppDynamics. Karavel requested a trial, downloaded our software and we sent them a trial license key for 30 days. The whole AppDynamics install, deployment and evaluation was solely conducted by the customer on their own. This might not sound that impressive, but this is what the software buying experience should be all about: the customer and the solution. If the customer can’t install, deploy and evaluate an APM solution on their own, how will they manage this process when it comes to a production deployment? Software should sell itself these days–if it requires an army of people to sell it, it probably requires an army of people to implement it as well.

You can read the full Karavel press release here:
http://www.appdynamics.com/press/press-release-01-03-12.php

Full case study is available here also:
http://www.appdynamics.com/documents/case_studies/AppDynamics_CS_Karavel.pdf

Remember, software like APM doesn’t have to be complex and expensive. With the internet these days, there is no excuse why a prospect can’t download or evaluate solutions online in just a few hours.

App Man.

Link to this post:

, , , , , , , , , , , ,

App Man

The 12 Days of DevOps

12 Days of DevOps

Embed this image on your site:

Link to this post:

, , , , ,

We recently finished conducting our annual Application Performance Management survey. Over 250 IT professionals participated, and they shared insights such as:
- Many Ops and Dev teams are anticipating growth in their applications by 20% or more
- Over 50% are planning to move to the cloud, and are architecting brand-new applications to be cloud-ready
- Most teams are using log files to monitor application performance, rather than an Application Performance Management (APM) tool.

We’ll release the full report soon, but here’s an infographic that summarizes some of the main findings:

AppDynamics Inforgraphic - Storm Clouds in 2012

Embed this image on your site:

What I found personally surprising was the heavy reliance on log files. When you’re troubleshooting distributed architectures, time is of the essence–and there’s no way to cut your MTTR down when you’re relying on log files to identify root cause.

In fact, there’s only one guy who ever made using a log file look cool:

And I think we can all agree that’s a pretty unique use case.

We’ll have the full survey results available soon.

 

 

Link to this post:

, , , , , , , , , , , , , , , , , , , ,

Peter Drucker proclaimed: “If you can’t measure it, you can’t manage it.” Do you know what’s “normal” for your mission-critical application? Actually, wait a second–with Halloween having just finished up,  maybe the following Young Frankenstein reference is more appropriate. Whenever I focus on the word “normal,” the first thing that pops into my head (pardon the pun) is that famous scene from Young Frankenstein:

DR. FREDERICK FRANKENSTEIN: Abby Normal?

IGOR: I’m almost sure that was the name.

DR. FREDERICK FRANKENSTEIN: [chuckles] Are you saying that I put an abnormal brain into a seven and a half foot long, fifty-four inch wide GORILLA?

[grabs Igor and starts throttling him]

DR. FREDERICK FRANKENSTEIN: Is that what you’re telling me?

Read the Full Post…

Link to this post:

, , , , , , , , ,

On Wednesday I delivered a keynote at WJAX in Munich. Everything went really well, but I was a little shocked at the response I got when I asked the audience “How many of you monitor the performance of your apps in production?” As I scanned the audience, I counted 9 out of ~950 developers had put their hands up, meaning about 1% had visibility of how their applications actually performed in production. I know what you’re thinking: “But isn’t application performance in production the responsibility of Operations?”  Well, it is and it isn’t. Most organizations think that when an application has an issue, it’s related to the infrastructure it runs on. That’s like saying when a car crashes, it’s because a part failed on the car whereas in actual fact most accidents are caused by the driver. Yes, hardware fails occasionally, but application logic and configuration drives how infrastructure resource is used, which is why most issues today occur when new code is deployed in production.

Read the Full Post…

Link to this post:

, , , , , , , , , ,

App Man

Just how useful is JMX Monitoring?

I’ve always been a skeptic of JMX monitoring, largely because I felt it was often wrongly positioned as the pillar stone of application monitoring software. An application for me is a collection of business services or transactions that users perform, that causes application logic (code) to request and process data. Without visibility into the performance of business transactions and code execution, JMX monitoring can be seen as just another infrastructure monitoring tool for the JVM. However, when application and JMX monitoring are combined into a single tool, they can offer powerful capabilities for managing application performance.

What is JMX Monitoring?

JMX Monitoring is done by querying data from “Managed Beans” (MBeans) that are exposed via a JVM port (JMX console). An MBean represents a resource running inside a JVM and provides data on the configuration and usage of that resource. MBeans are typically grouped into “domains” to denote where resources belong to. Typically in a JVM you’ll see multiple domains. For example, for an application running on tomcat you’d see “Catalina” and “Java.lang” domains. “Catalina” represents resources and MBeans relating to the Apache Tomcat container, and “Java.lang” represents the same for the JVM run-time (e.g. Hotspot). You might also see custom domains that belong to an application, given how trivial it is to write custom MBeans via the JMX interface.

Read the Full Post…

Link to this post:

, , , , , , ,

Hugh Brien

Software that “Just Works”

This is my first blog.  I’ve been a sales engineer for three application performance management (APM) products over the last 7 years (CA Wily Introscope, SpringSource/Hyperic, and now AppDynamics). I hadn’t really considered myself much of a “blogger” because I have alway thought that actions speak louder than words.  So I guess you are wondering why I would start now.  I guess you could say I was inspired by a recent experience at a customer site. It was quite a bit different than what I’ve been used to in my earlier APM career.

We recently had an experience with a customer who called and inquired about AppDynamics for monitoring several of their mission critical applications. As always our sales team kicked into high gear and had a conversation with the customer.  In less than 15 minutes we  agreed to start a Proof of Concept for AppDynamics running on a critical application.  Later that day, we setup an online conference with the customer and commenced an installation that took about 15 minutes.

Read the Full Post…

Link to this post:

, , , , , , , ,

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.

Read the Full Post…

Link to this post:

, , , , , , , , , , , , , ,

What happens when mission critical Java applications slow down or keep crashing in production? The vast majority of IT Operations (Ops) today bury their heads in log files. Why? because thats what they’ve been doing since IBM invented the mainframe. Diving into the weeds feels good, everyone feels productive looking at log entries, hoping that one will eventually explain the unexplainable. IT Ops may also look at system and network metrics which tell them how server resource and network bandwidth is being consumed. Again, looking at lots of metrics feels good but what is causing those server and network metrics to change in the first place? Answer: the application.

IT Ops monitor the infrastructure that applications run on, but they lack visibility of how applications actually work and utilize the infrastructure. To get this visibility, Ops must monitor the application run-time. A quick way to get started is to use the free tools that come with the application run-time. In the case of Java applications, both JConsole and VisualVM ship with the standard SDK and have proved popular choices for monitoring Java applications. When we built AppDynamics Lite we felt their was a void of free application monitoring solutions for IT Ops, the market had plenty of tools aimed at developers but many were just too verbose and intrusive for IT Ops to use in production. If we take a look at how JConsole, VisualVM and AppDynamics Lite compare, we’ll see just how different free application monitoring solutions can be.

Read the Full Post…

Link to this post:

, , , , , , , , , , ,

<< Latest posts

Older posts >>