Tip:
Highlight text to annotate it
X
Hi, I'm Bill Alderson. Hey, thank you for joining us for the Essential Building Blocks
to Performance Management. I'd like to talk to you today about part two, Decision Support
Metrics. Now, you have an infrastructure and you've got a lot of different SLAs. You've
got a lot of different things going on. You've got a lot of different metrics.
Out there you've got all of your various silos. You know how I like to talk about silos. You've
got your desktop. You've got your network. You've got your security. You've got your
platform, you've got your application, you've got your data base, right? You've got all
of these different silos. They all have metrics, they've got metrics and they're all delivering
metrics. They've all got SLAs, and they're all trying to do their best. They've got number,
and most of the times their numbers are looking pretty good. Right?
Okay, and then you've got end users out here, who are going across switches and routers
and firewalls and load balancers and WIN optimizers, you name it, you've got a lot of gizmos and
gadgets in between. Then you have a web server, and you've got a data base server, maybe an
app server up here. You've got a lot of technology between the client and the server.
So, first of all, my part one was on “architecture ownership”. Well, how can you design a performance
management monitoring system if you don't know where your test points are, right? How
are you going to find the test points along the way to put your network monitoring and
stuff? If you don't design this, I can assure you that the provider of millions of dollars
worth of network management and performance management tools. They'll come in, oh, yeah,
check the box; it's installed. Yeah, we installed it. But is it installed according to your
needs, your demands, your issues, your particular environment's needs. That's what we're trying
to accomplish here, decision support metrics. These metrics on all these dissimilar systems
should be somewhat, just like we have consolidated documentation, we should have some consolidated
metrics that help you see the end-to-end picture and the end-to-end performance of your infrastructure.
SNMP will help you found out, Okay, SNMP will say, “Okay, this circuit is overloaded or
this has too much memory or not enough memory.” It will give you status information about
a component. It doesn't give you performance information, it just tells you that there
is a problem. It tells you how much goes in, goes out of a port. But it doesn't tell you
what the end user is experiencing with that. No, you need performance management capabilities.
Well, before you can do performance management on your environment, things like Netflow.
Netflow will allow you to find out and use the routers as probes to determine how much
traffic for given applications are going through a particular circuit, and which users are
going through. It will give you rate and volume information. Netflow is a great capability.
You do have to know where you need to gather the information. That's why “architectural
ownership” is essential, prior to being able to put in a sophisticated performance
management capability, you have to know where your test points are, test point one, test
point two, test point three.
Just like on the old printed circuit boards that you had to troubleshoot. You went and
you read a voltage or you, you know, at a certain point or you looked a wave form at
test point one, test point two, test point three. Your enterprise network and application
delivery mechanism is the same sort of thing. Today you make up your own environment, you
integrate all these dissimilar tools and systems and configure them all differently. No two
environments are ever the same. It's like a fingerprint.
Just like your architecture is a fingerprint of your organization and your history and
your evolution of technology, also your decision support metrics, the metrics that you gather
from all your various silos, that you gather on user performance and that sort of thing.
All of those things are building blocks to have an effective application performance
management system, so that you know when a user out here is experiencing trouble.
You have your equipment, and you put it in there, so you have it documented. You have
all your silos reporting up, and then you have a consolidated view, perhaps a weekly
view, a weekly report that pulls all these things together so that you can see what the
users are getting out of your performance. In my opinion it's not enough to just have
these systems up and running in your environment.
What's really important is that they are delivering what I call “decision support reports”,
that help management understand where the bottlenecks are, because it's incredibly important
when you take a look at your portfolio spending. All the money that you're spending on all
the various projects that you've got going on, whether it's applications or refreshes
of desktops or refreshes of network or platform, all those initiatives require understanding
of what your baseline is and your metrics are so that you can quantify the improvements
that you're achieving from those improvement.
So it's not enough just to have them configured and installed, but you should get a weekly
report that helps you start to see the ebb and flow of your environment. There's a good
reason for that, because more and more today we're moving our stuff out where? Out to the
cloud. Well, we're moving and consolidating data centers, so we're going to move this
over to a new data center.
Well, how much traffic typically goes between here and here? How much traffic is then going
to go between here and here? If we have a problem out in the cloud, who's going to capture
packets for us to do performance analysis? Are your applications embedding packet capture
capability, so that in the event, yes, in the event that something does go wrong, all
of those problems are not hidden inside someone else' s cloud of architecture, clouded essentially
from your view.
You just have to keep paying more and more for processing resources because really, if
you had a packet capture capability and you could do performance analysis on that particular
segment, you might be able to do root cause analysis, find out what the problem is, and
mitigate it. But not if it's hidden. So that's my message, decision support metrics in the
cloud, in your data centers. If you're going to move your components around, you're going
to need to know the baseline. How many packets are we sending? How much volume of data?
So if we're going to pick up components of our architecture and move them somewhere else,
we need to know the end before we begin. So that we don't move everything out there a
great expense and a large long window, and then find out after we move it that it makes
our applications non-viable to the end users, because it's just too slow or doesn't have
the features that they were looking for to support the business or the mission.
Decision support metrics, what should they do? They should help you prioritize your portfolio
spending, they should give you ROI on what you spent, and you've got this improvement.
So if you know that it takes one second to get up to here and back, and it takes four
seconds to get from here to here, and three seconds to get from here to here, and eight
seconds to get from here to here, which part of your architecture if you add those all
up and get about 23 seconds of latency on a given click transaction that may be good
enough for you; it may not. It depends upon how many of those transactions you have to
do and the value of each one of those transactions. So if you make $100,000 with each one of those
23 second clicks, it's probably not bad, but if you have to do 50 of them to make $0.50,
it's going to take a long time. It's going to be consuming.
So knowing what your latency and what your response times are at different parts of your
architecture and what different dependencies are contributing to your latency. If you know
those ahead of time, it helps you prioritize and pinpoint where you're going to spend the
money. So that your portfolio spending is with pinpoint precision. That's what we're
talking about when we talk about “decision support metrics.” Decision support, the
metrics that offer you information so that you can prioritize your portfolio spending
and optimize your environment.
It's been nice talking to you. I've got several more issues to talk about in the portfolio
of building block essentials for network performance management. And I hope you stay tuned. I appreciate
you dialing in.