WEBVTT

0:00:02.760000 --> 0:00:08.120000
 In this video, we're going to take a
 look at a relatively new networking

0:00:08.120000 --> 0:00:13.740000
 service provided through Azure, which
 is the Azure Front Door Service.

0:00:13.740000 --> 0:00:17.060000
 The topics that we're going to look
 at, we're going to talk about what

0:00:17.060000 --> 0:00:20.200000
 the Front Door Service is,
 what Azure Front Door is.

0:00:20.200000 --> 0:00:26.100000
 We'll take a look at the components
 that make up Azure Front Door, and

0:00:26.100000 --> 0:00:30.780000
 then I'm going to demonstrate provisioning
 and setting up Azure Front

0:00:30.780000 --> 0:00:34.800000
 Door. Let's go ahead
 and jump into this.

0:00:34.800000 --> 0:00:40.600000
 Now, before I start talking about what
 explicitly Azure Front Door is,

0:00:40.600000 --> 0:00:47.580000
 I want to talk about a broader topic of
 load balancing and directing traffic

0:00:47.580000 --> 0:00:53.320000
 in Azure. If I think about Azure and
 I think about a workload, let's say

0:00:53.320000 --> 0:00:58.560000
 I've got a workload and I haven't
 running on two machines.

0:00:58.560000 --> 0:01:04.640000
 There are web app and this is web
 app one and this is web app two.

0:01:04.640000 --> 0:01:07.980000
 Now, these could actually be Azure
 web apps, so they could be running

0:01:07.980000 --> 0:01:14.740000
 the platform level, they could be running
 at the infrastructure level

0:01:14.740000 --> 0:01:19.680000
 on a virtual machine for the purpose of
 this discussion, it doesn't matter.

0:01:19.680000 --> 0:01:30.620000
 Well, we've got users out here, and we
 want the users to be able to connect

0:01:30.620000 --> 0:01:38.440000
 to these virtual machine or to these
 workloads, virtual machines making

0:01:38.440000 --> 0:01:39.660000
 that assumption.

0:01:39.660000 --> 0:01:45.980000
 Now, I could just give the public IP
 address of those workloads out to

0:01:45.980000 --> 0:01:55.560000
 different people, what I want instead
 is I want some sort of device or

0:01:55.560000 --> 0:02:02.280000
 service whereby my users go to that
 service, and based on going to that

0:02:02.280000 --> 0:02:07.980000
 service, my users are then directed
 to the appropriate location.

0:02:07.980000 --> 0:02:13.140000
 Now, there are a number of services
 that have actually been around for

0:02:13.140000 --> 0:02:20.600000
 a while. For example, I would have
 for years literally, I've had three

0:02:20.600000 --> 0:02:22.200000
 choices within Azure.

0:02:22.200000 --> 0:02:32.520000
 I could use Azure Traffic Manager, I
 could use Azure Application Gateway,

0:02:32.520000 --> 0:02:43.180000
 or I could use the Azure
 Load Balancer.

0:02:43.180000 --> 0:02:48.840000
 Now, each one of these kind of has its
 own pros and cons, Traffic Manager

0:02:48.840000 --> 0:02:53.220000
 is global, it's not really tied to any
 particular region, it's not tied

0:02:53.220000 --> 0:02:59.600000
 to any particular region, but that's
 not really doing load balancing,

0:02:59.600000 --> 0:03:04.640000
 your Traffic Manager, that's really
 just looking at DNS, and being able

0:03:04.640000 --> 0:03:07.120000
 to direct people based on DNS.

0:03:07.120000 --> 0:03:12.960000
 Application Gateway has a lot of functionality,
 it's a layer seven for

0:03:12.960000 --> 0:03:20.700000
 HTTP HTTPS, lots of cool stuff you
 can do there, and the Load Balancer

0:03:20.700000 --> 0:03:24.540000
 is pretty much your standard
 load balancer.

