WEBVTT

1
00:00.000 --> 00:07.680
Next, let's take a look at some of the features available in Microsoft's Azure.

2
00:07.680 --> 00:13.710
Now, what we want to do here is focus in particularly on three sort of unique

3
00:13.710 --> 00:14.680
load balancing and

4
00:14.680 --> 00:17.140
redundancy technologies that they offer.

5
00:17.140 --> 00:20.480
First, we'll look at the application gateway.

6
00:20.480 --> 00:24.610
Then we'll take a look at the load balancer and finally we'll look at the

7
00:24.610 --> 00:25.880
traffic manager.

8
00:25.880 --> 00:30.910
Now, keep in mind for a lot of the other features and the overall architecture,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:25.880 --> 00:30.910
Now, keep in mind for a lot of the other features and the overall architecture,

9
00:30.910 --> 00:31.560
Azure is going

10
00:31.560 --> 00:37.360
to be very similar to AWS and Google Cloud Services for that matter.

11
00:37.360 --> 00:40.420
They're going to be very similar with, of course, slightly different names for

12
00:40.420 --> 00:40.880
different

13
00:40.880 --> 00:41.880
technologies.

14
00:41.880 --> 00:45.000
But these are some features that are sort of unique to Azure.

15
00:45.000 --> 00:49.960
So let's go ahead and jump in and take a look.

16
00:49.960 --> 00:55.980
So the first feature we want to talk about is an HTTP based load balancer

17
00:55.980 --> 00:56.880
called Azure

18
00:56.880 --> 00:58.720
application gateway.

19
00:58.720 --> 01:06.320
Now, as the name sort of implies, this is, of course, specifically for HTTP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:58.720 --> 01:06.320
Now, as the name sort of implies, this is, of course, specifically for HTTP

20
01:06.320 --> 01:07.320
payloads.

21
01:07.320 --> 01:13.440
And it supports some pretty cool features such as cookie based session affinity

22
01:13.440 --> 01:13.520
.

23
01:13.520 --> 01:18.720
What this is for is to make sure that once a session is established, it's kept

24
01:18.720 --> 01:19.160
with the

25
01:19.160 --> 01:20.760
same server.

26
01:20.760 --> 01:26.000
The reason this is important is a lot of things with HTTP are session based,

27
01:26.000 --> 01:26.600
particularly

28
01:26.600 --> 01:29.680
when you're talking about multi-tiered applications.

29
01:29.680 --> 01:35.880
So it is important that the client gets reconnected to the same backend server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:29.680 --> 01:35.880
So it is important that the client gets reconnected to the same backend server.

30
01:35.880 --> 01:40.390
At the same time, this is going to provide stability and reliability to that

31
01:40.390 --> 01:41.200
connection

32
01:41.200 --> 01:45.840
because again, it will be going to the same backend server.

33
01:45.840 --> 01:49.920
It also supports TLS offload.

34
01:49.920 --> 01:56.240
Essentially the way this works is the client is still going to be talking HTTPS

35
01:56.240 --> 01:56.600
to the

36
01:56.600 --> 01:59.120
application gateway.

37
01:59.120 --> 02:05.500
Then we use HTTP from the application gateway back to the real web server,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:59.120 --> 02:05.500
Then we use HTTP from the application gateway back to the real web server,

38
02:05.500 --> 02:06.720
which would be

39
02:06.720 --> 02:09.920
the same server we were talking about up here.

40
02:09.920 --> 02:17.560
The advantage of this is it offloads all of that TLS decryption from the server

41
02:17.560 --> 02:17.600
.

42
02:17.600 --> 02:22.100
So the application gateway is what's having to decode or unencrypt all the

43
02:22.100 --> 02:23.160
traffic coming

44
02:23.160 --> 02:28.210
from the client where it's at its most vulnerable, passing over, say, for

45
02:28.210 --> 02:29.960
example, the internet.

46
02:29.960 --> 02:34.610
But then once it's within the secure environment of Azure, then that connection
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:29.960 --> 02:34.610
But then once it's within the secure environment of Azure, then that connection

47
02:34.610 --> 02:35.360
is sent with

48
02:35.360 --> 02:38.080
HTTP back to the server.

49
02:38.080 --> 02:42.990
Again, the key factor here though is that the connection over the public

50
02:42.990 --> 02:44.240
networks, i.e.

51
02:44.240 --> 02:47.640
the internet, is still secure.

52
02:47.640 --> 02:50.120
That's of course a key factor.

53
02:50.120 --> 02:53.660
That's why we were using TLS to begin with.

54
02:53.660 --> 02:57.840
This can also do URL-based content routing.

55
02:57.840 --> 03:02.100
Essentially, what we're doing is we're going to route the traffic based on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:57.840 --> 03:02.100
Essentially, what we're doing is we're going to route the traffic based on the

56
03:02.100 --> 03:02.920
destination

57
03:02.920 --> 03:08.040
URL rather than of course the way traditional IP routing works, which is based

58
03:08.040 --> 03:09.280
on the destination

59
03:09.280 --> 03:11.080
IP address.

60
03:11.080 --> 03:15.850
The big advantage here is this is going to offer a lot more flexibility for the

