WEBVTT

1
00:00.000 --> 00:09.000
Performance and redundancy have always been important factors on our networks.

2
00:09.000 --> 00:15.550
However, it hasn't always been so much a focus on necessarily internet access

3
00:15.550 --> 00:19.000
and specifically access to cloud resources.

4
00:19.000 --> 00:22.770
It used to just sort of be it in convenience for most companies if their

5
00:22.770 --> 00:25.000
internet connection went down.

6
00:25.000 --> 00:31.300
Anything mission critical was kept in-house or on-prem and we had all of those
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

6
00:25.000 --> 00:31.300
Anything mission critical was kept in-house or on-prem and we had all of those

7
00:31.300 --> 00:33.000
resources locally.

8
00:33.000 --> 00:38.070
But in today's environment, that's changing significantly where a lot of our

9
00:38.070 --> 00:42.000
mission critical stuff is kept out with cloud providers.

10
00:42.000 --> 00:47.360
So now it becomes absolutely critical to provide both performance and

11
00:47.360 --> 00:52.000
redundancy to those connections to the cloud providers.

12
00:52.000 --> 00:55.000
And that's what we're going to be focusing on right now.

13
00:55.000 --> 00:59.410
We're going to start by taking a look at why it's so important and some of the

14
00:59.410 --> 01:04.130
options and things we have to keep in mind as we're moving through this skill
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:59.410 --> 01:04.130
options and things we have to keep in mind as we're moving through this skill

15
01:04.130 --> 01:09.000
talking about providing both redundancy and performance.

16
01:09.000 --> 01:13.780
And also keep in mind that those two things are quite commonly tightly

17
01:13.780 --> 01:15.000
intertwined.

18
01:15.000 --> 01:21.580
Performance is redundancy in most cases, particularly if we're talking about

19
01:21.580 --> 01:23.000
something like connections.

20
01:23.000 --> 01:28.660
So, for example, if I have dual connections out to a cloud provider, am I just

21
01:28.660 --> 01:34.370
using one of them at a time in a failover, failback type scenario and just
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
01:28.660 --> 01:34.370
using one of them at a time in a failover, failback type scenario and just

22
01:34.370 --> 01:36.000
providing redundancy?

23
01:36.000 --> 01:42.040
Or am I using both connections simultaneously, load sharing or load balancing

24
01:42.040 --> 01:46.000
over them, and therefore offering performance.

25
01:46.000 --> 01:50.410
And then in the event of a failure, we of course failover and just use the one

26
01:50.410 --> 01:52.000
existing connection.

27
01:52.000 --> 01:56.680
So in that example, we will be providing both performance and redundancy to our

28
01:56.680 --> 01:58.000
cloud connection.

29
01:58.000 --> 02:05.230
So let's go ahead and jump in and take a closer look at our requirements and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:58.000 --> 02:05.230
So let's go ahead and jump in and take a closer look at our requirements and

30
02:05.230 --> 02:07.000
some of our options.

31
02:07.000 --> 02:12.400
So as I'm sure most of you are already aware, cloud services, really of any

32
02:12.400 --> 02:19.000
kind, are becoming mission critical to many companies, if not most companies.

33
02:19.000 --> 02:24.290
As I said during the introduction, it's not that long ago when internet access

34
02:24.290 --> 02:29.000
for a company was really just sort of a convenience. It was a luxury.

35
02:29.000 --> 02:33.860
We used it for a lot of things don't misunderstand, but it wasn't necessarily
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
02:29.000 --> 02:33.860
We used it for a lot of things don't misunderstand, but it wasn't necessarily

36
02:33.860 --> 02:37.000
mission critical to the core of the business.

37
02:37.000 --> 02:44.780
Now, so many companies are storing all of their data, for example, on Amazon S3

38
02:44.780 --> 02:46.000
storage.

39
02:46.000 --> 02:51.020
So if they lose reachability to that cloud service, they're going to be without

40
02:51.020 --> 02:52.000
their data.

