>>Joe, we've had a lot of customers tell us,
especially user groups over the last year,
that they sometimes, especially in this move to cloud,
will see opex bills,
subscription bills that are bigger than they expect.
And I think a lot of them are afraid
that this move to cloud,
move to PaaS, or IaaS, or even SaaS,
may actually put them in a situation
where they could have a career-limiting bill come in.
>>Sure.
>>And it almost makes it something
where they're worried about adopting that technology.
So talk to us about what's driving that option.
>>Sure, I mean there are many, many reasons
what's driving that adoption,
but if I were to categorize them
it would really fall into two big thematic things.
I think the first kinda category
is around cost and cost efficiency
in the way that you wanna be charged, right?
So there is kind of a move between capex to opex
that's happening to a lotta businesses,
and public cloud does allow you
to go do something like that.
And then there's a whole kinda secondary set of things
that are in really more around speed and agility, right?
And if you really think about all of these companies
that are really heading toward digitizing their businesses,
and almost all verticals are starting to do that,
it doesn't matter what size company that you are,
if you're the tiniest of companies
with two people on staff,
or if you've got hundreds of thousands of people
in your company,
speed ultimately is becoming a differentiator
for most of those customers that we have.
>>Well we've been at this now long enough, right?
This isn't, we're really 10 years
almost in cloud at this point,
that it's not new, and we've also seen some approaches
that haven't worked, right?
>>Yes, if you really think about the decade plus
that we been on this cloud journey,
a lotta customers and lotta different companies
originally started with the mindset of possibly
one of two different things, right?
One is hey, let's move everything out into the public cloud.
I think by now we're starting to find out
that probably isn't the right move to make.
If I even think about our government,
a lot of the government systems starting
to move into the public cloud,
originally they had a whole initiative around cloud first.
Okay, they were gonna move everything to the cloud.
I think what they're starting to find out,
and this is why the initiative changed a little bit
in how they budget and changed a little bit,
is that they're starting to realize
that this whole hybrid IT setup,
certain things in cloud,
certain things in a data center on premise,
is more of the reality.
It's not just part of the journey
of going on into the cloud.
So most companies are starting to realize,
not move everything into the cloud.
The second thing that a lotta companies started to do
when they didn't wanna take that extreme of a stance,
is to go well, anything new that we create
is gonna be out into the public cloud.
And what's interesting about that whole approach
is that, again, depending on the specific product
or service you're trying to deploy it actually,
from a cost perspective,
ends up becoming much, much more expensive.
So I'll give an example.
So a couple years ago in the news
there was this whole thing where Dropbox basically said,
hey look, we're gonna migrate some of the stuff
that we have out in public cloud.
I won't mention which vendor that they used.
>>Because cloud is always cheaper.
>>Aw yeah, but in this case it wasn't, right?
They started to migrate a lotta that stuff
into a data center that they were running.
And part of the reason is,
if you think about the cloud bill, right?
It's not just about how much storage you have,
what is the CPU that you're utilizing,
they actually make it fairly expensive
for you to be able to pull information outta the cloud.
And for items like Dropbox, where you're putting stuff in
and then you gotta retrieve a lotta that document
or Excel file, or whatever you're gonna be putting in there,
that ended up becoming really, really expensive
for Dropbox to host in a public cloud environment.
>>Right, but CEO for SolarWinds,
you are also making these same decisions,
so give us an example of something
where you had to make that call
of use the cloud or host it internally.
>>Yeah, so I think we basically approach
it where a lotta the other, I think companies,
have started to come to the realization
that this is probably the best method,
which is like, we're just looking at each situation
as a unique situation, right?
And so to give you an example,
even though we have lots and lots of SaaS products
and services that are sitting out there today,
and I'll pick one like the backup service
that we have for MSP,
that capability, again, much like Dropbox.
If we were to host it out into the public cloud,
even though it's a SaaS solution, think about it.
Like, when you put images into the cloud,
the public cloud vendor would make that fairly cheap
for you to do.
But the value in backup isn't putting it into the cloud.
The value for backup is when you are able to restore
that specific information, either via server
or a specific application.
In order for you to do that,
you gotta take information outta the cloud,
and that would make it super expensive.
And so that's why for us, even though it's a SaaS solution,
we host it in our own data centers.
>>Right, it's always funny the way ingest
is always free, and my joke is it's kind of a diode, right?
You don't really go, that free only goes one way.
But yeah, I can remember an app not too long ago
where I was following the recommended guidelines.
It was just based on a lambda function
that was triggering off this CloudWatch Logs.
And all of a sudden I started getting incremental charges
for key stores and for secret stores, and that was a shock.
It was a few cents here and there,
but when you start multiplying it,
following those guidelines,
it's not really one size fits all,
and a lotta times you're just gonna have to experiment
to figure out what works best for you.
>>Exactly, and it's one of the reasons why,
again it depends on the research,
but if you go out there it's not uncommon
if you're making that first journey out
into the public cloud for your bill
to be off upwards of 60%.
Cannot 16%, 60, six zero percent.
>>That's a surprise, 'cause there's all this,
there's a lotta visibility to those first launches,
there's a lotta eyeballs on it,
then all of a sudden you come out much higher
than you expected.
>>Yeah, so when you actually start taking
that journey, again 'cause that's gonna happen, right?
To most people it ends up happening
because that bill isn't, again, about just storage,
it's not about CPU, it's not just about network.
It's all these other services that you might be getting
as part of that specific cloud vendor,
and they're all a little bit different,
where it's gonna come as a surprise.
So I think, to a degree
when you're especially making that first part
of the journey,
some research is gonna be good,
but you are gonna get some surprises as well.
And so especially at the initial launch
of going into public cloud I would experiment
very, very small 'cause it's gonna be off of a small number
instead of a very large number.
>>So the expectation from leadership
is we want you to experiment.
>>Absolutely.
>>Fail fast, just don't fail too huge.
>>Yeah, don't fail like by a million dollars
or something like that.
Yeah, that will not be good for you.
>>So it sounds like there is legitimate fear there.
You could, with the click of a button
or more likely an API call,
spin up an almost unlimited amount of resources.
That is certainly not the problem in the rack.
You're gonna be limited
to what's actually sitting in the data center.
So is that something that just practitioners worry about,
that if you're an admin
and you're sort of learning how to manage those resources,
or is it something that the business worries about too?
>>I think certainly the business worries about it.
That's why a lotta times, especially again,
going down the journey of going out into the public cloud,
there is a lotta governance related to that, right?
Either through sign-off processes through a service catalog
or some kinda service request thing,
they keep a pretty close eye on it, right?
They don't want it to go out of control,
and that's why I think from a research perspective
it's pretty important for you to really start small.
Again, being off on a small number is not that bad, right?
I think with that said, if you take a step back,
it's actually not all that different
from what a lot of folks do,
kind of managing on-prem infrastructure, right?
At the end of the day, and if you look at the public cloud,
in reality there's servers there,
their network components there,
their storage there,
and even with AWS in reality,
they're just running Xen hypervisors, right?
It's stuff that you've managed before on-prem.
And I would even as go as far as to say
that in a lotta ways you're better equipped
than if you had just grown up in the public cloud.
>>Right, like capacity planning is something
that you care about 'cause that's how you fit
your applications into your three year burn down on capex.
>>Exactly, so think about that capacity management
and that capacity monitoring capability
in the public cloud, right?
In reality, because all of that public cloud infrastructure
is sitting on, again in AWS' case, Xen servers,
they could move that specific hypervisor
on you to an older server, right?
And so if you think about the way
that you do capacity planning and monitoring,
you'd be continuously monitoring the usage
of that specific piece of infrastructure.
And so if you had gone from the on-prem
over to now managing public cloud,
you'll start thinking about okay,
is this specific CPU pinged high
because I am on a different server?
Or is it because I really have that high utilization
and I need to go bring up another EC2 instance
or something like that.
>>So you're really talking about value monitoring,
to be able to say, I know this workload,
running in this VM, on this rack in my data center,
this is the performance I see,
and then using monitoring to compare
that against a recommended instance configuration,
for example in cloud, and try to figure out
how to compare those apples and orange.
>>Exactly, and think about that use case.
It's not something if you were just growing up
in public cloud,
that you would even think about doing, right?
You are just gonna assume well,
it's on the same specific server,
I'm gonna go bring up another hypervisor,
I'm gonna bring up another server from Amazon,
and you're gonna end up paying more money
but maybe you shouldn't done that, right?
Maybe you should've shut that specific EC2 instance down
and bring up another instance,
and then move the workload over to the new instance.
>>Or you end up in those situations that are different,
like for on-prem, low CPU, memory utilization, is good,
but in cloud if I have a bunch of resources
I'm paying for by the hour sitting
there with low utilization,
maybe I wanna get a little bit closer
to the limits of performance
for those instances before I create new ones.
>>Yeah, so that's again,
it's kina the same verbs, right?
You're still doing monitoring,
but that's where from an SLA and KPI perspective
where you do turn it upside down.
>>So you're not exactly talking
about business cost monitoring,
but when you look at things
like the Azure Cost Calculator tool,
we could've developed with Microsoft,
it was to help get people thinking
about monitoring in a broader sense.
It's always that they can't, or including cost,
is a part of that evaluation.
>>Yeah, and that's why we had developed the tool.
I really like the three letter acronym
I guess, the TLA of BCM.
>>Yeah, we would never do acronyms.
>>No, never, not in technology.
But yeah, it's one of the reasons
why we built it because we felt like it was so important
for our customers that's making that journey
from on-prem to the public cloud, right?
Especially around Azure, so.
And we'll continue to make improvements there, right?
Even though it's a free tool.
But we believe it's really, really critical
in the type of capability for our customers
to be successful as they migrate
or they start monitoring
and managing hybrid IT infrastructure.
>>Right, and it's interesting where it's appearing
in the product portfolio too, right?
So that is a free tool,
but then you also see it in server
and application monitoring.
You see it certainly in AppOptics and Loggly
and some of the other products that are designed
for application performance monitoring,
and then we're talking a lot in some other sections
about APM in general,
because as your ability to watch infrastructure,
so the traditional metrics goes away,
APM becomes a lot more expensive
because it ends up being about that end-user satisfaction
in making sure that you know
that you're making your users happy.
>>Yeah, and that's what we're really trying
to do at SolarWinds,
right, is to listen to our customer base.
We understand that they are making this journey
and that's why you are starting
to see lotta this capability not only from our on-prem,
traditionally on-prem capabilities like SAM,
which now we allow you to deploy into an Azure AWS.
We fully support that deployment model.
Or, in order for you to be able to if you want,
an all SaaS solution, have things like AppOptics
and Pingdom, Loggly and Papertrail, etc cetera,
for you to be able to just not have to worry
about managing it and just use the specific service.
So we'll continue to go down that journey.
We'll deploy capabilities that our customers need
and we're not really gonna leave them behind, right?
We wanna make sure that they're successful.
>>Well thanks for being a part of this session.
My big takeaway here is experimentation is a good thing.
Business expects us to and it's okay
to have some unknown knowns get in there
and figure those out,
but that rely on community, rely on other users,
go and make sure you've upgraded your tools
and you can get through this okay.
>>Absolutely, and again,
I wanna touch that, at the end of the day
you might actually be better prepared
having managed a lot of different types of infrastructure.
Again, the reality isn't that everything's gonna be
in the public cloud, right?
So from that perspective, you got skillsets
that you're not just gonna have
if you're just growing up in the public cloud.
>>It's remarkably portable.
>>Yeah, exactly.
>>Well, thanks so much for that, Joe.
Hopefully you got a lot out of this session.
And we don't all get a chance
to just walk into the CTO's office
and ask things like,
how much tolerance do you have for risk, or pain,
or how much budget do I have to play with?
So hopefully this has given you a chance
to look at some of the drivers behind it,
some of the ways you can stay outta trouble,
and most of all that you're gonna be okay.
Just don't spend a million dollars.