AppMan stealthily checking out the crowd at the AppDynamics booth at JavaOne.

It’s pretty amazing working a booth at one of the world’s largest Java conferences as an application monitoring vendor. You get to hear hundreds of opinions on managing java performance, along with stories from users of competing products and their mixed experiences. What was clear from the conversations I had at JavaOne was that customers of legacy monitoring solutions were struggling to get real tangible value from their investments. The same old stories of “It takes too long to configure,” It won’t run in production under peak load,” and “It doesn’t give us deep visibility to solve problems.” Conversations like these presented a real opportunity for us at JavaOne–so much so we’ve already set up several meetings as a result.

I can summarize my JavaOne experiences as blood, sweat, and tears:

Blood:

Here at AppDynamics we try to avoid conflict. Everything we do is about making life easy for our customers. We make it easy to do business with us, easy to use our products, and easy to solve complex problems. We don’t condone violence, but one of our prospective customers made a comment while in our JavaOne booth that we just had to share…

“If our Ops guys don’t buy AppDynamics, I will beat them.”

I hope this is not a literal statement. Still, having worked in a large IT shop fighting application fires…I get it! When you’ve seen how much AppDynamics can help your everyday work life, you should accept no half-baked substitutes.

Sweat:

Prospects from our competitors were out in full force at the AppDynamics booth. We heard the same woeful tales from them over and over again: their application monitoring tools were too hard to use, they took too much effort to deploy, and they didn’t provide the right data to solve problems.

We hear you loud and clear. Deploying APM so that it solves your problems should not be a full time job. Whether your enterprise is one big distributed application or thousands of applications and services, deployment and maintenance of your APM tool should not take significant amounts of time and effort.

Tears:

Really? Crying at JavaOne? Well, almost. Even though our company super hero App Man is big, burly, and has incredible super powers … he also has a sensitive side. Especially when it comes to customers and their impression of our tools. App Man showed off his sensitivity in a tweet after a conversation with one of our users at JavaOne…

“An @AppDynamics lite user just told me he loved my product. I almost cried.”

It’s cool, App Man. It’s okay to cry, especially when it’s for a good reason. I can’t think of a better reason than another happy customer.

If you happened to be at JavaOne and stopped by our booth, we would love to hear from you. Many of you asked us to follow up directly and we are working hard to make that happen. There was quite a frenzy of activity at the AppDynamics booth with people queued 3 deep waiting to speak with us and get a demo of our product. Hopefully we got everyone who wanted to speak with us. If we somehow missed you, please accept our apologies and let us know so that we can make amends.

JavaOne, JavaOne 2012

There’s been a generational shift in how Java enterprise applications are created: they have been broken down from a monolithic architecture into multiple services, and they’re highly interconnected and distributed. How can Java developers and Operations teams adapt to these changes?

This keynote will discuss the 4 Big Things that Java professionals need to design for now:

• Cloud: Most applications built will have some part of its service in the cloud
• Big Data: With the advent of NoSQL, Hadoop, and distributed caches, how should we now approach the data layer?
• Agile Development & Operations: Developers won’t just be responsible for the code, but how it’s deployed. How does that affect the DevOps relationships?
• Failure is an option: Distributed systems won’t just invite but demand failure, so how can failure become part of the initial design?

This talk will present recommended strategies and approaches for these new design imperatives.

You can watch the keynote here

Agile Development, appdynamics, application monitoring, Big Data, cloud, DevOps, Stephen Burton, WJAX, WJAX 2011

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…

apm, Application Performance Management, Introscope JMX, JMX, JMX Metrics, JMX Monitoring, Tomcat JMX, Weblogic JMX

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…

apm, appdynamics lite, application monitoring, Application Performance Management, Free application monitoring, Java Monitoring, JConsole, JVM, JVM Monitoring, Oracle, Oracle Java Monitoring, VisualVM