41
02:52.000 --> 02:56.160
And again, in most situations, that's going to make it difficult for the

42
02:56.160 --> 02:58.000
employees to be productive.

43
02:58.000 --> 03:04.240
So just like any other mission critical resources, it really is up to the IT
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
02:58.000 --> 03:04.240
So just like any other mission critical resources, it really is up to the IT

44
03:04.240 --> 03:11.000
department to provide the needed services for the connectivity to the cloud.

45
03:11.000 --> 03:16.000
Specifically, we're talking about things like scalability.

46
03:16.000 --> 03:20.000
This needs to be able to grow as our needs grow.

47
03:20.000 --> 03:24.430
And that could mean anything from the actual services that we're getting from

48
03:24.430 --> 03:29.000
the cloud providers themselves to our connections to the cloud services.

49
03:29.000 --> 03:35.000
It needs to be resilient and provide high availability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
03:29.000 --> 03:35.000
It needs to be resilient and provide high availability.

50
03:35.000 --> 03:38.000
Now, those two things go very closely hand in hand.

51
03:38.000 --> 03:42.000
But really what we're talking about is it needs to stay up.

52
03:42.000 --> 03:44.000
It needs to stay available.

53
03:44.000 --> 03:47.980
And that can mean a lot of things and that's what we're going to be trying to

54
03:47.980 --> 03:50.000
clarify here as we move forward.

55
03:50.000 --> 03:55.140
So as we're thinking about this, there's a lot of things that we need to

56
03:55.140 --> 04:01.150
consider for not just the cloud service itself, which of course we have to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
03:55.140 --> 04:01.150
consider for not just the cloud service itself, which of course we have to be

57
04:01.150 --> 04:02.000
concerned with.

58
04:02.000 --> 04:08.000
But let's not forget, we also have to have a connection to that cloud service.

59
04:08.000 --> 04:13.000
A lot of the things we're going to be discussing involve the on-prem location,

60
04:13.000 --> 04:18.760
because the cloud providers themselves are going to be offering a lot of this

61
04:18.760 --> 04:20.000
redundancy.

62
04:20.000 --> 04:24.270
So when we start talking about things like Internet redundancy and power

63
04:24.270 --> 04:28.960
redundancy and cooling redundancy and all this kind of stuff, the cloud

64
04:28.960 --> 04:32.000
providers are offering that to their own equipment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
04:28.960 --> 04:32.000
providers are offering that to their own equipment.

65
04:32.000 --> 04:36.380
In other words, the cloud itself is relatively resilient. That's what we're

66
04:36.380 --> 04:39.000
going to be discussing and how they do that.

67
04:39.000 --> 04:43.870
We have things like zones and regions and again, all of the equipment in all of

68
04:43.870 --> 04:47.000
those zones and regions also has redundancy.

69
04:47.000 --> 04:50.000
But this is what we need to talk about and discuss.

70
04:50.000 --> 04:54.000
But it's not enough just for the cloud to have that redundancy.

71
04:54.000 --> 04:59.110
We need to have it on our equipment as well, because again, if we can't get to

72
04:59.110 --> 05:00.000
the cloud.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
05:00.000 --> 05:03.990
Well, then we won't be able to access the resources, even if they are still up

74
05:03.990 --> 05:05.000
and available.

75
05:05.000 --> 05:08.000
So what are the things we have to worry about?

76
05:08.000 --> 05:10.000
Let's talk first about scalability.

77
05:10.000 --> 05:14.000
And there's really sort of three aspects to this.

78
05:14.000 --> 05:17.000
First, we have vertical scaling.

79
05:17.000 --> 05:22.780
Vertical scaling involves increasing the resources of an individual node to

80
05:22.780 --> 05:25.000
handle an increased load.

81
05:25.000 --> 05:30.680
So if we were talking about, say, a physical server, for example, we would be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
05:25.000 --> 05:30.680
So if we were talking about, say, a physical server, for example, we would be

82
05:30.680 --> 05:35.000
adding more RAM to it or adding more hard drive space to it.