0:03:24.540000 --> 0:03:36.020000
 It's a layer four load balancer, can
 load balance and also can do based

0:03:36.020000 --> 0:03:39.720000
 on IP address and
 also port number.

0:03:39.720000 --> 0:03:45.440000
 The Traffic Manager is global, the Application
 Gateway is highly functional,

0:03:45.440000 --> 0:03:49.160000
 but it's tied to a specific protocol
 and it's regional, and I'll get to

0:03:49.160000 --> 0:03:49.860000
 that in a moment.

0:03:49.860000 --> 0:03:55.980000
 The Load Balancer is definitely regional,
 it's tied to specific services,

0:03:55.980000 --> 0:04:03.100000
 and it does however give you much more
 choice in terms of what you actually

0:04:03.100000 --> 0:04:06.900000
 want to do with it, because I can go
 off different ports, I'm not limited

0:04:06.900000 --> 0:04:11.800000
 to HTTPS, both the Application Gateway
 and the Load Balancer are actually

0:04:11.800000 --> 0:04:17.200000
 balancing traffic, in other words the
 packets are coming through the load

0:04:17.200000 --> 0:04:22.120000
 balancers to the back end, whereas
 Traffic Manager again is just DNS.

0:04:22.120000 --> 0:04:25.640000
 So those are three different options,
 they give us some functionality,

0:04:25.640000 --> 0:04:28.600000
 both the Application Gateway and the
 Load Balancers, as I said, these

0:04:28.600000 --> 0:04:34.240000
 are both tied into a region, which
 means for example if a region goes

0:04:34.240000 --> 0:04:37.580000
 down, then the Application Gateway
 goes down or the Load Balancer goes

0:04:37.580000 --> 0:04:40.480000
 down, so you do have a little bit
 of that single point of failure.

0:04:40.480000 --> 0:04:46.720000
 Well now we have a new service,
 which is Azure Front Door.

0:04:46.720000 --> 0:04:55.840000
 And Azure Front Door really is a combination
 of a little bit of Traffic

0:04:55.840000 --> 0:04:58.940000
 Manager and Application Gateway,
 but it is global.

0:04:58.940000 --> 0:05:02.200000
 By and large if you understand Application
 Gateway, you'll understand

0:05:02.200000 --> 0:05:06.920000
 Front Door, in fact I personally find
 Front Door a bit easier to implement

0:05:06.920000 --> 0:05:11.420000
 than Application Gateway, they really
 do many of the same things, but

0:05:11.420000 --> 0:05:16.280000
 Front Door has got frankly a lot of
 really nice little default values

0:05:16.280000 --> 0:05:18.080000
 that makes it pretty
 quick to set up.

0:05:18.080000 --> 0:05:24.040000
 The idea here being that Front Door
 is going to give you a layer 7 HTTP,

0:05:24.040000 --> 0:05:31.400000
 HTTPS load balancing solution that's
 global, is highly configurable, and

0:05:31.400000 --> 0:05:36.740000
 does see many functions similar to Application
 Gateway, which we're going

0:05:36.740000 --> 0:05:39.400000
 to get into those functions
 right now.

0:05:39.400000 --> 0:05:41.860000
 So that's the purpose of it.

0:05:41.860000 --> 0:05:43.240000
 What does it do?

0:05:43.240000 --> 0:05:47.280000
 First of all it has smart health probes,
 and this is something that's

0:05:47.280000 --> 0:05:52.320000
 a bit of an advance over either the Load
 Balancer or the Application Gateway,

0:05:52.320000 --> 0:05:57.120000
 in that it's looking at not only whether
 or not it's available, but it

0:05:57.120000 --> 0:06:06.960000
 can also do some load analysis, like what's
 the delay, et cetera, in communicating.

0:06:06.960000 --> 0:06:09.900000
 So that's the Health Probe.

0:06:09.900000 --> 0:06:18.120000
 You have URL-based routing, so as long
 as you get a URL to the Front Door,

