>>Rick, thank you so much for being a part of
this session, because we are gonna talk about upgrades.
And I know that doesn't sound like
maybe the coolest thing ever.
>>It's a topic that is near and dear to my heart,
but also strikes fear in my heart at times, too.
>>What strikes fear about it?
>>Well, there are points in time where upgrades
are kind of inevitable, you have to do them.
And then there's points in time when also upgrades
can end up being, retrospectively,
something I really should've done.
>>Right.
>>Because otherwise, something bad could've happened.
>>So basically, after you've completed an upgrade,
we forget how we felt before
because we're enjoying whatever the benefits of
that upgrade were, but before it just seems impossible.
>>Right.
I mean, ideally you've practiced, you've rehearsed
you've researched, you've got your upgrade underway.
When you actually you're completed,
it's like, anti-climactic.
It's like, that's all it was?
Really?
Nothing else?
>>Right, but does it feel a little bit different now?
Like, we're thinking about this batch of upgrades
over the last few years, maybe more than we have before?
>>My philosophy is people overthink them too much, honestly.
It's not as bad.
We've done a lot of work as software vendors,
to try to make upgrades less painful,
because people resist change and they resist doing upgrades.
You ultimately are going to be happy at the end of it
because you're gonna have more functionality, more features,
better protection, better security.
I can keep on going if you want. [laughs]
>>Well, but but every now and then,
there's one that almost works out in our favor.
Like we look back and are like,
"I'm so glad I didn't upgrade."
>>Yeah, I mean, the best I can do is
there's this war story I have,
honestly, about this one customer.
Where, they needed to do an upgrade to get access to
a new functionality of Azure Active Direct-
Sorry, of Active Directory Recycle Bin.
It came out with 2008 R2.
They were running an old version of Active Directory,
and they just were continuing to work with it.
But literally one admin person which had too many rights,
went in and deleted an entire OU structure
of a sub-office of a particular financial institution.
It proceeded to replicate, like it's supposed to,
across the entire Active Directory of this worldwide bank.
The only way they were able to save things from happening
was the fact that there was a latent, slow connection
to one of their offices in the Caribbean
and they were able to wake up in time to
basically call down to the Caribbean and say,
"Yank the network cable,
stop this so we can have a copy of this,"
and then mark it as being authoritive and plug it back in
to replicate back out again and save themselves, so.
Needless to say that was a bit of
a forced upgrade after the fact
that really should've been done a long time ago.
>>So they looked it after and said,
"We wanna make sure that we can
never save ourselves by not upgrading by upgrading."
[laughs]
>>Basically, yes.
>>You did mention 2008 R2 there,
and that is one of the things that, to me,
is really interesting is that I think a lot of times
we forget how different that upgrade was.
So, why is it so sticky?
Why is it different?
>>So, it depends again on the audience,
for how long you've been in IT for.
You might have inherited this environment already,
or maybe you were back in the day, from years ago,
with all the gray hairs that we all have these days.
>>That comes from IT, by the way.
>>Yeah, it does, it does.
Or loss of hair.
You literally had, back in the day, a 32-bit environment
operating system and then new hardware coming out,
virtualization was just starting to
become en vogue and supported
and happy and good, and you now ended up in an environment
where you had 64-bit operating systems and 64-bit hardware.
Faster drives, faster memory, more memory.
So, it was like a forced function of
I can't get any of this new functionality,
I got new hardware coming in,
I've got to go to 64-bit.
Which is 2008 R2.
>>So it was sort of gravity around 64-bit.
>>There was a momentous period in time
when the shift happened.
>>And it literally drove virtualization because now you can
put a little bit over a gig in a process.
>>But that was like a bare metal to bare metal,
which to me is probably the most nail-biting,
scariest type of upgrade to do.
>>What, no just, uh, snapshot and change?
>>But now you're there, it's virtualized.
So it's abstracted, so I can easily go in and spin up
a new virtual instance of a new operating system,
a new application layer,
and then throw my data and my app on top of that,
and it's easy because I still have my old one.
But back then, hardware to hardware,
you had to have two things.
So that was definitely a little bit challenging,
but well worth the effort.
The problem is now we have all these people
that are still on 2008 R2 because ah, you know,
it's workin'! It's good!
I'm there, I'm 64-bit, I'm virtualized!
>>It's interesting.
You think about that, like also there was
a fundamental shift in what was driving upgrades and
change in the way we sort of re-architected applications
because, the thing about metal was, it's all feeds and
speeds, right?
It's this box, this proc, and this memory
that tells me how this thing's gonna perform,
and once we went to abstraction,
once we started to virtualize our workloads
then all of a sudden it became more about the performance
of the thing, and the cost of the thing,
or the nimbleness of managing the thing.
And so it changed that conversation about the way that we
were doing tech, and there was this period right at the
same time that 2008 R2--well, 2008 initially and all the way
through R2 was really being adopted, we also started
kind of changing the way that we were designing our
applications.
Do you see that now?
Are we kind of in another, is it like a 10-year
revisiting cycle where we're trying to clear out
a bunch of technical debt that had accumulated,
or it's just more options and we have to be more thoughtful?
>>So, it's kinda both.
I don't think you're gonna peg me down to one side
or the other, it's kinda both.
Because, you know, I've made the transition to doing a lot
more cloud-type stuff,
which is another conversation
around upgrades and migrations.
>>And most of our customers now are beginning to do-
>>Right.
But it's almost as if we've got all the stuff
that's working on top of 2008 R2, there is no major,
massive event other than the small, little things
that keep on piling up on things.
And so, one of them would be things like
access to more RAM, access to more features,
more functionality, but there hasn't been another
momentous issue to kinda drive us forward.
So, obviously the one that we have that's kind of a big,
momentous issue is the fact that, you know what, that's end
of support, end of security updates, end of things.
And, you're kind of in a spot right now where this is now
gonna be one of the driving factors
we go off of to do the upgrades.
So, what I've been seeing is that things are
actually happening much faster, much more incremental,
they're using more, you know- I wanna say the agile
process, the DevOps principles concept of lots of small
added value and small changes to be able to go ahead and
move forward, as opposed to these big, massive, momentum
ones that are going in.
>>Well, for our customers, we see that a lot, too.
We try, especially if you're in the business
of being helpful, you don't wanna add yet another thing
in forcing an upgrade, but every now and then
about a four-ish year cycle,
we'll find that we are gonna require an upgrade.
For us, it's SQL Server 2016 to get a bunch of new
functionality where we can take advantage of
in-memory tables and columnstore, right?
Where if you want to go to millions of log messages an hour,
if you wanna go to lots and lots and lots of analysis on
flow data, for example, you simply are gonna have to
move to that technology because
it will change your experience of the existing product.
A big part of this driver, especially for cloud, is that
it's not just upgrade, but it's migration.
But I think the concern that a lot of people have is that
there's just some things that are not going to migrate ever.
>>So, absolutely.
There's some things that are going to be
staying on-premises, and some things it will make more
sense to actually start to use hybrid or start to put it
natively, directly inside the cloud.
So, one example for stuff that's gonna stay on-premises for
quite some time because of the apps that we have and the
stuff that we have going on is like
good old Active Directory.
>>Yeah.
>>You can do an Active Directory connect to go off and
to synchronize your security principles up into Azure,
as an example, but you're still going to have people
logging in and working with stuff that's gonna be
on-premises for quite some time.
>>Yeah, low latency for authentication is kind of important.
>>Right.
So, for that one there, you're not necessarily going to be
doing an in-place upgrade of
the individual domain controllers.
That makes more sense to do what I call a rolling upgrade,
or I call it the Shell Game, but that sounds kind of dirty.
The rolling upgrade of simply, it's bring up a new box
next to it that's running a more modern operating system,
like go right to 2019 if you wanted to, and then promote
it to become a domain controller, transfer, synchronize,
transfer some roles, take this one down, and then repeat,
repeat, repeat, repeat across the board.
That makes more sense to do it, that way you have a nice,
clean, pristine system but you also maintain
all the security principles and all the
Active Directory goodness from before.
For the upgrade piece, where it makes sense it's kind of
an upgrade, but think of something else like,
file servers as an example.
So file servers you definitely want to
have stuff on-premises-
>>SMB's important.
>>SMB for being able to get access and talking to
things, just please use SMB version 3, not version 1-
>>Set the minimum to two.
>>You can set the minimum to two, but stay with three.
So, what we've done is we've actually made some services,
my good friend Ned Pyle has gone off and made
the Storage Migration Service.
Completely free, runs on top of a 2016 or 2019 box,
and then it goes and can migrate content off of Linux boxes,
SANS, individual servers running 2003,
but no one has 2003 out there anymore, right?
Or 2008 R2, or 2012, 2016, all over to one box.
But then, besides keeping it on that one box,
or that one file store, or maybe it's a cluster,
whatever it happens to be,
you can now tie this in to Azure with Azure File Sync,
and that will make it so that will keep a cache
of hot data of files that are being accessed
locally on that one box.
But then it goes and automatically makes a backup of
all those files up inside of Azure, which then can be
replicated to different locations if you wanted to.
>>Well, and that gets to that thing of where
you start talking about resiliency versus availability,
because if now I can actually sync my files somewhere else,
maybe I don't have to spend as much on a high availability
solution for those files.
>>Right.
>>And most of our customers, actually, upgrades are
pretty simple, right?
They basically will do exactly what you just said,
they'll spin up another VM, and then do a fresh install
and then pretty much just point it at the database server
and it'll carry it forward.
But you mentioned something there that was interesting.
In-place upgrades.
That does feel something that's different
between the experience with 2008 R2 and 2012.
>>See, I still have kind of like, PTSD, when you say
in-place upgrade from being burned in the past.
And almost every single person that
works in operations has that.
>>Hard down for a day.
>>Yeah, so.
So, let's just say, once you get to a more modern platform
like 2012, even, let's go baby steps here.
Once you get to 2012, we spent a lot of time in the
operating system space to go through and make it so that
in-place upgrades are actually pretty painless.
It gets better with 2016, and even better with 2019.
So, in-place is definitely a viable option.
But for those really tricky ones
that you can't go off and do the shell game,
move things around, but it's definitely gotten a lot better
from a story perspective.
>>Are in-place upgrades really
baby steps to continuous upgrades?
>>Well, it's definitely in the right direction.
Continuous upgrades, thinking from a cloud mindset,
cloud mentality, once you've started to go to like 2019
versions of things, we have long-term services branch,
we've got a faster rev branch.
Think of it almost like a desktop cycle
that you'd be doing for your servers,
because things become so much more easier to bring in new
functionality underneath the platform as it runs.
And then, if you starting talking about moving workloads up
into Azure, as an example, because rerun the fabric and
rerun the infrastructure that's up there, you'll all of a
sudden be able to take advantage of all sorts of new
hardware without even doing anything to your base operating
system, or your application layer up there either.
So, it's a good time to be looking at upgrades
and also migrations, too.
>>But in all this, especially at a time where you know
things are changing, like you have a sense
that there's an inflection point.
It's really hard, in the moment, to find that one forcing
function that says "Oh, I'm gonna get 10 years of new
functionality out of this one move."
>>I mean really the forcing function right now is
the opportunity for what's coming, that we don't know
what's around the corner, right?
So, as an example, you can't take advantage of
the new functionality of doing a lot of
the hybrid connectivity to Azure, or new functionality
of on-premises technologies,
unless you're on a modern version.
So, you have to get at least into the 2012, 2016 area
to be able to do it.
Because if you're running 2008 R2, you don't
have that option to be able to use any of that stuff.
I mean even just going ahead and doing a base OS install.
2008 R2 base OS with, what, 285 patches coming down?
That's a good four reboots in two and a half,
three, four hours to get that OS.
>>So a lot of that, you think, people thinking about
containers or being able to really take advantage
of different packaging mechanisms as part of that?
Is it like putting another layer of abstraction on top?
>>Well, no, the way I look at it is, again,
with all these new opportunities that's coming with
the new functionality of 2019 or 2016,
it's besides the new potential of new options,
it's also a time to kind of step back
and to rethink and re-architect things.
When I look at doing an upgrade cycle,
I look at it from the perspective of, what can I fix and
what can I re-architect to make my life easier?
And then leverage some new functionality.
Like the Azure File Sync as an example,
'cause that now frees up the ability to have
only a 50% of my files stores required to be on-premises,
the rest of the stuff is up inside of Azure and I don't care
about it.
It'll come down if it's needed.
I can't do that with an old version of a server operating
system.
So, rethinking becomes very, very important and
sitting back to reflect takes time.
>>So, if you remember everything that you got,
going from 2003 to 2008, all the benefits that came,
so you're recommending that we think about this time
as a similar time.
That that investment now in really rethinking is
actually going to get us ahead and solve a lot of
difficulties that we won't discover until later.
>>Well, absolutely.
What I will say is I do have to put a little bit
of a plug in about the fact that, if you are on 2008 R2,
you don't have much time to have that rethinking take place.
So you're gonna have to make a choice.
You can either migrate to a more modern version on-premises,
or stay on 2008, but then you're gonna have to buy
extended support agreement for security updates,
or migrate certain workloads of 2008 R2 up into Azure
to get three years of updates,
but that's still only going buy you time.
You still have to rethink, reimagine, and then figure
out how to go off and modernize that particular workload.
>>Well thanks for being a part of this conversation.
I know it sounds like it's not cool to talk about upgrades,
but I think it really is.
Ane the other good thing is there's a lot of
really great resources to help people.
Especially for Microsoft products, what, there's,
Microsoft Upgrade and Microsoft Learn.
Talk about that for just a minute.
>>Right, so obviously if you're talking about
technology-wise and the different offers and options that
we have available for doing upgrades and migrations,
that's gonna be found at aka.ms/upgrade
or aka.ms/migrate.
Those are the two main resources, they'll translate over to
the proper pages to get access to those resources.
But, don't forget, you also have to upgrade and migrate your
skillset, and that's where things like aka.ms/azopsfun for
fundamentals will give you the fundamentals from an
operations perspective of what to use inside of Azure,
how it can work if you're a little bit scared
and don't really want to take the first, or second,
or third step into using cloud technologies,
that's a good place for Microsoft Learn to have a sandbox,
be safe, and try out some of those technologies.
>>Yeah, and for SolarWinds customers, there's
the SolarWinds Customer Success Center,
live training classes, just about any kind of guide
you could imagine for doing those upgrades and also
we just started offering Premier Support
so that for customers that need a little extra hand,
we'll help them with upgrade planning and the rest of it.
>>Right on.
>>Thanks again for being a part of this session,
it's been a great chat.
>>I'm glad for working through the therapy session.
[laughing]