83
05:35.000 --> 05:40.510
In the case of our cloud services, maybe it means using a different tier of

84
05:40.510 --> 05:47.000
server offered by that cloud provider to run our resource or our application.

85
05:47.000 --> 05:52.000
Horizontal scaling, on the other hand, is growing out.

86
05:52.000 --> 05:56.000
So this would involve adding more nodes to a system.

87
05:56.000 --> 05:59.810
So maybe more network connections that I can bundle together and use

88
05:59.810 --> 06:01.000
simultaneously.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
05:59.810 --> 06:01.000
simultaneously.

89
06:01.000 --> 06:05.690
Maybe adding more servers to run our application and putting them behind

90
06:05.690 --> 06:08.000
something like a load balancer.

91
06:08.000 --> 06:11.000
So there are several different options for horizontal scaling.

92
06:11.000 --> 06:17.000
And then a lot of these providers also offer automated scaling.

93
06:17.000 --> 06:22.750
In fact, you can even do this in your private cloud using something like VMware

94
06:22.750 --> 06:28.670
, the vSphere product supports automatic scaling within clusters, where it can

95
06:28.670 --> 06:33.670
actually spin up new servers, spin down servers, as you need them or don't need
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
06:28.670 --> 06:33.670
actually spin up new servers, spin down servers, as you need them or don't need

96
06:33.670 --> 06:34.000
them.

97
06:34.000 --> 06:37.860
So essentially what we're saying is that automated scaling is going to

98
06:37.860 --> 06:42.820
dynamically adjust the resources, which enables the system to automatically

99
06:42.820 --> 06:45.000
adapt to changing workloads.

100
06:45.000 --> 06:49.270
This is going to optimize efficiency and responsiveness to change on the

101
06:49.270 --> 06:50.000
network.

102
06:50.000 --> 06:54.000
Next, let's talk more about high availability.

103
06:54.000 --> 06:59.760
And of course, probably the most important factor here is to have redundant

104
06:59.760 --> 07:01.000
components.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
06:59.760 --> 07:01.000
components.

105
07:01.000 --> 07:05.000
So here we're going to be talking generally about physical equipment.

106
07:05.000 --> 07:10.930
We're going to be talking about having routers with multiple power supplies or

107
07:10.930 --> 07:18.490
dual supervisor engines, having a fan tray that has say nine fans in it, but it

108
07:18.490 --> 07:22.000
's enough to keep the system cool if we only have eight fans.

109
07:22.000 --> 07:32.000
So that's giving us fan redundancy in a fan tray.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
07:22.000 --> 07:32.000
So that's giving us fan redundancy in a fan tray.

110
07:32.000 --> 07:33.660
And keep in mind that the large majority of Cisco equipment has redundant

111
07:33.660 --> 07:35.000
options as far as components within the device itself.

112
07:35.000 --> 07:40.000
Then let's not forget you can also of course have redundant devices.

113
07:40.000 --> 07:43.000
We can have multiple edge routers.

114
07:43.000 --> 07:47.700
We could have multiple switches in our environment, all designed for redundancy

115
07:47.700 --> 07:49.000
and availability.

116
07:49.000 --> 07:55.120
Generally speaking, having redundant devices in and of itself isn't going to do

117
07:55.120 --> 07:57.000
us a whole lot of good.

118
07:57.000 --> 08:03.000
Unless we also have redundant connections going to those redundant devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
07:57.000 --> 08:03.000
Unless we also have redundant connections going to those redundant devices.

119
08:03.000 --> 08:07.000
And believe me, I have seen different combinations of all of this.

120
08:07.000 --> 08:11.640
And you have to keep in mind too, that budget has to be considered here as well

121
08:11.640 --> 08:12.000
.

122
08:12.000 --> 08:15.960
And we'll talk about that actually a little bit more, but we can provide

123
08:15.960 --> 08:18.000
redundancy to all of these things.

124
08:18.000 --> 08:21.000
And even the infrastructure itself.

