WEBVTT

1
00:00:00.000 --> 00:00:01.380
In this lesson,

2
00:00:01.380 --> 00:00:05.130
we will learn about availability considerations.

3
00:00:05.130 --> 00:00:07.560
Availability considerations ensure

4
00:00:07.560 --> 00:00:12.360
that users can access systems, applications, and services

5
00:00:12.360 --> 00:00:15.570
even in the face of failures, high demand,

6
00:00:15.570 --> 00:00:17.640
or other disruptions.

7
00:00:17.640 --> 00:00:19.440
Availability considerations

8
00:00:19.440 --> 00:00:22.800
result in the implementation of load balancing,

9
00:00:22.800 --> 00:00:26.190
using persistent and non-persistent affinity,

10
00:00:26.190 --> 00:00:28.710
as well as interoperability.

11
00:00:28.710 --> 00:00:32.490
Let's learn more about load balancing, persistence,

12
00:00:32.490 --> 00:00:36.150
non-persistence, and interoperability.

13
00:00:36.150 --> 00:00:38.820
First, we have load balancing.

14
00:00:38.820 --> 00:00:42.390
Load balancing is a technique used in web services

15
00:00:42.390 --> 00:00:44.490
to distribute incoming traffic

16
00:00:44.490 --> 00:00:47.010
across multiple backend servers.

17
00:00:47.010 --> 00:00:48.600
Load balancing ensures

18
00:00:48.600 --> 00:00:51.930
that no single server becomes overwhelmed

19
00:00:51.930 --> 00:00:56.460
and that servers remain available even during peak demand.

20
00:00:56.460 --> 00:00:58.800
Think of it like a host at a restaurant

21
00:00:58.800 --> 00:01:00.510
with several waiters.

22
00:01:00.510 --> 00:01:04.470
Each waiter can service a handful of tables at a time.

23
00:01:04.470 --> 00:01:06.330
When new customers come in,

24
00:01:06.330 --> 00:01:08.460
the host distributes them evenly

25
00:01:08.460 --> 00:01:10.440
across the available waiters

26
00:01:10.440 --> 00:01:13.260
to ensure that no waiter gets overburdened

27
00:01:13.260 --> 00:01:15.720
and everyone is served efficiently.

28
00:01:15.720 --> 00:01:18.840
Similarly, load balancing helps maintain

29
00:01:18.840 --> 00:01:21.120
the availability of a service

30
00:01:21.120 --> 00:01:23.760
by spreading requests across servers

31
00:01:23.760 --> 00:01:26.670
so that no one server gets too busy.

32
00:01:26.670 --> 00:01:29.130
Load balancers use different algorithms

33
00:01:29.130 --> 00:01:33.180
to determine how to distribute that incoming traffic.

34
00:01:33.180 --> 00:01:36.210
One common approach is called Round Robin.

35
00:01:36.210 --> 00:01:37.650
Using Round Robin,

36
00:01:37.650 --> 00:01:41.310
requests are sent to servers in a rotating order.

37
00:01:41.310 --> 00:01:42.480
In Round Robin,

38
00:01:42.480 --> 00:01:45.630
there is no consideration for server load.

39
00:01:45.630 --> 00:01:49.380
Requests are simply forwarded to the next server in line.

40
00:01:49.380 --> 00:01:51.960
Another method is least connections.

41
00:01:51.960 --> 00:01:53.580
Using least connections,

42
00:01:53.580 --> 00:01:55.740
a load balancer directs traffic

43
00:01:55.740 --> 00:01:59.730
to the server with the fewest active connections.

44
00:01:59.730 --> 00:02:03.480
Some load balancers use an IP hashing method

45
00:02:03.480 --> 00:02:04.830
to distribute load.

46
00:02:04.830 --> 00:02:09.060
The IP hashing method hashes the client's IP address

47
00:02:09.060 --> 00:02:13.110
and maps that client IP address to an available server.

48
00:02:13.110 --> 00:02:17.130
In this way, IP hashing ensures a specific user

49
00:02:17.130 --> 00:02:20.700
is always sent back to the same server.

50
00:02:20.700 --> 00:02:22.650
Load balancing can also act