0:06:18.120000 --> 0:06:20.800000
 you could have a path in there, have
 different paths going to different

0:06:20.800000 --> 0:06:24.280000
 locations. You could have multiple
 site hostings, I can actually have

0:06:24.280000 --> 0:06:28.540000
 multiple front ends for Front
 Door with different URLs.

0:06:28.540000 --> 0:06:33.000000
 It supports session affinity, so if
 somebody's going through Front Door

0:06:33.000000 --> 0:06:37.100000
 and they've been directed to one particular
 endpoint on the back end,

0:06:37.100000 --> 0:06:39.060000
 you can make sure they
 keep going there.

0:06:39.060000 --> 0:06:41.620000
 It does SSL termination, right?

0:06:41.620000 --> 0:06:49.720000
 And if you're not familiar with that,
 SSL termination, here's the idea.

0:06:49.720000 --> 0:06:52.020000
 I've got a user up here.

0:06:52.020000 --> 0:07:20.800000
 The user makes a request to, let's say,
 a Front Door here, and that request

0:07:20.800000 --> 0:07:24.680000
 gets directed to Front Door, but on
 the back end, I really have one of

0:07:24.680000 --> 0:07:30.660000
 two things. I've got, let's say, a
 web app, and this web app has just

0:07:30.660000 --> 0:07:44.020000
 a generic, even HTTP, ls.ione
.com, ls for low security.

0:07:44.020000 --> 0:07:50.940000
 And what I could do is I could actually
 have the traffic routed over there

0:07:50.940000 --> 0:07:59.900000
 where either I don't have a SSL certificate
 or I could actually do mapping

0:07:59.900000 --> 0:08:04.060000
 of that certificate, so maybe I have
 a different HTTPS on the back end,

0:08:04.060000 --> 0:08:07.160000
 but I knew that wouldn't fit there,
 so I didn't type it in.

0:08:07.160000 --> 0:08:09.140000
 I didn't know that,
 I was just lucky.

0:08:09.140000 --> 0:08:12.040000
 That's secure socket layers termination,
 and we've kind of talked about

0:08:12.040000 --> 0:08:13.320000
 briefly, all of these features.

0:08:13.320000 --> 0:08:16.660000
 These are just all things
 that Front Door does.

0:08:16.660000 --> 0:08:20.400000
 You have the ability to have custom
 domains, and as you would expect,

0:08:20.400000 --> 0:08:25.460000
 if it does secure socket layer termination,
 SSL, and by the way, secure

0:08:25.460000 --> 0:08:30.500000
 socket layer, TLS, they're different,
 I know, but they're referred to

0:08:30.500000 --> 0:08:33.420000
 the same. This doesn't mean you
 don't have TLS with this.

0:08:33.420000 --> 0:08:36.240000
 It's just how it's referred to.

0:08:36.240000 --> 0:08:40.700000
 You also have web application firewall
 that is actually pretty configurable.

0:08:40.700000 --> 0:08:44.320000
 This is again very similar to what
 you have with application gateway,

0:08:44.320000 --> 0:08:45.460000
 if you're familiar with
 that, if you're not.

0:08:45.460000 --> 0:08:47.280000
 Well, now you are.

0:08:47.280000 --> 0:08:52.700000
 And there are built-in rules, industry
 standard rules for protection against

0:08:52.700000 --> 0:08:57.980000
 things like script injection attacks,
 SQL injection attacks, and many

0:08:57.980000 --> 0:09:03.560000
 others. You can also have URL redirection,
 so anything from, let's say,

0:09:03.560000 --> 0:09:07.980000
 if a HTTP request comes in and you
 want to redirect that to HTTPS, you

0:09:07.980000 --> 0:09:12.740000
 can do that. You could also just really
 do whatever redirection you want,

0:09:12.740000 --> 0:09:16.160000
 and URL rewrite.

