1
00:00:00,040 --> 00:00:03,839
Welcome to the M365 FM podcast,
where we explore the people,
2
00:00:03,839 --> 00:00:06,759
ideas and technologies shaping
the future of work.
3
00:00:06,759 --> 00:00:09,279
What Azure SQL database actually
is.
4
00:00:09,279 --> 00:00:10,800
Let's start with the plain
version.
5
00:00:10,800 --> 00:00:12,759
Before any of the acronyms get
involved.
6
00:00:12,759 --> 00:00:14,279
Azure SQL database is a
7
00:00:14,279 --> 00:00:15,359
relational database that
8
00:00:15,359 --> 00:00:16,800
Microsoft runs for you in their
9
00:00:16,800 --> 00:00:17,199
cloud.
10
00:00:17,199 --> 00:00:19,760
You don't buy a machine, you
don't install the software, and
11
00:00:19,760 --> 00:00:21,120
you don't keep it patched.
12
00:00:21,120 --> 00:00:23,760
All of that now sits on
Microsoft's side of the line.
13
00:00:23,760 --> 00:00:25,039
You create a database, point
14
00:00:25,039 --> 00:00:26,160
your application at it, and the
15
00:00:26,160 --> 00:00:27,239
rest happens quietly in the
16
00:00:27,239 --> 00:00:27,920
background.
17
00:00:27,920 --> 00:00:29,039
The engine underneath is the
18
00:00:29,039 --> 00:00:30,559
same SQL server engine that has
19
00:00:30,559 --> 00:00:31,839
been running business databases
20
00:00:31,839 --> 00:00:32,399
for decades.
21
00:00:32,399 --> 00:00:33,679
Your t-SQL still works, your
22
00:00:33,679 --> 00:00:35,159
tools still connect, and the
23
00:00:35,159 --> 00:00:36,500
skills you already have carry
24
00:00:36,500 --> 00:00:37,359
straight over.
25
00:00:37,359 --> 00:00:40,600
It isn't some stripped down
cousin of SQL server at all.
26
00:00:40,600 --> 00:00:42,479
It's the same animal living in a
new home.
27
00:00:42,479 --> 00:00:44,640
That's the whole idea behind the
phrase database.
28
00:00:44,640 --> 00:00:46,399
As a service, you aren't renting
29
00:00:46,399 --> 00:00:47,320
a box and doing the work
30
00:00:47,320 --> 00:00:47,799
yourself.
31
00:00:47,799 --> 00:00:49,039
You're renting an outcome and
32
00:00:49,039 --> 00:00:50,079
someone else keeps the lights
33
00:00:50,079 --> 00:00:50,520
on.
34
00:00:50,520 --> 00:00:52,799
Microsoft describes the service
as evergreen.
35
00:00:52,799 --> 00:00:55,320
That word means it stays on the
latest stable version
36
00:00:55,320 --> 00:00:58,200
automatically, so you never hit
an end of support wall.
37
00:00:58,200 --> 00:01:00,619
Azure gives you three ways to
run that engine, and knowing
38
00:01:00,619 --> 00:01:03,600
which is which clears up a lot
of confusion as your SQL
39
00:01:03,600 --> 00:01:05,799
database is the fully managed
option, and it's the one we're
40
00:01:05,799 --> 00:01:06,799
talking about today.
41
00:01:06,799 --> 00:01:10,040
Azure SQL managed instance is
the near-complete version built
42
00:01:10,040 --> 00:01:12,959
for lifting existing SQL server
applications into the cloud.
43
00:01:12,959 --> 00:01:14,120
Almost unchanged.
44
00:01:14,120 --> 00:01:15,719
SQL server on an Azure Virtual
45
00:01:15,719 --> 00:01:17,200
Machine is the one where you run
46
00:01:17,200 --> 00:01:18,719
everything yourself, exactly
47
00:01:18,719 --> 00:01:19,819
like a server in your own
48
00:01:19,819 --> 00:01:20,480
office.
49
00:01:20,480 --> 00:01:23,719
Inside Azure SQL database, you
deploy in one of two shapes.
50
00:01:23,719 --> 00:01:27,319
A single database has its own
dedicated set of resources.
51
00:01:27,319 --> 00:01:28,439
They're managed through
52
00:01:28,439 --> 00:01:29,640
something called a logical
53
00:01:29,640 --> 00:01:31,439
server, which is really just an
54
00:01:31,439 --> 00:01:32,680
administrative home for your
55
00:01:32,680 --> 00:01:35,159
databases, logins, and firewall
56
00:01:35,159 --> 00:01:36,599
rules.
57
00:01:36,599 --> 00:01:39,359
An elastic pool is a group of
databases that share one set of
58
00:01:39,359 --> 00:01:42,000
resources, and will come back to
why that matters so much.
59
00:01:42,000 --> 00:01:44,599
What you're really buying with
all of this is delegation.
60
00:01:44,599 --> 00:01:47,480
Microsoft patches the engine,
takes the backups, keeps it
61
00:01:47,480 --> 00:01:49,200
available, and keeps it current.
62
00:01:49,200 --> 00:01:51,760
There are no virtual machines to
watch and no operating system
63
00:01:51,760 --> 00:01:52,879
for you to babysit.
64
00:01:52,879 --> 00:01:54,560
For a beginner, that's the
entire appeal.
65
00:01:54,560 --> 00:01:56,840
The parts you'd normally have to
learn the hard way are simply
66
00:01:56,840 --> 00:01:58,040
someone else's job.
67
00:01:58,040 --> 00:02:00,640
Whether that trade is right for
you is a question we'll settle
68
00:02:00,640 --> 00:02:03,439
near the end when we put it head
to head with running SQL server
69
00:02:03,439 --> 00:02:04,930
on a virtual machine.
70
00:02:04,930 --> 00:02:07,890
Microsoft frames the whole
decision as a single choice, and
71
00:02:07,890 --> 00:02:09,090
it's worth repeating.
72
00:02:09,090 --> 00:02:11,849
You either manage the database
yourself, applying the patches
73
00:02:11,849 --> 00:02:14,569
and taking the backups, or you
hand those jobs to Azure.
74
00:02:14,569 --> 00:02:16,009
If your honest answer is hand
75
00:02:16,009 --> 00:02:17,169
them over, you're in the right
76
00:02:17,169 --> 00:02:17,650
place.
77
00:02:17,650 --> 00:02:20,050
And if you're worried about the
bill, Microsoft's own
78
00:02:20,050 --> 00:02:22,770
documentation puts the starting
point at about five dollars a
79
00:02:22,770 --> 00:02:24,490
month on the basic tier.
80
00:02:24,490 --> 00:02:25,969
The two ways you pay for it.
81
00:02:25,969 --> 00:02:28,689
Now that you know what the thing
is, the first real decision is
82
00:02:28,689 --> 00:02:29,729
how you pay for it.
83
00:02:29,729 --> 00:02:33,330
Azure SQL database sells itself
through two purchasing models,
84
00:02:33,330 --> 00:02:36,129
and picking one is the choice
that shapes everything else.
85
00:02:36,129 --> 00:02:38,729
The first is the DTU model and
it's the bundle.
86
00:02:38,729 --> 00:02:40,729
Compute, storage and input and
87
00:02:40,729 --> 00:02:42,090
output are wrapped together into
88
00:02:42,090 --> 00:02:43,330
one number.
89
00:02:43,330 --> 00:02:46,729
A DTU is a blended measure of
CPU memory reads and writes, so
90
00:02:46,729 --> 00:02:48,530
you don't have to think about
any of those separately.
91
00:02:48,530 --> 00:02:50,530
You pick a size and the size
sets all of them.
92
00:02:50,530 --> 00:02:52,650
If you like a simple package
with a predictable monthly
93
00:02:52,650 --> 00:02:54,289
number, this is the set menu.
94
00:02:54,289 --> 00:02:56,569
Its tiers are basic, standard,
and premium.
95
00:02:56,569 --> 00:02:59,090
The scaling is roughly linear,
which makes it easy to reason
96
00:02:59,090 --> 00:03:02,370
about double the dtus, and you
roughly double the resources
97
00:03:02,370 --> 00:03:03,969
available to that database.
98
00:03:03,969 --> 00:03:05,169
A large premium database can
99
00:03:05,169 --> 00:03:06,449
carry hundreds of times the
100
00:03:06,449 --> 00:03:07,729
compute of the smallest basic
101
00:03:07,729 --> 00:03:08,129
one.
102
00:03:08,129 --> 00:03:11,250
The second is the V core model,
and it's the build your own.
103
00:03:11,250 --> 00:03:14,689
A V core is a logical processor,
and this model lets you choose
104
00:03:14,689 --> 00:03:16,250
compute and storage separately.
105
00:03:16,250 --> 00:03:17,370
You also pick the hardware
106
00:03:17,370 --> 00:03:18,770
generation and you match the
107
00:03:18,770 --> 00:03:20,270
price to the workload instead of
108
00:03:20,270 --> 00:03:20,770
guessing.
109
00:03:20,770 --> 00:03:22,210
Microsoft recommends this model
110
00:03:22,210 --> 00:03:23,530
and its tiers are general
111
00:03:23,530 --> 00:03:24,849
purpose, business critical, and
112
00:03:24,849 --> 00:03:25,650
hyperscale.
113
00:03:25,650 --> 00:03:27,169
One difference here matters for
your wallet.
114
00:03:27,169 --> 00:03:28,449
Because the V core model adds
115
00:03:28,449 --> 00:03:29,930
three extras the DTU bundle
116
00:03:29,930 --> 00:03:30,689
doesn't have.
117
00:03:30,689 --> 00:03:32,289
There's Azure Hybrid Benefit,
118
00:03:32,289 --> 00:03:33,650
which lets you reuse existing
119
00:03:33,650 --> 00:03:35,090
SQL server licenses for a
120
00:03:35,090 --> 00:03:35,689
discount.
121
00:03:35,689 --> 00:03:37,930
And there's serverless where a
database can pause whenever
122
00:03:37,930 --> 00:03:39,210
nobody's using it.
123
00:03:39,210 --> 00:03:42,169
Hyperscale is the third, and
it's built for serious scale.
124
00:03:42,169 --> 00:03:44,930
That gap is a big reason teams
tend to start on V core.
125
00:03:44,930 --> 00:03:46,930
There's one more thing that
should put you at ease.
126
00:03:46,930 --> 00:03:48,050
You aren't locked in forever,
127
00:03:48,050 --> 00:03:49,150
because Microsoft lets you
128
00:03:49,150 --> 00:03:50,449
convert a database from one
129
00:03:50,449 --> 00:03:52,289
model to the other online, your
130
00:03:52,289 --> 00:03:53,490
application stays up the whole
131
00:03:53,490 --> 00:03:53,849
time.
132
00:03:53,849 --> 00:03:55,229
That makes the switch closer to
133
00:03:55,229 --> 00:03:56,210
changing a setting than
134
00:03:56,210 --> 00:03:57,090
rebuilding anything.
135
00:03:57,090 --> 00:03:59,330
So this is a decision, not a
life sentence.
136
00:03:59,330 --> 00:04:01,490
If you want the simplest
possible start and a fixed
137
00:04:01,490 --> 00:04:04,129
number, DTU is a reasonable
place to begin.
138
00:04:04,129 --> 00:04:06,569
If you want control, savings or
room to grow.
139
00:04:06,569 --> 00:04:07,889
V core is where you'll end up.
140
00:04:07,889 --> 00:04:10,050
And there's one tear hiding in
here that can make a quiet
141
00:04:10,050 --> 00:04:12,250
little database almost free
while it sits idle.
142
00:04:12,250 --> 00:04:13,689
We'll get to it in a minute.
143
00:04:13,689 --> 00:04:15,009
Picking your service tier.
144
00:04:15,009 --> 00:04:17,930
Choosing a purchasing model gets
you into the right store.
145
00:04:17,930 --> 00:04:21,050
Choosing a service tier is
picking the thing off the shelf.
146
00:04:21,050 --> 00:04:22,129
This is where the size and the
147
00:04:22,129 --> 00:04:23,529
plumbing live, and it's less
148
00:04:23,529 --> 00:04:24,649
intimidating than the name
149
00:04:24,649 --> 00:04:25,290
suggests.
150
00:04:25,290 --> 00:04:28,050
On the V Corps side, general
purpose is the default and the
151
00:04:28,050 --> 00:04:29,129
sensible starting point.
152
00:04:29,129 --> 00:04:31,769
It's budget friendly and handles
most everyday workloads just
153
00:04:31,769 --> 00:04:34,449
fine with storage that goes up
to four terabytes.
154
00:04:34,449 --> 00:04:37,610
Business critical steps up to
much faster local storage built
155
00:04:37,610 --> 00:04:40,449
for applications that need quick
responses on heavy transactions.
156
00:04:40,449 --> 00:04:43,730
It costs roughly two point seven
times more than general purpose,
157
00:04:43,730 --> 00:04:46,730
and the reason is simple it
keeps three extra copies of your
158
00:04:46,730 --> 00:04:50,370
data warm and ready, so a
failure barely slows you down.
159
00:04:50,370 --> 00:04:52,050
Hyperscale is the big one, with
160
00:04:52,050 --> 00:04:53,209
storage that scales up to one
161
00:04:53,209 --> 00:04:54,069
hundred and twenty eight
162
00:04:54,069 --> 00:04:54,769
terabytes.
163
00:04:54,769 --> 00:04:55,889
Microsoft now calls it the
164
00:04:55,889 --> 00:04:57,329
recommended default for new and
165
00:04:57,329 --> 00:04:58,490
modern workloads.
166
00:04:58,490 --> 00:05:00,209
On the DTU side, the tiers run
167
00:05:00,209 --> 00:05:01,670
from basic through standard to
168
00:05:01,670 --> 00:05:02,250
premium.
169
00:05:02,250 --> 00:05:04,250
Basic is genuinely tiny, with
170
00:05:04,250 --> 00:05:05,930
five Dtus and two gigabytes of
171
00:05:05,930 --> 00:05:07,370
storage, and it's perfect for
172
00:05:07,370 --> 00:05:08,610
learning or a small side
173
00:05:08,610 --> 00:05:09,250
project.
174
00:05:09,250 --> 00:05:12,170
Standard covers a wide middle
ground and premium adds the
175
00:05:12,170 --> 00:05:15,089
speed and the in-memory features
you'd want for something busier.
176
00:05:15,089 --> 00:05:18,110
One small thing is worth knowing
the smallest D2 sizes give you
177
00:05:18,110 --> 00:05:20,810
less than a single V core of
processing power, so if your
178
00:05:20,810 --> 00:05:23,230
workload leans hard on the
processor, you'll want to move
179
00:05:23,230 --> 00:05:24,410
up a size or two.
180
00:05:24,410 --> 00:05:26,250
That brings us to the tier I
promised you.
181
00:05:26,250 --> 00:05:27,529
Inside the V Corps General
182
00:05:27,529 --> 00:05:28,810
purpose tier, you can choose
183
00:05:28,810 --> 00:05:29,410
serverless.
184
00:05:29,410 --> 00:05:31,889
A serverless database scales its
compute on its own.
185
00:05:31,889 --> 00:05:32,569
By default.
186
00:05:32,569 --> 00:05:35,370
It pauses after an hour of no
activity, so you're billed only
187
00:05:35,370 --> 00:05:36,810
for storage while it sleeps.
188
00:05:36,810 --> 00:05:39,730
The moment someone connects, it
wakes up and gets back to work.
189
00:05:39,730 --> 00:05:40,810
That makes it ideal for the
190
00:05:40,810 --> 00:05:42,170
intermittent project, the demo,
191
00:05:42,170 --> 00:05:43,850
or the database that sits idle
192
00:05:43,850 --> 00:05:44,529
most weekends.
193
00:05:44,529 --> 00:05:45,610
It isn't the right pick for a
194
00:05:45,610 --> 00:05:46,649
workload that runs around the
195
00:05:46,649 --> 00:05:47,410
clock.
196
00:05:47,410 --> 00:05:50,129
It also isn't available in the
business critical tier or
197
00:05:50,129 --> 00:05:51,769
anywhere in the DTU model.
198
00:05:51,769 --> 00:05:53,970
The rule of thumb that saves
beginners a lot of stress is
199
00:05:53,970 --> 00:05:57,569
this start small, watch the
numbers and grow later.
200
00:05:57,569 --> 00:05:58,850
Changing size is an online
201
00:05:58,850 --> 00:06:00,089
operation, so you're not stuck
202
00:06:00,089 --> 00:06:01,250
with the choice you made on day
203
00:06:01,250 --> 00:06:01,769
one.
204
00:06:01,769 --> 00:06:04,810
Start cheap, measure honestly
and let the metrics tell you
205
00:06:04,810 --> 00:06:06,410
when to move up.
206
00:06:06,410 --> 00:06:08,209
Elastic pools the timeshare
trick.
207
00:06:08,209 --> 00:06:10,569
So far we've been talking about
one database at a time.
208
00:06:10,569 --> 00:06:12,740
The money problem shows up when
you have dozens.
209
00:06:12,740 --> 00:06:13,939
It's worth understanding because
210
00:06:13,939 --> 00:06:15,019
this is where a lot of teams
211
00:06:15,019 --> 00:06:16,220
quietly overspend.
212
00:06:16,220 --> 00:06:17,819
Picture twenty small databases,
213
00:06:17,819 --> 00:06:19,220
each one busy for a few minutes
214
00:06:19,220 --> 00:06:20,540
a day and idle the rest of the
215
00:06:20,540 --> 00:06:21,060
time.
216
00:06:21,060 --> 00:06:23,680
If you give each one its own
resources sized for its peak,
217
00:06:23,680 --> 00:06:26,620
you're paying for power that
sits unused almost all day.
218
00:06:26,620 --> 00:06:27,860
If you size them for the
average.
219
00:06:27,860 --> 00:06:30,180
Instead, they'll choke the
moment a spike arrives.
220
00:06:30,180 --> 00:06:33,120
Neither one feels good, and the
elastic pool fixes this by
221
00:06:33,120 --> 00:06:34,740
turning it into a timeshare.
222
00:06:34,740 --> 00:06:36,180
You put a group of databases on
223
00:06:36,180 --> 00:06:37,740
one server, and they share one
224
00:06:37,740 --> 00:06:39,220
fixed pool of resources for one
225
00:06:39,220 --> 00:06:39,860
price.
226
00:06:39,860 --> 00:06:42,660
The busy ones borrow while the
idle ones give back.
227
00:06:42,660 --> 00:06:43,860
The shared resources are
228
00:06:43,860 --> 00:06:45,920
measured in E, dtus or vcores,
229
00:06:45,920 --> 00:06:47,259
but you can think of it as one
230
00:06:47,259 --> 00:06:48,660
tank of fuel that everyone draws
231
00:06:48,660 --> 00:06:49,220
from.
232
00:06:49,220 --> 00:06:51,180
Microsoft's own example makes it
concrete.
233
00:06:51,180 --> 00:06:54,060
Twenty databases that each spike
to ninety Dtus, but average
234
00:06:54,060 --> 00:06:56,420
under five can share one hundred
editors between them.
235
00:06:56,420 --> 00:06:57,699
That's a twenty times reduction
236
00:06:57,699 --> 00:06:59,019
in resources and about a
237
00:06:59,019 --> 00:07:00,220
thirteen times reduction in
238
00:07:00,220 --> 00:07:01,939
price compared with sizing each
239
00:07:01,939 --> 00:07:02,899
one separately.
240
00:07:02,899 --> 00:07:04,019
The intuition is that those
241
00:07:04,019 --> 00:07:05,620
peaks never line up, so the pool
242
00:07:05,620 --> 00:07:06,579
rarely serves more than a
243
00:07:06,579 --> 00:07:07,899
fraction of the total demand at
244
00:07:07,899 --> 00:07:08,420
once.
245
00:07:08,420 --> 00:07:10,959
The pattern that benefits is
specific, and this is the part
246
00:07:10,959 --> 00:07:12,339
people get wrong.
247
00:07:12,339 --> 00:07:14,899
Pools suit databases with low
average use and short,
248
00:07:14,899 --> 00:07:17,819
infrequent spikes that don't all
happen at the same time.
249
00:07:17,819 --> 00:07:20,819
Savings can show up with as few
as two standard tier databases,
250
00:07:20,819 --> 00:07:23,579
and the more you add, the better
the math usually gets.
251
00:07:23,579 --> 00:07:25,019
But if your databases are busy
252
00:07:25,019 --> 00:07:26,540
all day, every day, don't pool
253
00:07:26,540 --> 00:07:26,779
them.
254
00:07:26,779 --> 00:07:28,660
They'll fight each other for the
same resources.
255
00:07:28,660 --> 00:07:30,980
And you'll wonder why
performance got worse.
256
00:07:30,980 --> 00:07:33,060
What Azure handles so you don't
have to.
257
00:07:33,060 --> 00:07:36,060
We've saved the part that should
let you sleep at night.
258
00:07:36,060 --> 00:07:38,620
This is where the managed
service really earns its keep.
259
00:07:38,620 --> 00:07:40,180
Backups happen automatically and
260
00:07:40,180 --> 00:07:41,379
you can't accidentally switch
261
00:07:41,379 --> 00:07:42,300
them off.
262
00:07:42,300 --> 00:07:45,019
Azure takes a full backup every
week, a differential backup
263
00:07:45,019 --> 00:07:47,420
every twelve to twenty four
hours, and a log backup roughly
264
00:07:47,420 --> 00:07:48,540
every ten minutes.
265
00:07:48,540 --> 00:07:50,899
That gives you something like an
undo button point in time.
266
00:07:50,899 --> 00:07:53,779
Restore lets you roll a database
back to a specific moment within
267
00:07:53,779 --> 00:07:54,699
the retention window.
268
00:07:54,699 --> 00:07:55,980
That window is seven days by
269
00:07:55,980 --> 00:07:57,680
default and configurable up to
270
00:07:57,680 --> 00:07:58,620
thirty five.
271
00:07:58,620 --> 00:08:01,500
When someone drops a table on a
Friday afternoon, this feature
272
00:08:01,500 --> 00:08:03,939
is the difference between a bad
day and a disaster.
273
00:08:03,939 --> 00:08:06,180
If you need more than that,
there are two more layers.
274
00:08:06,180 --> 00:08:09,420
Geo restore lets you rebuild in
a completely different region.
275
00:08:09,420 --> 00:08:10,800
When the primary one is having
276
00:08:10,800 --> 00:08:12,300
trouble and it's switched on by
277
00:08:12,300 --> 00:08:12,819
default.
278
00:08:12,819 --> 00:08:15,939
Long term retention keeps full
backups for up to ten years,
279
00:08:15,939 --> 00:08:18,139
which is the kind of thing
compliance teams ask for.
280
00:08:18,139 --> 00:08:19,420
You just have to turn it on
281
00:08:19,420 --> 00:08:20,680
because it isn't on out of the
282
00:08:20,680 --> 00:08:21,339
box.
283
00:08:21,339 --> 00:08:23,779
There's a small catch that trips
people up, so it's worth saying
284
00:08:23,779 --> 00:08:27,139
plainly you can't download these
automatic backups like a file
285
00:08:27,139 --> 00:08:27,540
they live in.
286
00:08:27,540 --> 00:08:28,939
Microsoft managed storage and
287
00:08:28,939 --> 00:08:30,079
exist to be restored, not
288
00:08:30,079 --> 00:08:30,860
exported.
289
00:08:30,860 --> 00:08:32,299
If you genuinely need a copy of
290
00:08:32,299 --> 00:08:33,899
your data outside Azure, you
291
00:08:33,899 --> 00:08:35,019
export a portable package
292
00:08:35,019 --> 00:08:35,620
instead.
293
00:08:35,620 --> 00:08:38,259
And the odd part is that
deleting a database doesn't
294
00:08:38,259 --> 00:08:39,860
delete its backups right away.
295
00:08:39,860 --> 00:08:42,299
Deleting and recreating a
database to save money can
296
00:08:42,299 --> 00:08:43,620
actually cost you more.
297
00:08:43,620 --> 00:08:45,019
High availability works the same
298
00:08:45,019 --> 00:08:46,139
way, and it mostly stays
299
00:08:46,139 --> 00:08:47,019
invisible.
300
00:08:47,019 --> 00:08:48,460
By default, your data is copied
301
00:08:48,460 --> 00:08:49,899
three times inside a single data
302
00:08:49,899 --> 00:08:51,419
center, and committed data is
303
00:08:51,419 --> 00:08:52,139
never lost.
304
00:08:52,139 --> 00:08:55,179
If a machine running your
database fails, Azure moves you
305
00:08:55,179 --> 00:08:56,659
to a new one automatically.
306
00:08:56,659 --> 00:08:59,259
For something stronger, you
enable zone redundancy, which
307
00:08:59,259 --> 00:09:01,899
spreads your database across two
or three zones in a region.
308
00:09:01,899 --> 00:09:03,039
That way, a whole data center
309
00:09:03,039 --> 00:09:04,299
going dark doesn't take you with
310
00:09:04,299 --> 00:09:04,620
it.
311
00:09:04,620 --> 00:09:06,059
Just know it isn't available on
312
00:09:06,059 --> 00:09:07,700
the basic or standard tiers at
313
00:09:07,700 --> 00:09:08,299
all.
314
00:09:08,299 --> 00:09:11,000
Though it's available on general
purpose, business, critical,
315
00:09:11,000 --> 00:09:12,779
hyperscale, and premium.
316
00:09:12,779 --> 00:09:15,139
The availability guarantee
climbs along with all of that,
317
00:09:15,139 --> 00:09:17,990
Microsoft's published service
level agreement puts zone
318
00:09:17,990 --> 00:09:20,730
redundant business critical and
premium databases at a guarantee
319
00:09:20,730 --> 00:09:23,309
of at least ninety nine point
nine nine five percent, and
320
00:09:23,309 --> 00:09:25,350
business critical includes one
more nice bonus.
321
00:09:25,350 --> 00:09:26,789
It gives you a free read only
322
00:09:26,789 --> 00:09:28,509
copy of your database, so your
323
00:09:28,509 --> 00:09:29,830
reports and analytics can run
324
00:09:29,830 --> 00:09:30,750
there and leave your main
325
00:09:30,750 --> 00:09:32,190
workload alone.
326
00:09:32,190 --> 00:09:34,629
Security without the jargon,
backups protect you from
327
00:09:34,629 --> 00:09:36,950
accidents, and security protects
you from people.
328
00:09:36,950 --> 00:09:39,549
It helps to see it as layers
moving from the outside.
329
00:09:39,549 --> 00:09:42,909
In the outer layer is the front
door and by default it's locked.
330
00:09:42,909 --> 00:09:46,429
Nothing reaches your server
until you explicitly allow it.
331
00:09:46,429 --> 00:09:49,190
Firewall rules let you permit
access by IP address.
332
00:09:49,190 --> 00:09:51,830
You can restrict everything to
your own virtual network so only
333
00:09:51,830 --> 00:09:53,429
your own systems can lock.
334
00:09:53,429 --> 00:09:55,149
The next layer is who you are.
335
00:09:55,149 --> 00:09:57,909
You can sign in with Microsoft
Entry ID, the identity system
336
00:09:57,909 --> 00:10:00,309
that used to be called Azure
Active Directory, or with a
337
00:10:00,309 --> 00:10:03,549
plain SQL username and password
entry is the better choice when
338
00:10:03,549 --> 00:10:04,429
you can use it.
339
00:10:04,429 --> 00:10:05,950
It brings multifactor sign in
340
00:10:05,950 --> 00:10:07,789
conditional access rules, and a
341
00:10:07,789 --> 00:10:08,909
way to stop hard coding
342
00:10:08,909 --> 00:10:10,029
passwords into connection
343
00:10:10,029 --> 00:10:10,789
strings.
344
00:10:10,789 --> 00:10:13,230
Then there's what you're allowed
to do once you're inside.
345
00:10:13,230 --> 00:10:14,350
The guiding idea is least
346
00:10:14,350 --> 00:10:15,429
privilege, which just means
347
00:10:15,429 --> 00:10:16,470
giving people the smallest
348
00:10:16,470 --> 00:10:17,830
amount of access they need to do
349
00:10:17,830 --> 00:10:18,309
their job.
350
00:10:18,309 --> 00:10:19,769
If you need to go further, row
351
00:10:19,769 --> 00:10:20,909
level security can hide
352
00:10:20,909 --> 00:10:22,070
individual rows.
353
00:10:22,070 --> 00:10:23,509
That way a user only ever sees
354
00:10:23,509 --> 00:10:24,789
their own records, which is
355
00:10:24,789 --> 00:10:26,070
handy when many customers share
356
00:10:26,070 --> 00:10:27,029
one database.
357
00:10:27,029 --> 00:10:28,309
Encryption shows up in three
358
00:10:28,309 --> 00:10:29,549
places, and the good news is
359
00:10:29,549 --> 00:10:30,710
that the most important one is
360
00:10:30,710 --> 00:10:31,629
already on.
361
00:10:31,629 --> 00:10:34,190
Data in transit is always
encrypted with TLS.
362
00:10:34,190 --> 00:10:36,950
Data at rest is protected by
transparent data encryption,
363
00:10:36,950 --> 00:10:39,710
which is switched on by default
on every new database.
364
00:10:39,710 --> 00:10:42,230
And for a specific sensitive
column, like a credit card
365
00:10:42,230 --> 00:10:44,629
number, always encrypted can
keep even your own database
366
00:10:44,629 --> 00:10:46,029
administrators from reading it.
367
00:10:46,029 --> 00:10:47,509
The key never reaches the
servers at all.
368
00:10:47,509 --> 00:10:48,549
Finally, there's watching for
369
00:10:48,549 --> 00:10:50,149
trouble auditing records who did
370
00:10:50,149 --> 00:10:51,990
what into your own storage and
371
00:10:51,990 --> 00:10:53,629
defender for cloud raises a flag
372
00:10:53,629 --> 00:10:55,149
on things like SQL injection
373
00:10:55,149 --> 00:10:56,789
attempts and strange sign in
374
00:10:56,789 --> 00:10:57,470
patterns.
375
00:10:57,470 --> 00:10:58,990
You can also classify and label
376
00:10:58,990 --> 00:11:00,029
the sensitive data in your
377
00:11:00,029 --> 00:11:01,710
database, which gives you a map
378
00:11:01,710 --> 00:11:02,990
of where your risk actually
379
00:11:02,990 --> 00:11:03,629
lives.
380
00:11:03,629 --> 00:11:06,509
The plain takeaway is that the
safe settings are the defaults.
381
00:11:06,509 --> 00:11:07,750
Your main job is deciding who
382
00:11:07,750 --> 00:11:09,370
gets in and what they can touch,
383
00:11:09,370 --> 00:11:11,269
Azure SQL database or a virtual
384
00:11:11,269 --> 00:11:11,909
machine.
385
00:11:11,909 --> 00:11:14,870
Everything so far assumes you
want a managed database, but
386
00:11:14,870 --> 00:11:17,470
there's a real fork in the road
here, and it's worth saying out
387
00:11:17,470 --> 00:11:20,830
loud, you can hand Microsoft the
keys, or you can keep them.
388
00:11:20,830 --> 00:11:23,049
Choose the managed Azure SQL
389
00:11:23,049 --> 00:11:24,690
database when you want patching,
390
00:11:24,690 --> 00:11:26,110
upgrades, backups, and high
391
00:11:26,110 --> 00:11:27,509
availability taken off your
392
00:11:27,509 --> 00:11:28,110
plate.
393
00:11:28,110 --> 00:11:30,629
Choose it when you want that
higher availability guarantee.
394
00:11:30,629 --> 00:11:31,389
And when you're building
395
00:11:31,389 --> 00:11:32,509
something new and want to move
396
00:11:32,509 --> 00:11:32,909
quickly.
397
00:11:32,909 --> 00:11:34,029
It's built for cloud first
398
00:11:34,029 --> 00:11:35,909
applications and for teams that
399
00:11:35,909 --> 00:11:36,909
would rather ship than
400
00:11:36,909 --> 00:11:37,909
administer.
401
00:11:37,909 --> 00:11:39,269
It also lets one person manage
402
00:11:39,269 --> 00:11:40,470
far more databases than they
403
00:11:40,470 --> 00:11:41,710
ever could by hand, which
404
00:11:41,710 --> 00:11:43,110
matters once your project starts
405
00:11:43,110 --> 00:11:43,710
to grow.
406
00:11:43,710 --> 00:11:45,110
Choose SQL server on an Azure
407
00:11:45,110 --> 00:11:46,570
Virtual Machine when you need
408
00:11:46,570 --> 00:11:48,350
operating system level access,
409
00:11:48,350 --> 00:11:49,470
or when you want full control
410
00:11:49,470 --> 00:11:50,830
over the engine, choose it when
411
00:11:50,830 --> 00:11:52,070
you have to match an existing on
412
00:11:52,070 --> 00:11:52,830
premises setup.
413
00:11:52,830 --> 00:11:55,470
Exactly, or when you're lifting
an old application into the
414
00:11:55,470 --> 00:11:56,789
cloud with no code changes.
415
00:11:56,789 --> 00:11:59,110
With a virtual machine, you
decide when updates run and you
416
00:11:59,110 --> 00:12:00,149
get every feature.
417
00:12:00,149 --> 00:12:03,590
You also own the patching, the
backups, and failover plan.
418
00:12:03,590 --> 00:12:04,950
If your application depends on
419
00:12:04,950 --> 00:12:06,230
the operating system or on
420
00:12:06,230 --> 00:12:07,830
scheduled jobs inside SQL server
421
00:12:07,830 --> 00:12:09,309
itself, the virtual machine is
422
00:12:09,309 --> 00:12:10,590
often the only option that won't
423
00:12:10,590 --> 00:12:11,149
fight you.
424
00:12:11,149 --> 00:12:13,029
There's a middle option worth
knowing about.
425
00:12:13,029 --> 00:12:14,590
Azure SQL Managed Instance gives
426
00:12:14,590 --> 00:12:16,029
you close to full SQL server
427
00:12:16,029 --> 00:12:17,549
compatibility while keeping the
428
00:12:17,549 --> 00:12:18,909
managed benefits, and Microsoft
429
00:12:18,909 --> 00:12:19,950
recommends it for most
430
00:12:19,950 --> 00:12:20,830
migrations.
431
00:12:20,830 --> 00:12:22,230
So if you're moving an existing
432
00:12:22,230 --> 00:12:23,590
system and full control isn't
433
00:12:23,590 --> 00:12:24,549
actually required.
434
00:12:24,549 --> 00:12:25,909
That's often the sweet spot.
435
00:12:25,909 --> 00:12:27,549
The trade off in one line is
this.
436
00:12:27,549 --> 00:12:30,210
Managed means less work and a
stronger guarantee, but fewer
437
00:12:30,210 --> 00:12:31,309
knobs to turn.
438
00:12:31,309 --> 00:12:32,509
A virtual machine means every
439
00:12:32,509 --> 00:12:34,070
knob you could want and the
440
00:12:34,070 --> 00:12:35,309
responsibility that comes with
441
00:12:35,309 --> 00:12:36,070
them.
442
00:12:36,070 --> 00:12:37,350
If you're new to all this, the
443
00:12:37,350 --> 00:12:38,549
honest default is to start
444
00:12:38,549 --> 00:12:40,190
managed and only reach for the
445
00:12:40,190 --> 00:12:41,429
virtual machine when you have a
446
00:12:41,429 --> 00:12:43,230
specific reason.
447
00:12:43,230 --> 00:12:44,750
The mistakes beginners make
448
00:12:44,750 --> 00:12:46,070
knowing the right choice is half
449
00:12:46,070 --> 00:12:46,789
the battle.
450
00:12:46,789 --> 00:12:49,350
The other half is not tripping
over the same handful of things
451
00:12:49,350 --> 00:12:52,110
that catch almost everyone, so
let's run through them.
452
00:12:52,110 --> 00:12:54,909
The first is paying for peak you
never use, or the opposite,
453
00:12:54,909 --> 00:12:57,309
starving a database to save a
few dollars and then wondering
454
00:12:57,309 --> 00:12:58,110
why it's slow.
455
00:12:58,110 --> 00:12:59,230
What's your real usage for a
456
00:12:59,230 --> 00:13:00,370
couple of weeks and size to
457
00:13:00,370 --> 00:13:00,789
that?
458
00:13:00,789 --> 00:13:01,830
Not to a guess.
459
00:13:01,830 --> 00:13:03,870
Next comes pooling the wrong
databases.
460
00:13:03,870 --> 00:13:05,350
Elastic pools are for spiky,
461
00:13:05,350 --> 00:13:06,870
mostly idle databases, not for
462
00:13:06,870 --> 00:13:08,269
workloads that run flat out all
463
00:13:08,269 --> 00:13:08,750
day.
464
00:13:08,750 --> 00:13:09,950
Put the busy ones in a pool and
465
00:13:09,950 --> 00:13:10,909
they'll compete for the same
466
00:13:10,909 --> 00:13:11,789
resources.
467
00:13:11,789 --> 00:13:12,750
A third one is choosing
468
00:13:12,750 --> 00:13:14,070
serverless for an always on
469
00:13:14,070 --> 00:13:15,470
application, and then getting
470
00:13:15,470 --> 00:13:16,710
annoyed by the pause and wake
471
00:13:16,710 --> 00:13:17,389
delay.
472
00:13:17,389 --> 00:13:19,909
Serverless is for intermittent
use, full stop.
473
00:13:19,909 --> 00:13:20,909
Another is forgetting that
474
00:13:20,909 --> 00:13:22,129
backup retention defaults to
475
00:13:22,129 --> 00:13:22,710
seven days.
476
00:13:22,710 --> 00:13:23,710
If you need to keep history
477
00:13:23,710 --> 00:13:25,200
longer or a compliance rule
478
00:13:25,200 --> 00:13:25,679
demands it.
479
00:13:25,679 --> 00:13:27,919
You have to turn on long term
retention yourself.
480
00:13:27,919 --> 00:13:30,720
One more is assuming zone
redundancy comes included on the
481
00:13:30,720 --> 00:13:31,720
basic and standard tiers.
482
00:13:31,720 --> 00:13:32,679
It doesn't exist at all.
483
00:13:32,679 --> 00:13:34,960
So you have to pick a supporting
tier and switch it on.
484
00:13:34,960 --> 00:13:37,919
And the last is treating the
firewall as an afterthought.
485
00:13:37,919 --> 00:13:40,899
Nothing gets in until you say
so, and the safest habit is to
486
00:13:40,899 --> 00:13:43,799
keep it that way, allowing only
the addresses and networks that
487
00:13:43,799 --> 00:13:45,320
genuinely need access.
488
00:13:45,320 --> 00:13:47,159
None of these are exotic
mistakes.
489
00:13:47,159 --> 00:13:48,000
They're just the ones that
490
00:13:48,000 --> 00:13:49,360
quietly cost people money and
491
00:13:49,360 --> 00:13:50,639
sleep.
492
00:13:50,639 --> 00:13:52,519
Wrapping up what to remember.
493
00:13:52,519 --> 00:13:53,700
Let's pull this together into
494
00:13:53,700 --> 00:13:54,879
something you can actually hold
495
00:13:54,879 --> 00:13:55,720
on to.
496
00:13:55,720 --> 00:13:58,639
Azure SQL database is the SQL
server engine running as a
497
00:13:58,639 --> 00:14:01,600
managed service in Microsoft's
Cloud, you choose how you pay
498
00:14:01,600 --> 00:14:05,600
either the DTU bundle or the
build your own Vcore model, and
499
00:14:05,600 --> 00:14:07,440
then you pick a tier and a size.
500
00:14:07,440 --> 00:14:08,600
You can share resources across
501
00:14:08,600 --> 00:14:10,080
many databases with an elastic
502
00:14:10,080 --> 00:14:11,799
pool, or let a quiet database
503
00:14:11,799 --> 00:14:12,440
pause itself.
504
00:14:12,440 --> 00:14:15,080
With serverless backups, high
availability, and encryption all
505
00:14:15,080 --> 00:14:17,720
come switched on, and you reach
for it instead of a virtual
506
00:14:17,720 --> 00:14:19,799
machine whenever you'd rather
not run the server yourself.
507
00:14:19,799 --> 00:14:22,000
So I'll leave you with one
question to sit with.
508
00:14:22,000 --> 00:14:24,559
If Microsoft took patching
backups and failover off your
509
00:14:24,559 --> 00:14:27,360
plate tomorrow, what would you
actually spend that time on?
00:00:00,040 --> 00:00:03,839
Welcome to the M365 FM podcast,
where we explore the people,
2
00:00:03,839 --> 00:00:06,759
ideas and technologies shaping
the future of work.
3
00:00:06,759 --> 00:00:09,279
What Azure SQL database actually
is.
4
00:00:09,279 --> 00:00:10,800
Let's start with the plain
version.
5
00:00:10,800 --> 00:00:12,759
Before any of the acronyms get
involved.
6
00:00:12,759 --> 00:00:14,279
Azure SQL database is a
7
00:00:14,279 --> 00:00:15,359
relational database that
8
00:00:15,359 --> 00:00:16,800
Microsoft runs for you in their
9
00:00:16,800 --> 00:00:17,199
cloud.
10
00:00:17,199 --> 00:00:19,760
You don't buy a machine, you
don't install the software, and
11
00:00:19,760 --> 00:00:21,120
you don't keep it patched.
12
00:00:21,120 --> 00:00:23,760
All of that now sits on
Microsoft's side of the line.
13
00:00:23,760 --> 00:00:25,039
You create a database, point
14
00:00:25,039 --> 00:00:26,160
your application at it, and the
15
00:00:26,160 --> 00:00:27,239
rest happens quietly in the
16
00:00:27,239 --> 00:00:27,920
background.
17
00:00:27,920 --> 00:00:29,039
The engine underneath is the
18
00:00:29,039 --> 00:00:30,559
same SQL server engine that has
19
00:00:30,559 --> 00:00:31,839
been running business databases
20
00:00:31,839 --> 00:00:32,399
for decades.
21
00:00:32,399 --> 00:00:33,679
Your t-SQL still works, your
22
00:00:33,679 --> 00:00:35,159
tools still connect, and the
23
00:00:35,159 --> 00:00:36,500
skills you already have carry
24
00:00:36,500 --> 00:00:37,359
straight over.
25
00:00:37,359 --> 00:00:40,600
It isn't some stripped down
cousin of SQL server at all.
26
00:00:40,600 --> 00:00:42,479
It's the same animal living in a
new home.
27
00:00:42,479 --> 00:00:44,640
That's the whole idea behind the
phrase database.
28
00:00:44,640 --> 00:00:46,399
As a service, you aren't renting
29
00:00:46,399 --> 00:00:47,320
a box and doing the work
30
00:00:47,320 --> 00:00:47,799
yourself.
31
00:00:47,799 --> 00:00:49,039
You're renting an outcome and
32
00:00:49,039 --> 00:00:50,079
someone else keeps the lights
33
00:00:50,079 --> 00:00:50,520
on.
34
00:00:50,520 --> 00:00:52,799
Microsoft describes the service
as evergreen.
35
00:00:52,799 --> 00:00:55,320
That word means it stays on the
latest stable version
36
00:00:55,320 --> 00:00:58,200
automatically, so you never hit
an end of support wall.
37
00:00:58,200 --> 00:01:00,619
Azure gives you three ways to
run that engine, and knowing
38
00:01:00,619 --> 00:01:03,600
which is which clears up a lot
of confusion as your SQL
39
00:01:03,600 --> 00:01:05,799
database is the fully managed
option, and it's the one we're
40
00:01:05,799 --> 00:01:06,799
talking about today.
41
00:01:06,799 --> 00:01:10,040
Azure SQL managed instance is
the near-complete version built
42
00:01:10,040 --> 00:01:12,959
for lifting existing SQL server
applications into the cloud.
43
00:01:12,959 --> 00:01:14,120
Almost unchanged.
44
00:01:14,120 --> 00:01:15,719
SQL server on an Azure Virtual
45
00:01:15,719 --> 00:01:17,200
Machine is the one where you run
46
00:01:17,200 --> 00:01:18,719
everything yourself, exactly
47
00:01:18,719 --> 00:01:19,819
like a server in your own
48
00:01:19,819 --> 00:01:20,480
office.
49
00:01:20,480 --> 00:01:23,719
Inside Azure SQL database, you
deploy in one of two shapes.
50
00:01:23,719 --> 00:01:27,319
A single database has its own
dedicated set of resources.
51
00:01:27,319 --> 00:01:28,439
They're managed through
52
00:01:28,439 --> 00:01:29,640
something called a logical
53
00:01:29,640 --> 00:01:31,439
server, which is really just an
54
00:01:31,439 --> 00:01:32,680
administrative home for your
55
00:01:32,680 --> 00:01:35,159
databases, logins, and firewall
56
00:01:35,159 --> 00:01:36,599
rules.
57
00:01:36,599 --> 00:01:39,359
An elastic pool is a group of
databases that share one set of
58
00:01:39,359 --> 00:01:42,000
resources, and will come back to
why that matters so much.
59
00:01:42,000 --> 00:01:44,599
What you're really buying with
all of this is delegation.
60
00:01:44,599 --> 00:01:47,480
Microsoft patches the engine,
takes the backups, keeps it
61
00:01:47,480 --> 00:01:49,200
available, and keeps it current.
62
00:01:49,200 --> 00:01:51,760
There are no virtual machines to
watch and no operating system
63
00:01:51,760 --> 00:01:52,879
for you to babysit.
64
00:01:52,879 --> 00:01:54,560
For a beginner, that's the
entire appeal.
65
00:01:54,560 --> 00:01:56,840
The parts you'd normally have to
learn the hard way are simply
66
00:01:56,840 --> 00:01:58,040
someone else's job.
67
00:01:58,040 --> 00:02:00,640
Whether that trade is right for
you is a question we'll settle
68
00:02:00,640 --> 00:02:03,439
near the end when we put it head
to head with running SQL server
69
00:02:03,439 --> 00:02:04,930
on a virtual machine.
70
00:02:04,930 --> 00:02:07,890
Microsoft frames the whole
decision as a single choice, and
71
00:02:07,890 --> 00:02:09,090
it's worth repeating.
72
00:02:09,090 --> 00:02:11,849
You either manage the database
yourself, applying the patches
73
00:02:11,849 --> 00:02:14,569
and taking the backups, or you
hand those jobs to Azure.
74
00:02:14,569 --> 00:02:16,009
If your honest answer is hand
75
00:02:16,009 --> 00:02:17,169
them over, you're in the right
76
00:02:17,169 --> 00:02:17,650
place.
77
00:02:17,650 --> 00:02:20,050
And if you're worried about the
bill, Microsoft's own
78
00:02:20,050 --> 00:02:22,770
documentation puts the starting
point at about five dollars a
79
00:02:22,770 --> 00:02:24,490
month on the basic tier.
80
00:02:24,490 --> 00:02:25,969
The two ways you pay for it.
81
00:02:25,969 --> 00:02:28,689
Now that you know what the thing
is, the first real decision is
82
00:02:28,689 --> 00:02:29,729
how you pay for it.
83
00:02:29,729 --> 00:02:33,330
Azure SQL database sells itself
through two purchasing models,
84
00:02:33,330 --> 00:02:36,129
and picking one is the choice
that shapes everything else.
85
00:02:36,129 --> 00:02:38,729
The first is the DTU model and
it's the bundle.
86
00:02:38,729 --> 00:02:40,729
Compute, storage and input and
87
00:02:40,729 --> 00:02:42,090
output are wrapped together into
88
00:02:42,090 --> 00:02:43,330
one number.
89
00:02:43,330 --> 00:02:46,729
A DTU is a blended measure of
CPU memory reads and writes, so
90
00:02:46,729 --> 00:02:48,530
you don't have to think about
any of those separately.
91
00:02:48,530 --> 00:02:50,530
You pick a size and the size
sets all of them.
92
00:02:50,530 --> 00:02:52,650
If you like a simple package
with a predictable monthly
93
00:02:52,650 --> 00:02:54,289
number, this is the set menu.
94
00:02:54,289 --> 00:02:56,569
Its tiers are basic, standard,
and premium.
95
00:02:56,569 --> 00:02:59,090
The scaling is roughly linear,
which makes it easy to reason
96
00:02:59,090 --> 00:03:02,370
about double the dtus, and you
roughly double the resources
97
00:03:02,370 --> 00:03:03,969
available to that database.
98
00:03:03,969 --> 00:03:05,169
A large premium database can
99
00:03:05,169 --> 00:03:06,449
carry hundreds of times the
100
00:03:06,449 --> 00:03:07,729
compute of the smallest basic
101
00:03:07,729 --> 00:03:08,129
one.
102
00:03:08,129 --> 00:03:11,250
The second is the V core model,
and it's the build your own.
103
00:03:11,250 --> 00:03:14,689
A V core is a logical processor,
and this model lets you choose
104
00:03:14,689 --> 00:03:16,250
compute and storage separately.
105
00:03:16,250 --> 00:03:17,370
You also pick the hardware
106
00:03:17,370 --> 00:03:18,770
generation and you match the
107
00:03:18,770 --> 00:03:20,270
price to the workload instead of
108
00:03:20,270 --> 00:03:20,770
guessing.
109
00:03:20,770 --> 00:03:22,210
Microsoft recommends this model
110
00:03:22,210 --> 00:03:23,530
and its tiers are general
111
00:03:23,530 --> 00:03:24,849
purpose, business critical, and
112
00:03:24,849 --> 00:03:25,650
hyperscale.
113
00:03:25,650 --> 00:03:27,169
One difference here matters for
your wallet.
114
00:03:27,169 --> 00:03:28,449
Because the V core model adds
115
00:03:28,449 --> 00:03:29,930
three extras the DTU bundle
116
00:03:29,930 --> 00:03:30,689
doesn't have.
117
00:03:30,689 --> 00:03:32,289
There's Azure Hybrid Benefit,
118
00:03:32,289 --> 00:03:33,650
which lets you reuse existing
119
00:03:33,650 --> 00:03:35,090
SQL server licenses for a
120
00:03:35,090 --> 00:03:35,689
discount.
121
00:03:35,689 --> 00:03:37,930
And there's serverless where a
database can pause whenever
122
00:03:37,930 --> 00:03:39,210
nobody's using it.
123
00:03:39,210 --> 00:03:42,169
Hyperscale is the third, and
it's built for serious scale.
124
00:03:42,169 --> 00:03:44,930
That gap is a big reason teams
tend to start on V core.
125
00:03:44,930 --> 00:03:46,930
There's one more thing that
should put you at ease.
126
00:03:46,930 --> 00:03:48,050
You aren't locked in forever,
127
00:03:48,050 --> 00:03:49,150
because Microsoft lets you
128
00:03:49,150 --> 00:03:50,449
convert a database from one
129
00:03:50,449 --> 00:03:52,289
model to the other online, your
130
00:03:52,289 --> 00:03:53,490
application stays up the whole
131
00:03:53,490 --> 00:03:53,849
time.
132
00:03:53,849 --> 00:03:55,229
That makes the switch closer to
133
00:03:55,229 --> 00:03:56,210
changing a setting than
134
00:03:56,210 --> 00:03:57,090
rebuilding anything.
135
00:03:57,090 --> 00:03:59,330
So this is a decision, not a
life sentence.
136
00:03:59,330 --> 00:04:01,490
If you want the simplest
possible start and a fixed
137
00:04:01,490 --> 00:04:04,129
number, DTU is a reasonable
place to begin.
138
00:04:04,129 --> 00:04:06,569
If you want control, savings or
room to grow.
139
00:04:06,569 --> 00:04:07,889
V core is where you'll end up.
140
00:04:07,889 --> 00:04:10,050
And there's one tear hiding in
here that can make a quiet
141
00:04:10,050 --> 00:04:12,250
little database almost free
while it sits idle.
142
00:04:12,250 --> 00:04:13,689
We'll get to it in a minute.
143
00:04:13,689 --> 00:04:15,009
Picking your service tier.
144
00:04:15,009 --> 00:04:17,930
Choosing a purchasing model gets
you into the right store.
145
00:04:17,930 --> 00:04:21,050
Choosing a service tier is
picking the thing off the shelf.
146
00:04:21,050 --> 00:04:22,129
This is where the size and the
147
00:04:22,129 --> 00:04:23,529
plumbing live, and it's less
148
00:04:23,529 --> 00:04:24,649
intimidating than the name
149
00:04:24,649 --> 00:04:25,290
suggests.
150
00:04:25,290 --> 00:04:28,050
On the V Corps side, general
purpose is the default and the
151
00:04:28,050 --> 00:04:29,129
sensible starting point.
152
00:04:29,129 --> 00:04:31,769
It's budget friendly and handles
most everyday workloads just
153
00:04:31,769 --> 00:04:34,449
fine with storage that goes up
to four terabytes.
154
00:04:34,449 --> 00:04:37,610
Business critical steps up to
much faster local storage built
155
00:04:37,610 --> 00:04:40,449
for applications that need quick
responses on heavy transactions.
156
00:04:40,449 --> 00:04:43,730
It costs roughly two point seven
times more than general purpose,
157
00:04:43,730 --> 00:04:46,730
and the reason is simple it
keeps three extra copies of your
158
00:04:46,730 --> 00:04:50,370
data warm and ready, so a
failure barely slows you down.
159
00:04:50,370 --> 00:04:52,050
Hyperscale is the big one, with
160
00:04:52,050 --> 00:04:53,209
storage that scales up to one
161
00:04:53,209 --> 00:04:54,069
hundred and twenty eight
162
00:04:54,069 --> 00:04:54,769
terabytes.
163
00:04:54,769 --> 00:04:55,889
Microsoft now calls it the
164
00:04:55,889 --> 00:04:57,329
recommended default for new and
165
00:04:57,329 --> 00:04:58,490
modern workloads.
166
00:04:58,490 --> 00:05:00,209
On the DTU side, the tiers run
167
00:05:00,209 --> 00:05:01,670
from basic through standard to
168
00:05:01,670 --> 00:05:02,250
premium.
169
00:05:02,250 --> 00:05:04,250
Basic is genuinely tiny, with
170
00:05:04,250 --> 00:05:05,930
five Dtus and two gigabytes of
171
00:05:05,930 --> 00:05:07,370
storage, and it's perfect for
172
00:05:07,370 --> 00:05:08,610
learning or a small side
173
00:05:08,610 --> 00:05:09,250
project.
174
00:05:09,250 --> 00:05:12,170
Standard covers a wide middle
ground and premium adds the
175
00:05:12,170 --> 00:05:15,089
speed and the in-memory features
you'd want for something busier.
176
00:05:15,089 --> 00:05:18,110
One small thing is worth knowing
the smallest D2 sizes give you
177
00:05:18,110 --> 00:05:20,810
less than a single V core of
processing power, so if your
178
00:05:20,810 --> 00:05:23,230
workload leans hard on the
processor, you'll want to move
179
00:05:23,230 --> 00:05:24,410
up a size or two.
180
00:05:24,410 --> 00:05:26,250
That brings us to the tier I
promised you.
181
00:05:26,250 --> 00:05:27,529
Inside the V Corps General
182
00:05:27,529 --> 00:05:28,810
purpose tier, you can choose
183
00:05:28,810 --> 00:05:29,410
serverless.
184
00:05:29,410 --> 00:05:31,889
A serverless database scales its
compute on its own.
185
00:05:31,889 --> 00:05:32,569
By default.
186
00:05:32,569 --> 00:05:35,370
It pauses after an hour of no
activity, so you're billed only
187
00:05:35,370 --> 00:05:36,810
for storage while it sleeps.
188
00:05:36,810 --> 00:05:39,730
The moment someone connects, it
wakes up and gets back to work.
189
00:05:39,730 --> 00:05:40,810
That makes it ideal for the
190
00:05:40,810 --> 00:05:42,170
intermittent project, the demo,
191
00:05:42,170 --> 00:05:43,850
or the database that sits idle
192
00:05:43,850 --> 00:05:44,529
most weekends.
193
00:05:44,529 --> 00:05:45,610
It isn't the right pick for a
194
00:05:45,610 --> 00:05:46,649
workload that runs around the
195
00:05:46,649 --> 00:05:47,410
clock.
196
00:05:47,410 --> 00:05:50,129
It also isn't available in the
business critical tier or
197
00:05:50,129 --> 00:05:51,769
anywhere in the DTU model.
198
00:05:51,769 --> 00:05:53,970
The rule of thumb that saves
beginners a lot of stress is
199
00:05:53,970 --> 00:05:57,569
this start small, watch the
numbers and grow later.
200
00:05:57,569 --> 00:05:58,850
Changing size is an online
201
00:05:58,850 --> 00:06:00,089
operation, so you're not stuck
202
00:06:00,089 --> 00:06:01,250
with the choice you made on day
203
00:06:01,250 --> 00:06:01,769
one.
204
00:06:01,769 --> 00:06:04,810
Start cheap, measure honestly
and let the metrics tell you
205
00:06:04,810 --> 00:06:06,410
when to move up.
206
00:06:06,410 --> 00:06:08,209
Elastic pools the timeshare
trick.
207
00:06:08,209 --> 00:06:10,569
So far we've been talking about
one database at a time.
208
00:06:10,569 --> 00:06:12,740
The money problem shows up when
you have dozens.
209
00:06:12,740 --> 00:06:13,939
It's worth understanding because
210
00:06:13,939 --> 00:06:15,019
this is where a lot of teams
211
00:06:15,019 --> 00:06:16,220
quietly overspend.
212
00:06:16,220 --> 00:06:17,819
Picture twenty small databases,
213
00:06:17,819 --> 00:06:19,220
each one busy for a few minutes
214
00:06:19,220 --> 00:06:20,540
a day and idle the rest of the
215
00:06:20,540 --> 00:06:21,060
time.
216
00:06:21,060 --> 00:06:23,680
If you give each one its own
resources sized for its peak,
217
00:06:23,680 --> 00:06:26,620
you're paying for power that
sits unused almost all day.
218
00:06:26,620 --> 00:06:27,860
If you size them for the
average.
219
00:06:27,860 --> 00:06:30,180
Instead, they'll choke the
moment a spike arrives.
220
00:06:30,180 --> 00:06:33,120
Neither one feels good, and the
elastic pool fixes this by
221
00:06:33,120 --> 00:06:34,740
turning it into a timeshare.
222
00:06:34,740 --> 00:06:36,180
You put a group of databases on
223
00:06:36,180 --> 00:06:37,740
one server, and they share one
224
00:06:37,740 --> 00:06:39,220
fixed pool of resources for one
225
00:06:39,220 --> 00:06:39,860
price.
226
00:06:39,860 --> 00:06:42,660
The busy ones borrow while the
idle ones give back.
227
00:06:42,660 --> 00:06:43,860
The shared resources are
228
00:06:43,860 --> 00:06:45,920
measured in E, dtus or vcores,
229
00:06:45,920 --> 00:06:47,259
but you can think of it as one
230
00:06:47,259 --> 00:06:48,660
tank of fuel that everyone draws
231
00:06:48,660 --> 00:06:49,220
from.
232
00:06:49,220 --> 00:06:51,180
Microsoft's own example makes it
concrete.
233
00:06:51,180 --> 00:06:54,060
Twenty databases that each spike
to ninety Dtus, but average
234
00:06:54,060 --> 00:06:56,420
under five can share one hundred
editors between them.
235
00:06:56,420 --> 00:06:57,699
That's a twenty times reduction
236
00:06:57,699 --> 00:06:59,019
in resources and about a
237
00:06:59,019 --> 00:07:00,220
thirteen times reduction in
238
00:07:00,220 --> 00:07:01,939
price compared with sizing each
239
00:07:01,939 --> 00:07:02,899
one separately.
240
00:07:02,899 --> 00:07:04,019
The intuition is that those
241
00:07:04,019 --> 00:07:05,620
peaks never line up, so the pool
242
00:07:05,620 --> 00:07:06,579
rarely serves more than a
243
00:07:06,579 --> 00:07:07,899
fraction of the total demand at
244
00:07:07,899 --> 00:07:08,420
once.
245
00:07:08,420 --> 00:07:10,959
The pattern that benefits is
specific, and this is the part
246
00:07:10,959 --> 00:07:12,339
people get wrong.
247
00:07:12,339 --> 00:07:14,899
Pools suit databases with low
average use and short,
248
00:07:14,899 --> 00:07:17,819
infrequent spikes that don't all
happen at the same time.
249
00:07:17,819 --> 00:07:20,819
Savings can show up with as few
as two standard tier databases,
250
00:07:20,819 --> 00:07:23,579
and the more you add, the better
the math usually gets.
251
00:07:23,579 --> 00:07:25,019
But if your databases are busy
252
00:07:25,019 --> 00:07:26,540
all day, every day, don't pool
253
00:07:26,540 --> 00:07:26,779
them.
254
00:07:26,779 --> 00:07:28,660
They'll fight each other for the
same resources.
255
00:07:28,660 --> 00:07:30,980
And you'll wonder why
performance got worse.
256
00:07:30,980 --> 00:07:33,060
What Azure handles so you don't
have to.
257
00:07:33,060 --> 00:07:36,060
We've saved the part that should
let you sleep at night.
258
00:07:36,060 --> 00:07:38,620
This is where the managed
service really earns its keep.
259
00:07:38,620 --> 00:07:40,180
Backups happen automatically and
260
00:07:40,180 --> 00:07:41,379
you can't accidentally switch
261
00:07:41,379 --> 00:07:42,300
them off.
262
00:07:42,300 --> 00:07:45,019
Azure takes a full backup every
week, a differential backup
263
00:07:45,019 --> 00:07:47,420
every twelve to twenty four
hours, and a log backup roughly
264
00:07:47,420 --> 00:07:48,540
every ten minutes.
265
00:07:48,540 --> 00:07:50,899
That gives you something like an
undo button point in time.
266
00:07:50,899 --> 00:07:53,779
Restore lets you roll a database
back to a specific moment within
267
00:07:53,779 --> 00:07:54,699
the retention window.
268
00:07:54,699 --> 00:07:55,980
That window is seven days by
269
00:07:55,980 --> 00:07:57,680
default and configurable up to
270
00:07:57,680 --> 00:07:58,620
thirty five.
271
00:07:58,620 --> 00:08:01,500
When someone drops a table on a
Friday afternoon, this feature
272
00:08:01,500 --> 00:08:03,939
is the difference between a bad
day and a disaster.
273
00:08:03,939 --> 00:08:06,180
If you need more than that,
there are two more layers.
274
00:08:06,180 --> 00:08:09,420
Geo restore lets you rebuild in
a completely different region.
275
00:08:09,420 --> 00:08:10,800
When the primary one is having
276
00:08:10,800 --> 00:08:12,300
trouble and it's switched on by
277
00:08:12,300 --> 00:08:12,819
default.
278
00:08:12,819 --> 00:08:15,939
Long term retention keeps full
backups for up to ten years,
279
00:08:15,939 --> 00:08:18,139
which is the kind of thing
compliance teams ask for.
280
00:08:18,139 --> 00:08:19,420
You just have to turn it on
281
00:08:19,420 --> 00:08:20,680
because it isn't on out of the
282
00:08:20,680 --> 00:08:21,339
box.
283
00:08:21,339 --> 00:08:23,779
There's a small catch that trips
people up, so it's worth saying
284
00:08:23,779 --> 00:08:27,139
plainly you can't download these
automatic backups like a file
285
00:08:27,139 --> 00:08:27,540
they live in.
286
00:08:27,540 --> 00:08:28,939
Microsoft managed storage and
287
00:08:28,939 --> 00:08:30,079
exist to be restored, not
288
00:08:30,079 --> 00:08:30,860
exported.
289
00:08:30,860 --> 00:08:32,299
If you genuinely need a copy of
290
00:08:32,299 --> 00:08:33,899
your data outside Azure, you
291
00:08:33,899 --> 00:08:35,019
export a portable package
292
00:08:35,019 --> 00:08:35,620
instead.
293
00:08:35,620 --> 00:08:38,259
And the odd part is that
deleting a database doesn't
294
00:08:38,259 --> 00:08:39,860
delete its backups right away.
295
00:08:39,860 --> 00:08:42,299
Deleting and recreating a
database to save money can
296
00:08:42,299 --> 00:08:43,620
actually cost you more.
297
00:08:43,620 --> 00:08:45,019
High availability works the same
298
00:08:45,019 --> 00:08:46,139
way, and it mostly stays
299
00:08:46,139 --> 00:08:47,019
invisible.
300
00:08:47,019 --> 00:08:48,460
By default, your data is copied
301
00:08:48,460 --> 00:08:49,899
three times inside a single data
302
00:08:49,899 --> 00:08:51,419
center, and committed data is
303
00:08:51,419 --> 00:08:52,139
never lost.
304
00:08:52,139 --> 00:08:55,179
If a machine running your
database fails, Azure moves you
305
00:08:55,179 --> 00:08:56,659
to a new one automatically.
306
00:08:56,659 --> 00:08:59,259
For something stronger, you
enable zone redundancy, which
307
00:08:59,259 --> 00:09:01,899
spreads your database across two
or three zones in a region.
308
00:09:01,899 --> 00:09:03,039
That way, a whole data center
309
00:09:03,039 --> 00:09:04,299
going dark doesn't take you with
310
00:09:04,299 --> 00:09:04,620
it.
311
00:09:04,620 --> 00:09:06,059
Just know it isn't available on
312
00:09:06,059 --> 00:09:07,700
the basic or standard tiers at
313
00:09:07,700 --> 00:09:08,299
all.
314
00:09:08,299 --> 00:09:11,000
Though it's available on general
purpose, business, critical,
315
00:09:11,000 --> 00:09:12,779
hyperscale, and premium.
316
00:09:12,779 --> 00:09:15,139
The availability guarantee
climbs along with all of that,
317
00:09:15,139 --> 00:09:17,990
Microsoft's published service
level agreement puts zone
318
00:09:17,990 --> 00:09:20,730
redundant business critical and
premium databases at a guarantee
319
00:09:20,730 --> 00:09:23,309
of at least ninety nine point
nine nine five percent, and
320
00:09:23,309 --> 00:09:25,350
business critical includes one
more nice bonus.
321
00:09:25,350 --> 00:09:26,789
It gives you a free read only
322
00:09:26,789 --> 00:09:28,509
copy of your database, so your
323
00:09:28,509 --> 00:09:29,830
reports and analytics can run
324
00:09:29,830 --> 00:09:30,750
there and leave your main
325
00:09:30,750 --> 00:09:32,190
workload alone.
326
00:09:32,190 --> 00:09:34,629
Security without the jargon,
backups protect you from
327
00:09:34,629 --> 00:09:36,950
accidents, and security protects
you from people.
328
00:09:36,950 --> 00:09:39,549
It helps to see it as layers
moving from the outside.
329
00:09:39,549 --> 00:09:42,909
In the outer layer is the front
door and by default it's locked.
330
00:09:42,909 --> 00:09:46,429
Nothing reaches your server
until you explicitly allow it.
331
00:09:46,429 --> 00:09:49,190
Firewall rules let you permit
access by IP address.
332
00:09:49,190 --> 00:09:51,830
You can restrict everything to
your own virtual network so only
333
00:09:51,830 --> 00:09:53,429
your own systems can lock.
334
00:09:53,429 --> 00:09:55,149
The next layer is who you are.
335
00:09:55,149 --> 00:09:57,909
You can sign in with Microsoft
Entry ID, the identity system
336
00:09:57,909 --> 00:10:00,309
that used to be called Azure
Active Directory, or with a
337
00:10:00,309 --> 00:10:03,549
plain SQL username and password
entry is the better choice when
338
00:10:03,549 --> 00:10:04,429
you can use it.
339
00:10:04,429 --> 00:10:05,950
It brings multifactor sign in
340
00:10:05,950 --> 00:10:07,789
conditional access rules, and a
341
00:10:07,789 --> 00:10:08,909
way to stop hard coding
342
00:10:08,909 --> 00:10:10,029
passwords into connection
343
00:10:10,029 --> 00:10:10,789
strings.
344
00:10:10,789 --> 00:10:13,230
Then there's what you're allowed
to do once you're inside.
345
00:10:13,230 --> 00:10:14,350
The guiding idea is least
346
00:10:14,350 --> 00:10:15,429
privilege, which just means
347
00:10:15,429 --> 00:10:16,470
giving people the smallest
348
00:10:16,470 --> 00:10:17,830
amount of access they need to do
349
00:10:17,830 --> 00:10:18,309
their job.
350
00:10:18,309 --> 00:10:19,769
If you need to go further, row
351
00:10:19,769 --> 00:10:20,909
level security can hide
352
00:10:20,909 --> 00:10:22,070
individual rows.
353
00:10:22,070 --> 00:10:23,509
That way a user only ever sees
354
00:10:23,509 --> 00:10:24,789
their own records, which is
355
00:10:24,789 --> 00:10:26,070
handy when many customers share
356
00:10:26,070 --> 00:10:27,029
one database.
357
00:10:27,029 --> 00:10:28,309
Encryption shows up in three
358
00:10:28,309 --> 00:10:29,549
places, and the good news is
359
00:10:29,549 --> 00:10:30,710
that the most important one is
360
00:10:30,710 --> 00:10:31,629
already on.
361
00:10:31,629 --> 00:10:34,190
Data in transit is always
encrypted with TLS.
362
00:10:34,190 --> 00:10:36,950
Data at rest is protected by
transparent data encryption,
363
00:10:36,950 --> 00:10:39,710
which is switched on by default
on every new database.
364
00:10:39,710 --> 00:10:42,230
And for a specific sensitive
column, like a credit card
365
00:10:42,230 --> 00:10:44,629
number, always encrypted can
keep even your own database
366
00:10:44,629 --> 00:10:46,029
administrators from reading it.
367
00:10:46,029 --> 00:10:47,509
The key never reaches the
servers at all.
368
00:10:47,509 --> 00:10:48,549
Finally, there's watching for
369
00:10:48,549 --> 00:10:50,149
trouble auditing records who did
370
00:10:50,149 --> 00:10:51,990
what into your own storage and
371
00:10:51,990 --> 00:10:53,629
defender for cloud raises a flag
372
00:10:53,629 --> 00:10:55,149
on things like SQL injection
373
00:10:55,149 --> 00:10:56,789
attempts and strange sign in
374
00:10:56,789 --> 00:10:57,470
patterns.
375
00:10:57,470 --> 00:10:58,990
You can also classify and label
376
00:10:58,990 --> 00:11:00,029
the sensitive data in your
377
00:11:00,029 --> 00:11:01,710
database, which gives you a map
378
00:11:01,710 --> 00:11:02,990
of where your risk actually
379
00:11:02,990 --> 00:11:03,629
lives.
380
00:11:03,629 --> 00:11:06,509
The plain takeaway is that the
safe settings are the defaults.
381
00:11:06,509 --> 00:11:07,750
Your main job is deciding who
382
00:11:07,750 --> 00:11:09,370
gets in and what they can touch,
383
00:11:09,370 --> 00:11:11,269
Azure SQL database or a virtual
384
00:11:11,269 --> 00:11:11,909
machine.
385
00:11:11,909 --> 00:11:14,870
Everything so far assumes you
want a managed database, but
386
00:11:14,870 --> 00:11:17,470
there's a real fork in the road
here, and it's worth saying out
387
00:11:17,470 --> 00:11:20,830
loud, you can hand Microsoft the
keys, or you can keep them.
388
00:11:20,830 --> 00:11:23,049
Choose the managed Azure SQL
389
00:11:23,049 --> 00:11:24,690
database when you want patching,
390
00:11:24,690 --> 00:11:26,110
upgrades, backups, and high
391
00:11:26,110 --> 00:11:27,509
availability taken off your
392
00:11:27,509 --> 00:11:28,110
plate.
393
00:11:28,110 --> 00:11:30,629
Choose it when you want that
higher availability guarantee.
394
00:11:30,629 --> 00:11:31,389
And when you're building
395
00:11:31,389 --> 00:11:32,509
something new and want to move
396
00:11:32,509 --> 00:11:32,909
quickly.
397
00:11:32,909 --> 00:11:34,029
It's built for cloud first
398
00:11:34,029 --> 00:11:35,909
applications and for teams that
399
00:11:35,909 --> 00:11:36,909
would rather ship than
400
00:11:36,909 --> 00:11:37,909
administer.
401
00:11:37,909 --> 00:11:39,269
It also lets one person manage
402
00:11:39,269 --> 00:11:40,470
far more databases than they
403
00:11:40,470 --> 00:11:41,710
ever could by hand, which
404
00:11:41,710 --> 00:11:43,110
matters once your project starts
405
00:11:43,110 --> 00:11:43,710
to grow.
406
00:11:43,710 --> 00:11:45,110
Choose SQL server on an Azure
407
00:11:45,110 --> 00:11:46,570
Virtual Machine when you need
408
00:11:46,570 --> 00:11:48,350
operating system level access,
409
00:11:48,350 --> 00:11:49,470
or when you want full control
410
00:11:49,470 --> 00:11:50,830
over the engine, choose it when
411
00:11:50,830 --> 00:11:52,070
you have to match an existing on
412
00:11:52,070 --> 00:11:52,830
premises setup.
413
00:11:52,830 --> 00:11:55,470
Exactly, or when you're lifting
an old application into the
414
00:11:55,470 --> 00:11:56,789
cloud with no code changes.
415
00:11:56,789 --> 00:11:59,110
With a virtual machine, you
decide when updates run and you
416
00:11:59,110 --> 00:12:00,149
get every feature.
417
00:12:00,149 --> 00:12:03,590
You also own the patching, the
backups, and failover plan.
418
00:12:03,590 --> 00:12:04,950
If your application depends on
419
00:12:04,950 --> 00:12:06,230
the operating system or on
420
00:12:06,230 --> 00:12:07,830
scheduled jobs inside SQL server
421
00:12:07,830 --> 00:12:09,309
itself, the virtual machine is
422
00:12:09,309 --> 00:12:10,590
often the only option that won't
423
00:12:10,590 --> 00:12:11,149
fight you.
424
00:12:11,149 --> 00:12:13,029
There's a middle option worth
knowing about.
425
00:12:13,029 --> 00:12:14,590
Azure SQL Managed Instance gives
426
00:12:14,590 --> 00:12:16,029
you close to full SQL server
427
00:12:16,029 --> 00:12:17,549
compatibility while keeping the
428
00:12:17,549 --> 00:12:18,909
managed benefits, and Microsoft
429
00:12:18,909 --> 00:12:19,950
recommends it for most
430
00:12:19,950 --> 00:12:20,830
migrations.
431
00:12:20,830 --> 00:12:22,230
So if you're moving an existing
432
00:12:22,230 --> 00:12:23,590
system and full control isn't
433
00:12:23,590 --> 00:12:24,549
actually required.
434
00:12:24,549 --> 00:12:25,909
That's often the sweet spot.
435
00:12:25,909 --> 00:12:27,549
The trade off in one line is
this.
436
00:12:27,549 --> 00:12:30,210
Managed means less work and a
stronger guarantee, but fewer
437
00:12:30,210 --> 00:12:31,309
knobs to turn.
438
00:12:31,309 --> 00:12:32,509
A virtual machine means every
439
00:12:32,509 --> 00:12:34,070
knob you could want and the
440
00:12:34,070 --> 00:12:35,309
responsibility that comes with
441
00:12:35,309 --> 00:12:36,070
them.
442
00:12:36,070 --> 00:12:37,350
If you're new to all this, the
443
00:12:37,350 --> 00:12:38,549
honest default is to start
444
00:12:38,549 --> 00:12:40,190
managed and only reach for the
445
00:12:40,190 --> 00:12:41,429
virtual machine when you have a
446
00:12:41,429 --> 00:12:43,230
specific reason.
447
00:12:43,230 --> 00:12:44,750
The mistakes beginners make
448
00:12:44,750 --> 00:12:46,070
knowing the right choice is half
449
00:12:46,070 --> 00:12:46,789
the battle.
450
00:12:46,789 --> 00:12:49,350
The other half is not tripping
over the same handful of things
451
00:12:49,350 --> 00:12:52,110
that catch almost everyone, so
let's run through them.
452
00:12:52,110 --> 00:12:54,909
The first is paying for peak you
never use, or the opposite,
453
00:12:54,909 --> 00:12:57,309
starving a database to save a
few dollars and then wondering
454
00:12:57,309 --> 00:12:58,110
why it's slow.
455
00:12:58,110 --> 00:12:59,230
What's your real usage for a
456
00:12:59,230 --> 00:13:00,370
couple of weeks and size to
457
00:13:00,370 --> 00:13:00,789
that?
458
00:13:00,789 --> 00:13:01,830
Not to a guess.
459
00:13:01,830 --> 00:13:03,870
Next comes pooling the wrong
databases.
460
00:13:03,870 --> 00:13:05,350
Elastic pools are for spiky,
461
00:13:05,350 --> 00:13:06,870
mostly idle databases, not for
462
00:13:06,870 --> 00:13:08,269
workloads that run flat out all
463
00:13:08,269 --> 00:13:08,750
day.
464
00:13:08,750 --> 00:13:09,950
Put the busy ones in a pool and
465
00:13:09,950 --> 00:13:10,909
they'll compete for the same
466
00:13:10,909 --> 00:13:11,789
resources.
467
00:13:11,789 --> 00:13:12,750
A third one is choosing
468
00:13:12,750 --> 00:13:14,070
serverless for an always on
469
00:13:14,070 --> 00:13:15,470
application, and then getting
470
00:13:15,470 --> 00:13:16,710
annoyed by the pause and wake
471
00:13:16,710 --> 00:13:17,389
delay.
472
00:13:17,389 --> 00:13:19,909
Serverless is for intermittent
use, full stop.
473
00:13:19,909 --> 00:13:20,909
Another is forgetting that
474
00:13:20,909 --> 00:13:22,129
backup retention defaults to
475
00:13:22,129 --> 00:13:22,710
seven days.
476
00:13:22,710 --> 00:13:23,710
If you need to keep history
477
00:13:23,710 --> 00:13:25,200
longer or a compliance rule
478
00:13:25,200 --> 00:13:25,679
demands it.
479
00:13:25,679 --> 00:13:27,919
You have to turn on long term
retention yourself.
480
00:13:27,919 --> 00:13:30,720
One more is assuming zone
redundancy comes included on the
481
00:13:30,720 --> 00:13:31,720
basic and standard tiers.
482
00:13:31,720 --> 00:13:32,679
It doesn't exist at all.
483
00:13:32,679 --> 00:13:34,960
So you have to pick a supporting
tier and switch it on.
484
00:13:34,960 --> 00:13:37,919
And the last is treating the
firewall as an afterthought.
485
00:13:37,919 --> 00:13:40,899
Nothing gets in until you say
so, and the safest habit is to
486
00:13:40,899 --> 00:13:43,799
keep it that way, allowing only
the addresses and networks that
487
00:13:43,799 --> 00:13:45,320
genuinely need access.
488
00:13:45,320 --> 00:13:47,159
None of these are exotic
mistakes.
489
00:13:47,159 --> 00:13:48,000
They're just the ones that
490
00:13:48,000 --> 00:13:49,360
quietly cost people money and
491
00:13:49,360 --> 00:13:50,639
sleep.
492
00:13:50,639 --> 00:13:52,519
Wrapping up what to remember.
493
00:13:52,519 --> 00:13:53,700
Let's pull this together into
494
00:13:53,700 --> 00:13:54,879
something you can actually hold
495
00:13:54,879 --> 00:13:55,720
on to.
496
00:13:55,720 --> 00:13:58,639
Azure SQL database is the SQL
server engine running as a
497
00:13:58,639 --> 00:14:01,600
managed service in Microsoft's
Cloud, you choose how you pay
498
00:14:01,600 --> 00:14:05,600
either the DTU bundle or the
build your own Vcore model, and
499
00:14:05,600 --> 00:14:07,440
then you pick a tier and a size.
500
00:14:07,440 --> 00:14:08,600
You can share resources across
501
00:14:08,600 --> 00:14:10,080
many databases with an elastic
502
00:14:10,080 --> 00:14:11,799
pool, or let a quiet database
503
00:14:11,799 --> 00:14:12,440
pause itself.
504
00:14:12,440 --> 00:14:15,080
With serverless backups, high
availability, and encryption all
505
00:14:15,080 --> 00:14:17,720
come switched on, and you reach
for it instead of a virtual
506
00:14:17,720 --> 00:14:19,799
machine whenever you'd rather
not run the server yourself.
507
00:14:19,799 --> 00:14:22,000
So I'll leave you with one
question to sit with.
508
00:14:22,000 --> 00:14:24,559
If Microsoft took patching
backups and failover off your
509
00:14:24,559 --> 00:14:27,360
plate tomorrow, what would you
actually spend that time on?