51
00:02:22.650 --> 00:02:26.700
as a defensive mechanism against certain types of attack,

52
00:02:26.700 --> 00:02:31.700
particularly distributed denial of service, or DDoS attacks.

53
00:02:31.860 --> 00:02:35.520
In a DDoS attack, an attacker floods a server

54
00:02:35.520 --> 00:02:38.310
with an overwhelming amount of requests,

55
00:02:38.310 --> 00:02:41.910
crashing the system by exhausting its resources.

56
00:02:41.910 --> 00:02:43.650
With load balancing in place,

57
00:02:43.650 --> 00:02:47.070
traffic can be distributed across multiple servers,

58
00:02:47.070 --> 00:02:50.610
preventing a single server from being overwhelmed.

59
00:02:50.610 --> 00:02:53.190
If the servers start to become overwhelmed,

60
00:02:53.190 --> 00:02:55.200
the load balancer can simply drop

61
00:02:55.200 --> 00:02:59.910
additional incoming requests, preventing the DDoS attack.

62
00:02:59.910 --> 00:03:04.020
Second, let's talk about persistence and non-persistence.

63
00:03:04.020 --> 00:03:05.820
Persistence and non-persistence

64
00:03:05.820 --> 00:03:09.990
relate to how user requests are handled by the servers.

65
00:03:09.990 --> 00:03:11.730
Let's start with persistence.

66
00:03:11.730 --> 00:03:15.180
In simple terms, persistence means that once a user

67
00:03:15.180 --> 00:03:17.280
connects to a specific server,

68
00:03:17.280 --> 00:03:19.620
they stay connected to that same server

69
00:03:19.620 --> 00:03:21.630
for the duration of their session.

70
00:03:21.630 --> 00:03:24.810
This is often referred to as session affinity.

71
00:03:24.810 --> 00:03:26.730
Session affinity is important

72
00:03:26.730 --> 00:03:29.010
for maintaining data integrity,

73
00:03:29.010 --> 00:03:31.020
especially in situations

74
00:03:31.020 --> 00:03:34.440
where the server stores session-specific information

75
00:03:34.440 --> 00:03:37.680
like shopping carts or user preferences.

76
00:03:37.680 --> 00:03:40.680
For example, if you are shopping online

77
00:03:40.680 --> 00:03:42.900
and adding items to your cart,

78
00:03:42.900 --> 00:03:46.410
you want all your requests to be handled by the same server

79
00:03:46.410 --> 00:03:49.200
so that your cart data stays intact.

80
00:03:49.200 --> 00:03:52.740
Session affinity guarantees a continuous connection,

81
00:03:52.740 --> 00:03:55.710
making sure that any session-specific data

82
00:03:55.710 --> 00:03:58.290
remains accurate and available.

83
00:03:58.290 --> 00:04:00.450
Non-persistence, on the other hand,

84
00:04:00.450 --> 00:04:02.970
means each request a user makes

85
00:04:02.970 --> 00:04:05.610
may be handled by a different server.

86
00:04:05.610 --> 00:04:07.830
This is more efficient for systems

87
00:04:07.830 --> 00:04:10.050
where each request is independent

88
00:04:10.050 --> 00:04:12.450
and there's no need to maintain a connection

89
00:04:12.450 --> 00:04:13.890
to the same server.

90
00:04:13.890 --> 00:04:17.340
For example, if you are browsing a news website

91
00:04:17.340 --> 00:04:19.920
where each article you read is separate

92
00:04:19.920 --> 00:04:23.850
and doesn't need to be connected to your previous actions,

93
00:04:23.850 --> 00:04:26.190
non-persistence works just fine.

94
00:04:26.190 --> 00:04:30.300
In this case, the load balancer can distribute your request

95
00:04:30.300 --> 00:04:32.790
to whichever server is the least busy,

96
00:04:32.790 --> 00:04:34.560
maximizing efficiency

97
00:04:34.560 --> 00:04:38.460
and keeping the system response fast during heavy traffic.

98
00:04:38.460 --> 00:04:42.870
Third, and finally, let's talk about interoperability.

99
00:04:42.870 --> 00:04:44.910
Interoperability is the ability