0:09:16.160000 --> 0:09:20.160000
 And that would be the case if somebody
 is going to a particular path,

0:09:20.160000 --> 0:09:26.580000
 centerinie.com, and we'll call that
 path A, but on the web app that has

0:09:26.580000 --> 0:09:33.600000
 to map to path C, you can do that kind
 of URL rewrite, which is pretty

0:09:33.600000 --> 0:09:40.900000
 cool. So it's really just giving you a
 lot of tools to manage your incoming

0:09:40.900000 --> 0:09:46.960000
 HTTP HTTPS traffic, whether it's for
 a web app, a REST API, or anything

0:09:46.960000 --> 0:09:50.360000
 else like that, pretty much covers the
 spectrum of things that you would

0:09:50.360000 --> 0:09:54.880000
 be using over HTTP slash HTTPS.

0:09:54.880000 --> 0:10:01.160000
 All right, now let's talk about what
 we have with Azure Front Door.

0:10:01.160000 --> 0:10:04.420000
 And the good thing about Azure Front
 Door is that it's very powerful,

0:10:04.420000 --> 0:10:08.800000
 but it's also really relatively
 simple to set up.

0:10:08.800000 --> 0:10:12.700000
 And I'm going to go through the primary
 path here where we set this up,

0:10:12.700000 --> 0:10:15.520000
 and then just kind of demonstrate it,
 and you'll see these parts that

0:10:15.520000 --> 0:10:17.440000
 we can provision.

0:10:17.440000 --> 0:10:26.820000
 There are really three main components
 to Azure Front Door with a few

0:10:26.820000 --> 0:10:28.660000
 other things here.

0:10:28.660000 --> 0:10:31.780000
 Kind of hang down off
 of one of them.

0:10:31.780000 --> 0:10:37.060000
 All right, first, for Azure Front
 Door, we have the front end.

0:10:37.060000 --> 0:10:45.740000
 Front end is going to be associated with
 a URL, and it's a public endpoint,

0:10:45.740000 --> 0:10:47.440000
 as simple as that.

0:10:47.440000 --> 0:10:55.100000
 We then have back end pools.

0:10:55.100000 --> 0:10:59.840000
 You have multiple back end pools just
 as you can have multiple front ends,

0:10:59.840000 --> 0:11:03.720000
 and the back end pool is going to be
 associated with back ends, which

0:11:03.720000 --> 0:11:11.780000
 can be a variety of end points such as
 a public IP address, a app service,

0:11:11.780000 --> 0:11:15.820000
 and many others, and we'll
 see what we have there.

0:11:15.820000 --> 0:11:22.380000
 And then tying them together, you have
 routing rules, or just really just

0:11:22.380000 --> 0:11:25.780000
 referred to as rules.

0:11:25.780000 --> 0:11:30.940000
 And the routing rules are going to allow
 you to define the way that your

0:11:30.940000 --> 0:11:35.500000
 front end is connecting up to your back
 end, what front ends connect to

0:11:35.500000 --> 0:11:41.800000
 back ends. You can do things like define,
 obviously, parameters of that

0:11:41.800000 --> 0:11:45.480000
 connection. So we'll
 just say config.

0:11:45.480000 --> 0:11:52.180000
 You also have the ability
 to customize the probe.

0:11:52.180000 --> 0:12:00.260000
 How's the probe working to make sure
 that back end is, in fact, up and

0:12:00.260000 --> 0:12:04.860000
 running. And that's really pretty much
 what you have to worry about with

0:12:04.860000 --> 0:12:07.660000
 front door. So what I'm going to do
 now is I'm going to go ahead and go

0:12:07.660000 --> 0:12:11.740000
 through the process of provisioning
 an Azure front door, getting it all

0:12:11.740000 --> 0:12:15.560000
 hooked up. I've got a couple of virtual
 machines that I can use as a back

0:12:15.560000 --> 0:12:22.980000
 end, virtual machines that have public
 IPs that I can connect to.

