[upbeat music]
>>Hello everyone, welcome to today's session.
We're talking about the complexity
of modern infrastructure monitoring.
I'm SolarWinds Head Geek, Patrick Hubbard,
and joining me, of course most of you probably
already know from the THWACK, Adam Hert.
Adam, how you doing?
>>Hey, doing great. I'm excited to be here
and talk about some infrastructure monitoring.
>>Yeah, it's really interesting you know,
you are a Senior Product Manager for
application performance monitoring at SolarWinds,
>>Right. >>But you sort of come to this
from the pure application side,
but from the cloud, right?
>>It's funny, I've done the opposite
of what most people have done.
So I really started in the cloud,
started with that kind of the modern application piece,
and now I'm also the product manager for
Server & Application Monitor and really helping
people manage both their on-premises applications
and infrastructure and kind of help them
on that journey as well to the cloud.
>>What I love about that history is that you started
really with pure applications, right?
The point of cloud is there is no infrastructure.
And they've discovered that infrastructure
is really important and most of SolarWinds
customers are actually hybrid.
I mean, you hear vendors talk about hybrid all the time
and I mean, we certainly do too,
but they have ended up with these applications
which have components, which are on-prem,
or maybe they're in another data center
or maybe they're integrated SaaS solutions.
And so you're sort of walking
down from pure application in the cloud,
into the infrastructure that actually represents
what most of our customers are operating.
>>That's right, and you know what?
Both infrastructure and hybrid infrastructure
means different things to different people, right?
If you talk about infrastructure
on-premises, it's pretty cut and dry, right?
You've got your hardware, you've got your virtual machines,
got your databases and that stuff.
And then if you move to the cloud
and suddenly you're using Lambda,
is that infrastructure?
Is that an application?
What is that, Right?
It means different things to different people
and some companies, that is infrastructure
and suddenly the infrastructure team needs to own
this new Lambda thing
and they have to monitor the performance of it.
>>Yeah, I'd argue that is modern infrastructure.
I think we always did it before
from the hardware perspective.
And there was a neat stack and there was a rack
and it had all, as you were mentioning before,
all of the components are right there,
you had root access to it all.
And increasingly it's sort of fanning out
into all of these components.
Let's pull up a diagram here of a typical application.
And I mean, you can see right here,
if you were used to traditional application monitoring,
Where you've got access
to the components this is wildly different.
>>It for sure it's changing and you know what,
we often talk about hybrid IT
and I think you brought it up earlier.
And when we think about hybrid IT
like the simplest solution to it is,
Oh, that means you have some on-premises hardware,
and then you've got something in the cloud, right?
But what is that something?
I mean, if you've just got a virtual machine
in the cloud, great.
You could monitor these things pretty much the same, right?
They're pretty similar, some small variances,
but it's really much more of kind of a journey
and a spectrum of hybrid IT of,
Hey, do you have a couple of things on-premises?
And then suddenly do you have Kubernetes
in the cloud and do you have Lambda
and all this stuff and suddenly
hybrid IT is very complicated.
>>Right, I mean, what I loved about this diagram, right?
Is you have all the application components
that are cloud-based, but you've also
you can see the application components that are on-prem and
you're looking at express routes and you're looking at VPN
connectivity and BGP and all of the other layers
that are a part of that.
And so, I think a lot of us
sort of come from, I mean, certainly me,
I sort of start with the network and then I layer on
application components after that.
But when application components are a service,
then those dependencies for infrastructure actually become
more important not less.
Maybe there were a whole lot of vendors
that sort of wave their hands at it and said,
Oh, you'll survive hybrid. Don't worry about it.
It'll be fine
but that's not something we bought, right?
That's something that's been sort of forced on us in order
to bolt these things together.
But its not a lot of maturity
that makes it automatically snap together.
So, I think that's the thing that's
different right now is we're at a period where we,
as monitoring experts are supposed to be able to understand
how to knit it all into something usable.
And that's not always really clear.
>>And I think, you know, it's good to kind of look at
kind of the the two ends of the spectrum here
and kind of look at the journey of hybrid IT
and how you can monitor these things
and the problems that you'll face.
And if we start with, you know,
you've got an application running on-premises,
it's maybe just on a single host,
the things that you care about is,
Hey, is that host up?
You actually care about the hardware, like is a fan running?
What's the temperature of that machine?
You know, am I running out of memory and stuff like that.
And then--
>>PSU's okay, data stigs okay.
>>For sure. And then if you think about the far extreme end,
and you've got a serverless Lambda function running,
like, it's totally different.
You don't have a CPU.
You don't have really memory that
you'd need to care about quite as much.
There's certainly no fans that you can manage.
So, I've kind of talked through some of the stuff that goes
from the old hardware on-premises
to the Lambda function in the cloud,
there's kind of challenges and different things
you need to watch for along the way.
>>Well, and then there's those other things, right?
Like, let's say that application maybe was,
we wont say transformed, but let's say modernized, right?
So maybe something that had been in a MySQL database
or SQL database for a long time has been
deconstructed into something now
with no SQL document
database type data. >>Yeah
And if you're a database administrator,
it's still the same data,
the application is still accessing the same data,
but now it's a completely different specialty
and it's a little bit different in monitoring.
So, walk us through really the difference between a
monolithic application and a cloud application.
>>For sure, so let's start with
Server & Application Monitor, right?
So, when you're using Server & Application Monitor
and you're monitoring infrastructure that's on-premises,
one of the key things there is
your infrastructure is fairly static, right?
So we've got dashboards that show you,
Hey, is a node up or down, right?
That your starting point of, you know,
is my infrastructure alive, and then on top of that
we put the applications and these are often,
off-the-shelf applications.
We've got things like SharePoint
if you're running that there.
And different, yeah, these off-the-shelf applications
that you're running and we'll pull metrics out of those.
So you can see, Hey, is this up?
Is it available? Is it performing well?
And we're really kind of monitoring these at an entity basis
and we're kind of storing that information.
And one of the differences when we go to the cloud,
and when we're looking at AppOptics very much designed
for things that are more ephemeral.
When you're in the cloud,
if there's a problem with a virtual machine,
you click a button,
you blow it away and you create a new one, right?
So cloud monitoring if that is there,
is kind of not as appropriate because these things
kind of come and go.
Maybe you have automatic load balancing and an auto-scaling
where these things are just going to come and go by the
hour and sometimes even in a few minutes.
>>Well, and in this example here,
If you're using SAM,
you can do a decent amount of cloud monitoring directly from
Server & Application Monitor.
But the thing that is different
and sort of, as you're describing,
like you start with the application.
If you're monitoring applications
is you're starting with applications,
and then you push down into the infrastructure, right?
You're trying to look at resource consumption for the
platforms that are providing those application services.
So that might be the hypervisors and clusters
and VMware instances, or it might be,
if you're running Nutanix, it might be, you know,
more visibility into HCI because you actually care
about the physical assets that you own,
that you manage because they're
having a material effect on the
performance of the application.
So you start to start with the application definition,
and then you're gonna push down
into the physical infrastructure.
But if you're talking about Kubernetes or containers,
that really is a part of it.
So, is that kind of where that switch is to combining
AppOptics with Server & Application Monitoring?
>>It's a great pivot point. And we should,
I think probably for a lot of people listening to this call,
they probably heard Kubernetes in their organization
and probably not super excited about it, right?
>>No, no, it's magical, [laughs] it's everything.
You just, put a little Kubernetes on it.
It's gonna be fine.
>>That's certainly how it's sold.
But for the, the infrastructure,
people that actually have to manage this stuff,
now you have to learn Kubernetes
and you have to learn how to monitor it.
So, really at its outset,
you have a Kubernetes cluster,
which runs, can be on serverless in managed places,
but often it's still running on infrastructure
and this could be in the cloud space.
So you're still running VMs and you have to monitor those.
If you're the infrastructure guy,
you guys still have to monitor the CPU
and those things like you normally would.
And actually, if we take a look at a dashboard in
AppOptics, we can go a little bit deeper than that,
cause there are some things that are important.
When you're building out applications in Kubernetes.
You have your cluster, which is a bunch of machines
that are running a Kubernetes all at once.
And those machines are called Nodes in Kubernetes.
They just chose a new name, but they're called Nodes.
And then on top of the Nodes,
you run things that are called Pods,
which are just groups of containers.
So you've got your cluster, which is a whole group of Nodes,
which are just virtual machines.
And then you have containers running on top of that.
And there's Kubernetes makes a lot of things easy,
but it also comes with its own challenges.
So one example is when you spin up an application
or a service in Kubernetes, you have to say,
hey, how many copies of this?
Or how many pods of this should we run?
And if you run into performance problems,
if you're just the application guy you say,
Hey, just give me more of these, right?
If I want this to be faster, you say,
Instead of five I need 10. And it's like--
>>But hardware is not free in the cloud?
>>The hardware is not free.
It's like the old problem of people spinning up too many
virtual machines, on a hypervisor,
and thinking that they're free.
But with the dashboard in AppOptics, we can look at,
Hey, what's the latency of this service?
How much resources is this service using?
Maybe we can look at the total memory consumption
across the cluster,
the average memory consumption per node
or per pod in the cluster.
And then instead of the application developers
just running wild, us as infrastructure people
who have to pay the bill at the end of the day
and manage this stuff can take a look at a dashboard
like this and say,
Hey, you know what?
This one service is using 80% of the resources
in our cluster.
We need to go have a conversation with these guys.
Maybe this isn't appropriate"
And now we have the visibility--
>>Well, I was gonna say the other thing too is
you've got, you know, with going back to
the Monolith example, right?
If it needs more memory, if it needs to more caching,
if it needs more IO,
it needs what would be horizontally scaling
with instances in a cluster, right?
It's gonna take care of all of that for you.
And in some dashboard,
you can actually sort of see what it's doing
and it's tuning, but in this case, it's up to you, right?
Like that application in Kubernetes is defined as a service.
And it's typically not what we think of
as a single application, right?
It is multiple services
that are actually flying in formation.
And so to your point, it's like,
you have that initial moment of creating,
like say, Oh, we need eight.
We need eight instances at even time.
Or you do auto load balancing as a part of the orchestrator.
But it's like, is that really enough?
If you have a bottleneck, that's a part of that application
it's going to be one or more of those components,
or maybe the way that traffic is moving or maybe proxies,
or you have security limitations or something else,
or you're orphaning resources.
So you really are looking at a whole load of those parts
in aggregate that define that application with a lot more
granularity than you normally would
with a packaged application.
>>And with AppOptics, we have the visibility for,
the developer teams and the infrastructure team to have this
conversation so they can see
what's going on inside this cluster.
What's the resource limitations on the nodes,
on the pods, like, have we misconfigured this?
So we have way too many pods of one service.
And I think just as an organization too,
when you're starting to use Kubernetes,
it's good to kind of have these conversations of,
who's responsible for what,
and just be proactive about some of these problems.
Like if the application developer just says,
Hey, I need all these resources for my service.
And they just write it in their code.
Suddenly they have that,
but then it comes back and,
suddenly you're out of resources on your virtual machines,
that's running the cluster
and now it's the infrastructure guy's problem.
>>Right. >>I mean, these problems
are really shared and you need to have that communication
and you need the visibility in order to drive
those conversations properly.
>>So, basically it's that same problem
that I think you and I have both seen before
where on a Hypervisor, someone says,
Hey, you know, this application is not performing well,
I need more V procs.
And you go take a look at it,
and it's over-provisioned.
So instead of adding V procs,
you actually remove a few,
the performance goes up and they say,
Thank you so much for adding all of those extra processes.
I really appreciate it.
But you're tuning.
So, you're saying it's really the same thing.
It's just a different set of metrics that you're
looking at to be able to perform that.
>>It's really the same old problem
that we saw in hypervisors.
It's just, the terminology is different,
but it's the same problem.
>>We hear people talk about
observability and visibility
and what we're really talking about with hybrid applications
is we're talking about sort of changing that zoom, right?
So, if you're talking about increasing visibility,
you're thinking more or observability,
you were sort of thinking about pulling back
so you can see that broader, integrated infrastructure.
But at the same time, especially if it's new technology,
or something where it doesn't have,
doesn't come with a built-in monitoring interface.
You really are gonna have to sort of zoom in
to a particular technology or an approach
that can give you the data that you need to really monitor
all aspects of that application.
>>That's right, the visibility is a good term to use,
because these things are different.
And I think, one takeaway is that,
Hey, when you're in this hybrid approach,
just realize that they are different.
Talk about how they're different with your team.
Talk about that some of the failure options
of the things that you need to watch out for.
And then, you kind of build a monitoring plan,
and look for the tools and the right ways to kinda
get that visibility and monitor with your team,
because you do have to work together across
your application and your infrastructure teams these days.
>>Well, the good news is even a couple of years ago,
this is a lot harder, right?
The technologies weren't quite as mature,
we didn't have the same sort of our customers
weren't using a more sort of standard set
of reference practices.
And then, you know, our SolarWinds and other tools,
for example, weren't as mature as they were either.
So, this is a great time to really start.
I liked that idea of working with the team,
just remembering that this is actually
just one more challenge to
solve and that the tools are already there, right?
So it's really just a different way of thinking about it.
You're not reinventing the wheel.
You're sort of bolting on some new attachments
where necessary to increase visibility.
>>That's right, and you know what,
if you're just trying to dip of your toe into this stuff,
and you heard Kubernetes for the first time today,
just start a conversation in THWACK.
There's lots of other people that are having these problems,
and there's a community behind you as well.
>>Or just use a Kubernetes managed service,
and then you don't have to worry about it all--
>>Or do that--
>>Build your containers push them up--
>>All the problems, yeah.
[both laughs]
>>Awesome, well, Adam,
thank you so much for being with us today.
We hope that you enjoyed this session
and feel free to reach out Adam, where, THWACK?
>>THWACK is great, Yep.
Find us in THWACK, Adam.Hert,
and yeah, thanks for having me Patrick.
>>Awesome, thanks so much for being a part of the session.
Hope to see you guys soon.