125
08:21.000 --> 08:25.990
We can have redundancy within our infrastructure, multiple UPS's backup

126
08:25.990 --> 08:31.000
generators, multiple power grids, multiple HVAC.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
08:25.990 --> 08:31.000
generators, multiple power grids, multiple HVAC.

127
08:31.000 --> 08:35.830
Again, we'll explore this a little bit more in the next video, but there's all

128
08:35.830 --> 08:39.950
sorts of options for redundancy when it comes to the actual infrastructure

129
08:39.950 --> 08:42.000
where this equipment is running.

130
08:42.000 --> 08:47.130
And as we said, sort of along the same lines as high availability would be res

131
08:47.130 --> 08:48.000
iliency.

132
08:48.000 --> 08:52.000
The real trick is a way to handle our high availability.

133
08:52.000 --> 08:57.790
In other words, we have to have that fault tolerance of course, which is going

134
08:57.790 --> 09:00.000
right back to the high availability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
09:00.000 --> 09:05.000
But we're also talking about things here like HSRP or VRRP.

136
09:05.000 --> 09:08.000
So our first hop redundancy protocols.

137
09:08.000 --> 09:12.820
This can include things like having a disaster recovery site or a disaster

138
09:12.820 --> 09:17.000
recovery plan, maybe multiple disaster recovery locations.

139
09:17.000 --> 09:21.610
And probably the most important part of the resiliency and dealing with the

140
09:21.610 --> 09:26.000
high availability is to have some form of automated failover here.

141
09:26.000 --> 09:30.000
We want to have some form of a failover mechanism.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
09:30.000 --> 09:35.000
And we want this to be very predictive, meaning we should know what it's going

143
09:35.000 --> 09:39.000
to do and how it's going to behave in the event of a failure.

144
09:39.000 --> 09:44.210
This is where things like HSRP, VRRP, dynamic routing protocols, IPS LA

145
09:44.210 --> 09:50.000
monitors, tracked objects, BFD or bi-directional forwarding detection.

146
09:50.000 --> 09:54.500
Even QOS can help with this kind of a situation, particularly on the predictive

147
09:54.500 --> 09:59.000
side, to predict how certain type of traffic is going to be handled.

148
09:59.000 --> 10:04.000
And that prioritization may change in the event of a failure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
09:59.000 --> 10:04.000
And that prioritization may change in the event of a failure.

149
10:04.000 --> 10:06.000
So again, there's a lot of different aspects here.

150
10:06.000 --> 10:10.780
And again, we'll be covering this in a little more detail as we dive in more in

151
10:10.780 --> 10:12.000
the next video.

152
10:12.000 --> 10:17.810
But also keep in mind with everything we're talking about here, that every

153
10:17.810 --> 10:24.000
single component in the entire path has to provide these features, or we're

154
10:24.000 --> 10:28.000
going to have a single point of failure.

155
10:28.000 --> 10:30.000
That's of course what we don't want.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
10:30.000 --> 10:34.860
But this falls back to that old saying that your network is only going to be as

157
10:34.860 --> 10:37.000
strong as your weakest link.

158
10:37.000 --> 10:41.000
If you do have a single point of failure, guess what's going to fail?

159
10:41.000 --> 10:45.510
The single point of failure, nine times out of ten, because that's just the way

160
10:45.510 --> 10:47.000
things seem to work.

161
10:47.000 --> 10:53.000
Now, as I mentioned, you do always have to look at cost versus risk.

162
10:53.000 --> 10:58.600
In other words, what's going to happen if this resource were to go down and how

163
10:58.600 --> 11:05.210
much is it going to cost me to provide the redundancy to ensure that it doesn't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

163
10:58.600 --> 11:05.210
much is it going to cost me to provide the redundancy to ensure that it doesn't

164
11:05.210 --> 11:06.000
go down.

165
11:06.000 --> 11:09.000
This is often referred to as a risk analysis.

166
11:09.000 --> 11:14.240
And keep in mind that this is going to include not just the physical equipment,