0:12:22.980000 --> 0:12:26.060000
 All right, let's go ahead and
 let's take a look at this.

0:12:26.060000 --> 0:12:29.220000
 There we go. This is my dashboard.


0:12:29.220000 --> 0:12:33.720000
 What I'm going to do is go ahead
 and create a resource.

0:12:33.720000 --> 0:12:41.880000
 I'm going to create a front door, type
 in front, and I get front door.

0:12:41.880000 --> 0:12:43.360000
 Oh, and there's one
 other component.

0:12:43.360000 --> 0:12:45.360000
 I'm glad that came up because
 I was doing it all tough.

0:12:45.360000 --> 0:12:49.540000
 You also do get the web application
 firewall that I did not put in there

0:12:49.540000 --> 0:12:52.420000
 into the diagram, but it
 is part of front door.

0:12:52.420000 --> 0:12:55.060000
 And we'll see where that comes up.


0:12:55.060000 --> 0:12:58.220000
 All right, so I'm going to
 create the front door.

0:12:58.220000 --> 0:13:02.960000
 I'm going to create a resource group,
 and we're going to cleverly call

0:13:02.960000 --> 0:13:06.040000
 this front door.

0:13:06.040000 --> 0:13:10.020000
 Front four. You can do that right.


0:13:10.020000 --> 0:13:17.580000
 Door, R, G. Okay, and we'll go ahead
 and put the resource group in the

0:13:17.580000 --> 0:13:20.020000
 east. Now, notice that says
 resource group location.

0:13:20.020000 --> 0:13:25.620000
 That is not the location of front
 door because front door is global.

0:13:25.620000 --> 0:13:29.520000
 All right, and so now I'm going
 to go ahead and set it up.

0:13:29.520000 --> 0:13:31.980000
 Here are the three components
 that I've got.

0:13:31.980000 --> 0:13:33.900000
 I've got my front end hosts.

0:13:33.900000 --> 0:13:36.700000
 I'm going to go and add
 a front end host.

0:13:36.700000 --> 0:13:43.800000
 Now, with the front end host, I'm going
 to give this a host name, and

0:13:43.800000 --> 0:13:50.840000
 I'm going to say this
 should be good there.

0:13:50.840000 --> 0:13:54.820000
 FD, not FR. There we go.

0:13:54.820000 --> 0:13:56.920000
 All right, now session affinity.

0:13:56.920000 --> 0:14:00.520000
 Do I want to ensure direct subsequent
 traffic from a user goes to the

0:14:00.520000 --> 0:14:01.700000
 same application back in?

0:14:01.700000 --> 0:14:03.140000
 Very easy to set.

0:14:03.140000 --> 0:14:07.320000
 Do I want to apply a web
 application firewall?

0:14:07.320000 --> 0:14:13.500000
 This is where it applies at the front end,
 but I have not set up any policies

0:14:13.500000 --> 0:14:17.080000
 for that, so I'm going to disable
 that for right now.

0:14:17.080000 --> 0:14:28.940000
 Next, I need to go ahead and
 set up the back end pool.

0:14:28.940000 --> 0:14:31.860000
 I'm going to add in
 the back end pool.

0:14:31.860000 --> 0:14:40.940000
 I'm going to give this a name
 of I and E, FD back end.

0:14:40.940000 --> 0:14:44.160000
 Now, I want to add some back end.

0:14:44.160000 --> 0:14:49.040000
 Back end host type, these are all the
 different back end hosts that I

0:14:49.040000 --> 0:14:53.960000
 can have. App service, cloud service,
 storage is kind of interesting.

0:14:53.960000 --> 0:14:56.440000
 But remember, storage
 is actually an API.

0:14:56.440000 --> 0:14:59.880000
 You could conceptually do that.

0:14:59.880000 --> 0:15:05.540000
 I can point to an application gateway,
 API management, a public IP address,

