AppDynamics for ServiceNow: More Metrics, More Power

AppDynamics and ServiceNow have been working together for many years to support our mutual customers. The first version of our alliance (version 1) included the integration of the AppDynamics flow map and application topology into the ServiceNow Configuration Management Database (CMDB). In version 2, we added support for IT operations-specific use cases such as ServiceNow Event Management.

Now we’re unveiling version 3, adding support for ServiceNow Operational Intelligence by integrating metric data seamlessly from AppDynamics. These metrics are delivered via a small integration server called the AppDynamics-ServiceNow Data Sync, which includes a simple web user interface and a new section for metric integration.

The Data Sync uses APIs to pull data from any AppDynamics controller (SaaS or on-premises) and feeds the data to a ServiceNow MID server of your choice. Many of our beta customers have been successfully running this integration on their MID servers for some time. And since this is a small standalone Java application, you can run it anywhere.

In the screenshot below, we’ve highlighted the new section (Metrics Integration) in the left-hand navigation bar:

In this new section, you can create a schedule to import metrics to a specific MID server, as shown below:

You also can import metrics to ServiceNow from your choice of AppDynamics applications. Currently, we provide a default set of metrics including calls per minute, average response time, errors per minute, number of slow calls, number of very slow calls, and number of exceptions. These metrics are shown in ServiceNow views in the Metric Explorer, Event Management or on custom dashboards.

As shown in the screenshots below, metrics are configured for anomaly scoring and alerting based on default or user-defined rules within ServiceNow Operational Intelligence:

We are hard at work planning version 4 of our AppDynamics Service Model Integration. Based on feedback from our customers, we’re focusing on improvements to integration setup and configuration. Our other primary goal is to significantly enhance our CMDB integration and data-import capabilities. The top customer request is for richer data to the CMDB—not just on the application itself, but also on each application component. Our goal is import far more than the minimal component data we bring in today.

We’re working closely with ServiceNow product management to enhance our capabilities and the ServiceNow platform to better support these requirements. We’d like to thank our great customers and ServiceNow, a wonderful partner that works closely with our product management and engineering teams. Please keep the ideas flowing!

Stay tuned for additional details leading up to ServiceNow’s Knowledge 19 conference, where we hope you’ll stop by and chat with our AppDynamics and Cisco reps. We’ll see you in Vegas May 5th through 9th!

This blog may contain product roadmap information of AppDynamics. AppDynamics reserves the right to change any product roadmap information at any time, for any reason and without notice. This information is intended to outline AppDynamics’ general product direction, it is not a guarantee of future product features, and it should not be relied on in making a purchasing decision. The development, release, and timing of any features or functionality described for AppDynamics’ products remains at AppDynamics’ sole discretion. AppDynamics reserves the right to change any planned features at any time before making them generally available as well as never making them generally available.

 

 

Forrester Talks Automation and Application Performance Management

Jean-Pierre (JP) Garbani of the analyst firm Forrester recently wrote a research paper titled “Technology Spotlight: Automate Application Performance Management – Automate Your Incident Management Process With Run Book Automation“. In this paper JP discusses the fact that IT must embrace automation if they are to be successful moving forward. He goes on to describe Run Book Automation (RBA) and how it applies to Application Performance Management (APM).

One of the most interesting parts of the research note is a graphical depiction of the intersection between APM and RBA. While I can’t show that image in this blog post I can say that it is a spot on depiction of how RBA works within AppDynamics. For those who are not familiar, AppDynamics decided to lead the APM industry in a new direction by listening to our customers and making RBA an important and fully integrated part of our product.

If you take nothing else away from this blog post or from JPs research paper you need to understand this key insight… The reason APM based RBA works so much better than traditional RBA is because APM understands exactly which application nodes are impacted at any given time and can perform run book remediation on those nodes without any input from a user.

The Old Way

Traditional RBA requires that you write tests to act as triggers for run book workflows. You would run these tests against pre-defined sets of infrastructure and application components when there is a problem so that your runbooks can fix any known issues. If your application and infrastructure change you need to manually modify the list components that are getting tested. This manual update process has been the downfall of RBA and other technologies (CMDB anyone?) as people have come to realize the time investment required to keep everything current. This problem is amplified by todays dynamic application technologies like virtualization and cloud computing.

Classic RBA Process

Process flow and timeline of classic RBA.

The New Way

Forrester and AppDynamics agree that the answer to the traditional RBA problem described above is by using APM to dynamically track the current state of application and infrastructure components as well as identify problems that trigger run book workflows for resolution. Identification of issues from within the application and in real time is a giant step forward from the pre-determined interval testing of traditional RBA. And when you combine this capability with real time business metrics you get a new capability that enables the business to react immediately to problems that have nothing to do with IT.

APM RBA Process