61
03:15.850 --> 03:16.240
load

62
03:16.240 --> 03:22.880
balancing if we're doing it by the URL rather than simply a destination IP.

63
03:22.880 --> 03:28.670
The reason for this is we could actually have different URLs that go to the

64
03:28.670 --> 03:29.760
same server.

65
03:29.760 --> 03:32.440
But we load balance them differently.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:29.760 --> 03:32.440
But we load balance them differently.

66
03:32.440 --> 03:36.160
We wouldn't be able to do that if we were doing it just based on the IP address

67
03:36.160 --> 03:36.600
because

68
03:36.600 --> 03:39.960
of course the server would have the same IP address.

69
03:39.960 --> 03:43.360
So that's where this flexibility comes into play.

70
03:43.360 --> 03:48.200
The next feature we want to talk about is network level load balancing.

71
03:48.200 --> 03:53.760
This is referred to as the Azure load balancer, pretty straightforward name.

72
03:53.760 --> 04:02.180
Now for this feature, the decisions are based upon the IP addresses and TCP or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
03:53.760 --> 04:02.180
Now for this feature, the decisions are based upon the IP addresses and TCP or

73
04:02.180 --> 04:03.040
UDP port

74
04:03.040 --> 04:04.280
numbers.

75
04:04.280 --> 04:11.080
So again, this one is not URL-based, but it's also not focusing strictly on

76
04:11.080 --> 04:11.440
HTTP.

77
04:11.440 --> 04:18.690
In fact, any TCP or UDP application is supported because again, we're using the

78
04:18.690 --> 04:19.640
TCP or UDP

79
04:19.640 --> 04:23.520
port numbers to actually direct the traffic.

80
04:23.520 --> 04:29.840
This will handle load balancing to any Azure VM or cloud services role.

81
04:29.840 --> 04:34.120
In other words, features being offered by Microsoft within the cloud.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
04:29.840 --> 04:34.120
In other words, features being offered by Microsoft within the cloud.

82
04:34.120 --> 04:38.160
This can load balance for either of those two things.

83
04:38.160 --> 04:43.910
And another really cool feature is that this supports both internet facing and

84
04:43.910 --> 04:44.640
internal

85
04:44.640 --> 04:46.320
facing devices.

86
04:46.320 --> 04:51.200
So we're not just talking about internet facing things, but if they're your own

87
04:51.200 --> 04:51.880
internal

88
04:51.880 --> 04:56.710
servers, again, for maybe an internal multi-tiered application, we can still

89
04:56.710 --> 04:57.680
use the network

90
04:57.680 --> 05:02.080
level load balancing to load balance between those devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:57.680 --> 05:02.080
level load balancing to load balance between those devices.

91
05:02.080 --> 05:07.120
And it also fully supports endpoint monitoring so we can keep track of how busy

92
05:07.120 --> 05:08.120
a particular

93
05:08.120 --> 05:11.720
server is and load balance accordingly.

94
05:11.720 --> 05:16.730
The final feature we want to discuss is the global load balancer referred to as

95
05:16.730 --> 05:17.220
Azure

96
05:17.220 --> 05:19.240
traffic manager.

97
05:19.240 --> 05:23.400
This one is a DNS based load balancer.

98
05:23.400 --> 05:27.760
And what's cool about this feature and why it's referred to as global load

99
05:27.760 --> 05:28.480
balancing

100
05:28.480 --> 05:35.000
is this one can distribute traffic across all of the Azure regions.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
05:28.480 --> 05:35.000
is this one can distribute traffic across all of the Azure regions.

101
05:35.000 --> 05:38.680
So it's more than just within the same availability zone.

102
05:38.680 --> 05:43.660
And much like we can do with any cast addresses, clients are going to be

103
05:43.660 --> 05:45.160
directed to the best

104
05:45.160 --> 05:50.820
instance based on what, based on location, and that's going to be coming from

105
05:50.820 --> 05:51.680
the global

106
05:51.680 --> 05:54.720
regions and availability.

107
05:54.720 --> 05:58.360
Once again, this is going to support endpoint monitoring.

108
05:58.360 --> 06:02.580
That's how we're going to know if we have this availability for the server to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
05:58.360 --> 06:02.580
That's how we're going to know if we have this availability for the server to

109
06:02.580 --> 06:03.080
be able

110
06:03.080 --> 06:04.880
to take requests.

111
06:04.880 --> 06:09.090
So again, these are some pretty cool features that we have specifically with

112
06:09.090 --> 06:09.880
Microsoft's

113
06:09.880 --> 06:11.840
Azure.

114
06:11.840 --> 06:16.200
So in this video, we jumped in and just took a look at three pretty cool

115
06:16.200 --> 06:17.800
features we have

116
06:17.800 --> 06:23.720
specifically for load sharing and redundancy in Microsoft Azure.

117
06:23.720 --> 06:28.300
Next, let's take a look at some of the features available in the Google Cloud

118
06:28.300 --> 06:29.400
environment.

119
06:29.400 --> 06:37.400
[BLANK_AUDIO]
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
06:29.400 --> 06:37.400
[BLANK_AUDIO]
