>> You learned about the DTU model.
In this episode, you'll learn how you can level up with
some new options that are only possible in the vCore model.
This week on Data Exposed.
[MUSIC].
>> Hi, I'm Anna Hoffman,
and welcome to this episode of Data Exposed MVP edition.
Today I'm joined once again by Matt Gordon.
Thanks for being here again with us today, Matt.
>> Thanks for having me.
>> In the last episode,
we talked about the DTU model,
and while the DTU model is important,
there's also another model available for you.
Matt, can you tell us a little bit about it?
>> Yeah. There's a common misconception
that the DTU model is going away,
and that everything's going towards
the vCore tier, and that's not really true.
It's a different way to look at it,
and in my experience,
sometimes that can be a little bit easier to
translate to management as well.
Because you're like, "Well, I don't know what a DTU is."
You can see me on all the articles and
videos you want but I know what cores
are and so I want to license it
by cores because that's how I do it now.
That's when I go to a customer,
that's how I explain that.
Why don't we take a look into what these are?
>> Awesome. Sounds great.
>> Yeah. There's, I would say three and a half tiers here.
Let's go through what those are,
and we'll work left to right,
which is these all meet similar needs.
But obviously you can see from
the IOPS number and the latency numbers.
You're getting more performance out of each tier,
and there's some architecture differences as well.
General purpose, if you want to license by vCore,
is going to be where you start.
You'll note there's two compute tiers here.
There's provision which is
what we all know and maybe love, which is,
I am provisioning resources that I will use and like it says,
it's built per hour based on the vCores you have.
Then there's serverless. Let's take a minute.
We'll hop out of this, we'll go to
serverless because there's some interesting things there.
I think the name is silly.
It's not serverless.
There's a computer somewhere running this,
that is a very trendy name.
But so what it is,
is you're not necessarily
provisioning physical hardware to you at that second,
it's to handle more bursty workloads,
where it's going to say,
"There are some VMs
maybe warmed up and I'm going to go grab those,
and I'm going to give you a lot more machine
than you had because I can
see that the workload's getting a lot more demanding than it was."
What you've got here is you have min and max vCores,
and basically that's telling it what's the range,
where should I always need to be?
You measure that off your workload.
It does affect billing as well,
because as the text says,
this is actually built per second based on the vCores used.
You see that over here,
there's the storage cost and then compute is built separately.
You can set min and max there and tell it where to cap out,
and that's one way you would manage costs here.
Auto-pause is also, that's an important thing to set,
because that's going to tell it basically,
as the database has gone idle,
when is it okay for it to auto-pause.
Now, bearing in mind that as the workload starts to ramp back up,
there can be a bit of a delay in performance as it
pulls the resources back in that it needs.
You can also set max size down here as well.
That's serverless, its newest,
so a lot of folks haven't seen that.
I want to make sure I ran through that.
We'll go back to provision here as well.
One thing interesting about the vCore license, and again,
something else where a manager might be interested in
this is if you're using the Azure Hybrid Benefit,
then you're able to bring that license here.
That's something again, managers like to hear that saving money,
they're all about that especially now.
Then here we have what we're used to maybe if we've dialed up
other Azure SQL Databases in the past,
we can go from two vCores up to 80.
You'll see we've started here at pretty basic.
We've got a terabyte, two vCores.
As we start to ramp those up,
you'll notice just as you'd expect,
the cost goes up as well.
That's general purpose, for me,
it's almost like an equivalent to standard in the DTU model.
Then let's jump to hyperscale.
Hyperscale is an odd duck.
You'll see, and this is what I really want to call it here.
The architecture under hyperscale is very
interesting and we probably don't have the time to go into it now.
But it's capable of massive workloads that no other tiers.
However, because the storage architecture is different,
the way to approach these backups is different.
All of those things.
You can't hop from it to another tier.
If you try to provision a database, does this,
you basically have to sign off and say,
"I know I'm not going to call support."
Say, "Oh, I have hyperscale and now needs to be something else."
You can't make that change because
the architecture is vastly different and it's really, really cool.
But like I said, probably out of the scope of our chat here.
Now that we've bumped up here,
you see we've got vCores here.
We can store up to a 100 terabytes,
which is pretty exciting.
We can go up to 80 vCores just as you'd
expect the cost changes quite a bit.
We also have secondary replicas here as well,
which does give us the ability to scale out our reads.
But as you suspect,
the more hardware we introduce
here to more of the cost goes up as well.
The last tier that I want to get to,
and for me this is interesting because
when you're up to these tiers and you're talking about
hundreds of thousands of IOPS and things like that.
A lot of times this is a customer that's coming
from a very robust on-prem environment.
A lot of time,
especially if they've done
anything SQL Server in
the last eight or 10 years and uptime is a big deal.
There is always on AG's there.
A lot of times
that conversation with me will start as like, "Well,
we have 24 node AG's and we want
all those up in Azure and we want to save a bunch of money."
Just introducing a bunch of VMs
and lifting and shifting everything you
have and putting those
AG's in Azure is not going to be the right answer.
But something like this tier very much
can be because under the covers it's the same thing.
Mostly like it's a very similar architecture,
but you don't need cluster knowledge.
You don't need your Windows Apps folks involved,
it's all managed for you.
Now, you're certainly paying for that,
but that can be a nice transition
from somebody probably who is talking to me now,
who thought maybe two or three years ago, "Oh,
there's not enough power in the Cloud for what we do."
There certainly is now,
and it's just part of explaining what we can do here.
Again, we've got our Azure Hybrid Benefit, we've got vCores,
and just as you'd expect just as we've gone over,
you'll note as we expand the vCores,
we expand our storage here as well,
up to the cap of four terabytes.
We're able to turn on read scale-out here,
similar to what we went over just now,
and we're able to turn on zone redundancy as well.
That's basically redundancy within an Azure region.
You're not vulnerable if there's an issue with one datacenter,
that's not going to take you down
as long as you've turned this on.
You'll note when we turn that on,
the cost actually does not change.
>> Thanks Matt, this has been a really great explanation of
the different service tiers within the vCore purchasing model.
I actually learned a bit myself about the business critical model.
Thanks for sharing that with us today.
As people look at these options similar to the DTU model,
how would you give advice on which level to go to,
when to level up,
when to level down,
because there is like you mentioned,
a cost associated with that.
>> Yeah. It depends what you're after and how much influence,
let's say management has as well.
I know a lot of my customers
the DBAs know what a DTU is, are familiar with it.
The managers want to vCore model,
and so we end up here.
Obviously you can get more performance out of these tiers as well.
It really depends what thereafter,
like I mentioned, if you're wanting to simulate,
you're always on a G environment in a platform as
a service offering and get
all the warm fuzzies that comes with all those nodes.
Then you would go probably business
critical here to get that same feeling.
But otherwise, it really depends how many IOPS do you need?
How much performance do you really need?
With the special call-out to hyperscale, if you need,
let's say you have a 20 terabyte database on on-prem.
You have to go to hyperscale.
You don't have a choice, but you didn't have
that choice before it used to be if you had 20,
you had to do lots and lots of tricks.
Yeah. It's really all what you want.
If you have a really bursty workload,
and you don't want to manage that by
turning performance all the way up
and all the way down and all that.
Serverless probably is the right answer despite the silly name.
>> Awesome. Well, Matt I know you're a race car driver,
and I think you had a really great analogy.
I didn't want to stop the show without letting you share with us.
>> In racing, typically,
especially from the drivers point of view,
the more money that I spend,
the faster I'm going to go, because the problem is never me.
It's never my skills, so it's
something with the car that needs to be better.
In Azure SQL, it's pretty similar.
The more performance you want, unfortunately,
the more you have to pay, but
you also get more speed, and speed is fun.
>> Speed is fun. Awesome. Well, thanks
so much for joining us on this short series, these two videos.
Matt, we really appreciate you being on the show.
For our viewers, we hope you enjoyed this little mini series.
Let us know what service tier you're moving to,
what you've learned throughout this video,
and we hope to see you next time on Data Exposed.
[MUSIC]