167
11:14.240 --> 11:17.000
but also the different cloud components.

168
11:17.000 --> 11:22.000
How many gateways or servers are we going to deploy in AWS, for example.

169
11:22.000 --> 11:26.880
So just to sort of give you a real world example of what I'm talking about with

170
11:26.880 --> 11:29.000
this cost to risk analysis.

171
11:29.000 --> 11:35.000
One of the enterprises I used to work for, we had several very large locations.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
11:29.000 --> 11:35.000
One of the enterprises I used to work for, we had several very large locations.

172
11:35.000 --> 11:39.890
I'm talking about buildings that had somewhere around 500 to 1000 people

173
11:39.890 --> 11:41.000
working in them.

174
11:41.000 --> 11:46.100
And in those locations, we would offer redundant routers with redundant

175
11:46.100 --> 11:47.000
switches.

176
11:47.000 --> 11:52.000
They had redundant power supplies. They had redundant supervisor engines.

177
11:52.000 --> 11:55.000
They had pretty much redundant everything.

178
11:55.000 --> 11:58.000
But of course, all of that costs money.

179
11:58.000 --> 12:04.230
On the flip side, we had some very, very small locations where there were maybe
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
11:58.000 --> 12:04.230
On the flip side, we had some very, very small locations where there were maybe

180
12:04.230 --> 12:08.000
five to 10 people working at that location.

181
12:08.000 --> 12:13.920
There, all we provided was a single router and a single switch for their

182
12:13.920 --> 12:15.000
network.

183
12:15.000 --> 12:18.990
And again, the thought process is basically, if that equipment were to go down,

184
12:18.990 --> 12:24.550
we can replace it and get it back up and running within four hours, because we

185
12:24.550 --> 12:26.000
have four hour response.

186
12:26.000 --> 12:31.390
However, all that's going to happen is five to 10 people aren't going to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
12:26.000 --> 12:31.390
However, all that's going to happen is five to 10 people aren't going to be

187
12:31.390 --> 12:34.000
able to work for about four hours.

188
12:34.000 --> 12:39.000
That's completely different than 500 to 1000 and one building.

189
12:39.000 --> 12:44.280
I think we had like 2,500 people in it give or take that being down for four

190
12:44.280 --> 12:47.000
hours is a whole different situation.

191
12:47.000 --> 12:51.960
Not to mention some of those buildings had the higher ups in the corporation

192
12:51.960 --> 12:53.000
working in them.

193
12:53.000 --> 12:57.000
And some of the remote offices were really just sales offices.

194
12:57.000 --> 13:02.180
And while they didn't really need network connection all the time in order for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
12:57.000 --> 13:02.180
And while they didn't really need network connection all the time in order for

195
13:02.180 --> 13:04.000
them to do their job anyway.

196
13:04.000 --> 13:06.000
So that's exactly what we're talking about.

197
13:06.000 --> 13:10.680
We're not going to spend all that money at a small remote location that doesn't

198
13:10.680 --> 13:14.000
even really need the network to get their job done.

199
13:14.000 --> 13:17.930
Where we're going to spend our money is in the big facilities where the

200
13:17.930 --> 13:22.000
important work is being done that does need network connectivity.

201
13:22.000 --> 13:25.000
Now don't misunderstand both jobs were very important.

202
13:25.000 --> 13:29.000
It's just one really needs network connectivity and the other one.

203
13:29.000 --> 13:31.000
Well, it was more of a convenience.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
13:29.000 --> 13:31.000
Well, it was more of a convenience.

204
13:31.000 --> 13:35.000
So that's where we have to look at how much we're going to spend versus.

205
13:35.000 --> 13:39.000
Well, what's going to happen if they can't get to the network, right?

206
13:39.000 --> 13:41.000
What's the worst case scenario?

207
13:41.000 --> 13:46.000
That's your cost versus risk and it always has to be in the back of your mind

208
13:46.000 --> 13:49.000
when you're dealing with performance and redundancy.

