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.

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.

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.

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.

ADDM, CMDB, CMS, dependency mapping, discovery, SIS

Unicorns, those magical mythical creatures that many have searched for but never actually found. One of our customers recommended AppDynamics to their associates and compared us to “Unicorns … only real.” This analogy is really great since Enterprises have been searching for “software that just works” but up until recently haven’t been able to find it. So now that we’ve found them, lets talk about 2 awesome Unicorns, AppDynamics and PagerDuty.

Recently we released a couple of blogs about the AppDynamics and PagerDuty integration. If you haven’t had the chance yet you can check them out here and here. I had some time to sit back and really think about what these two companies and our  integration mean to the IT world and I want to share those thoughts with you.

I’m a person that has worked in many sizes of company from really small startups (less than 20 employees) to really large enterprises (more than 250,000 employees) and a few in between. IT support levels vary greatly within these different size organizations. In particular, the ability to detect problems and notify the right people quickly is an issue in the SMB world (at the companies I worked for anyway).

One of the reasons for this problem lies in the costs associated with traditional monitoring and alerting systems. Beyond the up front purchase price there is typically the ongoing configuration and maintenance costs which can drive TCO excruciatingly high in no time. When thinking about SMB, taking into account the high purchase price, high setup cost, and high maintenance costs it’s no wonder very few companies invest in the software they need to monitor and manage their environment properly.

Taking it a step further, it’s a shame that large enterprises have to pay these exorbitant costs and suffer through “Enterprise Class Software” that takes an army of highly paid consultants and/or employees to setup and maintain.

This is why AppDynamics and PagerDuty is a big deal to me. Enterprise quality software that is as easy to use, configure and maintain as consumer software while not sacrificing functionality. This was unheard of 5 years ago. Thankfully, things are changing rapidly for the better. AppDynamics and PageryDuty allow any company to quickly deploy, configure, manage, identify, isolate, alert, troubleshoot, automate, repair, etc… All of this done better than the Enterprise Class products of 5 years ago and at fraction of the TCO.

Specifically, here are a few of the things that are way better when you use AppDynamics and PagerDuty:

Monitoring

• 90% less configuration and management work with better results.
• Isolation of problems down to the node, page, transaction, or line of code level.
• Automatic remediation of known problems.
• Reduced dependency on “The Expert” who actually knows how to set up and use the monitoring tool.

Alerting

• Ability to interface with modern devices (like sending push notifications to iOS and Android)
• Easy to use graphical interface for configuration of advance rules.
• On call scheduling so you don’t have to “pass the pager”. Yep, there are still pagers out there.
• Automated escalation of alerts that have not been responded to yet.

When it comes right down to it we are in a time where software is being re-invented and every company from the biggest to the smallest need to re-evaluate their strategy and take advantage of the amazing tools at their disposal. Here’s your chance to catch a Unicorn, don’t miss out by looking the other direction.

Click here to start your free trial of AppDynamics and catch a Unicorn for yourself.

Alerts, Enterprise APM, enterprise software, pagerduty, unicorns

Today AppDynamics announced integration with PagerDuty, a SaaS-based provider of IT alerting and incident management software that is changing the way IT teams are notified, and how they manage incidents in their mission-critical applications.  By combining AppDynamics’ granular visibility of applications with PagerDuty’s reliable alerting capabilities, customers can make sure the right people are proactively notified when business impact occurs, so IT teams can get their apps back up and running as quickly as possible.

You’ll need a PagerDuty and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of PagerDuty and AppDynamics online.  Once you complete this simple installation, you’ll start receiving incidents in PagerDuty created by AppDynamics out-of-the-box policies.

Alert Storm, Alert Storming, Alerts, apm, APM Integration, APM Thought Leadership, appdynamics, AppDynamics Pro, application, Application Complexity, application monitoring, Application Performance, Application Performance Management, Application Performance Monitoring, incident management, integration, pagerduty, Production Monitoring

It’s been about 12 years since I last scripted in PHP. I pretty much paid my way through college building PHP websites for small companies that wanted a web presence. Back then PHP was the perfect choice, because nearly all the internet service providers had PHP support for free if you registered domain names with them. Java and .NET wasn’t an option for a poor smelly student like me, so I just wrote standard HTML with embedded scriplets of PHP code and bingo–I had dynamic web pages.

Today, 244 million websites run on PHP which is almost 75% of the web. That’s a pretty scary statistic. If only I’d kept coding PHP back when I was 21, I’d be a billionaire by now! PHP is a pretty good example of how open-source technology can go viral and infect millions of developers and organizations world-wide.

Read the Full Post…

apm, APM Thought Leadership, App Man, appdynamics, AppDynamics Pro, application monitoring, Application Performance, Application Performance Management, Application Performance Monitoring, Appman, Enterprise APM, php, Production Monitoring