0:15:05.540000 --> 0:15:08.060000
 traffic manager, or
 some custom host.

0:15:08.060000 --> 0:15:12.760000
 This doesn't even have to be in Azure,
 but I have some public IPs.

0:15:12.760000 --> 0:15:15.800000
 Someone will say, all right, we're
 going to go with the public IP.

0:15:15.800000 --> 0:15:22.600000
 I'm going to go with the first
 one here, west web to pip.

0:15:22.600000 --> 0:15:30.900000
 It's got a back end host header,
 port number, HTTPS port priority.

0:15:30.900000 --> 0:15:34.020000
 I've got priority and wait,
 and I set both of these.

0:15:34.020000 --> 0:15:37.000000
 This is a little different, for
 example, than traffic manager.

0:15:37.000000 --> 0:15:41.660000
 With traffic manager, I choose, for
 example, I could choose priority or

0:15:41.660000 --> 0:15:44.520000
 waited. Here, I kind
 of have both, right?

0:15:44.520000 --> 0:15:47.660000
 So as long as things have the same priority
 and they're the highest priority,

0:15:47.660000 --> 0:15:53.300000
 meaning the lowest priority number,
 then it looks at the wait next.

0:15:53.300000 --> 0:15:58.460000
 So I just have this as a wait of 50 and
 it is enabled, and I can add that.

0:15:58.460000 --> 0:16:02.220000
 And I'm going to add
 another back end.

0:16:02.220000 --> 0:16:08.740000
 And this is going to be another
 public IP address.

0:16:08.740000 --> 0:16:13.920000
 And this one is going to
 be apps east web to.

0:16:13.920000 --> 0:16:21.040000
 Got my back end host header, all right,
 my HTTP, HTTPS, my priority and

0:16:21.040000 --> 0:16:25.380000
 wait. And I'm going to
 go ahead and add that.

0:16:25.380000 --> 0:16:31.940000
 All right, so I now have my two
 back ends in this back end pool.

0:16:31.940000 --> 0:16:37.120000
 All right, I've got the health
 probes and it is enabled.

0:16:37.120000 --> 0:16:42.700000
 It's going to look, I can specify
 the path and look at the root.

0:16:42.700000 --> 0:16:48.440000
 Looking for HTTP traffic, and it can
 probe either based on a head request

0:16:48.440000 --> 0:16:52.740000
 or a get request, with head being
 a little bit more efficient.

0:16:52.740000 --> 0:16:57.880000
 And I can set the interval, okay, and
 I can also go into load balancing.

0:16:57.880000 --> 0:17:00.020000
 And this is actually pretty cool.

0:17:00.020000 --> 0:17:04.800000
 This goes into that
 smart pro, right?

0:17:04.800000 --> 0:17:11.400000
 It says, okay, the sample size, and
 that's going to be for requests.

0:17:11.400000 --> 0:17:17.500000
 Successful samples are two, okay, and
 latency sensitivity in milliseconds.

0:17:17.500000 --> 0:17:20.440000
 So how sensitive is it to latency?


0:17:20.440000 --> 0:17:24.740000
 And you're looking to say, okay, we
 just want whatever back end has the

0:17:24.740000 --> 0:17:29.240000
 lowest latency. And there we go.

0:17:29.240000 --> 0:17:30.800000
 All right, so I've got
 my back end pool.

0:17:30.800000 --> 0:17:33.780000
 Now I need my routing rules.

0:17:33.780000 --> 0:17:36.420000
 And you connect the two up.

0:17:36.420000 --> 0:17:40.980000
 I'm going to give this a name.

0:17:40.980000 --> 0:17:47.960000
 It's going to be I-N-E-F-D rule.

0:17:47.960000 --> 0:17:53.140000
 And accepted protocols,
 we'll let them both.

0:17:53.140000 --> 0:17:56.060000
 The front end hosts, the only front
 end hosts that we've got.

0:17:56.060000 --> 0:18:00.220000
 All right, the path that this rule matches,
 I've got the slash star, so

