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

Welcome back to my series on migration to the cloud. In my last post we discussed all of the effort you need to put into the planning phase of your migration. In this post we are going to focus on what should happen directly after the migration has been completed.

Regardless of how well you planned or if you just decided to dive right in without any forethought, there are steps that need to be taken after your migration to ensure your application is working properly and performing up to snuff. These steps need to be performed whether you chose to use a public, private or hybrid cloud implementation.

Step 1: Take Your New Cloud Based Application for a Test Drive

Go easy at first and just roll through the functionality as a user would. If it doesn’t work well for you then you know it wont work well when there are a bunch of users hitting it.

Assuming things went well with your functional test it’s time to go bigger. Lay down a load test and see step 2 below.

Step 2: Monitoring is Not the Job of Your Users

If you’re relying on the users of your application to let you know if there are performance or stability issues you are already a major step behind your competition. If you planned properly then you have a monitoring system in place. If you’re just winging it, put in a monitoring system now!!!

Here are the things your monitoring tool should help you understand:

• Architecture and Flow: You design an application architecture to support the type of application you are building. How do you really know if you have deployed the architecture you designed in the first place? How do you know if your application flow changes over time and causes problems? Cloud computing environments are dynamic and can shift at any given time. You need to have a tool in place that let’s you know exactly what happened, when and if it caused any impact.

What happens if you don’t have a flow map? Simple, when there’s a problem you waste a bunch of time trying to figure out what components were involved in the problematic transaction so that you can isolate the problem to the right component.

• Response Times: Slow sucks! You moved to the cloud for many potential reasons but one thing is certain, your users don’t want your application(s) to run slowly. It seems obvious to monitor the response time of your applications but I’m constantly amazed by how many organizations still don’t have this type of monitoring in place for their applications. There are really only 2 options in this category; let your users tell you when (notice I didn’t say if) your application is slow or have a monitoring tool alert you right away.

• Resources: You need to keep an eye on the resources you are consuming in the cloud. New instances of your application can quickly add up to a large expense if your code is inefficient. You need to understand how well your application scales under load and fix the resource hogs so that you can drive better value out of your application as usage increases.

Step 3: Elasticity

Elasticity is a key benefit of migrating your application to the cloud. Traditional application architectures accounted for periodic spikes in workload by permanently over-allocating resources. Put simply, we used to buy a bunch of servers so that we could handle the monthly or yearly spikes in activity. Most of these servers sat nearly idle the rest of the year and generated heat.

If you’re going to take advantage of the inherent elasticity within your cloud environment you need to understand exactly how your application will respond to being overloaded and how your infrastructure adapts to this condition. Cloud providers have tools to execute the dynamic shift in resources but ultimately you need a tool to detect the trigger conditions and then interface with the dynamic provisioning features of your cloud.

The combination of slow transactions AND resource exhaustion would be a great trigger to spin up new application instances. Each condition on its own does not justify adding a new resource.

The point here is that migrating to the cloud is not a magic bullet. You need to know how to use the features that are available and you need the right tools to help you understand exactly when to use those features. You need to stress your new cloud application to the point of failure and understand how to respond BEFORE you set users free on your application. Your users will certainly break your application and during an event is not the proper time to figure out how to manage your application in the cloud.

Let failure be your guide to success. Fail when it doesn’t matter so that you can success when the pressure is on. The cloud auto-scaling features shown in this post are part of AppDynamics Pro 3.7. Click here to start your free trial today.

Application Elasticity, auto-scaling, cloud architecture, Cloud Migration, Cloud Monitoring

Welcome, let’s start with a quick introduction of who you are and what your role is at PagerDuty.
My name is Alex, I’m PagerDuty’s CEO and co-founder.

And what beer will you be drinking tonight?
Guinness! It’s the office favorite.

What problems does your solution or service solve for customers?
PagerDuty provides centralized, highly-targeted alerting, escalation, and incident management.  We integrate with the monitoring systems you have in place to provide a single place to manage all of your alerting.  When things go down, we wake you up.

What types of technology trends are you seeing within your customer base?
We have a great mix of customers, from large enterprises (we have 15 of the Fortune 100 as customers), to mid-size companies like Splunk, Citrix, and Box, to two-person startups, which gives us an interesting perspective.  The most obvious trend that we’re seeing is companies looking to automate the notification piece of ‘monitoring and alerting’ right off the bat.  With IaaS providers like Rackspace and AWS, the need to do a costly NOC build-out has been almost entirely eliminated.  Folks who do have a NOC in place are looking to automate what they can, while allowing on-site engineers to tackle the problems they’re best equipped to solve.

What application performance pain and challenges do you typically see within customer accounts?
All our customers have mission-critical infrastructure in place, and for many of them, slow applications directly equate to lost revenue.  When company performance depends on applications being available and responsive, having an APM solution deployed isn’t a luxury, it’s a necessity.

Why does partnering with AppDynamics make good sense?
AppDynamics is the enterprise APM solution, and PagerDuty is the enterprise alerting solution.  There couldn’t be a more natural fit – when AppDynamics detects an issue, PagerDuty wakes you up.

What’s your favorite thing about AppDynamics?
The ROI! We’re big believers in actively monitoring revenue-critical production applications. Anything you can deploy and see a 2x, 4x, 10x return, quickly, that’s pretty great in my book.

How can someone find out more about PagerDuty?
Just signup for a free trial at pagerduty.com.  Or just shoot us an email at sales@pagerduty.com and a member of our sales staff will reach out to setup a demo.

Which software companies inspire you?
B2B companies that make something people want and that solves a clear need.  We like companies that can tackle hair on fire problems.  AppDynamics, obviously, and Splunk come to mind.

Who is your favorite super hero and why?
Spiderman.  He’s powerful yet flawed – a real human super hero.

Alert Storming, Alerts, App Man, application monitoring, Application Performance, Application Performance Management, Application Performance Monitoring, Appman, Appman Beers, Beers, Guinness, incident management, pagerduty, startups, technology trends