100
00:04:44.910 --> 00:04:48.750
of different systems, applications, or devices

101
00:04:48.750 --> 00:04:50.760
to work together seamlessly,

102
00:04:50.760 --> 00:04:55.020
exchanging and using information without any barriers.

103
00:04:55.020 --> 00:04:58.620
It's like making sure different types of equipment, tools,

104
00:04:58.620 --> 00:05:02.520
or even teams can all cooperate effectively

105
00:05:02.520 --> 00:05:05.490
even if they were originally built separately.

106
00:05:05.490 --> 00:05:08.250
So interoperability ensures

107
00:05:08.250 --> 00:05:10.620
that various systems can communicate

108
00:05:10.620 --> 00:05:14.640
and function smoothly even in complex environments.

109
00:05:14.640 --> 00:05:17.820
For example, imagine you are using an app

110
00:05:17.820 --> 00:05:20.430
that pulls data from different sources,

111
00:05:20.430 --> 00:05:21.870
like a fitness app

112
00:05:21.870 --> 00:05:25.410
that gathers information from your phone's GPS,

113
00:05:25.410 --> 00:05:29.610
your smartwatch, and a cloud-based health database.

114
00:05:29.610 --> 00:05:31.560
Interoperability ensures

115
00:05:31.560 --> 00:05:34.500
that these different sources can work together

116
00:05:34.500 --> 00:05:36.570
so your app runs smoothly.

117
00:05:36.570 --> 00:05:40.080
Without interoperability, one part of the system

118
00:05:40.080 --> 00:05:42.870
might not be able to communicate with another,

119
00:05:42.870 --> 00:05:46.080
causing errors or making the service unavailable

120
00:05:46.080 --> 00:05:47.220
when you need it.

121
00:05:47.220 --> 00:05:49.440
From an availability standpoint,

122
00:05:49.440 --> 00:05:52.770
interoperability helps systems stay online

123
00:05:52.770 --> 00:05:54.450
and function properly.

124
00:05:54.450 --> 00:05:56.940
When different systems can work together,

125
00:05:56.940 --> 00:05:59.940
they can handle user requests more efficiently

126
00:05:59.940 --> 00:06:01.620
and share resources,

127
00:06:01.620 --> 00:06:05.310
which means less downtime and fewer bottlenecks.

128
00:06:05.310 --> 00:06:08.280
For example, in the financial industry,

129
00:06:08.280 --> 00:06:11.880
interoperability between different banking systems

130
00:06:11.880 --> 00:06:15.090
allows customers to seamlessly transfer money

131
00:06:15.090 --> 00:06:19.680
between accounts at different banks, use various ATMs,

132
00:06:19.680 --> 00:06:21.990
and make transactions online

133
00:06:21.990 --> 00:06:25.530
regardless of which institution they belong to.

134
00:06:25.530 --> 00:06:29.820
So remember, availability considerations ensure

135
00:06:29.820 --> 00:06:34.560
that systems and services remain accessible and operational

136
00:06:34.560 --> 00:06:38.850
even during high demand, failures, or disruptions.

137
00:06:38.850 --> 00:06:42.090
To achieve this, techniques like load balancing,

138
00:06:42.090 --> 00:06:46.620
session persistence, and interoperability are used.

139
00:06:46.620 --> 00:06:49.260
Load balancing helps distribute traffic

140
00:06:49.260 --> 00:06:52.770
across multiple servers to prevent overload.

141
00:06:52.770 --> 00:06:56.160
Persistence ensures that users remain connected

142
00:06:56.160 --> 00:06:59.970
to the same server for the duration of their session.

143
00:06:59.970 --> 00:07:02.340
Non-persistence allows requests

144
00:07:02.340 --> 00:07:05.820
to be handled by different servers, increasing efficiency

145
00:07:05.820 --> 00:07:09.390
and optimizing resource use across the system.

146
00:07:09.390 --> 00:07:13.800
And finally, interoperability ensures that different systems

147
00:07:13.800 --> 00:07:16.080
and applications work together,

148
00:07:16.080 --> 00:07:20.223
enabling both availability and functionality.