WEBVTT
00:00:00.490 --> 00:00:02.180
Hi, my name's Grahan Cooley.
00:00:02.180 --> 00:00:04.440
I am here with Anton Kucer.
00:00:04.440 --> 00:00:09.009
I am the Senior Product Marketing
Manager for the Azure CDN product,
00:00:09.009 --> 00:00:12.412
and Anton is our Program Manager for
the Azure CDN.
00:00:12.412 --> 00:00:14.423
Thanks, everyone, for coming.
00:00:14.423 --> 00:00:17.050
Hope that you're enjoying
the show so far.
00:00:18.340 --> 00:00:20.110
Today we're gonna talk
about a few things.
00:00:22.880 --> 00:00:25.490
First we're gonna talk about
briefly what is a CDN.
00:00:25.490 --> 00:00:27.820
There's different ways about
talking about a CDN and
00:00:27.820 --> 00:00:30.320
we wanna go over some of the basics
to make sure that we're all
00:00:30.320 --> 00:00:31.190
speaking the same language.
00:00:32.840 --> 00:00:36.390
Then we'll talk about why
Azure CDN in particular.
00:00:36.390 --> 00:00:41.890
There's a bunch of different ways to
both purchase and deploy CDNs today,
00:00:41.890 --> 00:00:45.220
from building your own internally
all the way out to purchasing from
00:00:45.220 --> 00:00:48.850
a pure CDN provider, or
from a cloud platform like Azure.
00:00:50.120 --> 00:00:53.320
So we'll talk a little bit
about what is different about
00:00:54.410 --> 00:00:56.600
our CDN from the average CDN.
00:00:57.990 --> 00:00:59.720
And then we'll talk
about what's new.
00:00:59.720 --> 00:01:03.290
The whole purpose of today is
to give you a preview of what
00:01:03.290 --> 00:01:07.270
the Azure Premium CDN
offer is gonna look like.
00:01:07.270 --> 00:01:10.290
We'll do a deeper dive into the new
features that are gonna be coming
00:01:10.290 --> 00:01:13.900
with the new offer when it
debuts later this summer.
00:01:15.020 --> 00:01:18.130
This is really our first time
discussing this kind of widely and
00:01:18.130 --> 00:01:21.350
publicly, so we're gonna be eager
for questions from you guys.
00:01:21.350 --> 00:01:24.480
So we're gonna stop when we get into
the features section at the end of
00:01:24.480 --> 00:01:28.100
each feature discussion and
ask you if you have any follow-up
00:01:28.100 --> 00:01:31.230
questions to really do a deeper
dive into what they consist of.
00:01:31.230 --> 00:01:32.660
Some of those are fairly
straightforward,
00:01:32.660 --> 00:01:33.610
some are a little more complex.
00:01:34.620 --> 00:01:37.554
And then we'll give you at the very
end of that a couple of the features
00:01:37.554 --> 00:01:39.593
that we have coming even
further down the line.
00:01:39.593 --> 00:01:44.535
And at the very end we'll leave the
questions open just generally, so
00:01:44.535 --> 00:01:48.360
feel free to shoot any
questions that you have.
00:01:48.360 --> 00:01:51.550
Don't feel shy at all
about raising your hands.
00:01:51.550 --> 00:01:56.420
And then let's get started.
00:01:56.420 --> 00:01:59.360
Let's test out our hand raising
by seeing how many people here
00:01:59.360 --> 00:02:03.030
feel that they have a good
understanding of what a CDN does?
00:02:04.210 --> 00:02:06.170
Good, good.
00:02:06.170 --> 00:02:09.240
How many of you are actively using
CDNs today in your own solution?
00:02:09.240 --> 00:02:10.702
Very good.
00:02:13.708 --> 00:02:15.191
Let's go a little solution specific.
00:02:15.191 --> 00:02:18.543
How many are using CDNs for
video streaming today?
00:02:21.489 --> 00:02:27.630
How about for application or CDN or
website performance acceleration?
00:02:27.630 --> 00:02:28.130
Very good.
00:02:30.130 --> 00:02:34.280
And then how about just your
standard static file delivery?
00:02:34.280 --> 00:02:35.918
Talk about firmware or
software updates.
00:02:40.530 --> 00:02:43.069
And how many people thought that
they were coming in to hear about
00:02:43.069 --> 00:02:44.350
something specific to Canada?
00:02:46.370 --> 00:02:49.550
No, that's good.
It's happened a couple times before.
00:02:49.550 --> 00:02:55.160
All right, so what is a CDN?
00:02:55.160 --> 00:02:58.150
So let's talk real quickly
about the core CDN elements.
00:02:58.150 --> 00:02:59.559
We tried to really boil this down.
00:02:59.559 --> 00:03:02.964
For those of you that are very
familiar with CDNs this may
00:03:02.964 --> 00:03:04.530
be a little repetitive.
00:03:04.530 --> 00:03:08.600
But it's good as in
there's a colloquial
00:03:08.600 --> 00:03:11.600
version when people talk about CDNs,
there's also industry terms.
00:03:11.600 --> 00:03:14.130
So we wanna kinda baseline
everybody and make sure that
00:03:14.130 --> 00:03:16.780
they understand where we're coming
from when we talk about CDNs.
00:03:18.930 --> 00:03:21.070
This is at a fairly
superficial level,
00:03:21.070 --> 00:03:23.110
so there's always gonna
be some variance.
00:03:23.110 --> 00:03:26.390
So don't get too upset if something
in there is oversimplified.
00:03:27.960 --> 00:03:31.200
CDN has a very high level
that's easy to understand,
00:03:31.200 --> 00:03:34.300
and then boy, you kind of
skip that second level and
00:03:34.300 --> 00:03:36.300
you get deep into the weeds when
you're doing configuration.
00:03:36.300 --> 00:03:38.510
So this is going to be
kind of a baseline,
00:03:38.510 --> 00:03:41.730
and then we'll jump into
the weeds a little bit later on.
00:03:41.730 --> 00:03:45.410
So at its core CDN involves three
elements from our perspective.
00:03:45.410 --> 00:03:47.990
First is the Customer Origin Server,
00:03:47.990 --> 00:03:51.070
which is where the customer
places their content.
00:03:51.070 --> 00:03:54.750
The second is the CDN Edge Network
of POP locations,
00:03:54.750 --> 00:03:58.030
where the customer will
point towards his content.
00:03:59.130 --> 00:04:01.238
And then finally,
you have the HTTP client,
00:04:01.238 --> 00:04:03.633
which requests the customer
content via that CDN.
00:04:07.595 --> 00:04:10.677
The interaction of those and
the play from in a circuit is
00:04:10.677 --> 00:04:13.880
how the CDN kind of
accelerates that delivery.
00:04:13.880 --> 00:04:16.000
And we'll try and stick to these
color codes as we go forward.
00:04:17.260 --> 00:04:21.830
So the common core CDN traffic flow
involves those three elements.
00:04:21.830 --> 00:04:23.223
When a client requests an asset,
00:04:23.223 --> 00:04:25.810
the check is performed to find
out whether the requested asset
00:04:25.810 --> 00:04:27.617
has already been cached
in that POP or not.
00:04:31.397 --> 00:04:34.470
For the purposes of this discussion,
we'll assume that it isn't.
00:04:37.260 --> 00:04:39.230
If it is,
it'll be immediately served up.
00:04:39.230 --> 00:04:42.630
In the diagram here we assume that
on the first request it is not.
00:04:42.630 --> 00:04:45.000
So there's no previously
cached asset, and
00:04:45.000 --> 00:04:48.540
the first step of serving this asset
is for the POP closest to the client
00:04:48.540 --> 00:04:51.450
to retrieve that requested
asset from the origin server.
00:04:51.450 --> 00:04:56.300
So once that POP closest to the
client receives the requested asset,
00:04:56.300 --> 00:04:58.330
the next step involves
sending it to the client,
00:04:58.330 --> 00:05:01.150
after which it will cache
the asset on an Edge Server.
00:05:01.150 --> 00:05:04.598
So in the above diagram
you see the client and
00:05:04.598 --> 00:05:08.380
a first request,
requesting of the Edge Network.
00:05:08.380 --> 00:05:10.700
Edge Network doesn't have it,
checks with the origin server.
00:05:10.700 --> 00:05:12.520
Origin server sends it back
to the Edge Network and
00:05:12.520 --> 00:05:13.930
all the way back to the client.
00:05:13.930 --> 00:05:17.060
Now the advantage of CDN is more
on the subsequent requests.
00:05:17.060 --> 00:05:19.360
So from there on forward,
00:05:21.280 --> 00:05:24.820
the client is gonna have a direct
connection with the Edge Network.
00:05:24.820 --> 00:05:26.630
The purpose there is
to serve that asset as
00:05:26.630 --> 00:05:29.490
close to the client as possible.
00:05:29.490 --> 00:05:34.840
Now when we say close here, often
we do mean geographically close,
00:05:34.840 --> 00:05:38.410
but in realistic terms,
we mean network closeness.
00:05:38.410 --> 00:05:39.216
So network closeness and
00:05:39.216 --> 00:05:40.989
geographic closeness may not
be the same exact thing.
00:05:47.491 --> 00:05:49.280
So how does a CDN help?
00:05:49.280 --> 00:05:52.866
So in a normal situation
without a CDN,
00:05:52.866 --> 00:05:58.084
what you see is a request from
a client's computer travel
00:05:58.084 --> 00:06:02.976
through their ISP through
the regular Internet, and
00:06:02.976 --> 00:06:09.417
this is generally what is referred
to in the industry as the last mile.
00:06:13.724 --> 00:06:14.822
And I just described it backwards.
00:06:14.822 --> 00:06:18.803
The first request from the computer.
00:06:18.803 --> 00:06:19.839
Let's just see here.
00:06:22.704 --> 00:06:24.289
HTTP client to the Internet
is that last mile.
00:06:24.289 --> 00:06:27.042
It's called the last mile cuz
we're thinking about it from
00:06:27.042 --> 00:06:28.840
ourselves just serving traffic out.
00:06:28.840 --> 00:06:33.410
That center part where the data is
traveling is called the middle mile.
00:06:33.410 --> 00:06:37.060
And the first mile is that
business from the original server
00:06:37.060 --> 00:06:37.860
to the Internet.
00:06:38.930 --> 00:06:44.520
So what we really do is
minimize that round trip
00:06:44.520 --> 00:06:47.600
and make that middle mile efficient.
00:06:47.600 --> 00:06:52.630
The biggest advantage there is
minimizing that first mile traffic.
00:06:54.490 --> 00:07:00.970
Any questions up to this point?
00:07:00.970 --> 00:07:05.384
Cool, so with a CDN what you're
doing is placing the Edge Network in
00:07:05.384 --> 00:07:07.860
between that Internet connection.
00:07:07.860 --> 00:07:12.830
So the public Internet is not
optimized, obviously, for
00:07:12.830 --> 00:07:17.770
your particular asset travel.
00:07:17.770 --> 00:07:20.794
We call this the bacon effect.
00:07:20.794 --> 00:07:24.946
I would normally put up a big
picture of Kevin Bacon here, but
00:07:24.946 --> 00:07:29.600
I think we're a little concerned
about copyright infringement.
00:07:29.600 --> 00:07:31.480
So for
this purposes of this discussion,
00:07:31.480 --> 00:07:34.070
bacon is just regular bacon.
00:07:34.070 --> 00:07:39.214
So in a normal Internet scenario,
the relationships
00:07:39.214 --> 00:07:43.950
between ISPs and
networks can be loose.
00:07:45.150 --> 00:07:46.168
You have various levels of
00:07:46.168 --> 00:07:47.839
relationships that
travel through them.
00:07:47.839 --> 00:07:53.610
So on the last slide the middle
mile looked very simple as a box.
00:07:53.610 --> 00:07:56.450
In reality it is a huge aspect.
00:07:58.870 --> 00:08:02.970
We think of the Internet as actually
many networks of loosely combined
00:08:03.980 --> 00:08:06.570
through a myriad of agreements
that connect one another.
00:08:06.570 --> 00:08:08.110
Sometimes those
agreements are strong and
00:08:08.110 --> 00:08:11.300
formal, but often they are casual
and comparatively weak.
00:08:12.460 --> 00:08:14.660
When you request a piece of data
through the public Internet,
00:08:14.660 --> 00:08:17.650
that request travels through
a network of those relationships,
00:08:17.650 --> 00:08:21.510
often very many of them,
hence the possibly up to six or
00:08:21.510 --> 00:08:22.740
seven degrees of separation.
00:08:22.740 --> 00:08:23.601
Hence the Bacon effect.
00:08:23.601 --> 00:08:27.800
So it can travel in a nonlinear way.
00:08:27.800 --> 00:08:31.360
It can get from point to point based
on whatever the network conditions
00:08:31.360 --> 00:08:37.750
define at that time, and it's rarely
the case that it will be the same.
00:08:37.750 --> 00:08:40.720
All the way from the original
client request to the origin.
00:08:40.720 --> 00:08:42.402
Then it's gotta come back, and
00:08:42.402 --> 00:08:44.966
it will come back in
the same haphazard pattern.
00:08:49.375 --> 00:08:53.940
So with a CDN we call it
the direct bacon effect.
00:08:53.940 --> 00:08:58.490
You now have a direct
connection between two points.
00:08:58.490 --> 00:09:01.540
So your client will
request its data.
00:09:01.540 --> 00:09:02.908
That data will travel
out across the ISP.
00:09:02.908 --> 00:09:07.801
You've pre-notified the client that
you've loaded that information on
00:09:07.801 --> 00:09:13.757
a CDN, so it's gonna go
directly out to the CDN.
00:09:19.364 --> 00:09:19.933
And then it's gonna come back.
00:09:24.586 --> 00:09:30.350
In this representation,
the purple is the Edge Network.
00:09:30.350 --> 00:09:34.770
It's gonna communicate directly
with a POP that is close to
00:09:34.770 --> 00:09:36.460
the origin location.
00:09:36.460 --> 00:09:41.560
It's gonna load that origin up and
it's gonna serve that asset not only
00:09:41.560 --> 00:09:47.650
to your end client but to the Edge
Network closest to that client.
00:09:47.650 --> 00:09:51.950
It does travel over that but these
agreements are much more curated.
00:09:51.950 --> 00:09:56.075
Essentially part of what you're
doing when you buy a service like
00:09:56.075 --> 00:10:00.275
CDN is not only are you purchasing
access to The hardware that makes
00:10:00.275 --> 00:10:05.000
these transits significantly more
efficient, but you're also standing
00:10:05.000 --> 00:10:09.350
behind the agreements and the
relationships they've built with all
00:10:09.350 --> 00:10:12.500
the individual network
providers over there.
00:10:12.500 --> 00:10:14.470
They understand what the network
looks like at a particular
00:10:14.470 --> 00:10:19.700
point in time, and will choose the
route that is best for your travel.
00:10:19.700 --> 00:10:23.350
Furthermore, you get
the No Bacon Effect going forward
00:10:24.410 --> 00:10:26.800
as we saw on that first or
second slide.
00:10:26.800 --> 00:10:31.860
The information will served directly
from the Edge going forward.
00:10:33.310 --> 00:10:37.284
Subsequent requests to that same
content are available from the Edge.
00:10:37.284 --> 00:10:40.474
So if we're closer to the end.
00:10:40.474 --> 00:10:41.334
Can you bump that forward for me?
00:10:45.195 --> 00:10:48.800
All right so,
when is it good to use a CDN?
00:10:51.170 --> 00:10:54.180
Utilizing a CDN is a good
general practice, but
00:10:54.180 --> 00:10:55.160
there are always conditions for
00:10:55.160 --> 00:10:59.540
which is better suited and those
where it may not be a better ideal.
00:10:59.540 --> 00:11:02.880
Best care scenario for a CDN is
where the content is relatively
00:11:02.880 --> 00:11:08.140
static, and by that I mean it's
not going to require refreshment
00:11:08.140 --> 00:11:11.800
over and over again in between
being served to multiple clients.
00:11:11.800 --> 00:11:15.890
Although there are additional
services that you can use to
00:11:15.890 --> 00:11:18.020
mitigate that and
allow it to be more dynamic,
00:11:18.020 --> 00:11:20.140
and we'll talk about
that a little bit later.
00:11:20.140 --> 00:11:23.730
And you're looking for situations
where the end users are many and
00:11:23.730 --> 00:11:25.640
at some distance from the origin.
00:11:25.640 --> 00:11:30.584
So many users, not proximate
to the original origin,
00:11:30.584 --> 00:11:34.890
and can be reused that data over and
over again.
00:11:37.140 --> 00:11:38.410
When not to use a CDN.
00:11:39.440 --> 00:11:42.500
Very well could be a scenario where
the origin itself is actually better
00:11:42.500 --> 00:11:44.510
suited to deliver to
a group of users.
00:11:44.510 --> 00:11:49.490
So the most common scenario there
is where the content is expected to
00:11:49.490 --> 00:11:53.520
be broadcast to a limited area,
particularly close to the origin
00:11:53.520 --> 00:11:56.100
where the network hops
may not be that numerous.
00:11:56.100 --> 00:11:59.320
So actual hops again may
not be represented by that
00:11:59.320 --> 00:12:00.710
geographic distance.
00:12:00.710 --> 00:12:03.230
So it's important to do testing on
your actual solution to determine
00:12:03.230 --> 00:12:04.520
what your scenario demands.
00:12:04.520 --> 00:12:06.949
When we say close, again, we're
talking about network closeness.
00:12:08.600 --> 00:12:11.110
There are a myriad of
different ways that
00:12:11.110 --> 00:12:14.800
the networks are constructed
that could result in things that
00:12:14.800 --> 00:12:16.640
make not a lot of sense
as the crow flies.
00:12:16.640 --> 00:12:20.900
I think one of the biggest examples
is in LatAm, where the network
00:12:20.900 --> 00:12:23.710
connections between each other
are not always the best.
00:12:23.710 --> 00:12:25.036
And, often times,
00:12:25.036 --> 00:12:29.800
you'll see a network transit all the
way up through Miami and back down.
00:12:29.800 --> 00:12:33.239
Even if the countries
are right next to each other.
00:12:33.239 --> 00:12:37.500
>> Must be a secure VPN connection?
00:12:37.500 --> 00:12:39.720
>> No, it wouldn't be over
a secure VPN connection.
00:12:39.720 --> 00:12:41.600
Still over the open internet.
00:12:41.600 --> 00:12:45.619
But over a peering or
a transit route.
00:12:45.619 --> 00:12:46.554
>> Okay.
>> But it could be coupled
00:12:46.554 --> 00:12:47.059
with SSL, right?
00:12:47.059 --> 00:12:49.343
>> Yeah.
I mean the other example,
00:12:49.343 --> 00:12:54.302
the extreme example of outside of
LatAm is China where a lot of people
00:12:54.302 --> 00:12:58.391
assume that if you're not
using a POPS inside of China,
00:12:58.391 --> 00:13:03.460
that you should serve directly from
somewhere just in the vicinity.
00:13:03.460 --> 00:13:05.780
Like Hong Kong or
Singapore something like that.
00:13:05.780 --> 00:13:07.410
The reality is those
transit routes and
00:13:07.410 --> 00:13:10.180
the peering routes get
incredibly congested.
00:13:10.180 --> 00:13:14.170
China has no incentive to increase
the pipes that are coming out, and
00:13:14.170 --> 00:13:17.010
so we'll find that in many cases
actually coming out from Miami once
00:13:17.010 --> 00:13:20.010
again you can have much
better performance.
00:13:20.010 --> 00:13:22.500
Because if you have a pipe and
I'm shrinking that pipe down,
00:13:22.500 --> 00:13:25.170
everyone's trying to get their data
through because it seems to be
00:13:25.170 --> 00:13:28.640
the cheapest and fastest way, it's
not always the best performance, so.
00:13:28.640 --> 00:13:31.020
We'll sometimes have people take
a look at trace routes, and go,
00:13:31.020 --> 00:13:32.330
hey why are you serving
out from Miami?
00:13:32.330 --> 00:13:35.100
It's cuz it's actually faster
than trying to go directly in.
00:13:35.100 --> 00:13:37.290
Yeah exactly.
00:13:37.290 --> 00:13:39.810
>> And it's often you get the time
zone differences as well.
00:13:39.810 --> 00:13:43.580
Part of the intelligence built in
is that network part of it where it
00:13:43.580 --> 00:13:46.920
it knows that the Miami POP and
everyone in Miami is asleep.
00:13:46.920 --> 00:13:48.350
And everyone in China is awake.
00:13:48.350 --> 00:13:51.449
It may legitimately be faster
at any given point in time for
00:13:51.449 --> 00:13:53.789
it to travel around the world and
come back,
00:13:53.789 --> 00:13:56.269
if the local area is
particularly congested.
00:13:59.989 --> 00:14:03.986
Another scenario where a CDN may
not be completely appropriate is
00:14:03.986 --> 00:14:07.472
transfer of small, or
single large files to a specific or
00:14:07.472 --> 00:14:09.450
limited number of recipients.
00:14:09.450 --> 00:14:12.890
One of the most common scenarios
here would be ingesting
00:14:12.890 --> 00:14:13.460
into Azure, right?
00:14:13.460 --> 00:14:16.690
You have a single file you
want to ingest into Azure.
00:14:16.690 --> 00:14:19.741
If you're doing that
regularly with large volumes,
00:14:19.741 --> 00:14:23.673
you may want to look at something
like Azure's Express Route service
00:14:23.673 --> 00:14:27.159
which would give you a direct
connection to the data center.
00:14:27.159 --> 00:14:30.521
If you were uploading files, maybe
not to Azure directly, but to point
00:14:30.521 --> 00:14:33.840
to point to an individual person,
CDN might not be the best solution.
00:14:33.840 --> 00:14:38.040
But again, we have partners like
Aspera that do fast file transfer
00:14:38.040 --> 00:14:41.950
that would allow that,
probably a little bit more smoothly.
00:14:41.950 --> 00:14:46.710
The point generally being we have
00:14:46.710 --> 00:14:49.100
a general set of rules which
apply to most people, but
00:14:49.100 --> 00:14:53.530
it's always best to come in and
check and test your own system.
00:14:53.530 --> 00:14:56.886
We have a session tomorrow on
performance and monitoring,
00:14:56.886 --> 00:15:00.241
where we'll dive a little bit
more deeply into the tools and
00:15:00.241 --> 00:15:02.000
techniques about doing that.
00:15:02.000 --> 00:15:05.592
All right, before we jump into that,
00:15:05.592 --> 00:15:11.559
any general questions on how we
see CDN from that perspective?
00:15:11.559 --> 00:15:14.939
>> [INAUDIBLE]
>> Sure.
00:15:14.939 --> 00:15:19.480
>> So what do you see
the difference in these cases for
00:15:19.480 --> 00:15:22.300
CDN versus WAN acceleration?
00:15:22.300 --> 00:15:23.740
>> CDN versus WAN acceleration.
00:15:26.639 --> 00:15:29.879
>> Depends on, I mean you,
with WAN, it's a local.
00:15:29.879 --> 00:15:31.562
You're doing localize,
00:15:31.562 --> 00:15:36.619
what's an example when you're saying
WAN acceleration, so we can compare?
00:15:36.619 --> 00:15:40.118
>> Just doing file
transfers from server UP,
00:15:40.118 --> 00:15:43.429
personally have a data
center in the US.
00:15:43.429 --> 00:15:48.036
We're doing file transfers from
Australia to a data center in
00:15:48.036 --> 00:15:52.997
the US so we have an accelerator
in our data center, an accelerator
00:15:52.997 --> 00:15:57.439
in wherever I said, Australia
wherever it is right there.
00:15:57.439 --> 00:15:58.409
>> Yeah.
00:15:58.409 --> 00:16:00.169
>> Try to help with stuff like that.
00:16:00.169 --> 00:16:03.647
>> So yeah, it kind of gets to what
Grant was talking about earlier in
00:16:03.647 --> 00:16:05.735
terms of, there's a tipping point.
00:16:05.735 --> 00:16:10.095
People tend to think of the CDN
as this kind of magic pixie dust.
00:16:10.095 --> 00:16:11.165
Like just throw in everything.
00:16:11.165 --> 00:16:14.845
And we actually see that dramatic
effect in Azure because it's so
00:16:14.845 --> 00:16:16.380
easy to go turn it on.
00:16:16.380 --> 00:16:20.550
Where when we look at those kind of
statistics in terms of the thousands
00:16:20.550 --> 00:16:23.180
of people that have, tens of
thousands of people that have turned
00:16:23.180 --> 00:16:25.730
on CDN, and how many of them are
actually doing significant traffic
00:16:25.730 --> 00:16:29.530
that would have any kind of dramatic
effect on what they're doing.
00:16:29.530 --> 00:16:31.640
And in most cases, they've just
turned it on small amounts of
00:16:31.640 --> 00:16:33.940
traffic moving up and down.
00:16:33.940 --> 00:16:38.210
There's no actual number that
where it becomes better, but
00:16:38.210 --> 00:16:42.640
I like to compare it to, if you
have like a few 100 clients that
00:16:42.640 --> 00:16:46.640
are accessing the content,
you're not really maximizing CDN.
00:16:46.640 --> 00:16:48.100
In many cases,
you're adding an extra hop and
00:16:48.100 --> 00:16:49.260
you're actually slowing things down.
00:16:49.260 --> 00:16:51.140
So when we talk about a kind
of a WAN acceleration,
00:16:51.140 --> 00:16:53.980
those are typically kind of more
long tail content that we are just
00:16:53.980 --> 00:16:56.190
trying to move it to
a small number of users.
00:16:56.190 --> 00:16:59.300
CDNs really start showing their
power when you get into thousands of
00:16:59.300 --> 00:17:00.770
users who are there.
00:17:00.770 --> 00:17:01.980
If you think about
the edge of a CDN,
00:17:01.980 --> 00:17:05.760
each one of those POPS is a data
center that is connected to
00:17:05.760 --> 00:17:11.690
a major transit center,
peering location for the internet,
00:17:11.690 --> 00:17:17.640
and it's hundreds to
thousands of servers.
00:17:17.640 --> 00:17:20.560
When you've first request it,
it comes into the Edge,
00:17:20.560 --> 00:17:23.010
you're gonna optimize it for the
small numbers that are coming in, so
00:17:23.010 --> 00:17:25.000
there's probably a single server
at the Edge that's serving it.
00:17:25.000 --> 00:17:28.080
Now as you have more, and more
connect, clients who are coming, and
00:17:28.080 --> 00:17:28.580
connecting in,
00:17:28.580 --> 00:17:32.315
you'll actually see performance
start to dramatically improve.
00:17:32.315 --> 00:17:36.580
As a file gets spread
across n number of servers,
00:17:36.580 --> 00:17:39.520
and then you start serving directly
out of memory versus out of
00:17:39.520 --> 00:17:40.810
directly off of the disk.
00:17:40.810 --> 00:17:45.290
So it's, if you try to
compare WAN acceleration,
00:17:45.290 --> 00:17:48.060
probably not ideal for
what you're trying to do with a CDN.
00:17:48.060 --> 00:17:50.120
Now there can be cases if
you're trying to accelerate and
00:17:50.120 --> 00:17:51.470
there's a large number of clients,
or
00:17:51.470 --> 00:17:54.360
you're kind of simultaneously
requesting the content.
00:17:55.920 --> 00:18:00.750
But yeah it's, kinda each scenario
you have to look at case by case and
00:18:02.730 --> 00:18:04.000
see, will the CDN work for me?
00:18:04.000 --> 00:18:06.260
Am I just adding something because
I don't truly understand what's
00:18:06.260 --> 00:18:08.480
happening and I think it's just
going to magically improve things.
00:18:08.480 --> 00:18:10.010
And in many cases it does, and
00:18:10.010 --> 00:18:13.460
then there's many cases where
it actually won't improve it.
00:18:13.460 --> 00:18:14.270
Did I answer the question or?
00:18:16.370 --> 00:18:20.013
And, you may wanna take a look at
the fast file transfer stuff like
00:18:20.013 --> 00:18:20.749
Aspera has.
00:18:20.749 --> 00:18:25.007
So, in those situations, that's
generally more expensive on a case
00:18:25.007 --> 00:18:29.191
by case basis, but if you're only
moving a limited number of files,
00:18:29.191 --> 00:18:32.240
it can really make a lot
of sense to your business.
00:18:32.240 --> 00:18:34.560
Any other questions?
00:18:34.560 --> 00:18:36.799
Cool, thanks for the questions.
00:18:36.799 --> 00:18:40.075
So, why Azure CDN?
00:18:40.075 --> 00:18:44.464
So our current offer
00:18:44.464 --> 00:18:49.110
has a fairly limited feature set
that was set a couple years ago.
00:18:49.110 --> 00:18:51.860
So what we're talking about today
and what we're gonna go into here in
00:18:51.860 --> 00:18:56.970
a little bit is our
re-engineering it for
00:18:56.970 --> 00:19:01.010
the modern work scenario for CDN.
00:19:01.010 --> 00:19:03.100
Our CDN, historically,
00:19:04.670 --> 00:19:08.380
was built in 2009-2010 mostly to
support the Windows update scenario.
00:19:08.380 --> 00:19:11.360
About a year ago, we implemented a
new architecture which was intended
00:19:11.360 --> 00:19:15.930
to match the current state
of the CDN marketplace.
00:19:15.930 --> 00:19:18.730
So, what'd happened in
the intervening years had
00:19:18.730 --> 00:19:20.350
been streaming video and
00:19:22.130 --> 00:19:27.020
site acceleration had become
the more dominant work scenarios.
00:19:27.020 --> 00:19:32.180
That's optimized for unknown number
of users at unknown points in
00:19:32.180 --> 00:19:35.749
time downloading file sizes that are
also largely variable or unknown.
00:19:37.180 --> 00:19:39.650
Our historic network had been
built for Windows updates, right?
00:19:39.650 --> 00:19:41.560
Which is pretty much
the exact opposite.
00:19:41.560 --> 00:19:43.840
Known number of users,
known file sizes and
00:19:43.840 --> 00:19:46.751
total control over when
that's gonna be distributed.
00:19:46.751 --> 00:19:50.196
So what we saw was that we
needed to make changes to make
00:19:50.196 --> 00:19:53.731
sure that that was meeting
the current market demand.
00:19:53.731 --> 00:19:58.099
So about a year ago we switched over
to a new architecture, Which is
00:19:58.099 --> 00:20:02.624
an underlying network is now a tier
one infrastructure that provides
00:20:02.624 --> 00:20:07.230
very quality service to thousands
of Azure CDN customers now.
00:20:07.230 --> 00:20:09.920
All of the features that we have
today are going to continue to be
00:20:09.920 --> 00:20:10.450
available but
00:20:10.450 --> 00:20:13.770
we're going to dramatically
expand into two new offers.
00:20:13.770 --> 00:20:16.900
So basic, or standard offer and
a premium offer.
00:20:16.900 --> 00:20:20.080
And the premium offer we'll
go into at some length.
00:20:20.080 --> 00:20:24.380
So, the current features, as I said,
are organized towards these pillars.
00:20:24.380 --> 00:20:26.000
We wanted it to be integrated.
00:20:26.000 --> 00:20:30.210
So, one of the advantages
Azure has over, say,
00:20:30.210 --> 00:20:34.040
a peer plate provider, would be
the single screen management and
00:20:34.040 --> 00:20:35.320
your unitary billing, and support.
00:20:37.030 --> 00:20:38.790
It does have some
customizations today.
00:20:43.804 --> 00:20:47.726
Custom domain names, query strings,
and then it does provide
00:20:47.726 --> 00:20:51.500
a significant level of convenience
in that it does automatic
00:20:51.500 --> 00:20:55.867
load-balancing and it plugs in
really well with our other services.
00:20:58.923 --> 00:21:02.227
From a unique standpoint,
we feel that these are really
00:21:02.227 --> 00:21:06.026
the differences that are gonna
happen from a cloud provider like
00:21:06.026 --> 00:21:10.870
Azure as oppose to a peer plate CDN
provider or building it yourself.
00:21:10.870 --> 00:21:13.588
It's integrated.
You're gonna have single sign on and
00:21:13.588 --> 00:21:17.699
unitary management of multiple
services and partner services.
00:21:17.699 --> 00:21:19.823
You're gonna be able to
control all of that.
00:21:19.823 --> 00:21:22.751
Close integration,
it has been developed or
00:21:22.751 --> 00:21:27.143
is under development with the other
Microsoft and Azure services,
00:21:27.143 --> 00:21:32.010
like Express Route, Media Services,
Web Sites and our Mobile services.
00:21:33.190 --> 00:21:37.100
The goal there is to make
that as close to a one-click
00:21:37.100 --> 00:21:39.180
experience as possible.
00:21:39.180 --> 00:21:42.350
We don't always meet that goal
today, but that's exactly what we're
00:21:42.350 --> 00:21:45.790
shooting for, make that a smooth and
painless as possible.
00:21:45.790 --> 00:21:47.350
Support is obviously huge.
00:21:47.350 --> 00:21:49.810
We stand behind all of our services.
00:21:49.810 --> 00:21:52.920
And you know where you can reach us.
00:21:52.920 --> 00:21:56.740
Single point of contact allowing for
quick and more efficient diagnosis
00:21:56.740 --> 00:21:59.110
and resolution in these
complex scenarios.
00:21:59.110 --> 00:22:01.469
And then you also have access
to all of our partners.
00:22:03.490 --> 00:22:05.570
Billing is a huge convenience,
right?
00:22:05.570 --> 00:22:08.530
You can track all of that,
alongside your other services.
00:22:08.530 --> 00:22:11.785
It's a lot easier when you're
building deployments for
00:22:11.785 --> 00:22:15.392
your customers if you can manage
that a lot more simply on ours.
00:22:22.450 --> 00:22:26.259
Long term, we are looking at
implementing many different
00:22:26.259 --> 00:22:30.500
advantages for
that to being a portfolio provider.
00:22:30.500 --> 00:22:34.310
One of those you'll see is that we
expect to be able to build different
00:22:34.310 --> 00:22:36.970
services in parallel, right?
00:22:36.970 --> 00:22:39.440
So you'll have different
flavors of CDN available and
00:22:39.440 --> 00:22:43.540
be able to manage those.
00:22:43.540 --> 00:22:44.090
So what's new?
00:22:44.090 --> 00:22:45.912
Any questions on any of that?
00:22:50.486 --> 00:22:51.647
>> One thing I should point out.
00:22:51.647 --> 00:22:55.060
One of the last points on there
was around no commitments,
00:22:55.060 --> 00:22:57.091
which can be taken one of two ways.
00:22:57.091 --> 00:22:58.379
[LAUGH]
>> [LAUGH]
00:22:58.379 --> 00:22:59.661
>> So when you use a CDM,
00:22:59.661 --> 00:23:02.883
you don't have to tell us
how much you're gonna use.
00:23:02.883 --> 00:23:07.529
But the reality is if you expect
that you're gonna push through large
00:23:07.529 --> 00:23:11.053
amounts of data If you want
the optimal experience,
00:23:11.053 --> 00:23:12.912
you should reach out to us.
00:23:12.912 --> 00:23:16.128
Usually we look at if in
the North America, Europe,
00:23:16.128 --> 00:23:20.880
if you're gonna be pushing more than
25Gbps, throughput at any periods of
00:23:20.880 --> 00:23:24.990
time come ask us to make sure that
the POPs are able to do what you do.
00:23:24.990 --> 00:23:26.200
Or that we can, in many cases,
00:23:26.200 --> 00:23:28.700
we can adjust and shape the traffic
around, take that into account.
00:23:28.700 --> 00:23:30.830
And so once again,
00:23:30.830 --> 00:23:33.470
this kinda gets back to my comment
around the magic pixie dust.
00:23:33.470 --> 00:23:35.990
We also think of the Cloud
as this completely flexible,
00:23:35.990 --> 00:23:36.940
just handle everything.
00:23:36.940 --> 00:23:39.904
Well, there are realities, cuz if
you have, you know, a hundred large
00:23:39.904 --> 00:23:42.530
customers who just wanna push
through massive amounts of data,
00:23:42.530 --> 00:23:44.200
it's gonna bump up
against each other.
00:23:44.200 --> 00:23:48.414
So, similar to the everyone's trying
shove everything into China, today.
00:23:48.414 --> 00:23:52.463
So the two points we
look at are in US,
00:23:52.463 --> 00:23:56.390
North America, Europe 25Gvps.
00:23:56.390 --> 00:24:00.030
And then as you get out into Asia we
like to take a look if you are doing
00:24:00.030 --> 00:24:02.252
over 10Gvps in a particular country.
00:24:02.252 --> 00:24:05.337
In most cases we can handle it, but
it kind of depends on what your
00:24:05.337 --> 00:24:07.750
loads are and
when you're gonna push it through.
00:24:07.750 --> 00:24:11.530
So, and it kind of segues into,
once again, a pitch for tomorrow.
00:24:11.530 --> 00:24:14.190
We'll go more in-depth in terms of
performance aspects ,and how you
00:24:14.190 --> 00:24:16.360
consider it, and how
00:24:19.920 --> 00:24:23.470
use the CDN correctly as opposed
to just trying use it as a funnel,
00:24:23.470 --> 00:24:26.220
you just try and throw through
data as quickly as possible.
00:24:26.220 --> 00:24:27.386
>> Well, Danny,
do you bring- oh go ahead.
00:24:27.386 --> 00:24:33.168
>> So what limitations do you
have on the point of origin?
00:24:33.168 --> 00:24:36.221
Like we're using Kaltura for video.
00:24:36.221 --> 00:24:37.721
>> Mm-hm
>> It's on the cloud,
00:24:37.721 --> 00:24:38.962
it's on our data center.
00:24:38.962 --> 00:24:45.647
And we still use Azure CPM, with,
you know, an external origin.
00:24:45.647 --> 00:24:47.250
>> In about a month.
00:24:47.250 --> 00:24:49.500
So, you can today if
you reach out to us.
00:24:49.500 --> 00:24:54.050
So we have the ability to have a CDN
supplemental portal where on a case
00:24:54.050 --> 00:24:56.020
by case basis we can expose,
00:24:56.020 --> 00:24:57.980
the advanced features that
Grant's gonna walk through.
00:24:57.980 --> 00:25:00.920
We do for a limited set of
customers, we do provide that for
00:25:00.920 --> 00:25:01.480
them today.
00:25:01.480 --> 00:25:03.390
So we just haven't made it
generally available to everyone.
00:25:03.390 --> 00:25:07.500
So if you reach out to us separately
we can go set that up for you.
00:25:07.500 --> 00:25:10.660
We'll be updating in the May,
June timeframe
00:25:10.660 --> 00:25:13.530
the existing Azure portals so that
it supports any kind of origins.
00:25:13.530 --> 00:25:17.320
So you can put in any
HTTP URL that you want.
00:25:17.320 --> 00:25:20.550
So when you're going back to
your origin, you'll be able to,
00:25:20.550 --> 00:25:21.580
as long as its HTTP or
00:25:21.580 --> 00:25:25.060
HTTPS you can use any port you
want going back to your origin.
00:25:25.060 --> 00:25:27.540
That will be supported very shortly.
00:25:27.540 --> 00:25:30.470
>> There's a couple of high-level
philosophy points that are behind
00:25:30.470 --> 00:25:32.438
both of those things that
Anton was just talking about.
00:25:32.438 --> 00:25:35.180
First, o n the no commitment and
00:25:35.180 --> 00:25:39.020
the way that we present these
offers is intended to be for
00:25:39.020 --> 00:25:41.750
people who are making these kind
of platform purchases, right.
00:25:41.750 --> 00:25:45.730
We understand that there's a massive
amount of Azure services and
00:25:45.730 --> 00:25:47.540
there's a massive amount
of Microsoft services.
00:25:47.540 --> 00:25:50.880
So, we try and streamline that
experience as much as possible.
00:25:50.880 --> 00:25:54.268
So, these are intended to be
bundles, which will come at
00:25:54.268 --> 00:25:58.081
a specific per gig price, rather
than some baseline traffic and
00:25:58.081 --> 00:26:01.066
then a bunch of additional
services added on top.
00:26:01.066 --> 00:26:04.545
So it's intended to be for the pay
as you go customer to make that as
00:26:04.545 --> 00:26:07.320
simple and
as straightforward as possible.
00:26:07.320 --> 00:26:13.540
And then on the point of
external origin, I think you've
00:26:13.540 --> 00:26:17.060
seen that shift that Microsoft
has had in the last year or so.
00:26:17.060 --> 00:26:22.550
It's really an important point
from Sation down that we not be
00:26:22.550 --> 00:26:26.590
limiting what it is that allows
you to do your business.
00:26:26.590 --> 00:26:32.490
So, and, opening up to any external
origin is one aspect of that.
00:26:32.490 --> 00:26:33.740
That's incredibly important right?
00:26:33.740 --> 00:26:36.573
We want you to be able to get
what you need from us but
00:26:36.573 --> 00:26:40.096
not feel that you are tied to any
particular part of what we do.
00:26:40.096 --> 00:26:42.800
So that's a huge important part.
00:26:42.800 --> 00:26:44.447
It's gonna be one of the first
things that come out of
00:26:44.447 --> 00:26:46.258
this features and we'll talk
about it a little bit more.
00:26:46.258 --> 00:26:47.593
>> I saw a hand in the back.
00:26:47.593 --> 00:26:52.410
>> Right now Azure's
tied to the cloud server?
00:26:52.410 --> 00:26:55.630
>> So today it's tied to,
you can do a hosted service,
00:26:55.630 --> 00:26:59.440
you can do Azure storage,
you can do websites.
00:26:59.440 --> 00:27:03.830
And then also if you go to
Media Services, we tie in
00:27:03.830 --> 00:27:07.580
directly from the Media Services
side, so Azure Media Services.
00:27:07.580 --> 00:27:08.890
So those are the four.
00:27:08.890 --> 00:27:11.189
And then May, June will allow
you to put in any URL you want.
00:27:14.851 --> 00:27:17.761
>> As I mentioned before
that kind of integration and
00:27:17.761 --> 00:27:21.709
the smooth integration of that will
extend even after we open up this
00:27:21.709 --> 00:27:22.930
external origin.
00:27:22.930 --> 00:27:25.450
So we do want to make it as
smooth and simple as possible for
00:27:25.450 --> 00:27:27.930
you if your using another
additional Azure service.
00:27:27.930 --> 00:27:30.090
But we don't want you to feel
limited to any of those.
00:27:32.510 --> 00:27:33.460
Any other questions?
00:27:35.260 --> 00:27:38.480
Cool, thanks for those questions.
00:27:38.480 --> 00:27:38.980
So, what's new?
00:27:41.070 --> 00:27:42.600
Here's the current offer landscape.
00:27:43.610 --> 00:27:45.840
We just talked about it, these
are things that are available today.
00:27:49.590 --> 00:27:52.676
I think I could.
00:27:52.676 --> 00:27:55.309
It is ironic that I continue to
talk about how awesome a one click
00:27:55.309 --> 00:27:56.104
button would be and
00:27:56.104 --> 00:27:58.702
then I can't manage the one click
button I have in front of me.
00:27:58.702 --> 00:28:01.229
[LAUGH] So today currently we have
access content from the Azure
00:28:01.229 --> 00:28:04.252
origins as we just talked about, the
query strings that we talked about.
00:28:04.252 --> 00:28:09.213
Custom domain names, that single
stream management, enterprise
00:28:09.213 --> 00:28:14.100
class billing and support and
then that inherent load balancing.
00:28:14.100 --> 00:28:17.920
What's coming up next is we're gonna
split our service into a standard
00:28:17.920 --> 00:28:20.008
CDN service and premium CDN service.
00:28:20.008 --> 00:28:23.570
So you're gonna get all the stuff
that you got before but
00:28:23.570 --> 00:28:26.850
we're gonna add the access to
content from external origins.
00:28:26.850 --> 00:28:28.830
We're gonna include content
purging and loading.
00:28:30.660 --> 00:28:31.860
Country filtering.
00:28:31.860 --> 00:28:32.790
Origin shield.
00:28:32.790 --> 00:28:35.790
A basic rules engine in the standard
package and a more advanced rules
00:28:35.790 --> 00:28:39.260
engine available in
the Premium CDN package.
00:28:39.260 --> 00:28:43.310
Basic analytics will be included and
more advanced analytics will
00:28:43.310 --> 00:28:44.990
be available in
the Premium CDN package,
00:28:44.990 --> 00:28:48.314
as well as token authentication.
00:28:48.314 --> 00:28:55.730
Stand-alone coming soon is gonna
be our custom SSL support.
00:28:55.730 --> 00:28:59.370
And then coming a little bit down
the line is advanced security,
00:28:59.370 --> 00:29:04.389
which is basically your web
application firewalls and
00:29:04.389 --> 00:29:06.830
support for
advanced dynamic content.
00:29:06.830 --> 00:29:09.658
>> What does Stand-alone mean?
00:29:09.658 --> 00:29:13.185
>> Stand-alone means it will,
so as I mentioned the,
00:29:13.185 --> 00:29:17.771
we're trying to make these packages
be as consumable as possible.
00:29:17.771 --> 00:29:20.448
So Standard CDN will be
at a flat per GIG rate,
00:29:20.448 --> 00:29:23.125
Premium CDN will be at
a flat per GIG rate, and
00:29:23.125 --> 00:29:26.316
then Custom SSL will have
a little uplift above that.
00:29:41.082 --> 00:29:42.910
>> Pretty much everything.
00:29:42.910 --> 00:29:47.740
Now we'll try to guide people more
towards, or away to an extent,
00:29:47.740 --> 00:29:49.440
from you actually
providing your certificate,
00:29:49.440 --> 00:29:51.760
where we'd actually
manage it directly.
00:29:51.760 --> 00:29:53.560
Just more secure.
00:29:53.560 --> 00:29:55.280
You don't have to worry about.
00:29:55.280 --> 00:29:58.451
You can be your own domain that you
want, your own custom domain, but
00:29:58.451 --> 00:30:01.183
it's more secure in terms of
Every two years or when you've
00:30:01.183 --> 00:30:04.211
got to renew your certificate
we'd handle that automatically.
00:30:04.211 --> 00:30:05.921
If there's any kind
of security issue we
00:30:05.921 --> 00:30:08.639
can easily update everyone's
certificates at the same time but
00:30:08.639 --> 00:30:11.170
we'll pretty much have every
option that you can think of.
00:30:11.170 --> 00:30:12.480
>> You also gonna offer people with
00:30:12.480 --> 00:30:14.450
current cdn's to wait
migrate through?
00:30:21.290 --> 00:30:23.165
>> Depends on the rules.
00:30:23.165 --> 00:30:28.950
Yeah, the interesting thing
about CDN is regardless of what
00:30:28.950 --> 00:30:32.570
we present is here's our advance and
our kind of standard offerings.
00:30:32.570 --> 00:30:36.660
There's a lot of custom
work that can be done,
00:30:36.660 --> 00:30:39.090
rules that can be written for
customers.
00:30:39.090 --> 00:30:41.340
Today we're just going over
kind of a basic set of
00:30:41.340 --> 00:30:42.040
things that can happen.
00:30:42.040 --> 00:30:44.810
But there's a lot of complex on the
CDN where you could actually have if
00:30:44.810 --> 00:30:46.800
you're doing authentication
at the edge.
00:30:46.800 --> 00:30:49.160
Where you could actually
go back to your origin and
00:30:49.160 --> 00:30:52.050
have a workflow that involves
callbacks to your origin.
00:30:52.050 --> 00:30:54.920
So it really depends on
what you're trying to do.
00:30:54.920 --> 00:30:58.750
We haven't seen any customer from
a large CDN that we haven't been
00:30:58.750 --> 00:31:00.070
able to migrate over.
00:31:01.510 --> 00:31:04.220
But it's going to be case by case
in terms of what would it take
00:31:04.220 --> 00:31:07.020
to move over, and
it depends on what you're using.
00:31:07.020 --> 00:31:09.620
And then the other thing
to always consider if
00:31:09.620 --> 00:31:13.610
you migrate a customer is don't
expect to do it over night.
00:31:13.610 --> 00:31:16.970
By that I mean you don't want
to blow away your cache.
00:31:16.970 --> 00:31:18.920
So typically if you set up
your rules you have the same
00:31:18.920 --> 00:31:21.270
configuration, slowly
migrate the content over so
00:31:21.270 --> 00:31:25.490
that if you switched over night onto
a new CDN you're gonna be filling
00:31:25.490 --> 00:31:26.610
that cache on the CDN again.
00:31:26.610 --> 00:31:29.690
And you can see issues where your
origins start getting pounded
00:31:29.690 --> 00:31:32.910
a little bit, or your performance
goes down slightly until you're
00:31:32.910 --> 00:31:35.800
actually primed to get all
the pops for your client requests.
00:31:37.120 --> 00:31:40.440
>> But, what we've seen in the CDN
industry is that it was established
00:31:40.440 --> 00:31:45.150
in a different time when this kind
of flexibility wasn't the norm.
00:31:45.150 --> 00:31:47.790
So, very difficult for us to,
well it's very difficult for
00:31:47.790 --> 00:31:50.690
anyone to map features
from CDN to CDN.
00:31:50.690 --> 00:31:51.450
At the end of the day,
00:31:51.450 --> 00:31:54.890
most of them have a way to
provide the same output.
00:31:54.890 --> 00:31:58.250
And what we really need to do when
we've migrated existing customers
00:31:58.250 --> 00:32:01.170
onto us is trying to figure
out what their end result is.
00:32:01.170 --> 00:32:04.420
Not necessarily have to match
exactly feature to feature but
00:32:04.420 --> 00:32:07.890
we recognize that as a pain point
and what we're trying to do is
00:32:07.890 --> 00:32:10.990
standardize as much
of that as possible.
00:32:10.990 --> 00:32:12.280
Over the next.
00:32:12.280 --> 00:32:14.850
Few years we've already
seen them started
00:32:14.850 --> 00:32:16.310
to make the conversion over, right.
00:32:16.310 --> 00:32:18.430
A lot more API driven stuff.
00:32:18.430 --> 00:32:21.830
Which freezes us up a little
bit more to try and
00:32:21.830 --> 00:32:26.274
make that feature map switch
over a little better.
00:32:26.274 --> 00:32:36.640
>> [INAUDIBLE]
00:32:36.640 --> 00:32:39.970
>> Most you can do yourself when
Grant was talking about last year.
00:32:39.970 --> 00:32:41.920
This was around April timeframe
where we moved off of the off
00:32:41.920 --> 00:32:43.700
of the old infrastructure.
00:32:43.700 --> 00:32:46.840
It was a lot of migration going on
because we completely moved everyone
00:32:46.840 --> 00:32:47.750
off an old infrastructure,
00:32:47.750 --> 00:32:50.220
it was multiple years over,
onto the new one.
00:32:50.220 --> 00:32:53.020
>> And
in that case we you know we just
00:32:53.020 --> 00:32:55.535
handle whatever migration
needed to happen.
00:32:55.535 --> 00:32:58.940
But it really depends on
00:32:58.940 --> 00:33:02.280
if it's we as much as possible
try to make it self provisioning.
00:33:02.280 --> 00:33:07.360
So that you can do it yourself but
there are workflows where we would
00:33:07.360 --> 00:33:09.760
need to have some kinda professional
services involved to move it over.
00:33:09.760 --> 00:33:12.070
Or really we'd have to see what
exactly what their work flow is, so
00:33:12.070 --> 00:33:13.410
it really depends.
00:33:13.410 --> 00:33:16.820
Assume that if you went to one
of the other big CDM's and
00:33:16.820 --> 00:33:19.383
it took them a month or
two to get you set up, [LAUGH]
00:33:19.383 --> 00:33:24.190
self provisioning might not happen
exactly the way you'd want it to.
00:33:25.370 --> 00:33:27.060
>> We're very familiar with
the painpoint right in
00:33:27.060 --> 00:33:28.200
addition to being a provider.
00:33:28.200 --> 00:33:31.240
Microsoft is also one of the biggest
CDN customers on the planet. Right.
00:33:31.240 --> 00:33:33.830
So all of our individual divisions
00:33:33.830 --> 00:33:38.080
in some cases utilize multiple
versions for different providers.
00:33:38.080 --> 00:33:41.020
So we often have to see
00:33:41.020 --> 00:33:43.800
how to balance between
multiple CDN providers.
00:33:43.800 --> 00:33:48.330
Multi-CDNs becoming the kinda
standard for the large deployments
00:33:48.330 --> 00:33:52.120
today, so what we're seeing
is more of a willingness for
00:33:52.120 --> 00:33:59.860
them to not feel that they have
to lock into a specific provider. Cool.
00:33:59.860 --> 00:34:03.130
Any other questions? Cool.
00:34:03.130 --> 00:34:03.840
Thank you for that question.
00:34:06.850 --> 00:34:09.370
Alright, as we talked about,
external origins.
00:34:09.370 --> 00:34:12.640
We talked about this new
philosophy of Microsoft where
00:34:12.640 --> 00:34:15.970
it's important for us to insure that
you can utilize our services as your
00:34:15.970 --> 00:34:20.060
business dictates,
not as our business dictates.
00:34:20.060 --> 00:34:22.850
We very much want you to feel
that you can use your own CDN in
00:34:22.850 --> 00:34:24.730
a manner that best supports
your own solution.
00:34:25.740 --> 00:34:28.490
And that means we don't want you
to have to be tied to any other
00:34:28.490 --> 00:34:30.030
additional services if
you don't want to be.
00:34:31.220 --> 00:34:33.400
We certainly work hard to make sure
that if you do want to use those
00:34:33.400 --> 00:34:36.850
services, the experience
is as smooth as possible.
00:34:36.850 --> 00:34:40.000
And, as I said, I think our goal
was to get as close to a one click
00:34:40.000 --> 00:34:43.630
integration of those other services,
one click deployment of CDNs with
00:34:43.630 --> 00:34:47.210
those is but, we're admittedly
that's far from universal.
00:34:48.230 --> 00:34:50.540
We talked a little bit of
external origin all ready, but
00:34:50.540 --> 00:34:52.080
if there are any other questions.
00:34:52.080 --> 00:34:53.720
I wanna stop at the end
of each feature slide and
00:34:53.720 --> 00:34:56.540
make sure that everyone gets
their questions answered.
00:34:58.020 --> 00:35:00.380
Anything on external origin?
00:35:00.380 --> 00:35:03.269
No, practical limitations
once it's deployed.
00:35:04.790 --> 00:35:10.400
But basically just drop the what's
going to be the interface connected
00:35:10.400 --> 00:35:12.310
to an external [INAUDIBLE].
00:35:12.310 --> 00:35:14.940
>> Just a drop down where you
can put any kind of HTTP,
00:35:14.940 --> 00:35:16.560
HPS service out.
00:35:16.560 --> 00:35:17.300
>> Yeah.
00:35:17.300 --> 00:35:20.440
>> So and what we've seen for
most of the large amount of
00:35:20.440 --> 00:35:23.750
customers using external it's
around from their own data centers.
00:35:23.750 --> 00:35:25.910
Sometimes from another
cloud provider.
00:35:25.910 --> 00:35:28.280
And kind of the beauty of Azure for
so
00:35:28.280 --> 00:35:31.290
many of the services or all services
is just how easy it is to use.
00:35:31.290 --> 00:35:34.560
So if you have an existing CM
provider it's very simple to kind of
00:35:34.560 --> 00:35:38.850
take a portion of your traffic,
light up Azure CDN and try it.
00:35:38.850 --> 00:35:43.121
About a month from now there won't
be any limitations in terms of what
00:35:43.121 --> 00:35:44.753
origin you use that from.
00:35:44.753 --> 00:35:46.130
>> Yeah.
00:35:46.130 --> 00:35:48.620
>> Common scenarios we see is
when people want to maintain
00:35:48.620 --> 00:35:52.140
strict control over their own
content or update it regularly.
00:35:53.190 --> 00:35:56.500
They might have unique content
policies or as Antoine
00:35:58.200 --> 00:36:03.270
mentioned the move from on prem
to the cloud often starts with
00:36:03.270 --> 00:36:06.340
content delivery networks
where it's the easiest piece,
00:36:06.340 --> 00:36:08.260
for some people it's
the easiest piece to.
00:36:09.410 --> 00:36:12.660
To carve off of their core services
that they have on their on premises.
00:36:12.660 --> 00:36:15.880
So we want to make sure that they
can continue to operate everything
00:36:15.880 --> 00:36:18.140
else the way that they have,
00:36:18.140 --> 00:36:22.230
and take just advantage of delivery
options if that's what they want.
00:36:22.230 --> 00:36:24.864
>> Even though their cloud is,
if you have deployment or
00:36:24.864 --> 00:36:26.914
solution on a different
cloud provider,
00:36:26.914 --> 00:36:30.262
we want to make sure that you know
that it's not gonna be disrupted.
00:36:35.672 --> 00:36:40.775
Purge/load CDNs attribute content as
close to your customers as possible
00:36:40.775 --> 00:36:45.473
but that creates many copies right
so purging has become an important
00:36:45.473 --> 00:36:49.930
aspect for making sure that your
content is as fresh as possible.
00:36:51.070 --> 00:36:53.550
Especially when you're
monetizing off that content.
00:36:53.550 --> 00:36:55.710
You wanna make sure that you've
spent all this time getting it
00:36:55.710 --> 00:36:58.530
prepared that you can get it out
there as quickly as possible.
00:36:58.530 --> 00:37:03.960
This will allow you to manually
flush that content, and refresh.
00:37:03.960 --> 00:37:06.980
So that you know you're not
getting old material served
00:37:06.980 --> 00:37:08.690
to your end users.
00:37:08.690 --> 00:37:13.450
Some common scenarios are,
updated news articles or videos.
00:37:13.450 --> 00:37:15.460
Pricing page errors,
which we have some experience with.
00:37:17.050 --> 00:37:20.920
Offensive content that you didn't
anticipate to be offensive.
00:37:20.920 --> 00:37:23.290
And occasionally bad
objects causing issues.
00:37:23.290 --> 00:37:26.590
One of the first steps you want is
to make sure that you can flush that
00:37:26.590 --> 00:37:31.030
and see if that is
the source of your trouble.
00:37:31.030 --> 00:37:33.090
>> So the one thing that
should be called out.
00:37:33.090 --> 00:37:37.590
People can tend to abuse purge by
abuse I don't mean you can throw as
00:37:37.590 --> 00:37:40.150
many kind of purge
requests as you want.
00:37:40.150 --> 00:37:43.250
But you need to understand what
it means when you purge and
00:37:43.250 --> 00:37:46.310
you're purely purging it
from the pops on the cdn.
00:37:46.310 --> 00:37:48.860
Now there can downstream from
the cdn there can be other
00:37:49.900 --> 00:37:53.700
caching that's happening at
the edge of an enterprise.
00:37:53.700 --> 00:37:55.610
And that's not gonna get
rid of that content.
00:37:55.610 --> 00:37:59.010
So best practice is always to,
if you're starting it fresh,
00:37:59.010 --> 00:37:59.850
is use versioning.
00:37:59.850 --> 00:38:02.600
So that, you change
the versioning for a file,
00:38:02.600 --> 00:38:04.080
the CDN will pick it
up automatically.
00:38:04.080 --> 00:38:05.440
You don't need to purge.
00:38:05.440 --> 00:38:10.040
But we understand some people older
architectures where they just
00:38:10.040 --> 00:38:13.540
can't get rid of some bad practices
in terms of how they developed it.
00:38:13.540 --> 00:38:17.830
But, if you're starting from fresh,
don't abuse Purge cuz you'll still
00:38:17.830 --> 00:38:19.860
have people, some subset
of people coming back and
00:38:19.860 --> 00:38:21.530
saying I'm still seeing
your old content.
00:38:21.530 --> 00:38:22.980
And everything can be
gone from the CDN, but
00:38:22.980 --> 00:38:25.506
you have something downstream
from that still caching it, so.
00:38:25.506 --> 00:38:32.990
And then Load's another
one to touch on.
00:38:32.990 --> 00:38:36.340
Is if there isn't a need by default,
you use Load.
00:38:36.340 --> 00:38:39.890
We typically see customers
using Load where they
00:38:39.890 --> 00:38:42.460
are gonna have a massive
amount of requests coming in.
00:38:42.460 --> 00:38:45.760
They want to ensure that the data
needs to be at the CDN to begin with
00:38:45.760 --> 00:38:48.410
so they can truly limit the number
of requests that come back to their
00:38:48.410 --> 00:38:50.390
origin to check if
there is a refresh or
00:38:50.390 --> 00:38:52.000
new content that's needed.
00:38:52.000 --> 00:38:57.730
But by default if you have a large
number of customers coming in.
00:38:57.730 --> 00:39:00.630
In most cases you don't need load
it's the individual pops themselves
00:39:00.630 --> 00:39:07.231
will come back and request it
from the origins and then Cache.
00:39:07.231 --> 00:39:14.485
>> Cool, any purge/load questions?
00:39:14.485 --> 00:39:16.780
Pretty straight forward.
00:39:16.780 --> 00:39:20.240
>> Country filtering is also
pretty straight forward, so
00:39:20.240 --> 00:39:22.850
there's only a number of scenarios
where this would be available.
00:39:22.850 --> 00:39:24.560
This gives you a lot of control over
00:39:25.950 --> 00:39:29.120
what that kind of access looks
like at a country per basis.
00:39:29.120 --> 00:39:31.340
And you could have
any sorts of legal or
00:39:31.340 --> 00:39:36.000
business requirements that you
would want to have to keep that
00:39:36.000 --> 00:39:38.690
content controlled within
certain countries.
00:39:38.690 --> 00:39:44.090
And the new Azure CDM will
allow you to control that and
00:39:44.090 --> 00:39:46.900
it dictate where it goes or
doesn't go.
00:39:47.900 --> 00:39:49.480
Common scenarios are pretty obvious.
00:39:49.480 --> 00:39:52.430
You want to constrain viewership of
videos to accommodate some sort of
00:39:52.430 --> 00:39:53.581
licensing requirements.
00:39:53.581 --> 00:39:56.041
Just one of the points
that we see a lot.
00:39:56.041 --> 00:39:59.466
And then also blocking content for
compliance or
00:39:59.466 --> 00:40:04.240
even just economic decisions Any
questions on country filtering?
00:40:06.520 --> 00:40:08.631
Also pretty straight forward.
00:40:12.147 --> 00:40:14.964
Origin Shield, so
Origin Shield allows for
00:40:14.964 --> 00:40:19.090
even more optimization and
utilization of that edge network.
00:40:19.090 --> 00:40:22.320
In this case,
you are utilizing an edge
00:40:23.630 --> 00:40:27.130
origin server instead of
your original origin server.
00:40:27.130 --> 00:40:30.630
So you tell the network
that you have content that
00:40:30.630 --> 00:40:34.220
you expect is gonna be hitting
your origin pretty hard.
00:40:34.220 --> 00:40:36.910
This will allow you to distribute
that a little quicker,
00:40:36.910 --> 00:40:38.450
reducing the amount
of round trip time.
00:40:40.690 --> 00:40:45.100
This is really just
an advanced version of
00:40:45.100 --> 00:40:48.124
the basic function of a CDN.
00:40:48.124 --> 00:40:51.070
And this will be included with both
the standard and advanced packages.
00:40:53.060 --> 00:40:54.750
Any questions on Origin Shield?
00:40:58.763 --> 00:40:59.657
Cool.
00:41:03.431 --> 00:41:05.310
Rules Engine.
00:41:05.310 --> 00:41:08.990
A rules engine's a really,
really powerful tool.
00:41:08.990 --> 00:41:12.460
There will be some basic
preset rules available in
00:41:12.460 --> 00:41:13.610
the standard package.
00:41:13.610 --> 00:41:17.690
But the really powerful version of
this is the advanced rules engine
00:41:17.690 --> 00:41:21.920
that will come in the advanced
package, the premium package.
00:41:21.920 --> 00:41:25.710
It's an interface that allows
you to create custom rules.
00:41:25.710 --> 00:41:31.207
It's very, very deep and rich,
almost bordering on programming.
00:41:31.207 --> 00:41:36.080
It's a bunch of if-then questions
that allow you to dictate what your
00:41:36.080 --> 00:41:38.569
specific distribution requires.
00:41:40.080 --> 00:41:42.650
We see a lot of special
timing rules for
00:41:42.650 --> 00:41:47.070
content, and very, very unique
behaviors for what happens.
00:41:47.070 --> 00:41:48.440
I think we see a lot of this.
00:41:48.440 --> 00:41:50.060
It's tied, often,
to our token authentication,
00:41:50.060 --> 00:41:51.300
which we'll talk about
in a little while.
00:41:54.430 --> 00:41:58.330
What would be the most common
scenario that you would see someone
00:41:58.330 --> 00:42:00.110
using a rules engine on?
00:42:00.110 --> 00:42:02.780
>> So yeah, one of the most common
ones is kind of controlling
00:42:02.780 --> 00:42:05.656
the caching behavior, both at the
edge or going down to the client.
00:42:05.656 --> 00:42:10.150
So kind of one of the ways to
think of the rules engine is,
00:42:10.150 --> 00:42:12.820
you're changing behavior
based on a particular match.
00:42:12.820 --> 00:42:15.500
And that match is anything that
comes in a client request.
00:42:15.500 --> 00:42:17.140
So it can be in a header.
00:42:17.140 --> 00:42:18.690
It can be in the URL itself.
00:42:18.690 --> 00:42:22.380
You can be looking at the URL and in
a basic kind of rules package you'll
00:42:22.380 --> 00:42:25.870
be able to do kind of wild
card lookups across that URL.
00:42:25.870 --> 00:42:29.580
As you get into advanced rules
engine, you can start doing RegEx
00:42:29.580 --> 00:42:33.160
comparisons on the URL or
inside of the header.
00:42:33.160 --> 00:42:35.380
But kind of anything that you can
think about changing behavior.
00:42:35.380 --> 00:42:37.450
Whether it's I'm changing
the caching behavior,
00:42:37.450 --> 00:42:39.520
I'm gonna redirect content.
00:42:39.520 --> 00:42:42.702
Whether I want to identify there's
a rich in the advanced rules.
00:42:42.702 --> 00:42:45.221
There's a rich ability to identify
the exact device that's coming in.
00:42:45.221 --> 00:42:49.621
Which type of Android device,or iOS
device and that you can redirect or
00:42:49.621 --> 00:42:52.349
change how content is
sent down to clients.
00:42:54.345 --> 00:42:57.280
>> Most CDN providers
have something like this.
00:42:57.280 --> 00:43:00.070
They often hide it back
behind a consultant.
00:43:00.070 --> 00:43:03.100
So you'll have to pay someone
to come in and do this set up.
00:43:03.100 --> 00:43:06.970
We are exposing this to allow for
your own self control of it.
00:43:08.030 --> 00:43:11.826
I think it's gonna be one of
the more, to me, one of the richer
00:43:11.826 --> 00:43:15.988
features that are available, and
you'll see the true power of it.
00:43:15.988 --> 00:43:19.182
I think that in the advanced,
there's almost no limitation to
00:43:19.182 --> 00:43:21.784
the amount of permutations
on an individual rule.
00:43:23.214 --> 00:43:24.991
Any questions on the rules engine?
00:43:29.565 --> 00:43:30.308
Cool.
00:43:33.869 --> 00:43:34.891
All right, analytics.
00:43:34.891 --> 00:43:39.590
Today our analytics are very, very,
very limited, almost non-existent.
00:43:39.590 --> 00:43:40.346
>> They are non-existent.
00:43:40.346 --> 00:43:42.990
>> [LAUGH]
>> Billing is our analytics today.
00:43:42.990 --> 00:43:43.690
>> That's right, yeah.
00:43:43.690 --> 00:43:45.080
You can see what you've used,
00:43:45.080 --> 00:43:47.200
because we need to charge you for
it.
00:43:47.200 --> 00:43:52.620
The new analytics package
is gonna be very rich.
00:43:52.620 --> 00:43:56.270
We'll have a core set that'll be
available in the standard package,
00:43:56.270 --> 00:44:00.880
and a very rich set available
in the premium package.
00:44:00.880 --> 00:44:04.690
With these logging and analytics you
can see where your customers are,
00:44:04.690 --> 00:44:06.890
and how they are or
aren't being served.
00:44:06.890 --> 00:44:09.590
You could use this information
to tune the CDN's behavior for
00:44:09.590 --> 00:44:12.660
your own, especially in conjunction
with some of those others like
00:44:12.660 --> 00:44:13.320
the rules engine.
00:44:14.680 --> 00:44:17.400
Common scenarios, there are common
scenarios for any analytics.
00:44:17.400 --> 00:44:20.300
You probably want the details
which are in the basic package.
00:44:20.300 --> 00:44:23.340
You can get stuff
like number of hits,
00:44:23.340 --> 00:44:25.960
the bandwidth that you're consuming.
00:44:25.960 --> 00:44:29.290
Data transferred and
the cache hit ratio, and
00:44:29.290 --> 00:44:34.570
you could divide that up based on
a period of time, day, week, month.
00:44:34.570 --> 00:44:37.700
In the advanced section, which is
where it gets really interesting.
00:44:37.700 --> 00:44:41.060
It opens up a more real-time
analytic so you can check and
00:44:41.060 --> 00:44:43.150
see what's happening
at an exact moment.
00:44:43.150 --> 00:44:47.330
Tied into that real-time analytics
are a rich set of alerts.
00:44:47.330 --> 00:44:51.730
Customizable alerts,
you'll be able to set up triggers,
00:44:51.730 --> 00:44:54.550
parameters that will send you emails
when certain things are happening.
00:44:54.550 --> 00:44:56.050
If you cross bandwidth level or
00:44:56.050 --> 00:44:59.570
if your cache hit ratio drops
below a certain amount.
00:44:59.570 --> 00:45:00.930
Anything that can be tracked for
00:45:00.930 --> 00:45:03.865
the most part,
you can set up an alert on.
00:45:03.865 --> 00:45:09.480
It'll also give you a lot of detail
on what the top scenarios are,
00:45:09.480 --> 00:45:12.623
what your top countries and
cities are, what your top files are,
00:45:12.623 --> 00:45:18.610
the top user agents that you're
seeing, and error types.
00:45:20.000 --> 00:45:21.514
Any questions on analytics?
00:45:25.286 --> 00:45:26.389
Powering through this.
00:45:30.419 --> 00:45:31.992
Token authentication.
00:45:31.992 --> 00:45:35.360
Token authentication's
a fairly rich feature.
00:45:37.290 --> 00:45:40.270
It's easy to explain,
00:45:40.270 --> 00:45:43.280
but usually inspires a lot
of different questions.
00:45:43.280 --> 00:45:46.560
So, the token authentication
basically allows for a token to be
00:45:48.220 --> 00:45:52.240
used for access to resources over
a limited or defined period of time.
00:45:52.240 --> 00:45:54.050
You can put additional
restriction on top of that.
00:45:55.190 --> 00:45:57.510
You can base that on a number
of different functions.
00:45:57.510 --> 00:46:01.100
Everything from user IP to URLs,
protocols or
00:46:01.100 --> 00:46:03.110
the individual countries
that are in there.
00:46:03.110 --> 00:46:06.050
We see this almost all the time
in media streaming where
00:46:06.050 --> 00:46:09.250
they want to control who's
access their video files.
00:46:09.250 --> 00:46:12.090
We get a lot of it on firmware
downloads where they want to check
00:46:12.090 --> 00:46:14.840
and make sure that the person
has the right to that download.
00:46:14.840 --> 00:46:17.110
There's a lot of
usage in hotlinking.
00:46:17.110 --> 00:46:20.900
This is a big way to prevent that.
00:46:22.400 --> 00:46:27.013
Often times we've seen it in
a number of our customers
00:46:27.013 --> 00:46:30.191
that they didn't utilize this, and
00:46:30.191 --> 00:46:35.022
somebody hotlinked to their
content deep in their URL.
00:46:35.022 --> 00:46:38.560
And now somebody's got their
picture out on somewhere else.
00:46:38.560 --> 00:46:40.270
This happens a lot
with your viral videos.
00:46:40.270 --> 00:46:44.300
That can really jack
your traffic rates up.
00:46:44.300 --> 00:46:47.851
So, and then you can always use it
for customer demographics as well.
00:46:49.849 --> 00:46:53.251
Really a key component, becoming
almost ubiquitous in most of
00:46:53.251 --> 00:46:55.820
the things that we're
deploying today.
00:46:55.820 --> 00:46:58.550
>> This is an example, also,
there was an earlier question on,
00:46:58.550 --> 00:47:00.858
how easy is it to go from
one system to another?
00:47:00.858 --> 00:47:04.102
So if you're doing kind of
basic token authentication,
00:47:04.102 --> 00:47:08.019
the way that you're doing the token
authentication on the client's
00:47:08.019 --> 00:47:10.940
likely different is you go
from one CDN to another.
00:47:10.940 --> 00:47:15.792
There's no standard way in terms of
how the tokens are created today.
00:47:15.792 --> 00:47:18.650
But even we're just kind of touching
the surface in terms of what
00:47:18.650 --> 00:47:21.940
you can do here, in terms here of
just kind of applying the token and
00:47:21.940 --> 00:47:23.270
having the CDN validate it.
00:47:23.270 --> 00:47:25.770
So typically the client will go into
some type of authentication service,
00:47:25.770 --> 00:47:28.740
get the token with the URL with
the token on the end of it.
00:47:28.740 --> 00:47:29.910
It's usually time limited.
00:47:29.910 --> 00:47:32.910
And then some of the additional
restrictions, Graham said.
00:47:32.910 --> 00:47:36.150
But there's also the ability if you
needed to where we do custom work
00:47:36.150 --> 00:47:38.730
where you could actually
hear the pop itself to
00:47:38.730 --> 00:47:40.990
go back to your origin to
do additional validation.
00:47:40.990 --> 00:47:43.610
So, and we'll see that more
in these really large,
00:47:43.610 --> 00:47:46.850
large download scenarios.
00:47:46.850 --> 00:47:49.191
>> Tie these things together, and
they really become a powerful tool.
00:47:49.191 --> 00:47:51.507
Especially token authentication and
rules engine,
00:47:51.507 --> 00:47:54.243
allows you to have a really deep
control over your own content.
00:47:54.243 --> 00:47:57.921
>> Now, with token authentication
is that very different from
00:47:57.921 --> 00:47:59.372
Key Vaulting in Azure?
00:47:59.372 --> 00:48:01.786
>> Correct, yeah.
00:48:01.786 --> 00:48:04.768
Key Vault's about storing your
secrets in a secure manner and
00:48:04.768 --> 00:48:07.530
then be able to hand them out
to others in a secure manner.
00:48:09.660 --> 00:48:13.340
>> The thing about a token is it's
basically, if you look at an URL has
00:48:13.340 --> 00:48:17.351
a token on it, so you're essentially
basically seeing some kind of hash
00:48:17.351 --> 00:48:21.360
with some information to clear also
in the URL that comes through.
00:48:21.360 --> 00:48:24.320
The authentication
service will create it.
00:48:24.320 --> 00:48:27.140
It will hand the client that
URL with a token on it.
00:48:27.140 --> 00:48:30.496
And when it comes back onto the POP,
the POP itself will recreate
00:48:30.496 --> 00:48:33.560
the hash based on the info
that's coming in on the client.
00:48:33.560 --> 00:48:36.275
Compare them, and if they match
they'll let it go through.
00:48:39.374 --> 00:48:41.499
>> Any other questions
on token authentication?
00:48:41.499 --> 00:48:42.440
>> Go ahead.
00:48:42.440 --> 00:48:45.474
>> Does it mean that I
could generate a toke for
00:48:45.474 --> 00:48:49.027
my application,
a metadata token in [INAUDIBLE]?
00:48:49.027 --> 00:48:50.572
>> Correct, yeah.
00:48:50.572 --> 00:48:54.586
So we provide you code and
then samples for
00:48:54.586 --> 00:48:59.066
basically being able to
generate that token.
00:48:59.066 --> 00:49:03.614
And that's the same code
that the POP on the CDN's
00:49:03.614 --> 00:49:07.164
gonna also validate it with, so.
00:49:07.164 --> 00:49:09.103
>> Will that cause any problems with
like Google's main product site?
00:49:09.103 --> 00:49:10.889
>> Not that I can think of.
00:49:10.889 --> 00:49:15.190
What kind of problem
are you thinking?
00:49:15.190 --> 00:49:17.463
>> A web server with
a lot of images on it.
00:49:17.463 --> 00:49:19.328
And I want to make sure that
those images aren't being
00:49:19.328 --> 00:49:20.783
deeplinked by another company.
00:49:20.783 --> 00:49:21.584
>> Right.
00:49:21.584 --> 00:49:24.732
>> But at the same time,
I still want that index for
00:49:24.732 --> 00:49:29.241
everything else in the server to be
able to search it and [INAUDIBLE].
00:49:32.098 --> 00:49:34.250
>> No, cuz it depends on
how you implement it.
00:49:34.250 --> 00:49:36.010
You can implement it so
it does have an impact.
00:49:36.010 --> 00:49:38.310
And so
you're gonna require that someone,
00:49:38.310 --> 00:49:39.900
cuz you can restrict
who get that URL.
00:49:39.900 --> 00:49:43.370
So you could basically authenticate
when someone comes in or
00:49:43.370 --> 00:49:44.608
if you want to treat
it just like a URL.
00:49:44.608 --> 00:49:47.259
It's like, I want to ensure
that someone isn't deeplinking,
00:49:47.259 --> 00:49:49.921
if I look at their firms they're
always coming for my websites.
00:49:49.921 --> 00:49:52.587
And you can do it in a more
lightweight manner, where you're
00:49:52.587 --> 00:49:55.790
just basically, you're creating a
token for a limited period of time.
00:49:55.790 --> 00:49:57.850
And the simplest one is,
I create a token.
00:49:57.850 --> 00:50:01.281
I just say it expires within Twenty
or 30 seconds, so someone can't grab
00:50:01.281 --> 00:50:04.281
it and toss them to someone else's
site and deep link from there.
00:50:04.281 --> 00:50:07.504
In that case if, you know, if you're
looking at analytics and Google, or
00:50:07.504 --> 00:50:09.670
others, it's not gonna
have any impact on that.
00:50:09.670 --> 00:50:12.130
As you get into more complex
limitations, where I wanna.
00:50:12.130 --> 00:50:14.750
You could restrict it based on,
I give you a token and
00:50:14.750 --> 00:50:16.830
I give you a time period
where it's valid for.
00:50:16.830 --> 00:50:20.310
I could also say, you know, I'm only
gonna allow for particular IPs.
00:50:21.460 --> 00:50:22.280
In that case,
00:50:22.280 --> 00:50:24.330
then you start blocking, but
you're doing that on purpose.
00:50:24.330 --> 00:50:29.037
So, it really depends
on use case scenario.
00:50:29.037 --> 00:50:33.770
>> [INAUDIBLE]
>> When you
00:50:33.770 --> 00:50:36.535
say how can it be configured.
00:50:36.535 --> 00:50:41.610
[INAUDIBLE]
>> So you're basically going
00:50:41.610 --> 00:50:44.785
to put a time stamp in there that
defines how long it's valid for.
00:50:44.785 --> 00:50:52.500
>> [INAUDIBLE]
>> Yeah.
00:50:52.500 --> 00:50:53.120
Yeah.
00:50:53.120 --> 00:50:56.540
So the most basic one is
somebody who's like I URL token.
00:50:56.540 --> 00:50:59.600
I might say it's valid for, a lot
of times we'll see it's valid for
00:50:59.600 --> 00:51:01.190
like half an hour, an hour.
00:51:01.190 --> 00:51:02.540
So something where
someone grabbed it and
00:51:02.540 --> 00:51:03.930
started tossing out
to lots of people.
00:51:03.930 --> 00:51:07.270
It's now invalid, and then you can
start layering on top in terms of,
00:51:07.270 --> 00:51:08.800
you can put geo
restrictions on it also.
00:51:08.800 --> 00:51:12.830
So if the request comes in, I know
all my users are from the U.S., and
00:51:12.830 --> 00:51:14.500
suddenly someone hands it
off to someone in Europe,
00:51:14.500 --> 00:51:15.820
I can block it based on that.
00:51:15.820 --> 00:51:18.730
So even if it's a half hour
valid if I toss it over to
00:51:18.730 --> 00:51:19.850
Europe it's no longer valid.
00:51:19.850 --> 00:51:26.720
So it's up to you how you want to
do it so Cool, any other questions?
00:51:28.050 --> 00:51:28.799
Cool, thank you.
00:51:31.633 --> 00:51:33.730
All right custom SSL.
00:51:33.730 --> 00:51:35.266
>> I think we've hit
this one in depth.
00:51:35.266 --> 00:51:38.600
[LAUGH]
>> [LAUGH] So the reality is that we
00:51:38.600 --> 00:51:44.370
live in an age now where all content
is moving from HTTP to HTTPS.
00:51:44.370 --> 00:51:48.250
I think we're kind of in the last
days of being able to deploy
00:51:48.250 --> 00:51:51.744
content at scale without some
level of security attached to it.
00:51:51.744 --> 00:51:54.930
So while the economics of purchasing
00:51:54.930 --> 00:51:58.980
SSL may not have caught up with
that, they certainly will.
00:51:58.980 --> 00:52:02.100
Our intent is to make SSL as
simple and easy as possible.
00:52:03.690 --> 00:52:05.430
So, we're gonna enable this.
00:52:05.430 --> 00:52:07.450
I mean, the common scenarios
are basically everything, but
00:52:07.450 --> 00:52:13.068
you really just need to secure,
secure, secure your content.
00:52:13.068 --> 00:52:14.870
Keep people out of it.
00:52:14.870 --> 00:52:19.870
It is becoming the number
one request for
00:52:19.870 --> 00:52:21.930
anyone, any CDN provider.
00:52:21.930 --> 00:52:24.290
There is a great variety in
how they provide those, so
00:52:24.290 --> 00:52:28.050
we're looking to make that as
a smooth experience as possible.
00:52:28.050 --> 00:52:31.480
Because we believe that
if you have it available,
00:52:31.480 --> 00:52:34.870
you're going to be much
more satisfied with
00:52:36.310 --> 00:52:39.745
the level of service as well,
you're customers.
00:52:39.745 --> 00:52:43.720
[INAUDIBLE] Custom SSL security.
00:52:43.720 --> 00:52:46.040
We're in this phase of,
00:52:46.040 --> 00:52:51.160
CDM went through this growth
phase where historically
00:52:51.160 --> 00:52:54.888
it has been very much focused on
what it stand for, content delivery.
00:52:54.888 --> 00:52:59.500
We came out of this phase in
the last few years, where it was
00:52:59.500 --> 00:53:04.420
starting to address the new nature
website and dynamic content right?
00:53:04.420 --> 00:53:07.240
So a lot of the focus in the CDN
industry in the last few years
00:53:07.240 --> 00:53:09.430
has been able to support
dynamic content, and
00:53:09.430 --> 00:53:14.150
how that content is delivered and
interfaced with.
00:53:14.150 --> 00:53:16.870
And now we're towards the end that,
where a lot of that has become
00:53:16.870 --> 00:53:19.120
settled, and
now we're looking at security.
00:53:19.120 --> 00:53:21.110
So we're kinda in this
security phase today, and
00:53:21.110 --> 00:53:23.940
I think a lot of the advances and
a lot of the discussions you're
00:53:23.940 --> 00:53:28.540
gonna see around CDN are gonna be
heavily security focused on that.
00:53:28.540 --> 00:53:30.850
Not only now, at this particular
point in time, but for
00:53:30.850 --> 00:53:32.320
the next couple years as well.
00:53:34.950 --> 00:53:38.793
And on that point,
any questions on Custom SSL?
00:53:43.204 --> 00:53:43.704
Cool.
00:53:45.250 --> 00:53:48.860
Coming soon, so on the tail
end of what I was just saying,
00:53:48.860 --> 00:53:52.920
these are gonna be some cutting
edge features that we think
00:53:52.920 --> 00:53:56.270
are a little further out than the
last group of features we discussed.
00:53:56.270 --> 00:53:59.880
But are hugely important to
the modern CDN workload, and
00:53:59.880 --> 00:54:02.590
our top priority for
us to get out the door.
00:54:02.590 --> 00:54:05.640
We put the fundamentals in place,
measuring perspective.
00:54:05.640 --> 00:54:08.050
And we're simply working on
how best to implement them
00:54:08.050 --> 00:54:10.350
into our existing offer and
show our new offerings.
00:54:10.350 --> 00:54:13.040
So look for more details on these
later in the calendar year, but
00:54:13.040 --> 00:54:15.510
we want to give you a quick sense
of what's coming down the pipe.
00:54:17.480 --> 00:54:22.440
So as we talked about security
it has become an incredibly
00:54:22.440 --> 00:54:23.409
important aspect.
00:54:24.470 --> 00:54:27.860
And a CDN inherently provides no
small amount of security, right.
00:54:29.100 --> 00:54:31.660
It has, in addition to
the protections we talked about with
00:54:31.660 --> 00:54:37.250
SSL, the nature of a CDN itself
distributing its content over
00:54:37.250 --> 00:54:39.950
via replication across
worldwide servers, and
00:54:39.950 --> 00:54:42.020
limiting the number
of hits on an origin,
00:54:42.020 --> 00:54:46.850
it naturally provides some level
of security against DDos attacks.
00:54:46.850 --> 00:54:49.220
And that can be enhanced by
using a service that's already
00:54:49.220 --> 00:54:50.420
watching it for you. Right?
00:54:50.420 --> 00:54:52.520
The CDN is
00:54:52.520 --> 00:54:54.510
paying attention to DDOSs for you.
00:54:54.510 --> 00:54:55.880
So it's standing in front of you.
00:54:57.120 --> 00:55:00.130
The service already defends against
the direct origin DDOS stacks,
00:55:00.130 --> 00:55:02.320
by forcing all of those
requests to go through the CDN.
00:55:02.320 --> 00:55:07.460
So the CDN's monitoring, tracking
where those IP origins are and
00:55:07.460 --> 00:55:11.640
making sure that only authorized IP
addresses can reach your origin.
00:55:11.640 --> 00:55:14.150
So you get a level of protection
simply by using the CDM.
00:55:14.150 --> 00:55:16.230
Now that's inherent, it's not this.
00:55:16.230 --> 00:55:17.730
So this is the more
advanced security.
00:55:19.340 --> 00:55:22.850
This offers a significantly
more rigorous defense,
00:55:22.850 --> 00:55:25.116
primarily through web
application firewalls, right?
00:55:25.116 --> 00:55:26.974
Or WAFs.
00:55:26.974 --> 00:55:31.800
WAFs have been an increasingly
important security service over
00:55:31.800 --> 00:55:32.840
the last few years.
00:55:34.100 --> 00:55:38.330
Traditionally have been deployed
on the customer's on-prem servers.
00:55:38.330 --> 00:55:41.160
And have involved complex
customizations to kind of support
00:55:41.160 --> 00:55:42.320
the applications they protect.
00:55:43.630 --> 00:55:49.870
But we're by contrast the WAF
deployments in the cloud offer
00:55:49.870 --> 00:55:54.000
the ability to, simply, turn it on
and utilize existing rule sets that
00:55:54.000 --> 00:55:58.770
they see as valuable, based on the
traffic they're already witnessing.
00:55:58.770 --> 00:56:02.550
It's got the on-demand scalability,
so you can turn it on when
00:56:02.550 --> 00:56:05.600
you feel that you have content
that is requiring of protection.
00:56:06.750 --> 00:56:09.590
It has those always-on
capabilities and
00:56:09.590 --> 00:56:11.228
it's got that swift
time to market benefit.
00:56:11.228 --> 00:56:15.920
So, our CDN is gonna offer you this
00:56:15.920 --> 00:56:19.780
affordable CDN integrated,
always up to date, solution for
00:56:19.780 --> 00:56:24.620
protecting websites, and
increasing their performance.
00:56:24.620 --> 00:56:28.370
So it delivers that via a kinda
broad set of rules that we curate,
00:56:28.370 --> 00:56:32.400
and we subscribe to
services to curate.
00:56:32.400 --> 00:56:35.950
And it combats a whole wide
range of possible attacks.
00:56:35.950 --> 00:56:38.740
So you'll be able to utilize
the intelligence that
00:56:38.740 --> 00:56:41.350
they see by seeing these things
happen all day, every day.
00:56:41.350 --> 00:56:44.650
You don't have to anticipate what
specifically you're gonna see.
00:56:46.270 --> 00:56:47.770
>> But it's not magic pixie dust.
00:56:47.770 --> 00:56:48.724
>> It's not magic pixie dust.
00:56:48.724 --> 00:56:52.080
[LAUGH]
>> The stereotypical example usually
00:56:52.080 --> 00:56:54.780
used for
WAF is around SQL injection.
00:56:54.780 --> 00:56:56.340
>> So you can protect it
from your origins, but
00:56:56.340 --> 00:56:59.360
you can segregate basic rule
from the edge of the network.
00:56:59.360 --> 00:57:01.160
And if the cdn's the edge of
the network, you can see that and
00:57:01.160 --> 00:57:03.560
you can prevent that traffic
from coming through so.
00:57:04.560 --> 00:57:07.420
And the magic pixie
dust kind of aspect,
00:57:07.420 --> 00:57:10.078
is the there are certain things
that are really easy to detect.
00:57:10.078 --> 00:57:12.630
There's other things remote a lot of
customers want to actually see, and
00:57:12.630 --> 00:57:17.390
then you know, and get alerts, and
then make changes based on those
00:57:17.390 --> 00:57:19.328
alerts so that they're not
breaking their website.
00:57:19.328 --> 00:57:23.020
Just cause the heuristics are
slightly off, or they are you know
00:57:23.020 --> 00:57:26.350
detecting something that's
perhaps not a security threat.
00:57:26.350 --> 00:57:30.190
>> Yep, there are stop lights and
stop signs out there and
00:57:30.190 --> 00:57:31.610
air bags and seat belts.
00:57:31.610 --> 00:57:34.370
But that doesn't necessarily mean
you're not gonna get in a car wreck
00:57:34.370 --> 00:57:35.273
or not gonna get hurt.
00:57:37.874 --> 00:57:40.721
So that's the security that kinda
touches on the advances that
00:57:40.721 --> 00:57:42.540
we're seeing in the CDN industry.
00:57:42.540 --> 00:57:45.140
So, this is one of our important
things that we wanna get out
00:57:45.140 --> 00:57:46.752
the door as quickly as possible, and
00:57:46.752 --> 00:57:48.529
we're targeting end
of calendar year.
00:57:51.756 --> 00:57:54.080
Dynamic Content support
is the other aspect.
00:57:54.080 --> 00:58:00.070
This platform kinda specializes
in this HTTP/HTTPS delivery
00:58:00.070 --> 00:58:03.390
of data that can't fully leverage
the data delivery efficiency derived
00:58:03.390 --> 00:58:08.620
from caching content, because of
that content itself is changing.
00:58:08.620 --> 00:58:11.220
The common scenarios
here are e-commerce,
00:58:11.220 --> 00:58:13.230
where people's pages
are changing dramatically, or
00:58:13.230 --> 00:58:16.760
they're trying to retain
a certain amount of things.
00:58:16.760 --> 00:58:18.800
Social media and financial.
00:58:18.800 --> 00:58:24.460
It's typically data base or user
driven so it changes all the time.
00:58:24.460 --> 00:58:28.870
And you need a special kind
of service to make sure that
00:58:31.280 --> 00:58:33.500
that is being refreshed at
the edge appropriately and
00:58:33.500 --> 00:58:37.850
you're still able to use the CDN in
the most efficient manner possible.
00:58:37.850 --> 00:58:41.060
>> So this one kinda goes,
it goes in juxtaposition to my
00:58:41.060 --> 00:58:43.050
earlier comment around
like when should I use it.
00:58:43.050 --> 00:58:47.260
Cuz it's hundreds of thousands of
users, in your typical case for
00:58:47.260 --> 00:58:51.730
kinda dynamic site acceleration, is
that you are not caching on the CDM.
00:58:51.730 --> 00:58:54.830
So you are improving the routing,
00:58:54.830 --> 00:58:58.010
you're improving how long
the TCP connection's kept open.
00:58:58.010 --> 00:59:00.840
You're just making it very
fast to go from the origin
00:59:00.840 --> 00:59:03.590
down to the client, because each,
the client it's unique.
00:59:03.590 --> 00:59:05.460
And so there's these two
layers where you can
00:59:05.460 --> 00:59:07.480
make a lot of improvements
on the networking side.
00:59:07.480 --> 00:59:10.310
And you can start making a lot
of improvements at the edge.
00:59:10.310 --> 00:59:13.460
The edge improvements are
interesting, cuz they're ones that
00:59:13.460 --> 00:59:18.070
in almost, most cases you could
do from yourself from the origin.
00:59:18.070 --> 00:59:20.500
Those are things if I
write a web page, and
00:59:20.500 --> 00:59:22.980
I take a look at like how
many TCP connections.
00:59:22.980 --> 00:59:25.100
How many round trips happen if
they're hundreds of thousands.
00:59:25.100 --> 00:59:28.490
Well I could optimize my pages
themselves to make it faster.
00:59:28.490 --> 00:59:30.820
But what we found in
a lot of enterprises,
00:59:30.820 --> 00:59:32.970
that it's very difficult,
you have multiple business units who
00:59:32.970 --> 00:59:35.190
are all contributing to
the same front page.
00:59:35.190 --> 00:59:36.300
And this is just very difficult for
00:59:36.300 --> 00:59:39.090
them to get something that
really reduces the time.
00:59:39.090 --> 00:59:42.500
So by doing it the ads, you can
start doing smarts in terms of if
00:59:42.500 --> 00:59:45.360
you have bulky JavaScript,
you can reduce it.
00:59:45.360 --> 00:59:47.380
You can, there's a lot of
minimization activities
00:59:47.380 --> 00:59:47.980
that you can do.
00:59:47.980 --> 00:59:52.379
If you have a banner on your webpage
which is made up of like five or
00:59:52.379 --> 00:59:54.011
ten different images.
00:59:54.011 --> 00:59:56.603
The CDN could request it from
the origin, but when the client one
00:59:56.603 --> 00:59:58.671
sends to the client it can
send it as a single image.
00:59:58.671 --> 01:00:01.806
There's a whole host of
optimizations that you can do to
01:00:01.806 --> 01:00:03.807
Speed up the delivery of content for
01:00:03.807 --> 01:00:06.670
dynamic content directly
to the clients.
01:00:06.670 --> 01:00:09.630
>> They're unique optimizations as
well, which is one of the aspects of
01:00:09.630 --> 01:00:12.580
the services, that it is going to be
ultimately tailored to your specific
01:00:12.580 --> 01:00:15.970
solution, and that's how it's going
to be able to optimize that content.
01:00:15.970 --> 01:00:19.470
There's going to be a level of
learning and application and
01:00:19.470 --> 01:00:24.800
settings that need to be addressed,
and that's part of what we're
01:00:24.800 --> 01:00:27.280
trying to solve with getting
implemented into our service.
01:00:28.590 --> 01:00:30.085
Any questions about dynamic content?
01:00:30.085 --> 01:00:40.420
>> [INAUDIBLE]
01:00:40.420 --> 01:00:42.610
>> It's also around the corner.
01:00:42.610 --> 01:00:45.634
As it only went to standard at
the beginning of this year.
01:00:45.634 --> 01:00:49.600
[LAUGH] When there's being ongoing
for that, but it will be there but
01:00:49.600 --> 01:00:53.280
I'd say it's a little bit
further around the corner.
01:00:53.280 --> 01:00:57.849
It's going to take some time for
the ecosystem to actually to
01:00:57.849 --> 01:01:02.965
support it across clients,
versus just the networks themselves.
01:01:06.332 --> 01:01:07.539
Any other questions?
01:01:11.139 --> 01:01:12.510
All right.
That's pretty much it for
01:01:12.510 --> 01:01:13.860
the features that
we want to discuss.
01:01:13.860 --> 01:01:15.770
We did want to open it up for
any general questions.
01:01:15.770 --> 01:01:17.190
Anything that we
hadn't touched upon?
01:01:17.190 --> 01:01:20.990
Or any general questions
you might have for us?
01:01:22.080 --> 01:01:22.665
Go ahead.
01:01:22.665 --> 01:01:32.665
[INAUDIBLE]
01:01:43.204 --> 01:01:48.460
>> Theoretically
01:01:48.460 --> 01:01:52.930
yes, you can do whatever
you want at the edge.
01:01:52.930 --> 01:01:55.970
This year it's not a focus
that we're doing right now.
01:01:58.710 --> 01:01:59.720
The focus for
01:01:59.720 --> 01:02:02.530
us in the next years all around is
kind of optimizing existing content.
01:02:02.530 --> 01:02:05.400
There's some tweaks that you can do,
but
01:02:05.400 --> 01:02:08.890
the kinda I wanna have the logic of
the edge are basically once again,
01:02:08.890 --> 01:02:12.930
I always think of the CDN
as kind of amorphous.
01:02:12.930 --> 01:02:15.630
You can do anything at the edge
anything you can think of doing.
01:02:15.630 --> 01:02:18.510
Its just when it happens, the,
01:02:18.510 --> 01:02:21.190
a few years ago the kind of CDN
industry the big move was around
01:02:21.190 --> 01:02:24.210
kind of the site acceleration
side of things dynamic content.
01:02:24.210 --> 01:02:27.110
The most recent kind of mover
in industries around, and
01:02:27.110 --> 01:02:29.180
the security at the edge.
01:02:29.180 --> 01:02:31.700
But I mean I can easily imagine
a future where there's a lot more
01:02:31.700 --> 01:02:33.990
smarts at the edge where
you're doing transforms.
01:02:33.990 --> 01:02:34.960
But there's a balance there,
01:02:34.960 --> 01:02:39.630
because you don't want to do a lot
of expensive operations at the edge.
01:02:39.630 --> 01:02:40.590
Otherwise it becomes,
01:02:40.590 --> 01:02:43.120
you know it's balance in terms
of do I do it at the origin.
01:02:43.120 --> 01:02:43.850
Or do I do it at the edge?
01:02:43.850 --> 01:02:45.890
So not something that's
available now might be
01:02:45.890 --> 01:02:46.602
something in the future.
01:02:46.602 --> 01:02:47.484
>> Okay.
01:02:50.154 --> 01:02:51.000
>> Any other questions?
01:02:51.000 --> 01:02:52.700
Go ahead.
01:02:52.700 --> 01:02:54.000
>> Yes.
>> Oh I'm sorry.
01:02:54.000 --> 01:03:01.710
>> [INAUDIBLE]
>> [INAUDIBLE]
01:03:01.710 --> 01:03:04.010
>> The standard package should be
01:03:04.010 --> 01:03:07.700
generally comparable to the transfer
rates that you would see, and
01:03:07.700 --> 01:03:09.810
then there will be
an uplift on the premium.
01:03:10.870 --> 01:03:17.398
Pricing hasn't been finalized yet,
but it's not gonna be exponential.
01:03:17.398 --> 01:03:22.750
[INAUDIBLE]
>> Mm-hm.
01:03:22.750 --> 01:03:27.620
>> [INAUDIBLE]
>> So if it's at the CEN,
01:03:27.620 --> 01:03:29.550
so, let me rewind a little bit.
01:03:29.550 --> 01:03:33.860
So if you have contents in Azure
storage today, you're gonna pay
01:03:33.860 --> 01:03:37.330
a small amount of money to go get
it up to, the small amount of your
01:03:37.330 --> 01:03:40.740
traffic is gonna be in delivering
up to one of those POPs.
01:03:40.740 --> 01:03:44.070
We'll typically see when we talk
about the cache hit ratio, is it's
01:03:44.070 --> 01:03:47.640
basically the ratio of how often are
you serving directly out of cache.
01:03:47.640 --> 01:03:50.730
So for
content that is widely viewed,
01:03:50.730 --> 01:03:53.050
you can easily see in the high
90s in terms of cache hit ratio.
01:03:53.050 --> 01:03:55.070
So there's a small percentage
of traffic that's going
01:03:55.070 --> 01:03:56.420
out to the storage or
01:03:56.420 --> 01:04:01.190
directly, the to the pop serv
filling their caches from storage.
01:04:01.190 --> 01:04:04.470
But yeah, there's a cost of
delivering from the POP itself, and
01:04:04.470 --> 01:04:10.350
also for uploading from
the origin into the CD and POPs.
01:04:10.350 --> 01:04:12.450
Did that answer?
01:04:12.450 --> 01:04:14.965
>> [INAUDIBLE]
01:04:14.965 --> 01:04:23.180
>> [INAUDIBLE].
01:04:23.180 --> 01:04:25.020
>> Not today,
01:04:25.020 --> 01:04:27.600
but that is part of the offering
that we're working on right now.
01:04:27.600 --> 01:04:30.760
So we want to ensure that pretty
much everything that you can do
01:04:30.760 --> 01:04:31.620
directly from the portal.
01:04:31.620 --> 01:04:33.880
And this is similar to everything
else that we do across Azure,
01:04:33.880 --> 01:04:35.690
like the wrestle APIs.
01:04:35.690 --> 01:04:37.930
And then of course we'll put
an SDK in front of that.
01:04:37.930 --> 01:04:40.280
So if you want to use
rust you can go do that.
01:04:40.280 --> 01:04:43.940
If you want to use it directly to
.NET SDK you can use that also.
01:04:43.940 --> 01:04:46.769
But not there yet but
it will be there shortly and sear.
01:04:51.041 --> 01:04:52.198
>> I have a question
on the [INAUDIBLE].
01:04:52.198 --> 01:05:00.570
>> [INAUDIBLE]
>> Yep.
01:05:00.570 --> 01:05:07.395
>> [INAUDIBLE]
01:05:07.395 --> 01:05:12.700
>> [INAUDIBLE]
01:05:12.700 --> 01:05:13.500
>> Today it doesn't,
01:05:13.500 --> 01:05:18.160
and that's the- so long term, what
we want to make it a lot simpler.
01:05:18.160 --> 01:05:21.510
So what we've seen is that
people just turn on the CDN.
01:05:21.510 --> 01:05:24.760
It's just like, I see the option,
I'm gonna turn it on, and yet
01:05:24.760 --> 01:05:26.830
if you have a huge amount
of long-tail content, and
01:05:26.830 --> 01:05:29.820
you look at it like the majority
of that is your websites, they're
01:05:29.820 --> 01:05:30.610
>> Not a lot of content
01:05:30.610 --> 01:05:31.300
flowing though them.
01:05:31.300 --> 01:05:33.580
There's a lot of huge, huge ones out
there, but there's a lot of small,
01:05:33.580 --> 01:05:34.910
small ones out there.
01:05:34.910 --> 01:05:40.130
And if you turn on CDN for you can
yourself target, based on host name,
01:05:40.130 --> 01:05:41.140
what you want to deliver from.
01:05:41.140 --> 01:05:44.590
So if you, you can basically say,
you know, I just want all my jpegs,
01:05:44.590 --> 01:05:47.320
and the rest of the website
goes directly from the origin,
01:05:47.320 --> 01:05:51.930
so I can just set the directory
associated with the domain and
01:05:51.930 --> 01:05:52.470
just send it out.
01:05:52.470 --> 01:05:54.540
So you'd have to configure
it yourself today.
01:05:54.540 --> 01:05:57.370
Long term what we wanna look at
is being able to provide feedback
01:05:57.370 --> 01:05:58.280
to customers.
01:05:58.280 --> 01:06:00.870
So that if they
configure it incorrectly,
01:06:00.870 --> 01:06:02.790
where they're just throwing
across everything,
01:06:02.790 --> 01:06:05.370
and it's not adding value that
we can provide that info.
01:06:05.370 --> 01:06:10.010
Or additionally, if you have,
you don't have the CDN turned on for
01:06:10.010 --> 01:06:11.710
services where it would make sense,
we could actually
01:06:12.820 --> 01:06:15.470
demonstrate to you and show you that
you can potentially see X amount of
01:06:15.470 --> 01:06:19.680
improvement, if you actually
did have it turned on.
01:06:19.680 --> 01:06:22.890
So it's hard from the surface
to tell, because it has a lot
01:06:22.890 --> 01:06:25.720
to do with if I just have content,
I still need to understand what's
01:06:25.720 --> 01:06:28.260
the shape of traffic where
all my client's coming from.
01:06:28.260 --> 01:06:29.890
Once you have live
content coming through,
01:06:29.890 --> 01:06:31.955
then you can very intelligently
start giving feedback.
01:06:31.955 --> 01:06:35.800
But when someone's first standing up
content, it's hard to give those,
01:06:35.800 --> 01:06:36.650
you can generalize.
01:06:36.650 --> 01:06:37.810
It's hard to give very exacts,
01:06:37.810 --> 01:06:40.125
in terms of when you'd see
actual performance gains.
01:06:40.125 --> 01:06:46.420
>> [INAUDIBLE]
>> Cool.
01:06:46.420 --> 01:06:47.130
Any other questions?
01:06:49.520 --> 01:06:50.830
Thank you all so much for coming.
01:06:50.830 --> 01:06:52.569
Really appreciate you taking
the time to sit with us.
01:06:54.180 --> 01:06:56.970
And we look forward to
seeing this rollout.
01:06:56.970 --> 01:06:59.900
And we hope to see
you guys on there.
01:06:59.900 --> 01:07:02.110
If you have any questions, we'll be
here for a few minutes afterwards.
01:07:02.110 --> 01:07:04.050
You're more than
welcome to come on up.
01:07:04.050 --> 01:07:07.041
And, I hope you have
a good rest of the show.
01:07:07.041 --> 01:07:09.030
>> [APPLAUSE]