209
13:49.000 --> 13:54.840
Something a little bit unique to the cloud environment specifically is having

210
13:54.840 --> 14:01.200
things like cloud interconnects and co locations, which we spoke of earlier in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
13:54.840 --> 14:01.200
things like cloud interconnects and co locations, which we spoke of earlier in

211
14:01.200 --> 14:02.000
previous skills.

212
14:02.000 --> 14:07.470
These are actually going to be great resources for providing specifically that

213
14:07.470 --> 14:10.000
redundancy for our cloud access.

214
14:10.000 --> 14:16.200
We actually spoke then about how we can use co locations and cloud interconnect

215
14:16.200 --> 14:21.000
s as a fallback for a direct internet connection failure.

216
14:21.000 --> 14:26.310
This point we did mention during the introduction that redundancy can actually

217
14:26.310 --> 14:31.000
be part of our scalability or performance until there's a failure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

217
14:26.310 --> 14:31.000
be part of our scalability or performance until there's a failure.

218
14:31.000 --> 14:35.020
So again, just to make it real easy if you have two connections and I'm load

219
14:35.020 --> 14:38.940
sharing across both of them, that's going to give me scalability slash

220
14:38.940 --> 14:40.000
performance.

221
14:40.000 --> 14:46.000
And then when a failure does occur, I simply lose the second connection.

222
14:46.000 --> 14:50.330
And now I just keep going over the single connection is my performance going to

223
14:50.330 --> 14:51.000
go down.

224
14:51.000 --> 14:55.000
Yes, of course it will because I'm using one connection instead of two.

225
14:55.000 --> 15:00.930
But that's also providing the redundancy then. That's the whole point is we can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

225
14:55.000 --> 15:00.930
But that's also providing the redundancy then. That's the whole point is we can

226
15:00.930 --> 15:05.000
sort of provide both at the same time, depending on our design.

227
15:05.000 --> 15:09.730
And one last thing to keep in mind, we're not necessarily always talking about

228
15:09.730 --> 15:12.000
redundant internet access here.

229
15:12.000 --> 15:18.000
This could actually be a combination of internet and private connections.

230
15:18.000 --> 15:23.040
Keep in mind, we would probably use one of these private connections to get to

231
15:23.040 --> 15:26.000
this co location or cloud interconnect.

232
15:26.000 --> 15:31.270
So that's what we're talking about here. We might have a direct internet
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

232
15:26.000 --> 15:31.270
So that's what we're talking about here. We might have a direct internet

233
15:31.270 --> 15:36.040
connection at a location and be using our private connection through a cloud

234
15:36.040 --> 15:41.000
interconnect or co location to back that up to provide our redundancy.

235
15:41.000 --> 15:47.000
So in this video, we got an introduction to performance and redundancy for

236
15:47.000 --> 15:49.000
cloud connectivity.

237
15:49.000 --> 15:53.950
We talked about why this is so important for companies, particularly in today's

238
15:53.950 --> 15:59.730
environment, where more and more mission critical cloud based applications and

239
15:59.730 --> 16:03.000
data are being used by major corporations.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

239
15:59.730 --> 16:03.000
data are being used by major corporations.

240
16:03.000 --> 16:08.820
As the IT department, if it's mission critical, it's our job to make sure that

241
16:08.820 --> 16:14.350
we have good performance when reaching the cloud, and it has redundancy in the

242
16:14.350 --> 16:16.000
case of a failure.

243
16:16.000 --> 16:20.000
And of course, those two things being very closely related.

244
16:20.000 --> 16:25.680
Keep in mind that our redundancy can if configured properly also help with

245
16:25.680 --> 16:27.000
performance.

246
16:27.000 --> 16:32.220
So in the next video, let's spend a few minutes jumping into a few of these
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
16:27.000 --> 16:32.220
So in the next video, let's spend a few minutes jumping into a few of these

247
16:32.220 --> 16:35.000
topics in a little bit more detail.

248
16:35.000 --> 16:43.920
[BLANK_AUDIO]