0:18:00.220000 --> 0:18:01.880000
 that's going to be everything.

0:18:01.880000 --> 0:18:06.260000
 Obviously, you can parse your traffic
 out by having traffic coming into

0:18:06.260000 --> 0:18:08.220000
 different ports.

0:18:08.220000 --> 0:18:09.920000
 I mean, different
 paths, excuse me.

0:18:09.920000 --> 0:18:13.760000
 This is at URL routing
 that we've got.

0:18:13.760000 --> 0:18:14.820000
 And then route type.

0:18:14.820000 --> 0:18:17.380000
 I can either forward
 or redirect, right?

0:18:17.380000 --> 0:18:22.600000
 Forward is going to be really the functionality
 of having something like

0:18:22.600000 --> 0:18:25.900000
 app, your application gateway.

0:18:25.900000 --> 0:18:30.900000
 Redirect, you're typically going to
 use to redirect into, for example,

0:18:30.900000 --> 0:18:37.000000
 HTTPS. Okay, and so typically, if I
 was doing that, I would look at that

0:18:37.000000 --> 0:18:41.300000
 and probably go incoming, HTTP.

0:18:41.300000 --> 0:18:44.100000
 Right, I'm going to redirect
 that to HTTPS.

0:18:44.100000 --> 0:18:46.540000
 I'm going to preserve
 everything else.

0:18:46.540000 --> 0:18:50.540000
 And leave it as HTTP element because
 that's what I'm doing.

0:18:50.540000 --> 0:18:52.420000
 All right, now route type.

0:18:52.420000 --> 0:18:54.620000
 We're going to switch
 it back to forwarding.

0:18:54.620000 --> 0:18:58.640000
 Okay, back end pool is going
 to be INE FD back end.

0:18:58.640000 --> 0:19:02.580000
 I'm going to, we can actually
 match the request.

0:19:02.580000 --> 0:19:05.440000
 Okay, I am not rewriting the URL.

0:19:05.440000 --> 0:19:11.140000
 Okay, I'm also not going to enable caching
 right now, but you can cache.

0:19:11.140000 --> 0:19:13.960000
 And that's actually really cool, a little
 bit of a side here, buried in

0:19:13.960000 --> 0:19:15.740000
 the middle of the presentation.

0:19:15.740000 --> 0:19:19.740000
 The way this works is they've
 got a, they being Azure.

0:19:19.740000 --> 0:19:23.020000
 Azure has a global network of
 point of presence servers.

0:19:23.020000 --> 0:19:26.860000
 And one of the cool things about front
 doors that it actually serves like

0:19:26.860000 --> 0:19:29.080000
 a CDN, a content delivery network.


0:19:29.080000 --> 0:19:34.240000
 And you can set up caching so that you
 get the benefits of a content delivery

0:19:34.240000 --> 0:19:38.600000
 network without having to
 specify a separate CDN.

0:19:38.600000 --> 0:19:41.100000
 And that's something
 that is important.

0:19:41.100000 --> 0:19:44.320000
 So hopefully you haven't gone to sleep
 before this because that's a pretty

0:19:44.320000 --> 0:19:46.540000
 powerful capability
 for front doors.

0:19:46.540000 --> 0:19:50.600000
 So not only do you have global load balancing,
 but you also have caching,

0:19:50.600000 --> 0:19:56.740000
 which is going to give you accelerated
 performance for your web requests.

0:19:56.740000 --> 0:19:59.920000
 All right, not using that though.

0:19:59.920000 --> 0:20:01.660000
 And that's my setup.

0:20:01.660000 --> 0:20:08.780000
 And now I'm going to go ahead
 and review and create.

0:20:08.780000 --> 0:20:11.540000
 It has past validation and so
 I'm going to create this.

0:20:11.540000 --> 0:20:15.440000
 Now it's going to take a few minutes
 to create and once that's done, we'll