Process flow and timeline of APM based RBA.

Application run book automation can be used by any organization large or small. If there are issues within your environment that have known fixes then you can use application RBA to automatically detect and remediate those problems within seconds. Stop wasting your time doing repetitive tasks and try AppDynamics for free today. If you’d like to read the Forrester research paper in its entirety you can download it for free by clicking here.

The Poor Misguided CMDB

It’s not an exciting or glamorous subject but it’s an absolutely critical concept for properly managing your applications and infrastructure. CMDB, CMS, SIS, EIEIO (joking) or anything else you want to call it these days is a concept that has been poorly implemented from the very beginning. The concept itself is sound; have a single source of truth that describes your application and infrastructure environments to enable IT operations efficiency (at least that’s the core concept in my mind).

CMDB’s are Awesome, but Not Really

Back in the my days working for global financial services institutions I relied heavily on the CMDB as a starting point for many different activities. I say it was only a starting point because invariably the information within the CMDB was wrong. It was either originally input wrong, not updated regularly enough, or updated with incorrect information. No matter what the real cause, my single source of truth became a partial source of truth that always required extensive verification. Not very efficient!

This is how a traditional CMDB represents component relationships.

This is how a traditional CMDB represents component relationships.

Getting back to my reliance upon the CMDB… Here are the types of activities that required me to query the CMDB:

  • Change controls – Anytime I needed to change anything on a production server I needed to understand what applications had components existing on that server.
  • Application upgrades – I needed to know all of the application components at that exact moment to make sure they all got the update.
  • Application migrations – There were times when we simply needed to move the application from one data center to another. This required a complete understanding of all application components, flows, and dependencies.
  • Performance troubleshooting – When I was asked to get involved with a performance problem, one of the first things I wanted to understand was all of the components that made up the application and any external dependencies.

There are many more uses for the data in the CMDB but those were my top use cases. As I said before, invariably the CMDB was wrong. There were usually components missing from the CMDB, and components in the CMDB that were no longer part of the application, and incorrect dependencies, and, and , and…

Salvation by Auto Discovery and Dependency Mapping, but Not Really

So what’s a good IT department supposed to do about this problem? Buy a discovery and dependency mapping tool of course. And that’s exactly what we did. We explored the market and brought in the best (relative) tool for the job. It was one of those agentless tools that makes deployment way faster and easier in a large enterprise like mine was. The problem, as I would later realize, is that agentless discovery tools only see what’s going on when they login and scan the host. Under normal conditions you can scan your environment maybe once or twice a day without completely overwhelming the tool. What that means is that all of those transient (short lived) services calls into or out of each application are misses by the discovery tool unless they happen to be running at nearly the exact time of the scan.

Discovery and dependency mapping tools did a better job at maintaining and visualizing relationships but still fell short.

Discovery and dependency mapping tools did a better job at maintaining and visualizing relationships but still fell short.

To add further insult to injury, most organizations don’t want a bunch of scanning activity going on during heavy business hours so the scans are typically relegated to the middle of the night when there is little or no load on the applications that are being scanned. This amplifies the transient communication dependency mapping problem. Now the vendors who sell these solutions will claim that there are ways to deal with this issue if you just use their network sniffer in conjunction with their agentless appliance. I won’t comment much on this but I will say that this creates another slew of deployment problems from a political and technical perspective and the thought of every trying it again makes me wince in pain. (Where did I put my therapists phone number again?)

The Application Knows, Really It Does

What better source of understanding application components and dependencies is there than the application itself? Let’s explore this for a moment. If you can live inside of the application and see all of the socket connections opening and closing then you absolutely know what else the application is communicating with. Imagine if there was a system that could automatically see all of these connection that open and close at any given time and draw a picture of the application and all of it’s dependencies at that exact moment in time or any point in the past. And imagine if this system had a published API that allowed your other systems to query it for this information. Regardless of transient or persistent connection types, you would have the ability to know all of the components of your application and all of its external dependencies. This is exactly what AppDynamics does out of the box.

Application Dependency Map

Discovery of application components and dependencies from within the application, in real time, provides the most accurate information possible.

I believe that the CMDB of old should be an ecosystem of information points that provide the truth at the moment it is requested. Forrester calls this a SIS (service information system) in their research paper titled “Reinvent The Obsolete But Necessary CMDB”. Click here to read it if you’re interested. The SIS isn’t some vendor tool, instead it’s an architectural construct that should be different for each company based upon their tools and requirements. From my perspective it is incredibly difficult and inefficient to manage a datacenter or group of applications without implementing this type of concept.

If you’ve already got AppDynamics deployed, consider using it as a significant source of truth about your applications. If you’re stuck with an outdated CMDB, consider shifting your architecture and check out how AppDynamics can help with a free trial.