0:20:15.440000 --> 0:20:19.080000
 come back and take a look at
 what has been generated.

0:20:19.080000 --> 0:20:21.860000
 All right, our deployment
 is complete.

0:20:21.860000 --> 0:20:23.900000
 Now what I'm going to do is just kind
 of go through and show you what

0:20:23.900000 --> 0:20:27.340000
 we have and what you can do.

0:20:27.340000 --> 0:20:32.580000
 Now it sometimes takes a little while
 for the front door service to fully

0:20:32.580000 --> 0:20:36.460000
 populate. So I'm not going to be able
 to show you the results of this,

0:20:36.460000 --> 0:20:39.220000
 but I can show you the components.


0:20:39.220000 --> 0:20:45.100000
 Again, they've really kind of pared
 this down to make it as simple as

0:20:45.100000 --> 0:20:49.480000
 possible. I have some monitoring
 right here on the front page.

0:20:49.480000 --> 0:20:53.400000
 Of course, I've got metrics and alerts
 and diagnostics like I do with

0:20:53.400000 --> 0:21:00.600000
 any other resource, but I've got the
 request, count, size, response, and

0:21:00.600000 --> 0:21:02.120000
 back end health percentage.

0:21:02.120000 --> 0:21:08.080000
 So some really basic data
 that I can keep track of.

0:21:08.080000 --> 0:21:11.340000
 Now I can also go into the front door
 designer, right, and this should

0:21:11.340000 --> 0:21:14.640000
 look familiar. This is pretty much
 the same thing that we had and if I

0:21:14.640000 --> 0:21:19.540000
 need to change anything, I can just
 go in here and change what I need.

0:21:19.540000 --> 0:21:26.880000
 I'm not going to make
 any changes on that.

0:21:26.880000 --> 0:21:31.180000
 And same thing with the back end, I
 go in here and change this back end

0:21:31.180000 --> 0:21:40.500000
 pool. And got a health probe, change
 the health probe as necessary.

0:21:40.500000 --> 0:21:43.500000
 And of course, same thing,
 routing rules.

0:21:43.500000 --> 0:21:44.440000
 Here's my routing rule.

0:21:44.440000 --> 0:21:50.060000
 If I need more routing rules, I
 can absolutely implement them.

0:21:50.060000 --> 0:21:51.740000
 And there we go.

0:21:51.740000 --> 0:21:56.060000
 This is pretty almost
 anticlimactic.

0:21:56.060000 --> 0:21:59.580000
 The only other thing I really need to do
 here is go over to the web application

0:21:59.580000 --> 0:22:04.180000
 firewall. Say you know what, I want
 to go ahead and activate a policy

0:22:04.180000 --> 0:22:08.240000
 for my iNIDemo FD.

0:22:08.240000 --> 0:22:10.840000
 And I don't actually still
 think I have a policy.

0:22:10.840000 --> 0:22:12.940000
 There we go. Don't have
 any existing policies.

0:22:12.940000 --> 0:22:18.160000
 I would have to go ahead and create
 one, which would be separate.

0:22:18.160000 --> 0:22:21.400000
 Okay, but that is
 Azure Front Door.

0:22:21.400000 --> 0:22:22.160000
 Very easy to set up.

0:22:22.160000 --> 0:22:27.140000
 And like I said, after it's time to
 settle out, be able to go ahead and

0:22:27.140000 --> 0:22:31.340000
 go in direct traffic
 to this front end.

0:22:31.340000 --> 0:22:34.900000
 I can even have my
 own CNAME record.

0:22:34.900000 --> 0:22:40.820000
 So my users aren't going to
 iNIDashdemo-fd.azurefd.net.

0:22:40.820000 --> 0:22:48.080000
 That's Front Door, global load balancing
 at the Layer 7 HTTP HTTPS with

0:22:48.080000 --> 0:22:52.320000
 many HTTP and HTTPS specific
 functionality.