1
00:00:00,000 --> 00:00:00,629

2
00:00:00,629 --> 00:00:02,170
DAVID MALAN: Okay, velkommen tilbage.

3
00:00:02,170 --> 00:00:06,520
Før vi dykker ned i cloud computing,
Jeg troede, jeg ville holde pause et øjeblik

4
00:00:06,520 --> 00:00:11,740
hvis der er nogen udestående spørgsmål
eller emner, der kom op under frokost

5
00:00:11,740 --> 00:00:13,834
der kan nu være af interesse.

6
00:00:13,834 --> 00:00:18,470

7
00:00:18,470 --> 00:00:21,410
>> PUBLIKUM: [uhørligt]

8
00:00:21,410 --> 00:00:22,090
>> DAVID MALAN: OK.

9
00:00:22,090 --> 00:00:23,555
Åh, OK.

10
00:00:23,555 --> 00:00:24,430
PUBLIKUM: [uhørligt]

11
00:00:24,430 --> 00:00:29,880

12
00:00:29,880 --> 00:00:31,420
>> DAVID MALAN: Nej, selvfølgelig.

13
00:00:31,420 --> 00:00:35,180
OK, godt forhåbentlig alle dine
opstå problemer i de næste par timer

14
00:00:35,180 --> 00:00:36,410
og i morgen især.

15
00:00:36,410 --> 00:00:42,700
Men lad os tage et kig, så ved hvor
den sidste diskussion om opsætning

16
00:00:42,700 --> 00:00:45,730
en hjemmeside fører mere generelt
når det kommer til cloud computing,

17
00:00:45,730 --> 00:00:48,210
opsætning af en server-arkitektur,
den slags beslutninger

18
00:00:48,210 --> 00:00:50,800
at ingeniører og
udviklere og ledere

19
00:00:50,800 --> 00:00:53,210
nødt til at gøre, når det kommer
til at gøre mere end blot

20
00:00:53,210 --> 00:00:56,550
tilmelding til en $ 10 per måned webhost
når du rent faktisk ønsker at bygge ud

21
00:00:56,550 --> 00:00:57,550
din egen infrastruktur.

22
00:00:57,550 --> 00:01:00,400
Og vi vil prøve at binde dette tilbage,
for eksempel til Dropbox m.fl.

23
00:01:00,400 --> 00:01:01,350
Ligesom dem.

24
00:01:01,350 --> 00:01:06,250
>> Så lad os begynde at overveje
hvilke problemer opstår som forretning

25
00:01:06,250 --> 00:01:09,390
får god og der opstår gode problemer.

26
00:01:09,390 --> 00:01:14,720
Det i meget enkle tilfælde af at have
lidt selskab, der har en web-server,

27
00:01:14,720 --> 00:01:21,470
du måtte have, lad os sige, en server,
vi bare tegne, der ligner dette.

28
00:01:21,470 --> 00:01:25,620
Og i disse dage, mest servers-- og lad os se
faktisk sætte et billede til dette bare så

29
00:01:25,620 --> 00:01:27,680
at det er en lidt mindre tågede.

30
00:01:27,680 --> 00:01:31,510
>> Så Dell rack server--
tilbage i dag, der

31
00:01:31,510 --> 00:01:33,730
var mainframe computere
der indtog hele rum.

32
00:01:33,730 --> 00:01:35,710
Disse dage, hvis du var
at få en server, det

33
00:01:35,710 --> 00:01:38,520
ser måske lidt noget som dette.

34
00:01:38,520 --> 00:01:41,760
Servere måles i hvad
kaldes rack enheder eller jernbanevirksomhederne.

35
00:01:41,760 --> 00:01:45,280
Og en jernbanevirksomhed er 1,5 inches,
som er en industristandard.

36
00:01:45,280 --> 00:01:49,300
Så det ligner en to RUC-server.

37
00:01:49,300 --> 00:01:51,240
Så det er 3 inches høj.

38
00:01:51,240 --> 00:01:54,430
Og de er generelt 19 inches lang,
hvilket betyder alt dette slags ting

39
00:01:54,430 --> 00:01:55,160
er standardiseret.

40
00:01:55,160 --> 00:01:59,420
>> Så hvis du kigger i et data center--
ikke bare på én server, men lad os

41
00:01:59,420 --> 00:02:02,110
tage et kig på Googles
datacenter og se, om vi

42
00:02:02,110 --> 00:02:04,280
se et flot billede i Google Billeder.

43
00:02:04,280 --> 00:02:09,090
Dette er meget bedre belyst end du
ville typisk finde, og meget

44
00:02:09,090 --> 00:02:14,900
sexier leder som følge heraf. Men
dette er, hvad der ligner et par

45
00:02:14,900 --> 00:02:17,380
hundrede servere
om det samme størrelse,

46
00:02:17,380 --> 00:02:21,450
faktisk, i rack efter rack efter
rack efter rack i et datacenter.

47
00:02:21,450 --> 00:02:26,150
>> Noget som denne-- dette kan meget vel
være Googles, da jeg googled Googles.

48
00:02:26,150 --> 00:02:28,330
Men det kunne være repræsentativ
mere generelt

49
00:02:28,330 --> 00:02:31,480
et datacenter, hvor mange
virksomheder typisk co-placeret.

50
00:02:31,480 --> 00:02:34,940
Og co-beliggende betyder generelt
at du går til et sted som Equinix

51
00:02:34,940 --> 00:02:40,280
eller andre leverandører, der har store
pakhuse, der har masser af magt,

52
00:02:40,280 --> 00:02:42,950
masser af køling, forhåbentlig
masser af sikkerhed,

53
00:02:42,950 --> 00:02:47,910
og individuelle bure omslutter racks af
servere, og du enten leje stativerne

54
00:02:47,910 --> 00:02:49,150
eller du bringer stativerne i.

55
00:02:49,150 --> 00:02:51,420
>> Og enkelte virksomheder,
nystartede især,

56
00:02:51,420 --> 00:02:54,820
vil have en vis form for biometri
at komme ind i deres bur, eller en nøgle,

57
00:02:54,820 --> 00:02:55,640
eller et nøglekort.

58
00:02:55,640 --> 00:02:56,990
Du åbner døren.

59
00:02:56,990 --> 00:03:00,354
Og inderside i der er blot
en firkantet optagelser fodaftryk

60
00:03:00,354 --> 00:03:03,270
at du betaler for, inde i
som du kan sætte noget, du ønsker.

61
00:03:03,270 --> 00:03:04,770
>> Og du typisk betaler for strømmen.

62
00:03:04,770 --> 00:03:06,920
Og du betaler for fodspor.

63
00:03:06,920 --> 00:03:08,770
Og så skal du betale
dig selv for serverne

64
00:03:08,770 --> 00:03:10,560
at du bringer ind i dette rum.

65
00:03:10,560 --> 00:03:12,850
Og hvad du så har den
mulighed for at gøre, er at betale nogen

66
00:03:12,850 --> 00:03:15,120
for din internetudbyder forbindelse.

67
00:03:15,120 --> 00:03:17,240
Du kan betale et vilkårligt antal
leverandører, som alle

68
00:03:17,240 --> 00:03:19,210
typisk kommer ind i denne datacenter.

69
00:03:19,210 --> 00:03:22,740
>> Men den virkelige interessante spørgsmål er,
hvad der faktisk går i disse stativer?

70
00:03:22,740 --> 00:03:25,020
De kan altså meget godt
ligne det, vi lige har set.

71
00:03:25,020 --> 00:03:27,870
Men de udfører forskellige funktioner
og måske nødt til at gøre forskellige ting.

72
00:03:27,870 --> 00:03:29,661
Og lad os faktisk
motivere denne diskussion

73
00:03:29,661 --> 00:03:35,370
med spørgsmålet om, hvad problemet
begynder at opstå, hvis du er en succes?

74
00:03:35,370 --> 00:03:37,900
>> Så du har fået en hjemmeside
at du har bygget.

75
00:03:37,900 --> 00:03:40,450
Og måske er det sælger widgets
eller sådan noget.

76
00:03:40,450 --> 00:03:43,620
Og du har gjort meget godt
med salg af widgets online.

77
00:03:43,620 --> 00:03:48,490
Og du begynder at opleve
nogle symptomer, din hjemmeside.

78
00:03:48,490 --> 00:03:51,070
Hvad der kunne være nogle af
de tekniske symptomer

79
00:03:51,070 --> 00:03:54,040
at brugere rapporterer som business
vokser og blomstrer

80
00:03:54,040 --> 00:03:59,482
og din hjemmeside er
nyder godt af det?

81
00:03:59,482 --> 00:04:02,690
>> PUBLIKUM: [uhørligt]

82
00:04:02,690 --> 00:04:05,910

83
00:04:05,910 --> 00:04:07,050
>> DAVID MALAN: Ja, præcis.

84
00:04:07,050 --> 00:04:10,040
Så du måske har en
afmatning af din hjemmeside.

85
00:04:10,040 --> 00:04:11,240
Og hvorfor kan det ske?

86
00:04:11,240 --> 00:04:12,660
Tja, hvis vi antager, for
af hensyn til diskussion

87
00:04:12,660 --> 00:04:15,160
lige nu, at du er på en
af disse kommercielle værter

88
00:04:15,160 --> 00:04:17,860
som vi talte om før frokost,
at du betale nogle flere dollars

89
00:04:17,860 --> 00:04:20,859
til per måned, og du har allerede betalt
for de årlige udgifter til dit domæne

90
00:04:20,859 --> 00:04:25,300
nævne, at web-vært er sandsynligvis
overselling deres ressourcer

91
00:04:25,300 --> 00:04:26,050
til en vis grad.

92
00:04:26,050 --> 00:04:29,000
Så du kan have et brugernavn
og adgangskode på deres server.

93
00:04:29,000 --> 00:04:32,410
Men så måske flere andre, eller flere
dusin andre, eller måske endda flere

94
00:04:32,410 --> 00:04:33,980
hundrede andre, brugere.

95
00:04:33,980 --> 00:04:37,190
>> Og hjemmesider lever fysisk
på samme server.

96
00:04:37,190 --> 00:04:38,340
Hvorfor er dette muligt?

97
00:04:38,340 --> 00:04:40,680
Well disse dage, servere
som dette typisk

98
00:04:40,680 --> 00:04:44,610
har flere harddiske, måske
så mange som seks eller flere harddiske,

99
00:04:44,610 --> 00:04:47,665
der hver især kan være så meget
som 4 terabyte disse dage.

100
00:04:47,665 --> 00:04:52,140
Så du kan have 24 terabytes af plads
på blot en lille server som denne.

101
00:04:52,140 --> 00:04:55,710
>> Og selv hvis du stjæler nogle af rummet
for redundans, som sikkerhedskopi,

102
00:04:55,710 --> 00:04:57,110
det er stadig en hel del plads.

103
00:04:57,110 --> 00:05:00,070
Og helt sikkert, en typisk hjemmeside
behøver ikke så meget plads.

104
00:05:00,070 --> 00:05:03,100
Bare registrere brugere
og lagring af logfiler over ordrer

105
00:05:03,100 --> 00:05:04,640
tager ikke så meget plads.

106
00:05:04,640 --> 00:05:07,550
Så du kan partitionere det helt
lidt og give hver bruger

107
00:05:07,550 --> 00:05:08,980
bare en lille bid af det.

108
00:05:08,980 --> 00:05:11,310
>> I mellemtiden har en computer
som dette disse dage

109
00:05:11,310 --> 00:05:16,370
typisk har flere CPUs-- ikke blot
en, måske to, måske fire, måske 16,

110
00:05:16,370 --> 00:05:17,149
eller endnu mere.

111
00:05:17,149 --> 00:05:18,940
Og hver af disse CPU'er
har noget, der hedder

112
00:05:18,940 --> 00:05:22,230
en kerne, som er lidt ligesom
en hjerne inde i en hjerne.

113
00:05:22,230 --> 00:05:26,800
Så i virkeligheden de fleste alle her med
moderne laptops har sandsynligvis en dual core

114
00:05:26,800 --> 00:05:32,030
eller quad core CPU-- og sandsynligvis kun
en CPU inde i en bærbar computer i disse dage.

115
00:05:32,030 --> 00:05:35,030
Men stationære computere
og rack-computere som

116
00:05:35,030 --> 00:05:39,000
dette kan have en hel
flere CPU'er, og til gengæld kerner.

117
00:05:39,000 --> 00:05:44,180
>> Og helt ærligt, selv i vores Mac'er og pc'er i
i dag, behøver du ikke virkelig har brug for dual kerner

118
00:05:44,180 --> 00:05:46,550
eller quad kerner til at tjekke din e-mail.

119
00:05:46,550 --> 00:05:49,090
Hvis der er nogen flaskehals, når
det kommer til at bruge en computer,

120
00:05:49,090 --> 00:05:51,925
du mennesket er formentlig den
langsomste ting om den pågældende computer.

121
00:05:51,925 --> 00:05:54,800
Og du kommer ikke til at være i stand til
tjekke din e-mail hurtigere, hvis du

122
00:05:54,800 --> 00:05:57,170
har fire gange så mange CPU'er eller kerner.

123
00:05:57,170 --> 00:05:59,700
>> Men det samme er slags
sand af en server.

124
00:05:59,700 --> 00:06:02,970
En enkelt hjemmeside måske ikke
nødvendigvis brug for mere end én

125
00:06:02,970 --> 00:06:05,756
CPU eller en kerne, en
lille hjerne inde gøre

126
00:06:05,756 --> 00:06:07,380
alle af tænkning og behandling.

127
00:06:07,380 --> 00:06:10,561
Så producenter har tilsvarende
begyndte at skære op disse ressourcer

128
00:06:10,561 --> 00:06:13,435
så måske din hjemmeside får en
kerne, din hjemmeside får en kerne,

129
00:06:13,435 --> 00:06:15,290
eller måske vi deler en sådan kerne.

130
00:06:15,290 --> 00:06:16,820
Vi er også deler diskplads.

131
00:06:16,820 --> 00:06:20,000
Og vi også deler RAM,
eller Random Access Memory

132
00:06:20,000 --> 00:06:22,520
fra før, hvoraf
der er også en endelig mængde.

133
00:06:22,520 --> 00:06:23,420
>> Og det er nøglen.

134
00:06:23,420 --> 00:06:25,960
Ligegyldigt hvor dyrt
computeren var,

135
00:06:25,960 --> 00:06:28,440
der er stadig et endeligt
mængde ressourcer i det.

136
00:06:28,440 --> 00:06:31,360
Og så mere og mere du
forsøge at forbruge disse ressourcer,

137
00:06:31,360 --> 00:06:32,850
de langsommere ting kan blive.

138
00:06:32,850 --> 00:06:34,646
Men hvorfor?

139
00:06:34,646 --> 00:06:39,352
Hvorfor skulle tingene langsomt ned som en
symptom på en server bliver overbelastet?

140
00:06:39,352 --> 00:06:40,060
Hvad sker der?

141
00:06:40,060 --> 00:06:42,895

142
00:06:42,895 --> 00:06:46,388
>> PUBLIKUM: [uhørligt]

143
00:06:46,388 --> 00:06:54,036

144
00:06:54,036 --> 00:06:55,160
DAVID MALAN: Ja, præcis.

145
00:06:55,160 --> 00:06:57,730
Jeg foreslog tidligere, at
RAM er en type hukommelse.

146
00:06:57,730 --> 00:07:00,290
Det er flygtige, hvorved det er
hvor apps og data er

147
00:07:00,290 --> 00:07:01,890
lagres, når de bliver brugt.

148
00:07:01,890 --> 00:07:03,990
Og så derfor er der
kun et endeligt antal

149
00:07:03,990 --> 00:07:05,790
af ting, du kan tilsyneladende gøre på en gang.

150
00:07:05,790 --> 00:07:07,740
Og det er også hurtigere,
hvilket er en god ting.

151
00:07:07,740 --> 00:07:09,990
Men det er også dyrere,
hvilket er en dårlig ting.

152
00:07:09,990 --> 00:07:15,376
Og det er også derfor til stede i lavere
mængder end diskplads, harddisk

153
00:07:15,376 --> 00:07:16,750
rum, som har tendens til at være billigere.

154
00:07:16,750 --> 00:07:18,830
>> Med andre ord, du
kan have 4 terabytes

155
00:07:18,830 --> 00:07:20,440
diskplads på din computer.

156
00:07:20,440 --> 00:07:24,300
Men du har måske 4
gigabyte, eller 64 gigabyte,

157
00:07:24,300 --> 00:07:29,180
i størrelsesorden, en faktor
1000 mindre, RAM i din computer.

158
00:07:29,180 --> 00:07:30,320
Så hvad gør en computer gøre?

159
00:07:30,320 --> 00:07:32,236
Nå, antage, at du
har 64 gigabyte

160
00:07:32,236 --> 00:07:35,110
RAM i en server som denne, som
ville være ganske almindeligt, hvis ikke lav

161
00:07:35,110 --> 00:07:36,140
disse dage.

162
00:07:36,140 --> 00:07:39,220
Men formoder du har så mange
brugere gør så mange ting

163
00:07:39,220 --> 00:07:42,480
at du slags slags
brug 65 gigabyte hukommelse

164
00:07:42,480 --> 00:07:44,960
at håndtere alt dette
samtidig brug?

165
00:07:44,960 --> 00:07:47,580
>> Nå, du kunne bare sige,
undskyld, nogle antallet af brugere

166
00:07:47,580 --> 00:07:48,840
kan bare ikke få adgang til webstedet.

167
00:07:48,840 --> 00:07:51,410
Og det er foranstaltningen
sidste udvej, helt sikkert.

168
00:07:51,410 --> 00:07:55,570
Eller du som operativsystemet
systemet, ligesom Windows eller Mac

169
00:07:55,570 --> 00:07:59,480
OS eller Linux eller Solaris eller noget
række andre OSE'er på den pågældende server,

170
00:07:59,480 --> 00:08:01,280
kunne bare beslutte, ved du hvad?

171
00:08:01,280 --> 00:08:03,780
Jeg har kun 64 gigabyte RAM.

172
00:08:03,780 --> 00:08:05,440
Jeg slags brug 65.

173
00:08:05,440 --> 00:08:06,210
Så ved du hvad?

174
00:08:06,210 --> 00:08:10,030
Jeg har tænkt mig at tage en gigabyte
værd af dataene i RAM

175
00:08:10,030 --> 00:08:15,240
der var mindst nylig adgang
og bare flytte det til disken midlertidigt,

176
00:08:15,240 --> 00:08:19,050
bogstaveligt kopiere det fra den hurtige
hukommelse til den langsommere hukommelse

177
00:08:19,050 --> 00:08:24,000
så jeg så kan klare at
65. gigabyte behov for hukommelse,

178
00:08:24,000 --> 00:08:25,650
gøre nogle beregninger på det.

179
00:08:25,650 --> 00:08:28,580
Så når jeg er færdig at gøre det,
Jeg vil bare flytte det til disk,

180
00:08:28,580 --> 00:08:35,030
flytte den anden RAM jeg midlertidigt sætte
på disken tilbage ind i selve hardwaren

181
00:08:35,030 --> 00:08:37,280
så jeg er lidt multitasking.

182
00:08:37,280 --> 00:08:41,190
>> Så jeg slags sætte ting
midlertidigt i dette langsommere rum

183
00:08:41,190 --> 00:08:44,159
så jeg skabe illusionen
håndtere alle.

184
00:08:44,159 --> 00:08:45,290
Men der er en afmatning.

185
00:08:45,290 --> 00:08:45,790
Hvorfor?

186
00:08:45,790 --> 00:08:49,380
Nå, inde i disse hårde
diske i disse dage er hvad?

187
00:08:49,380 --> 00:08:52,030
Snarere, hvad der gør en hård
kørsel forskellig fra RAM

188
00:08:52,030 --> 00:08:53,495
så godt du ved nu?

189
00:08:53,495 --> 00:08:56,750
>> PUBLIKUM: [uhørligt]

190
00:08:56,750 --> 00:08:59,540

191
00:08:59,540 --> 00:09:01,445
>> DAVID MALAN: OK, sandt.

192
00:09:01,445 --> 00:09:02,320
PUBLIKUM: [uhørligt]

193
00:09:02,320 --> 00:09:05,440

194
00:09:05,440 --> 00:09:06,750
>> DAVID MALAN: Så meget sandt.

195
00:09:06,750 --> 00:09:13,709
Og det er en bivirkning eller funktion
af det faktum, at RAM er faktisk hurtigere.

196
00:09:13,709 --> 00:09:15,750
Og derfor, du ønsker at
bruge det til nuværende brug.

197
00:09:15,750 --> 00:09:17,290
Og en disk er langsommere.

198
00:09:17,290 --> 00:09:19,630
Men det er permanent, eller flygtig.

199
00:09:19,630 --> 00:09:21,480
Så du bruger det til langtidsopbevaring.

200
00:09:21,480 --> 00:09:25,160
Men i form af
implementering, hvis jeg ser op

201
00:09:25,160 --> 00:09:29,297
hvad der kaldes en DIMM, Dual Inline Memory
Modul, dette er hvad et stykke af RAM

202
00:09:29,297 --> 00:09:30,380
typisk kan se ud.

203
00:09:30,380 --> 00:09:35,050
>> Så inde i vores Mac-- der er en fejl.

204
00:09:35,050 --> 00:09:41,080
Inde i vores Mac'er og pc'er, vores desktop
computere ville have pinde af hukommelse,

205
00:09:41,080 --> 00:09:43,220
som du ville kalde dem,
eller DIMM eller SIMM tilbage

206
00:09:43,220 --> 00:09:44,970
på dagen, hukommelse
at se sådan ud.

207
00:09:44,970 --> 00:09:47,900
Vores bærbare computere sandsynligvis have ting, som
er en tredje størrelse eller halv størrelse.

208
00:09:47,900 --> 00:09:50,066
De er lidt mindre,
men den samme idea-- lille

209
00:09:50,066 --> 00:09:52,110
stykker af grønne silicium
wafer eller plast,

210
00:09:52,110 --> 00:09:56,237
har små sorte chips på dem med masser
tråde forbinder alt.

211
00:09:56,237 --> 00:09:58,820
Du har måske en hel masse
disse indersiden af ​​din computer.

212
00:09:58,820 --> 00:10:00,903
Men takeaway her er
det er helt elektronisk.

213
00:10:00,903 --> 00:10:03,130
Der er bare elektroner
flyder på denne enhed.

214
00:10:03,130 --> 00:10:08,170
Derimod hvis vi ser på
indersiden af ​​en harddisk

215
00:10:08,170 --> 00:10:10,760
og træk et billede
her, ville du i stedet

216
00:10:10,760 --> 00:10:16,600
se noget som dette,
som ikke har elektricitet

217
00:10:16,600 --> 00:10:17,950
gå igennem det i sidste ende.

218
00:10:17,950 --> 00:10:20,265
Men hvad også springer ud
på dig om denne ting?

219
00:10:20,265 --> 00:10:21,140
PUBLIKUM: [uhørligt]

220
00:10:21,140 --> 00:10:22,710
DAVID MALAN: Ja, der er
tilsyneladende bevægelige dele.

221
00:10:22,710 --> 00:10:25,210
Det er lidt ligesom en gammel rekord
afspiller eller phonograph afspiller.

222
00:10:25,210 --> 00:10:26,200
Og det temmelig meget er.

223
00:10:26,200 --> 00:10:28,950
Det er lidt mere avanceret end at--
mens en grammofon afspiller brugt

224
00:10:28,950 --> 00:10:33,150
riller i posten, dette faktisk
bruger bittesmå magnetiske partikler

225
00:10:33,150 --> 00:10:34,550
at vi kan ikke helt se.

226
00:10:34,550 --> 00:10:38,520
Men hvis lidt magnetisk partikel
ser sådan ud, er det betragtes som en 1.

227
00:10:38,520 --> 00:10:41,230
Og hvis det ser sådan ud,
nord-syd i stedet for syd-nord,

228
00:10:41,230 --> 00:10:42,252
det kunne være en 0.

229
00:10:42,252 --> 00:10:45,460
Og vi vil se i morgen, hvordan vi kan bygge
fra den for et mere interessante ting.

230
00:10:45,460 --> 00:10:47,590
>> Men noget, der er
fik til fysisk at bevæge

231
00:10:47,590 --> 00:10:51,010
er helt sikkert kommer til at gå langsommere
end lysets hastighed,

232
00:10:51,010 --> 00:10:53,250
som i teorien er, hvad
en elektron kan flyde ved,

233
00:10:53,250 --> 00:10:54,620
dog realistisk ikke helt.

234
00:10:54,620 --> 00:10:56,900
Så mekanisk enheder: meget langsommere.

235
00:10:56,900 --> 00:10:58,320
Men de er billigere.

236
00:10:58,320 --> 00:11:00,944
Og du kan passe så meget
flere data inde i dem.

237
00:11:00,944 --> 00:11:03,110
Så det faktum, at der
findes i verden noget

238
00:11:03,110 --> 00:11:06,840
kaldes virtuel hukommelse,
anvendelse af en harddisk som denne

239
00:11:06,840 --> 00:11:10,160
som om det var RAM
transparent for brugeren,

240
00:11:10,160 --> 00:11:15,320
blot ved flytning af data
fra RAM til harddisken,

241
00:11:15,320 --> 00:11:18,714
derefter flytte den tilbage, når du har brug for
det igen, skaber afmatning.

242
00:11:18,714 --> 00:11:21,380
Fordi du bogstaveligt talt nødt til at
kopiere den fra et sted til et andet.

243
00:11:21,380 --> 00:11:25,100
Og de ting du kopierer det til og
fra er faktisk langsommere end RAM

244
00:11:25,100 --> 00:11:26,150
hvor du ønsker det skal være.

245
00:11:26,150 --> 00:11:29,030
>> Den alternative løsning her--
Hvis du ikke kan lide at bremse,

246
00:11:29,030 --> 00:11:32,014
og din virtuelle hukommelse er
slags blive henledt,

247
00:11:32,014 --> 00:11:33,680
hvad er en anden løsning på dette problem?

248
00:11:33,680 --> 00:11:35,260
>> PUBLIKUM: [uhørligt]

249
00:11:35,260 --> 00:11:37,260
DAVID MALAN: Nå,
forøge den virtuelle hukommelse

250
00:11:37,260 --> 00:11:39,135
ville lade os gøre dette på
en endnu større målestok.

251
00:11:39,135 --> 00:11:43,540
Vi kunne håndtere 66 gigabyte værd
af hukommelse behov, eller 67 gigabyte.

252
00:11:43,540 --> 00:11:45,830
Men formoder jeg kan ikke lide
denne langsomme ned, i virkeligheden

253
00:11:45,830 --> 00:11:49,380
Jeg vil slå virtuelle
hukommelse, hvis det er endda muligt,

254
00:11:49,380 --> 00:11:52,350
hvad der ellers kunne jeg kaste på
dette problem at løse det,

255
00:11:52,350 --> 00:11:56,900
hvor jeg vil håndtere flere brugere
og flere hukommelse krav

256
00:11:56,900 --> 00:11:59,100
end jeg fysisk har i øjeblikket?

257
00:11:59,100 --> 00:12:02,600
>> PUBLIKUM: [uhørligt]

258
00:12:02,600 --> 00:12:04,800

259
00:12:04,800 --> 00:12:06,140
>> DAVID MALAN: Desværre nej.

260
00:12:06,140 --> 00:12:09,850
Så CPU'en og kernerne de er
i er en begrænset ressource.

261
00:12:09,850 --> 00:12:13,280
Og der er ingen analog i denne sammenhæng.

262
00:12:13,280 --> 00:12:14,990
Godt spørgsmål, selv om.

263
00:12:14,990 --> 00:12:19,270
Så bare for at være klar, også hvis
indersiden af ​​denne computer er,

264
00:12:19,270 --> 00:12:24,510
lad os sige, en pind af RAM, der ser
ligesom denne-- og så vi vil kalde denne RAM.

265
00:12:24,510 --> 00:12:27,070
Og herovre er harddisken.

266
00:12:27,070 --> 00:12:30,130
Og jeg vil bare trække dette
billedligt som en lille cirkel.

267
00:12:30,130 --> 00:12:33,740
Der er 0 og 1'er i begge
these-- data, vil vi generalisere det som.

268
00:12:33,740 --> 00:12:38,030
>> Og i det væsentlige, at en bruger er
kører et program som,

269
00:12:38,030 --> 00:12:46,070
lad os sige, en hjemmeside, der kræver dette
meget RAM per bruger, hvad jeg foreslår,

270
00:12:46,070 --> 00:12:48,380
ved hjælp af denne ting
kaldes virtuel hukommelse,

271
00:12:48,380 --> 00:12:53,990
er bare midlertidigt flytte
at over her, så nu er jeg

272
00:12:53,990 --> 00:12:57,810
kan flytte en andens hukommelse
krav derovre.

273
00:12:57,810 --> 00:13:00,420
Og så når det er gjort,
Jeg kan kopiere denne tilbage over

274
00:13:00,420 --> 00:13:04,550
og dette gælder her, bevæger derved
hvad jeg ønskede derinde et andet sted

275
00:13:04,550 --> 00:13:05,050
helt.

276
00:13:05,050 --> 00:13:07,820
>> Så der er bare en masse
switcheroo, er takeaway her.

277
00:13:07,820 --> 00:13:12,380
Så hvis du ikke kan lide det, og du ikke
ønsker at sætte noget på harddisken,

278
00:13:12,380 --> 00:13:16,440
hvad er lidt den indlysende
business persons løsning

279
00:13:16,440 --> 00:13:19,684
på problemet, eller ingeniørens
løsning, for den sags skyld også?

280
00:13:19,684 --> 00:13:21,950
>> PUBLIKUM: [uhørligt]

281
00:13:21,950 --> 00:13:24,750
>> DAVID MALAN: Ja, jeg mener bogstaveligt
smide penge efter problemet.

282
00:13:24,750 --> 00:13:27,541
Og faktisk, det er den perfekte
segue til nogle af de højere niveau

283
00:13:27,541 --> 00:13:28,870
diskussioner af cloud computing.

284
00:13:28,870 --> 00:13:31,390
Fordi en masse af det er motiveret
af finansielle beslutninger,

285
00:13:31,390 --> 00:13:33,040
ikke engang nødvendigvis teknologiske.

286
00:13:33,040 --> 00:13:37,830
Hvis 64 gigs RAM er for lidt, ja,
hvorfor ikke få 128 gigabyte RAM?

287
00:13:37,830 --> 00:13:40,440
Hvorfor ikke få 256 gigabyte RAM?

288
00:13:40,440 --> 00:13:41,732
Tja, hvorfor ikke?

289
00:13:41,732 --> 00:13:42,608
>> PUBLIKUM: [uhørligt]

290
00:13:42,608 --> 00:13:44,482
DAVID MALAN: Tja, det
koster flere penge, sikker.

291
00:13:44,482 --> 00:13:46,970
Og hvis du allerede har reservedele
harddiskplads, effektivt,

292
00:13:46,970 --> 00:13:51,407
eller ækvivalent, harddiskplads er så
meget billigere du kan lige så godt bruge det.

293
00:13:51,407 --> 00:13:54,490
Så igen, der er denne handel det
vi så endnu tidligere denne morgen,

294
00:13:54,490 --> 00:13:56,656
hvor der er virkelig ikke
nødvendigvis en rigtige svar,

295
00:13:56,656 --> 00:14:01,360
der er bare en bedre eller dårligere svar
baseret på, hvad du rent faktisk bekymrer sig om.

296
00:14:01,360 --> 00:14:04,500
>> Så der er også teknologiske realiteter.

297
00:14:04,500 --> 00:14:06,870
Jeg kan ikke købe en computer,
til min viden,

298
00:14:06,870 --> 00:14:09,490
med en billion gigabyte
RAM lige nu.

299
00:14:09,490 --> 00:14:11,540
Det bare fysisk findes ikke.

300
00:14:11,540 --> 00:14:13,240
Så der er nogle øvre grænse.

301
00:14:13,240 --> 00:14:15,990
Men hvis du nogensinde har endda handlet
for en forbruger Mac eller pc,

302
00:14:15,990 --> 00:14:20,180
også, generelt er der
denne kurve funktioner

303
00:14:20,180 --> 00:14:23,410
hvor der kan være en god,
en bedre, og en bedste computer.

304
00:14:23,410 --> 00:14:25,730
>> Og de marginale afkast
på din dollar køb

305
00:14:25,730 --> 00:14:30,227
den bedste computer versus
bedre computer

306
00:14:30,227 --> 00:14:32,560
måske ikke nær så høj
som at bruge lidt flere penge

307
00:14:32,560 --> 00:14:35,599
og få det bedre computer
over god computer.

308
00:14:35,599 --> 00:14:38,390
Med andre ord, du betaler en
præmie for at få toppen af ​​linjen.

309
00:14:38,390 --> 00:14:40,790
>> Og hvad vi vil se i
diskussion af cloud computing

310
00:14:40,790 --> 00:14:44,940
er, at hvad der er meget almindeligt disse
dage, og hvilke virksomheder som Google

311
00:14:44,940 --> 00:14:50,560
tidligt populariseret, var ikke betaler
for og bygning virkelig fancy, dyrt

312
00:14:50,560 --> 00:14:53,540
souped op computere med
masser og masser af alt,

313
00:14:53,540 --> 00:15:00,140
men snarere at købe eller bygge temmelig
beskedne computere men masser af dem,

314
00:15:00,140 --> 00:15:03,280
og bruge noget, der er generelt
kaldet horisontal skalering i stedet

315
00:15:03,280 --> 00:15:04,320
af lodret skalering.

316
00:15:04,320 --> 00:15:08,115
>> Så lodret skalering ville betyde få mere
RAM, mere disk, mere af det hele,

317
00:15:08,115 --> 00:15:10,187
og slags investere
lodret i din hardware

318
00:15:10,187 --> 00:15:12,520
så du bare at få det
bedste af det bedste af det bedste,

319
00:15:12,520 --> 00:15:13,650
men du betale for det.

320
00:15:13,650 --> 00:15:17,580
Vandret skalering slags få
nederste materialelag ting, den gode model,

321
00:15:17,580 --> 00:15:19,922
eller endog værre model,
men få masser af dem.

322
00:15:19,922 --> 00:15:22,630
Men så snart du får masser af
them-- for eksempel i dette tilfælde

323
00:15:22,630 --> 00:15:27,330
webservere, hvis denne server
eller en webside vært er utilstrækkelig,

324
00:15:27,330 --> 00:15:32,310
så bare intuitivt, den
løsning på dette problem med belastning

325
00:15:32,310 --> 00:15:36,460
eller overbelastning på dine servere
enten få en større server

326
00:15:36,460 --> 00:15:40,770
eller, hvad jeg foreslår her i stedet
af skalering vertikalt så at sige,

327
00:15:40,770 --> 00:15:41,920
ville være, ved du hvad?

328
00:15:41,920 --> 00:15:43,580
Bare få en anden en af ​​disse.

329
00:15:43,580 --> 00:15:46,560
Eller måske endda få en tredje.

330
00:15:46,560 --> 00:15:48,900
Men nu har vi skabt
en ingeniør problem

331
00:15:48,900 --> 00:15:51,920
i kraft af denne forretning
eller finansiel beslutning.

332
00:15:51,920 --> 00:15:54,312
Hvad er ingeniør problem nu?

333
00:15:54,312 --> 00:15:56,040
>> PUBLIKUM: [uhørligt]

334
00:15:56,040 --> 00:15:59,740
>> DAVID MALAN: Ja, hvordan gør
du forbinde dem og-- ked?

335
00:15:59,740 --> 00:16:00,651
>> PUBLIKUM: [uhørligt]

336
00:16:00,651 --> 00:16:02,400
DAVID MALAN: Right,
fordi jeg stadig have--

337
00:16:02,400 --> 00:16:07,280
hvis jeg genindføre mig ind i dette billede,
hvis dette er min laptop eller andet sted

338
00:16:07,280 --> 00:16:12,400
på internettet, som nu er mellem
mig og virksomheden, vi taler om,

339
00:16:12,400 --> 00:16:17,960
nu er jeg nødt til at finde ud af, at der
server sender jeg denne bruger?

340
00:16:17,960 --> 00:16:25,090
Og hvis der er andre brugere, ligesom
dette, og så er dette en herovre,

341
00:16:25,090 --> 00:16:28,850
og måske det er bruger A, dette
er bruger B, er dette bruger C,

342
00:16:28,850 --> 00:16:34,720
og dette er server 1, 2, og 3-- nu
en intuitiv svaret kunne her være lige,

343
00:16:34,720 --> 00:16:37,460
Vi sender bruger A til en
og B-2 og C til 3.

344
00:16:37,460 --> 00:16:39,900
Og vi kan håndtere 3 gange så mange brugere.

345
00:16:39,900 --> 00:16:41,360
>> Men det er en forsimpling.

346
00:16:41,360 --> 00:16:44,480
Hvordan afgør, hvem de skal sende hvor?

347
00:16:44,480 --> 00:16:46,400
Så lad os prøve at argumentere igennem dette.

348
00:16:46,400 --> 00:16:50,110
Så formoder, at computere
A, B, og C er kunder,

349
00:16:50,110 --> 00:16:53,972
og servere 1, 2, og 3 er
horisontalt skaleret servere.

350
00:16:53,972 --> 00:16:55,180
Så de er en slags identiske.

351
00:16:55,180 --> 00:16:57,200
De er alle kører den samme software.

352
00:16:57,200 --> 00:16:59,770
Og de kan alle gøre det samme.

353
00:16:59,770 --> 00:17:01,520
Men årsagen til at vi har
tre af dem er så

354
00:17:01,520 --> 00:17:04,710
at vi kan håndtere tre
gange så mange mennesker på én gang.

355
00:17:04,710 --> 00:17:07,960
>> Så vi ved fra vores
diskussion før frokost

356
00:17:07,960 --> 00:17:11,460
at der er hardware i mellem
de bærbare computere og servere.

357
00:17:11,460 --> 00:17:14,920
Men vi vil bare slags generalisere
at nu da internettet eller skyen.

358
00:17:14,920 --> 00:17:18,707
Men vi ved, at i mit hjem,
der er sikkert et hjem router.

359
00:17:18,707 --> 00:17:21,290
I nærheden af ​​serverne, er der sandsynligvis
en router, DNS-server, DHCP.

360
00:17:21,290 --> 00:17:24,780
Der kan være alt
Vi ønsker i denne historie.

361
00:17:24,780 --> 00:17:33,360
>> Så hvordan gør vi begynder at beslutte,
når bruger A går til something.com,

362
00:17:33,360 --> 00:17:36,630
hvilken server til at dirigere brugeren til?

363
00:17:36,630 --> 00:17:39,409
Hvordan kan vi begynde at fortælle denne historie?

364
00:17:39,409 --> 00:17:40,450
PUBLIKUM: Load balancing?

365
00:17:40,450 --> 00:17:41,120
DAVID MALAN: Load balancing.

366
00:17:41,120 --> 00:17:42,502
Hvad mener du med det?

367
00:17:42,502 --> 00:17:44,660
>> PUBLIKUM: Vender tilbage
hvor de mest brug er

368
00:17:44,660 --> 00:17:47,472
og som man har
de fleste tilgængelige ressourcer.

369
00:17:47,472 --> 00:17:49,930
DAVID MALAN: OK, så lad mig
indføre en ny type hardware

370
00:17:49,930 --> 00:17:53,627
at vi endnu ikke har diskuteret, hvilke
er netop det, en load balancer.

371
00:17:53,627 --> 00:17:54,960
Også dette kunne bare være en server.

372
00:17:54,960 --> 00:17:58,130
Det kunne se ud nøjagtig som
den, vi oplevede for et øjeblik siden.

373
00:17:58,130 --> 00:18:01,000
En load balancer er virkelig
blot et stykke software

374
00:18:01,000 --> 00:18:02,660
at du kører på et stykke hardware.

375
00:18:02,660 --> 00:18:07,310
>> Eller du kan betale en sælger, ligesom
Citrix eller andre, Cisco eller andre.

376
00:18:07,310 --> 00:18:10,465
Du kan betale for deres egen hardware,
der er en hardware load balancer.

377
00:18:10,465 --> 00:18:12,840
Men det betyder bare de
præ-installeret load balancing

378
00:18:12,840 --> 00:18:15,580
software på deres hardware og
solgte det til jer alle sammen.

379
00:18:15,580 --> 00:18:18,670
Så vi vil bare tegne den som en
rektangel til vores formål.

380
00:18:18,670 --> 00:18:22,040
>> Hvor nu implementerer jeg en load balancer?

381
00:18:22,040 --> 00:18:28,150
Med andre ord, når brugeren A ønsker at
besøge min hjemmeside, deres anmodning eller anden måde

382
00:18:28,150 --> 00:18:31,070
eller andet, sandsynligvis ved hjælp af de
routere, vi talte om tidligere,

383
00:18:31,070 --> 00:18:33,750
vil til sidst nå
denne load balancer, som derefter

384
00:18:33,750 --> 00:18:36,210
nødt til at en routing-lignende beslutning.

385
00:18:36,210 --> 00:18:38,320
Men det er routing for sortering
af et højere formål nu.

386
00:18:38,320 --> 00:18:40,361
Det handler ikke kun om at få
fra punkt A til punkt

387
00:18:40,361 --> 00:18:44,730
B. Det handler om at beslutte, hvilken
punkt B er den bedste blandt them--

388
00:18:44,730 --> 00:18:46,660
1, 2 eller 3 i dette tilfælde.

389
00:18:46,660 --> 00:18:51,000
>> Så hvordan kan jeg beslutte, om
at gå til 1, til 2, 3?

390
00:18:51,000 --> 00:18:55,180
Hvad kan denne sorte boks, så at
tale, gøre på indersiden?

391
00:18:55,180 --> 00:18:57,880
Også dette er et andet eksempel i
datalogi af abstraktion.

392
00:18:57,880 --> 00:19:02,410
Jeg har bogstaveligt talt trukket en load balancer
som en sort boks med sort blæk, inde

393
00:19:02,410 --> 00:19:05,300
hvoraf er nogle interessante
logik, eller magic selv,

394
00:19:05,300 --> 00:19:07,840
hvoraf nødt til at blive
en decision-- 1, 2 eller 3.

395
00:19:07,840 --> 00:19:12,220
Og indgangen er bare A.

396
00:19:12,220 --> 00:19:13,442
>> PUBLIKUM: [uhørligt]

397
00:19:13,442 --> 00:19:14,400
DAVID MALAN: Jeg er ked af?

398
00:19:14,400 --> 00:19:14,770
PUBLIKUM: [uhørligt]

399
00:19:14,770 --> 00:19:18,310
DAVID MALAN: Okay, hvordan kan vi
kategorisere de typer af transaktioner

400
00:19:18,310 --> 00:19:19,095
her?

401
00:19:19,095 --> 00:19:23,772
>> PUBLIKUM: Visning af en webside
versus forespørge en database.

402
00:19:23,772 --> 00:19:24,980
DAVID MALAN: OK, det er godt.

403
00:19:24,980 --> 00:19:29,210
Så måske denne bruger A
ønsker at se en webside.

404
00:19:29,210 --> 00:19:32,954
Og måske er det endda statisk indhold,
noget, der ændrer sjældent, om nogensinde.

405
00:19:32,954 --> 00:19:34,870
Og det virker som en
temmelig simpel operation.

406
00:19:34,870 --> 00:19:38,260
Så måske vil vi bare vilkårligt,
men rimeligt, siger,

407
00:19:38,260 --> 00:19:42,750
server 1, hans formål i livet er
at bare tjene op statisk indhold,

408
00:19:42,750 --> 00:19:45,150
filer, der sjældent, om nogensinde, forandring.

409
00:19:45,150 --> 00:19:46,870
Måske er det billederne på siden.

410
00:19:46,870 --> 00:19:50,180
Måske er det teksten på siden eller
anden sådan slags uinteressante ting,

411
00:19:50,180 --> 00:19:52,460
intet transaktionsbeslutning, intet dynamisk.

412
00:19:52,460 --> 00:19:57,000
>> Hvis derimod bruger A kontrollerer
ud af hans eller hendes indkøbskurv,

413
00:19:57,000 --> 00:20:00,972
kræver en database, til et sted at gemme
og husk, at transaktionen, godt

414
00:20:00,972 --> 00:20:02,680
måske denne anmodning
skal gå til server 2.

415
00:20:02,680 --> 00:20:03,610
Så det er godt.

416
00:20:03,610 --> 00:20:07,010
Så vi kan indlæse balance baseret
af typen af ​​anmodninger.

417
00:20:07,010 --> 00:20:08,278
Hvor ellers kan vi gøre dette?

418
00:20:08,278 --> 00:20:13,690

419
00:20:13,690 --> 00:20:14,686
Hvad other--

420
00:20:14,686 --> 00:20:17,382
>> PUBLIKUM: Baseret på serverens
udnyttelse og kapacitet.

421
00:20:17,382 --> 00:20:18,340
DAVID MALAN: Right, OK.

422
00:20:18,340 --> 00:20:19,950
Så du nævnte, at tidligere, Kareem.

423
00:20:19,950 --> 00:20:26,850
Så hvad nu hvis vi giver nogle input
på [uhørligt] blandt servere 1, 2,

424
00:20:26,850 --> 00:20:32,070
og 3 til dette load balancer, så
de er bare hele tiden at informere

425
00:20:32,070 --> 00:20:36,420
den load balancer, hvad deres status er?

426
00:20:36,420 --> 00:20:39,842
Ligesom, hey, load balancer,
Jeg er på 50% udnyttelse.

427
00:20:39,842 --> 00:20:41,550
Med andre ord, jeg har
halvt så mange brugere

428
00:20:41,550 --> 00:20:43,520
som jeg faktisk kan håndtere lige nu.

429
00:20:43,520 --> 00:20:45,480
Hey, load balancer, jeg er
ved 100% udnyttelse.

430
00:20:45,480 --> 00:20:47,929
Hey, load balancer, 0% udnyttelse.

431
00:20:47,929 --> 00:20:49,970
Den load balancer, hvis det er
konstrueret på en måde,

432
00:20:49,970 --> 00:20:53,990
kan tage i disse bemærkninger
som input, kan det så

433
00:20:53,990 --> 00:20:57,420
beslutte, ooh, nummer 2 er på 100%.

434
00:20:57,420 --> 00:21:01,440
Lad mig sende ingen fremtidige anmodninger til ham
bortset brugerne allerede er tilsluttet.

435
00:21:01,440 --> 00:21:02,360
Denne fyr er på 0%.

436
00:21:02,360 --> 00:21:03,940
Lad os sende en masse trafik til ham.

437
00:21:03,940 --> 00:21:05,480
Denne fyr sagde, at han er på 50%.

438
00:21:05,480 --> 00:21:08,080
Lad os sende nogle trafik til ham.

439
00:21:08,080 --> 00:21:12,012
>> Så det ville være en ingrediens, der
vi kunne tage belastningen i betragtning.

440
00:21:12,012 --> 00:21:13,470
Og det kommer til at ændre sig over tid.

441
00:21:13,470 --> 00:21:14,678
Så afgørelserne vil ændre sig.

442
00:21:14,678 --> 00:21:17,350
Så det er en rigtig god teknik,
en, der er almindeligt anvendt.

443
00:21:17,350 --> 00:21:18,410
Hvad andet kunne vi gøre?

444
00:21:18,410 --> 00:21:20,380
Og lad os faktisk bare opsummere her.

445
00:21:20,380 --> 00:21:29,510
Så de beslutninger her kunne være
efter type af trafik, vil jeg kalde det.

446
00:21:29,510 --> 00:21:32,220
Det kan være baseret på belastning.

447
00:21:32,220 --> 00:21:34,692
Lad os se, om vi ikke kan
komme med et par andre.

448
00:21:34,692 --> 00:21:35,934
>> PUBLIKUM: [uhørligt]

449
00:21:35,934 --> 00:21:36,850
DAVID MALAN: Location.

450
00:21:36,850 --> 00:21:37,724
Så det er en god en.

451
00:21:37,724 --> 00:21:40,880
Så Beliggende- hvordan du måske
udnytte disse oplysninger?

452
00:21:40,880 --> 00:21:44,317
>> PUBLIKUM: [uhørligt]

453
00:21:44,317 --> 00:21:54,140

454
00:21:54,140 --> 00:21:57,040
>> DAVID MALAN: Åh, det er godt.

455
00:21:57,040 --> 00:21:59,450
Og om hvor mange millisekunder
ville det falde med

456
00:21:59,450 --> 00:22:02,466
baseret på hvad vi så dette
morgen, ville du sige?

457
00:22:02,466 --> 00:22:04,330
>> PUBLIKUM: [uhørligt]

458
00:22:04,330 --> 00:22:06,550
>> DAVID MALAN: Nå, baseret
på spor- ruter

459
00:22:06,550 --> 00:22:09,070
vi så tidligere, som er lige
et groft mål for noget,

460
00:22:09,070 --> 00:22:11,800
mindst hvor lang tid det tager
for data for at komme fra A til B

461
00:22:11,800 --> 00:22:16,140
føles noget lokale var, hvad,
ligesom 74 millisekunder, give eller tage?

462
00:22:16,140 --> 00:22:19,200
Og så noget 100 plus,
200 plus var sandsynligvis i udlandet.

463
00:22:19,200 --> 00:22:22,110
Og så baseret på det alene,
synes det rimeligt at antage,

464
00:22:22,110 --> 00:22:25,310
at for en bruger i USA
at få adgang til et europæisk server

465
00:22:25,310 --> 00:22:28,900
kan tage to eller tre gange
så længe, ​​selv i millisekunder,

466
00:22:28,900 --> 00:22:31,280
end det kan tage, hvis det
server var placeret her

467
00:22:31,280 --> 00:22:33,370
geografisk, eller omvendt.

468
00:22:33,370 --> 00:22:35,120
Så når jeg foreslog
tidligere, at specielt

469
00:22:35,120 --> 00:22:37,880
når du krydser at 200 millisekunder
tærskel, give eller tage,

470
00:22:37,880 --> 00:22:39,210
mennesker gør begynder at lægge mærke.

471
00:22:39,210 --> 00:22:42,960
Og spor rute er lige
under forudsætning af rå, uinteressante data.

472
00:22:42,960 --> 00:22:46,570
Når du har en hjemmeside, skal du
få brugeren downloader billeder eller film

473
00:22:46,570 --> 00:22:49,150
filer, masser af tekst,
efterfølgende anmodninger.

474
00:22:49,150 --> 00:22:53,116
Vi så da vi besøgte, hvad der var
det, Facebook eller Amazon tidligere,

475
00:22:53,116 --> 00:22:55,490
der er en hel masse ting
der skal downloades.

476
00:22:55,490 --> 00:22:56,573
Så det kommer til at tilføje op.

477
00:22:56,573 --> 00:23:00,259
Så multi-sekunder måske
ikke være urimeligt.

478
00:23:00,259 --> 00:23:01,800
Så godt, geografi er én ingrediens.

479
00:23:01,800 --> 00:23:05,920
Så i virkeligheden virksomheder som
Akamai, hvis du har hørt om dem,

480
00:23:05,920 --> 00:23:10,000
eller andre har længe taget
geografi i betragtning.

481
00:23:10,000 --> 00:23:14,170
Og det viser sig, at i kraft af en
IP-adresse, min laptop IP-adresse,

482
00:23:14,170 --> 00:23:18,277
du kan udlede, med en vis sandsynlighed,
hvor du er i verden.

483
00:23:18,277 --> 00:23:20,110
Og i virkeligheden er der
tredjepartstjenester dig

484
00:23:20,110 --> 00:23:24,480
kan betale hvem vedligeholde databaser
af IP-adresser og geografiske områder

485
00:23:24,480 --> 00:23:28,660
at med høj tillid vil være
sandt, når spurgt, hvor i verden

486
00:23:28,660 --> 00:23:30,090
er denne IP-adresse?

487
00:23:30,090 --> 00:23:32,130
>> Og så i virkeligheden, hvad
andre virksomheder bruger dette?

488
00:23:32,130 --> 00:23:35,900
Hvis du har Hulu eller Netflix, hvis det
du nogensinde har været på rejse i udlandet,

489
00:23:35,900 --> 00:23:38,640
og du forsøger at se noget på
Hulu, og du er ikke i USA,

490
00:23:38,640 --> 00:23:41,280
du kan se en meddelelse
siger, ikke i USA.

491
00:23:41,280 --> 00:23:43,208
Beklager, du kan ikke se dette indhold.

492
00:23:43,208 --> 00:23:44,420
>> PUBLIKUM: [uhørligt]

493
00:23:44,420 --> 00:23:46,020
>> DAVID MALAN: Virkelig?

494
00:23:46,020 --> 00:23:48,480
Men ja, så faktisk det er
et perfekt program

495
00:23:48,480 --> 00:23:51,060
af noget meget teknisk
til et reelt problem.

496
00:23:51,060 --> 00:23:55,100
Hvis du skulle VPN fra
Europa eller Asien eller hvor som helst

497
00:23:55,100 --> 00:23:57,950
i verden til din virksomheds
hovedkvarter i New York

498
00:23:57,950 --> 00:24:00,670
eller hvor du er, er du
vil skabe udseendet

499
00:24:00,670 --> 00:24:03,580
til eksterne hjemmesider,
du er faktisk i New York,

500
00:24:03,580 --> 00:24:05,660
selvom du er
fysisk ganske langt væk.

501
00:24:05,660 --> 00:24:08,057
>> Nu er du brugeren kommer til at
ved, du er tydeligvis væk.

502
00:24:08,057 --> 00:24:11,140
Men du også kommer til at føle det, fordi
af disse yderligere millisekunder.

503
00:24:11,140 --> 00:24:14,510
Det ekstra afstand og
kryptering, der sker i VPN

504
00:24:14,510 --> 00:24:15,760
vil forsinke tingene.

505
00:24:15,760 --> 00:24:17,680
Så det kan eller ikke
være en stor oplevelse.

506
00:24:17,680 --> 00:24:21,050
Men Hulu og Netflix kommer til at se
du som sidder et eller andet sted i New York,

507
00:24:21,050 --> 00:24:23,817
som du tydeligt har forstået.

508
00:24:23,817 --> 00:24:25,150
Sikke en perfekt løsning på det.

509
00:24:25,150 --> 00:24:28,490
>> Okay, så geografi er en beslutning.

510
00:24:28,490 --> 00:24:32,290
Hvad kan vi bruge til at beslutte, hvordan
at dirigere trafik fra A, B og C

511
00:24:32,290 --> 00:24:37,040
til 1, 2, og 3, igen, at sætte
engineering hat på?

512
00:24:37,040 --> 00:24:38,850
Alt dette lyder meget kompliceret.

513
00:24:38,850 --> 00:24:41,490
Uh, jeg ved ikke engang, hvor
at begynde at implementere dem.

514
00:24:41,490 --> 00:24:44,450
Giv mig noget, der er enklere.

515
00:24:44,450 --> 00:24:48,160
Hvad er den nemmeste måde
at træffe denne beslutning?

516
00:24:48,160 --> 00:24:49,840
>> PUBLIKUM: Er serveren tilgængelig?

517
00:24:49,840 --> 00:24:51,650
>> DAVID MALAN: Er serveren tilgængelig?

518
00:24:51,650 --> 00:24:53,970
Så ikke dårligt.

519
00:24:53,970 --> 00:24:54,470
Det er godt.

520
00:24:54,470 --> 00:24:56,260
Det er en slags nuancering af belastning.

521
00:24:56,260 --> 00:24:58,070
Så lad os holde det i belastningen kategori.

522
00:24:58,070 --> 00:25:00,010
Hvis du er til rådighed, jeg er bare
kommer til at sende dataene der.

523
00:25:00,010 --> 00:25:01,343
Men det kan give bagslag hurtigt.

524
00:25:01,343 --> 00:25:05,720
For hvis jeg bruger den logik, og hvis jeg
altid spørge en, er du på, er du på,

525
00:25:05,720 --> 00:25:08,970
er du på, hvis svaret er altid ja,
Jeg har tænkt mig at sende 100% af trafikken

526
00:25:08,970 --> 00:25:11,060
til ham, 0% for alle andre.

527
00:25:11,060 --> 00:25:14,430
Og på et tidspunkt, vi kommer til at ramme
at afmatningen eller website utilgængelig.

528
00:25:14,430 --> 00:25:17,630
Så hvad er lidt bedre end
det, men stadig temmelig simpel

529
00:25:17,630 --> 00:25:22,412
og ikke nær så klog som at tage alle
disse yderligere oplysninger i betragtning?

530
00:25:22,412 --> 00:25:23,992
>> PUBLIKUM: Omkostninger per server.

531
00:25:23,992 --> 00:25:25,200
DAVID MALAN: Omkostninger per server.

532
00:25:25,200 --> 00:25:28,010
OK, så lad mig kaste, at
i belastningen kategori, også.

533
00:25:28,010 --> 00:25:30,790
For hvad du finder i
et selskab, too-- at hvis du

534
00:25:30,790 --> 00:25:32,790
opgradere dine servere
over tid eller købe mere,

535
00:25:32,790 --> 00:25:36,242
du måske ikke være i stand til at få præcis
de samme versioner af hardware.

536
00:25:36,242 --> 00:25:37,450
Fordi det falder ud af dato.

537
00:25:37,450 --> 00:25:38,491
Du kan ikke købe det længere.

538
00:25:38,491 --> 00:25:39,360
Priserne ændrer sig.

539
00:25:39,360 --> 00:25:42,500
>> Så du kan have forskellige servere
i din klynge, så at sige.

540
00:25:42,500 --> 00:25:43,890
Det er helt fint.

541
00:25:43,890 --> 00:25:47,100
Men næste års hardware
kunne være dobbelt så hurtigt,

542
00:25:47,100 --> 00:25:49,390
dobbelt så stand som årets.

543
00:25:49,390 --> 00:25:51,500
Så vi kan kaste det
i lasten kategori.

544
00:25:51,500 --> 00:25:54,260
Denne feedback loop mellem 1,
2, og 3 i load balancer

545
00:25:54,260 --> 00:25:57,650
kunne sikkert fortælle det,
hey, jeg er på 50% kapacitet.

546
00:25:57,650 --> 00:26:00,100
Men ved den måde, jeg også
har dobbelt så mange kerner.

547
00:26:00,100 --> 00:26:02,319
Brug disse oplysninger.

548
00:26:02,319 --> 00:26:05,110
Selv simpler-- og dette vil
at være et tema i datalogi.

549
00:26:05,110 --> 00:26:08,990
I tvivlstilfælde, eller hvis du ønsker en enkel
løsning, der generelt fungerer godt

550
00:26:08,990 --> 00:26:12,730
over tid, skal du ikke vælge den samme
server hele tiden, men choose--

551
00:26:12,730 --> 00:26:14,039
>> PUBLIKUM: En tilfældig en?

552
00:26:14,039 --> 00:26:15,330
DAVID MALAN: --a tilfældig server.

553
00:26:15,330 --> 00:26:16,780
Ja, skal du vælge det ene eller det andet.

554
00:26:16,780 --> 00:26:21,160
Så tilfældighed er faktisk
denne meget kraftige ingrediens

555
00:26:21,160 --> 00:26:23,170
i datalogi,
og i teknik mere

556
00:26:23,170 --> 00:26:27,160
generelt, især når du ønsker
at lave en simpel beslutning hurtigt

557
00:26:27,160 --> 00:26:30,480
uden at komplicere det med alle
af disse meget klog, men også

558
00:26:30,480 --> 00:26:34,330
meget kloge, løsninger, der kræver
desto mere engineering, alle

559
00:26:34,330 --> 00:26:36,220
jo flere overvejelser, når
virkelig, hvorfor jeg ikke

560
00:26:36,220 --> 00:26:39,200
lige slags flip en mønt eller en
tresidet mønt i dette tilfælde

561
00:26:39,200 --> 00:26:41,690
og beslutte, om at gå 1, 2, 3?

562
00:26:41,690 --> 00:26:45,610
>> Det kunne give bagslag probalistisk,
men meget gerne odds

563
00:26:45,610 --> 00:26:48,860
af spejlvende hoveder igen og
igen og igen og igen

564
00:26:48,860 --> 00:26:53,870
og igen og igen er muligt i
reality-- super, super usandsynlig.

565
00:26:53,870 --> 00:26:58,170
Så over tid, odds er
blot at sende brugere tilfældigt

566
00:26:58,170 --> 00:27:00,660
til 1, 2, og 3 vil
arbejde ud helt fint.

567
00:27:00,660 --> 00:27:03,380
Og dette er en teknik
almindeligt kendt som round robin.

568
00:27:03,380 --> 00:27:05,160
>> Eller faktisk, det er ikke round robin.

569
00:27:05,160 --> 00:27:06,980
Dette ville være den tilfældige tilgang.

570
00:27:06,980 --> 00:27:09,250
Og hvis du ønsker at være endnu
lidt enklere end det,

571
00:27:09,250 --> 00:27:12,820
round robin ville være, første person går
til 1, andet person til 2, tredje person

572
00:27:12,820 --> 00:27:16,056
til 3, fjerde person til 1.

573
00:27:16,056 --> 00:27:17,430
Og deri ligger round robin.

574
00:27:17,430 --> 00:27:19,580
Du skal bare slags gå rundt i en cyklus.

575
00:27:19,580 --> 00:27:21,300
>> Nu skal du være smart om det.

576
00:27:21,300 --> 00:27:26,490
Du bør ikke blindt sende brugeren
server nummer et, hvis det, der er tilfældet?

577
00:27:26,490 --> 00:27:30,060

578
00:27:30,060 --> 00:27:32,870
Hvis det er ved max kapacitet, eller
det er bare ikke længere reagerer.

579
00:27:32,870 --> 00:27:35,270
Så ideelt du vil have nogle
form for feedback loop.

580
00:27:35,270 --> 00:27:38,040
Ellers du bare sende alle
af dine brugere til en blindgyde.

581
00:27:38,040 --> 00:27:40,790
Men der kan tages i betragtning, også.

582
00:27:40,790 --> 00:27:46,520
>> Så ikke under vurdere værdien af
bare tilfældighed, hvilket er ganske ofte

583
00:27:46,520 --> 00:27:48,970
en løsning på den slags problemer.

584
00:27:48,970 --> 00:27:51,580
Og vi vil skrive ned round robin.

585
00:27:51,580 --> 00:27:55,090
Så hvordan nogle virksomheder gennemfører
round robin eller tilfældighed

586
00:27:55,090 --> 00:27:56,840
eller nogen af ​​disse afgørelser?

587
00:27:56,840 --> 00:28:01,840
Nå desværre, de
gøre ting som dette.

588
00:28:01,840 --> 00:28:03,660
Lad mig trække op anden hurtig screenshot.

589
00:28:03,660 --> 00:28:13,052

590
00:28:13,052 --> 00:28:14,470
>> Faktisk, lad os gøre to.

591
00:28:14,470 --> 00:28:17,420

592
00:28:17,420 --> 00:28:21,370
Jeg ved ikke, hvorfor vi er
at få alle disse retter.

593
00:28:21,370 --> 00:28:22,280
Det er meget mærkeligt.

594
00:28:22,280 --> 00:28:31,714

595
00:28:31,714 --> 00:28:33,630
Okay, hvad jeg virkelig
ønsker, er et screenshot.

596
00:28:33,630 --> 00:28:36,990

597
00:28:36,990 --> 00:28:40,100
Det er underligt.

598
00:28:40,100 --> 00:28:42,930
Okay, så jeg kan spoof dette.

599
00:28:42,930 --> 00:28:46,080
Jeg ved ikke, hvor meget længere
Jeg ønsker at holde rulning.

600
00:28:46,080 --> 00:28:53,220
>> Så meget almindeligt, vil du finde dig selv
på en adresse som www.2.acme.com,

601
00:28:53,220 --> 00:28:56,030
måske www.3 eller 4 eller 5.

602
00:28:56,030 --> 00:28:57,424
Og hold øje for dette.

603
00:28:57,424 --> 00:28:58,590
Du behøver ikke se det så ofte.

604
00:28:58,590 --> 00:29:02,621
Men når du gør det, den slags har en tendens til
være større, ældre, stodgier virksomheder

605
00:29:02,621 --> 00:29:05,370
at teknologisk ikke rigtig
synes at vide, hvad de laver.

606
00:29:05,370 --> 00:29:08,150
Og du ser dette på tech virksomheder
nogle gange, de ældre.

607
00:29:08,150 --> 00:29:09,270
>> Så hvad laver de?

608
00:29:09,270 --> 00:29:11,890
Hvordan er de at gennemføre
load balancing, synes det?

609
00:29:11,890 --> 00:29:15,986
Hvis du finder dig selv som
bruger skrive www.something.com,

610
00:29:15,986 --> 00:29:19,760
og pludselig du er på
www.2.something.com,

611
00:29:19,760 --> 00:29:21,866
hvad har deres belastning
balancer sandsynligvis gjort?

612
00:29:21,866 --> 00:29:22,741
PUBLIKUM: [uhørligt]

613
00:29:22,741 --> 00:29:28,210

614
00:29:28,210 --> 00:29:31,079
>> DAVID MALAN: Ja, så det
load balancer er formentlig

615
00:29:31,079 --> 00:29:33,870
træffer en beslutning baseret på en af
disse beslutningsprocessen processes--

616
00:29:33,870 --> 00:29:35,210
er virkelig ligegyldigt hvilken.

617
00:29:35,210 --> 00:29:38,650
Men meget ligesom jeg har henledt
numre på tavlen her,

618
00:29:38,650 --> 00:29:40,650
serverne er ikke bare
kaldet 1, 2, og 3.

619
00:29:40,650 --> 00:29:43,870
De er sandsynligvis kaldt
www1, www2, www3.

620
00:29:43,870 --> 00:29:47,200
Og det viser sig, at indersiden af
en HTTP-anmodning er denne funktion.

621
00:29:47,200 --> 00:29:48,950
Og jeg har tænkt mig at
simulere dette som følger.

622
00:29:48,950 --> 00:29:53,230
>> Jeg har tænkt mig at åbne op, at samme
Fanen udvikler netværk som før bare

623
00:29:53,230 --> 00:29:55,560
så vi kan se hvad der foregår
på under kølerhjelmen.

624
00:29:55,560 --> 00:29:57,130
Jeg har tænkt mig at rydde skærmen.

625
00:29:57,130 --> 00:30:03,420
Og jeg har tænkt mig at gå til, lad os
sige, http://harvard.edu.

626
00:30:03,420 --> 00:30:06,560
Nu uanset
forretningsmæssige årsager, Harvard

627
00:30:06,560 --> 00:30:08,930
har besluttet, ligesom mange,
mange andre hjemmesider,

628
00:30:08,930 --> 00:30:12,712
at standardisere sin
hjemmeside på www.harvard.edu

629
00:30:12,712 --> 00:30:14,420
for både teknisk
og marketing årsager.

630
00:30:14,420 --> 00:30:16,326
Det er bare sådan i
mode at have www.

631
00:30:16,326 --> 00:30:20,500
>> Så serveren på Harvard har
en eller anden måde omdirigere brugeren,

632
00:30:20,500 --> 00:30:23,830
som jeg altid siger, fra
en URL til den anden.

633
00:30:23,830 --> 00:30:24,670
Hvordan kan det fungere?

634
00:30:24,670 --> 00:30:26,740
Nå, lad mig gå videre og tryk på Enter.

635
00:30:26,740 --> 00:30:30,830
Og bemærk webadressen faktisk hurtigt
ændret til www.harvard.edu.

636
00:30:30,830 --> 00:30:35,560
Lad mig rulle tilbage i denne
historie og klik på denne debug

637
00:30:35,560 --> 00:30:37,650
diagnostiske oplysninger, hvis du vil.

638
00:30:37,650 --> 00:30:39,170
Lad mig se på min anmodning.

639
00:30:39,170 --> 00:30:41,020
>> Så her er jeg anmodning.

640
00:30:41,020 --> 00:30:44,870
Og mærke til det er i overensstemmelse med den slags
af anmode jeg lavet af Facebook før.

641
00:30:44,870 --> 00:30:48,010
Men bemærk svaret.

642
00:30:48,010 --> 00:30:50,430
Hvad er anderledes i
svaret denne gang?

643
00:30:50,430 --> 00:30:51,890
>> PUBLIKUM: [uhørligt]

644
00:30:51,890 --> 00:30:54,290
>> DAVID MALAN: Ja, så det er ikke en 200 OK.

645
00:30:54,290 --> 00:30:56,130
Det er ikke en 404 ikke fundet.

646
00:30:56,130 --> 00:31:00,150
Det er en 301 flyttet permanent, hvilket
er lidt af en sjov måde at sige,

647
00:31:00,150 --> 00:31:05,270
Harvard har forhøjet og flyttede
andre steder for at www.harvard.edu.

648
00:31:05,270 --> 00:31:08,220
De 301 betyder, at en
dette er en omdirigering.

649
00:31:08,220 --> 00:31:12,812
Og hvor skal brugeren
tilsyneladende blive omdirigeret?

650
00:31:12,812 --> 00:31:15,520
Der er en ekstra tidbit af
oplysninger inde at kuvert.

651
00:31:15,520 --> 00:31:19,650
Og hver af disse linjer vil nu
begynde at kalde en HTTP header.

652
00:31:19,650 --> 00:31:23,620
Header er blot en central værdi
pair-- noget kolon noget.

653
00:31:23,620 --> 00:31:24,850
Det er et stykke information.

654
00:31:24,850 --> 00:31:27,131
Hvor skal det nye
placering tilsyneladende være?

655
00:31:27,131 --> 00:31:31,120

656
00:31:31,120 --> 00:31:33,692
Bemærk den sidste linje
blandt alle disse overskrifter.

657
00:31:33,692 --> 00:31:34,940
>> PUBLIKUM: [uhørligt]

658
00:31:34,940 --> 00:31:37,148
>> DAVID MALAN: Ja, så der er
yderligere information.

659
00:31:37,148 --> 00:31:40,120
Den første linje, som jeg har fremhævet
siger 301 flyttet permanent.

660
00:31:40,120 --> 00:31:42,820
Nå, hvor har det flyttet?

661
00:31:42,820 --> 00:31:45,340
Den sidste line-- og de ikke
skal være i denne rækkefølge.

662
00:31:45,340 --> 00:31:47,020
Det kan være tilfældigt.

663
00:31:47,020 --> 00:31:52,120
Placering kolon betyder, hey
browser, gå til denne URL i stedet.

664
00:31:52,120 --> 00:31:55,180
>> Så browsere forstår HTTP omdirigeringer.

665
00:31:55,180 --> 00:31:57,540
Og det er en meget, meget
almindelig måde hoppende

666
00:31:57,540 --> 00:31:59,680
brugeren fra et sted til et andet.

667
00:31:59,680 --> 00:32:02,660
For eksempel, hvis du nogensinde har prøvet
at besøge et websted, som du ikke er

668
00:32:02,660 --> 00:32:06,360
logget ind, kan du pludselig finde
dig selv på en ny webadresse helt være

669
00:32:06,360 --> 00:32:07,530
bedt om at logge ind.

670
00:32:07,530 --> 00:32:08,400
>> Hvordan kan det fungere?

671
00:32:08,400 --> 00:32:10,920
Serveren er sandsynligvis sende en 301.

672
00:32:10,920 --> 00:32:14,510
Der er også andre numre, ligesom
302, noget anderledes i betydning,

673
00:32:14,510 --> 00:32:16,490
at sende dig til en anden URL.

674
00:32:16,490 --> 00:32:18,770
Og så serveren,
når du har logget ind,

675
00:32:18,770 --> 00:32:22,000
vil sende dig tilbage til hvor
du faktisk hensigten.

676
00:32:22,000 --> 00:32:27,700
>> Så hvad, så er dårligt
manipuleret hjemmesider gør?

677
00:32:27,700 --> 00:32:31,340
Når du besøger
www.acme.com, og de bare

678
00:32:31,340 --> 00:32:35,490
tilfældigvis har navngivet deres servere
www1, www2, www3, og så videre,

679
00:32:35,490 --> 00:32:39,100
de er meget simply--
som er fair, men meget

680
00:32:39,100 --> 00:32:46,080
slags foolishly-- omdirigere dig til
en faktisk forskelligt navngivne server.

681
00:32:46,080 --> 00:32:48,650
Og det fungerer helt fint.

682
00:32:48,650 --> 00:32:49,930
Det er rart og nemt.

683
00:32:49,930 --> 00:32:52,200
>> Vi har set, hvordan det ville være
gjort under kølerhjelmen

684
00:32:52,200 --> 00:32:53,490
i den virtuelle kuvert.

685
00:32:53,490 --> 00:32:56,450
Men hvorfor er det velsagtens en
dårlig teknik beslutning?

686
00:32:56,450 --> 00:33:00,345
Og hvorfor er jeg slags nedladende
mod denne særlige teknik

687
00:33:00,345 --> 00:33:00,845
nærme sig?

688
00:33:00,845 --> 00:33:06,420

689
00:33:06,420 --> 00:33:07,850
Argumentere, hvorfor det er dårligt.

690
00:33:07,850 --> 00:33:09,375
Ben?

691
00:33:09,375 --> 00:33:10,250
PUBLIKUM: [uhørligt]

692
00:33:10,250 --> 00:33:12,864

693
00:33:12,864 --> 00:33:16,030
DAVID MALAN: Hver server skulle
har et eksemplar af hjemmesiden.

694
00:33:16,030 --> 00:33:16,738
Jeg er OK med det.

695
00:33:16,738 --> 00:33:19,490
Og i virkeligheden, det er hvad jeg er
formode for hele denne historie,

696
00:33:19,490 --> 00:33:22,104
for hvis vi wanted-- godt
faktisk, undtagen for Dan tidligere

697
00:33:22,104 --> 00:33:25,270
forslag, hvor, hvis du har forskellige
servere laver forskellige ting, så

698
00:33:25,270 --> 00:33:27,740
måske de kunne faktisk være
funktionelt gøre forskellige ting.

699
00:33:27,740 --> 00:33:30,698
>> Men selv da, på et tidspunkt, din
Databasen vil blive overbelastet.

700
00:33:30,698 --> 00:33:33,030
Din statiske aktiver server
vil blive overbelastet.

701
00:33:33,030 --> 00:33:34,850
Så på et tidspunkt, er vi
tilbage på denne historie, hvor vi

702
00:33:34,850 --> 00:33:36,475
brug flere kopier af den samme ting.

703
00:33:36,475 --> 00:33:37,395
Så jeg er OK med det.

704
00:33:37,395 --> 00:33:38,270
PUBLIKUM: [uhørligt]

705
00:33:38,270 --> 00:33:42,340

706
00:33:42,340 --> 00:33:45,350
>> DAVID MALAN: Ok, så nogle sider
kunne være uforholdsmæssigt populære.

707
00:33:45,350 --> 00:33:50,460
Og så fiksere på én adresse
er ikke nødvendigvis det bedste.

708
00:33:50,460 --> 00:33:51,110
[Uhørligt]?

709
00:33:51,110 --> 00:33:51,985
>> PUBLIKUM: [uhørligt]

710
00:33:51,985 --> 00:33:54,770

711
00:33:54,770 --> 00:33:57,623
>> DAVID MALAN: Hvad mener du med det?

712
00:33:57,623 --> 00:33:58,498
PUBLIKUM: [uhørligt]

713
00:33:58,498 --> 00:34:03,820

714
00:34:03,820 --> 00:34:05,072
>> DAVID MALAN: Ja, præcis.

715
00:34:05,072 --> 00:34:07,280
Så du ikke ønsker at
nødvendigvis have-- du helt sikkert

716
00:34:07,280 --> 00:34:11,370
ikke ønsker at have dine brugere
manuelt at skrive i www1 eller www2.

717
00:34:11,370 --> 00:34:14,550
Fra et branding perspektiv, det
bare ser lidt latterligt.

718
00:34:14,550 --> 00:34:17,340
Hvis du bare vil en slags
ren, elegant erfaring,

719
00:34:17,340 --> 00:34:20,364
have den slags tilfældigt
nummererede URL'er er virkelig ikke godt.

720
00:34:20,364 --> 00:34:22,780
Fordi så brugerne er helt sikkert
kommer til at kopiere og indsætte dem

721
00:34:22,780 --> 00:34:24,449
i e-mails eller onlinemeddelelser.

722
00:34:24,449 --> 00:34:25,659
>> Nu de er formerings.

723
00:34:25,659 --> 00:34:28,600
Nu er du slags forvirrende dit
mindre teknisk publikum, der mener

724
00:34:28,600 --> 00:34:32,239
din web-adresse er www2.something.com.

725
00:34:32,239 --> 00:34:35,434
Der er ingen tvingende semantik til det.

726
00:34:35,434 --> 00:34:38,100
Det sker bare at være en underliggende
tekniske detaljer, at du har

727
00:34:38,100 --> 00:34:40,190
nummereret dine servere på denne måde.

728
00:34:40,190 --> 00:34:45,760
>> Og værre endnu, hvad nu hvis, for eksempel,
måske omkring juletid, hvor

729
00:34:45,760 --> 00:34:50,090
virksomhed er virkelig boomer,
du har fået www1 gennem www99,

730
00:34:50,090 --> 00:34:53,530
men i januar og februar og
videre, deaktivere du halvdelen af ​​dem

731
00:34:53,530 --> 00:34:56,440
så du kun har www1 gennem www50?

732
00:34:56,440 --> 00:35:01,963
Hvad er konsekvenserne nu for at
meget rimelig forretningsmæssig beslutning?

733
00:35:01,963 --> 00:35:02,838
PUBLIKUM: [uhørligt]

734
00:35:02,838 --> 00:35:05,628

735
00:35:05,628 --> 00:35:07,752
DAVID MALAN: Du skal
styre alle dem, der stadig.

736
00:35:07,752 --> 00:35:10,515
PUBLIKUM: [uhørligt]

737
00:35:10,515 --> 00:35:11,390
DAVID MALAN: Præcis.

738
00:35:11,390 --> 00:35:12,681
Det er lidt af fangsten der.

739
00:35:12,681 --> 00:35:16,800
Hvis dine kunder er i vane med
bookmarking ting, e-maile dem, bare

740
00:35:16,800 --> 00:35:19,351
gemme URL'en eller andet sted, eller
hvis det er bare i deres auto

741
00:35:19,351 --> 00:35:22,350
fuldføre i deres browser, så de er
ikke rigtig med vilje at skrive det,

742
00:35:22,350 --> 00:35:25,560
det er bare sker, de kunne,
i 11 måneder ud af året

743
00:35:25,560 --> 00:35:27,190
effektivt, når en blindgyde.

744
00:35:27,190 --> 00:35:30,100
Og kun de mest snu af
brugere kommer til at indse,

745
00:35:30,100 --> 00:35:32,040
måske jeg skulle manuelt
fjerne dette nummer.

746
00:35:32,040 --> 00:35:35,610
Jeg mener, det er bare ikke kommer til at ske
med mange brugere, så dårligt for erhvervslivet,

747
00:35:35,610 --> 00:35:37,750
dårlig teknik implementering klogt.

748
00:35:37,750 --> 00:35:40,230
>> Så heldigvis er det ikke engang nødvendigt.

749
00:35:40,230 --> 00:35:43,120
Det viser sig, at det,
load balancers kan gøre

750
00:35:43,120 --> 00:35:48,130
er stedet for at sige, når A
gør en request-- hey A, gå til en.

751
00:35:48,130 --> 00:35:50,280
Med andre ord, i stedet
sende, at omdirigering

752
00:35:50,280 --> 00:35:53,540
således at trin et i dette
proces er farten her,

753
00:35:53,540 --> 00:35:55,280
han derefter fortalte at gå andre steder.

754
00:35:55,280 --> 00:35:57,530
Og så trin tre er, han går et andet sted.

755
00:35:57,530 --> 00:36:04,600
>> Man kan i stedet fortsætte med at route, at
fortsætte med at bruge dette udtryk, alle af en data

756
00:36:04,600 --> 00:36:10,590
gennem load balancer, så han
aldrig kontakter 1, 2, eller 3 direkte.

757
00:36:10,590 --> 00:36:15,150
Alle trafik betyder få "dirigeres"
af load balancer selv.

758
00:36:15,150 --> 00:36:17,524
Og så nu er vi slags
bevidst sløring linjerne

759
00:36:17,524 --> 00:36:18,690
blandt disse forskellige enheder.

760
00:36:18,690 --> 00:36:20,930
En load balancer kan route data.

761
00:36:20,930 --> 00:36:22,435
Det er bare en funktion, som det har.

762
00:36:22,435 --> 00:36:25,420
>> Så en load balancer, også, det er
et stykke software, virkelig.

763
00:36:25,420 --> 00:36:27,130
Og en router er et stykke software.

764
00:36:27,130 --> 00:36:29,660
Og du kan absolut have
to stykker software inde

765
00:36:29,660 --> 00:36:34,000
af én fysisk computer, så en belastning
balancer kan gøre disse mange ting.

766
00:36:34,000 --> 00:36:36,130
>> Så der er en anden vej
at gøre dette, som faktisk

767
00:36:36,130 --> 00:36:39,670
går tilbage til en slags første principper
af DNS, som vi talte om

768
00:36:39,670 --> 00:36:40,230
før pausen.

769
00:36:40,230 --> 00:36:41,634
DNS var Domain Name System.

770
00:36:41,634 --> 00:36:43,550
Husk, at du kan
bede en DNS-server, hvad er

771
00:36:43,550 --> 00:36:46,460
IP-adresse
google.com, facebook.com?

772
00:36:46,460 --> 00:36:48,250
>> Og vi kan faktisk gøre dette.

773
00:36:48,250 --> 00:36:51,940
Et værktøj vi ikke bruge tidligere er
en, der er lige så tilgængelige,

774
00:36:51,940 --> 00:36:55,510
kaldet nslookup, for navneserver opslag.

775
00:36:55,510 --> 00:36:57,410
Og jeg bare at skrive facebook.com.

776
00:36:57,410 --> 00:37:02,500
Og jeg kan se, at Facebook IP
adresse er tilsyneladende dette.

777
00:37:02,500 --> 00:37:05,520
Lad mig gå videre og kopiere
at gå til en browser,

778
00:37:05,520 --> 00:37:11,690
og gå til http: // og at
IP-adresse og tryk på Enter.

779
00:37:11,690 --> 00:37:14,140
Og ganske rigtigt, det ser ud til at virke.

780
00:37:14,140 --> 00:37:18,610
>> arbejder nu baglæns, hvad var
indersiden af ​​virtuelle kuvert

781
00:37:18,610 --> 00:37:25,454
at Facebook reagerede med, når
Jeg besøgte at IP-adresse direkte?

782
00:37:25,454 --> 00:37:26,745
Fordi varsel, hvor er jeg nu?

783
00:37:26,745 --> 00:37:29,250

784
00:37:29,250 --> 00:37:32,484
Hvor er jeg nu, adressen?

785
00:37:32,484 --> 00:37:33,450
>> PUBLIKUM: [uhørligt]

786
00:37:33,450 --> 00:37:36,116
>> DAVID MALAN: På sikker version,
og på www.facebook.com.

787
00:37:36,116 --> 00:37:38,520
Så det er ikke bare
den sikre IP-adresse.

788
00:37:38,520 --> 00:37:42,650
Facebook har taget det på sig selv
at sige, det er latterligt.

789
00:37:42,650 --> 00:37:45,710
Vi kommer ikke til at holde dig på dette
grimme leder webadresse, der er numerisk.

790
00:37:45,710 --> 00:37:50,120
Vi vil sende dig en HTTP
omdirigere via samme overskrift

791
00:37:50,120 --> 00:37:53,010
at vi så before--
placering colon noget.

792
00:37:53,010 --> 00:37:56,340
>> Og så betyder det blot, at under
hætten er stadig denne IP-adresse.

793
00:37:56,340 --> 00:37:59,010
Hver computer på internettet
har en IP-adresse, ser det ud til.

794
00:37:59,010 --> 00:38:01,480
Men du behøver ikke nødvendigvis
at udsætte det for brugeren.

795
00:38:01,480 --> 00:38:07,190
Og meget gerne tilbage i dag, er der
var 1-800-COLLECT, 1-800-C-O-L-L-E-C-T,

796
00:38:07,190 --> 00:38:11,700
i USA, var en måde at gøre indsamle
opkald via en meget let mindeværdig telefon

797
00:38:11,700 --> 00:38:17,140
nummer, eller 1-800-madras til at købe en seng,
og lignende huskesymboler at du selv se

798
00:38:17,140 --> 00:38:20,460
på telefonen slags slags
stadig, at breve kort til tal.

799
00:38:20,460 --> 00:38:21,470
>> Nu, hvorfor er det?

800
00:38:21,470 --> 00:38:26,080
Tja, det er meget nemmere at huske
1-800-madras eller 1-800-COLLECT stedet

801
00:38:26,080 --> 00:38:29,100
af 1-800 noget noget noget
noget noget noget

802
00:38:29,100 --> 00:38:31,030
noget, hvor hver
af disse er et ciffer.

803
00:38:31,030 --> 00:38:34,390
Ligeledes lærte verden
hurtigt, at vi ikke skal

804
00:38:34,390 --> 00:38:35,940
har folk huske IP-adresser.

805
00:38:35,940 --> 00:38:36,826
Det ville være dumt.

806
00:38:36,826 --> 00:38:38,200
Vi kommer til at bruge navne i stedet.

807
00:38:38,200 --> 00:38:40,420
Og det er derfor DNS blev født.

808
00:38:40,420 --> 00:38:45,510
>> Okay, så med det sagt, hvad angår
af load balancing, lad os prøve yahoo.com.

809
00:38:45,510 --> 00:38:47,030
Tja, det er interessant.

810
00:38:47,030 --> 00:38:51,464
Yahoo synes at vende tilbage tre IP'er.

811
00:38:51,464 --> 00:38:53,940
Så udlede dette,
Hvis du kunne, hvad der er

812
00:38:53,940 --> 00:38:58,600
en anden måde, at vi kunne gennemføre
denne opfattelse af load balancing

813
00:38:58,600 --> 00:39:04,310
måske uden selv at bruge en fysisk
enhed, har denne nye fysiske enhed?

814
00:39:04,310 --> 00:39:08,070
>> Med andre ord, kan jeg tage væk
finansieringen du har for load balancer

815
00:39:08,070 --> 00:39:10,990
og fortælle dig at bruge nogle af de eksisterende
stykke hardware til at gennemføre

816
00:39:10,990 --> 00:39:12,680
denne begrebet load balancing?

817
00:39:12,680 --> 00:39:18,870

818
00:39:18,870 --> 00:39:22,510
Og spoiler er,
ja, men hvad, eller hvordan?

819
00:39:22,510 --> 00:39:27,605
Hvad er Yahoo måske gør her?

820
00:39:27,605 --> 00:39:29,200
Kareem?

821
00:39:29,200 --> 00:39:30,635
OK, Chris?

822
00:39:30,635 --> 00:39:31,510
PUBLIKUM: [uhørligt]

823
00:39:31,510 --> 00:39:35,119

824
00:39:35,119 --> 00:39:36,910
DAVID MALAN: Ja, alle
tre af disse arbejder.

825
00:39:36,910 --> 00:39:39,890
Så tilfældighed, round robin,
Beliggende- du kan bare

826
00:39:39,890 --> 00:39:44,160
udnytte en eksisterende brik i puslespillet
at vi talte om tidligere af DNS

827
00:39:44,160 --> 00:39:49,580
systemet og blot sige, når den første
brugeren af ​​dagen anmoder yahoo.com,

828
00:39:49,580 --> 00:39:52,970
give dem den første IP-adresse,
som den sluttede i 45 deroppe.

829
00:39:52,970 --> 00:39:55,762
Og næste gang en bruger anmoder
IP-adresse yahoo.com

830
00:39:55,762 --> 00:39:57,970
fra et sted i verden,
give dem den anden IP,

831
00:39:57,970 --> 00:39:59,920
derefter den tredje IP, derefter
første IP, derefter det andet.

832
00:39:59,920 --> 00:40:01,850
Eller være smart om det
og gøre det grafisk.

833
00:40:01,850 --> 00:40:05,200
Eller det tilfældigt og ikke bare gøre
Det round robin på denne måde.

834
00:40:05,200 --> 00:40:07,580
>> Og i dette tilfælde, så
Vi behøver ikke engang

835
00:40:07,580 --> 00:40:10,190
at indføre denne sort
kasse ind i vores billede.

836
00:40:10,190 --> 00:40:11,690
Vi har ikke brug for en ny enhed.

837
00:40:11,690 --> 00:40:16,930
Vi er simpelthen fortæller computere
at gå til serverne direkte,

838
00:40:16,930 --> 00:40:18,680
effektivt, men ikke
ved hjælp af deres navn.

839
00:40:18,680 --> 00:40:20,054
De har brug for aldrig at kende navnet.

840
00:40:20,054 --> 00:40:25,690
De er bare at vide, at yahoo.com
Kort ethvert af disse IP-adresser.

841
00:40:25,690 --> 00:40:28,180
>> Så det sender nøjagtig samme anmodning.

842
00:40:28,180 --> 00:40:30,100
Men på ydersiden af
konvolutten, det simpelthen

843
00:40:30,100 --> 00:40:32,740
sætter IP, at det var informeret om.

844
00:40:32,740 --> 00:40:35,590
Og på denne måde, kunne også
vi indlæse balance anmodningerne

845
00:40:35,590 --> 00:40:39,330
ved blot at sende konvolutten til en
anderledes en af ​​Yahoos egne servere?

846
00:40:39,330 --> 00:40:42,390
>> Og hvis vi holder grave, vil vi se
sandsynligvis andre virksomheder med mere.

847
00:40:42,390 --> 00:40:44,380
CNN har to offentligt eksponeret.

848
00:40:44,380 --> 00:40:49,610
Selvom faktisk, hvis vi gør det igen
og igen-- cnn.com-- du kan se

849
00:40:49,610 --> 00:40:51,730
de er ved at ændre rækkefølge, faktisk.

850
00:40:51,730 --> 00:40:56,680
Så hvad mekanisme er
CNN bruger, tilsyneladende?

851
00:40:56,680 --> 00:40:57,440
>> PUBLIKUM: Tilfældig.

852
00:40:57,440 --> 00:40:59,440
DAVID MALAN: Tja, det
kunne være tilfældig, selv om det

853
00:40:59,440 --> 00:41:01,110
synes at cykle frem og tilbage.

854
00:41:01,110 --> 00:41:04,380
Så det er nok round robin, hvor
de er bare skifte rækkefølge, så

855
00:41:04,380 --> 00:41:05,880
at jeg formentlig vil tage den første.

856
00:41:05,880 --> 00:41:08,860
Min computer vil tage
første hver gang.

857
00:41:08,860 --> 00:41:10,490
Så det er load balancing.

858
00:41:10,490 --> 00:41:18,450
Og det giver os mulighed for, i sidste ende,
at kortlægge data, eller kort anmodninger,

859
00:41:18,450 --> 00:41:21,240
tværs af flere servere.

860
00:41:21,240 --> 00:41:24,226
Så hvad slags
nu stadig er problemer?

861
00:41:24,226 --> 00:41:26,350
Det føles som om vi bare virkelig
løst et godt problem.

862
00:41:26,350 --> 00:41:28,740
Vi fik brugere til forskellige servere.

863
00:41:28,740 --> 00:41:31,420
Men-- Åh, og Chris, gjorde
du har et spørgsmål før?

864
00:41:31,420 --> 00:41:34,378
>> PUBLIKUM: [uhørligt]

865
00:41:34,378 --> 00:41:43,670

866
00:41:43,670 --> 00:41:45,120
>> DAVID MALAN: Totally afhænger af.

867
00:41:45,120 --> 00:41:47,042
Så hvad sker der her?

868
00:41:47,042 --> 00:41:48,250
Og vi kan faktisk se dette.

869
00:41:48,250 --> 00:41:51,649
Så lad os prøve Yahoos.

870
00:41:51,649 --> 00:41:52,940
Faktisk, lad os gå til Facebook.

871
00:41:52,940 --> 00:41:54,520
Fordi vi ved, at man arbejder.

872
00:41:54,520 --> 00:41:56,545
Så jeg har tænkt mig at kopiere
at IP-adressen igen.

873
00:41:56,545 --> 00:41:58,820
Jeg har tænkt mig at lukke alle disse faner.

874
00:41:58,820 --> 00:42:03,800
Jeg har tænkt mig at gå åbent at
særligt netværk fanen hernede.

875
00:42:03,800 --> 00:42:07,800
Og jeg har tænkt mig at besøge kun http: //.

876
00:42:07,800 --> 00:42:10,694
Og nu vil jeg trykke Enter.

877
00:42:10,694 --> 00:42:11,860
Og lad os se, hvad der skete.

878
00:42:11,860 --> 00:42:20,662
>> Hvis jeg ser på denne anmodning, varsel
at my-- Facebook er et dårligt eksempel.

879
00:42:20,662 --> 00:42:22,370
Fordi de har en
super fancy teknik

880
00:42:22,370 --> 00:42:25,960
der skjuler, at detaljer fra os.

881
00:42:25,960 --> 00:42:30,690
Lad mig bruge Yahoo
instead-- http: // pågældende IP.

882
00:42:30,690 --> 00:42:36,030
Lad os åbne vores netværk
fane, bevare log.

883
00:42:36,030 --> 00:42:37,945
Og her går vi, Enter.

884
00:42:37,945 --> 00:42:40,669

885
00:42:40,669 --> 00:42:41,210
Det er sjovt.

886
00:42:41,210 --> 00:42:44,480
OK, så her er den berømte 404-meddelelse.

887
00:42:44,480 --> 00:42:48,500
Hvad er sjovt her er, at de
sandsynligvis aldrig vil være tilbage.

888
00:42:48,500 --> 00:42:51,430
Fordi der er nok
ikke noget galt per se.

889
00:42:51,430 --> 00:42:54,050
De har netop bevidst
besluttede ikke at støtte

890
00:42:54,050 --> 00:42:56,250
det numeriske form af deres adresse.

891
00:42:56,250 --> 00:43:00,270
>> Så det vi faktisk ser i
fanen Netværk, hvis jeg trækker det op her,

892
00:43:00,270 --> 00:43:06,140
er, som jeg siger, det berømte 404, hvor
hvis jeg ser på de svar overskrifter,

893
00:43:06,140 --> 00:43:09,070
dette er hvad jeg fik her-- 404 Ikke fundet.

894
00:43:09,070 --> 00:43:11,360
Så lad os prøve en anden.

895
00:43:11,360 --> 00:43:13,180
Lad os se, om CNN samarbejder med os.

896
00:43:13,180 --> 00:43:19,440
Jeg vil få fat i en af ​​CNN IP-adresser,
fjerne denne, http, dah, dah, dah, dah.

897
00:43:19,440 --> 00:43:21,620
Så som svar på Chris '
spørgsmål, at man arbejdede.

898
00:43:21,620 --> 00:43:24,140

899
00:43:24,140 --> 00:43:26,255
>> Og lad os gå til respons overskrifter.

900
00:43:26,255 --> 00:43:30,810

901
00:43:30,810 --> 00:43:33,640
Faktisk nej, okay, jeg er
kæmper for at finde en fungerende eksempel.

902
00:43:33,640 --> 00:43:38,270
Så CNN har besluttet, vil vi bare lade dig
uanset på hvilket adresse, du rent faktisk besøger,

903
00:43:38,270 --> 00:43:40,359
branding spørgsmål til side.

904
00:43:40,359 --> 00:43:43,275
Men hvad ville ikke være tilfældet, hvis
vi kunne se det i Facebooks tilfælde,

905
00:43:43,275 --> 00:43:46,700
er vi ville få en 301 Flyttet
Permanent, mest sandsynligt,

906
00:43:46,700 --> 00:43:54,420
inden i hvilken er
placering: https: //www.facebook.com.

907
00:43:54,420 --> 00:44:01,210
Og odds er www.facebook.com er en
alias for nøjagtig samme server vi bare

908
00:44:01,210 --> 00:44:01,710
gik til.

909
00:44:01,710 --> 00:44:03,500
>> Så det er lidt bagslag.

910
00:44:03,500 --> 00:44:05,170
Vi bogstaveligt besøger serveren.

911
00:44:05,170 --> 00:44:07,040
Serveren derefter fortæller os, gå væk.

912
00:44:07,040 --> 00:44:08,320
Gå til denne anden adresse.

913
00:44:08,320 --> 00:44:10,870
Men vi bare så tilfældigvis
gå tilbage til den samme server.

914
00:44:10,870 --> 00:44:14,550
Men formentlig vi nu ophold på det
server uden denne frem og tilbage.

915
00:44:14,550 --> 00:44:18,600
Fordi nu er vi ved hjælp af navngivne
version af hjemmesiden, ikke det numeriske.

916
00:44:18,600 --> 00:44:20,060
Godt spørgsmål.

917
00:44:20,060 --> 00:44:23,690
>> OK, så hvis vi nu assume-- vi
har løst load balancing.

918
00:44:23,690 --> 00:44:25,894
Vi har nu en mekanisme,
uanset om det er via DNS,

919
00:44:25,894 --> 00:44:29,060
uanset om det er via denne sorte boks, hvorvidt
det er at bruge nogen af ​​disse teknikker.

920
00:44:29,060 --> 00:44:33,810
Vi kan tage en brugers anmodning og
regne ud hvilken server, 1, 2 eller 3,

921
00:44:33,810 --> 00:44:35,420
at sende ham eller hende.

922
00:44:35,420 --> 00:44:39,180
>> Hvad begynder at bryde om vores hjemmeside?

923
00:44:39,180 --> 00:44:41,160
Med andre ord har vi
bygget en virksomhed,

924
00:44:41,160 --> 00:44:43,480
var tidligere på én enkelt server.

925
00:44:43,480 --> 00:44:46,870
Nu, virksomhed kører
tværs af flere servere.

926
00:44:46,870 --> 00:44:51,770
Hvilke typer af antagelser,
hvilke former for design beslutninger,

927
00:44:51,770 --> 00:44:54,870
kan nu bryde?

928
00:44:54,870 --> 00:44:55,745
>> Det er mindre indlysende.

929
00:44:55,745 --> 00:44:58,620
Men lad os se, om vi ikke kan sætte vores
fingeren på nogle af det problem, vi har

930
00:44:58,620 --> 00:44:59,780
skabt for os selv.

931
00:44:59,780 --> 00:45:02,750
Igen, det er lidt som at holde
ned lækagen i slangen.

932
00:45:02,750 --> 00:45:05,094
Og nu nogle nye spørgsmål
har dukkede op herovre.

933
00:45:05,094 --> 00:45:07,880

934
00:45:07,880 --> 00:45:11,380
>> PUBLIKUM: [uhørligt]

935
00:45:11,380 --> 00:45:16,574

936
00:45:16,574 --> 00:45:19,240
DAVID MALAN: OK, så vi er nødt til at
holde voksende vores plads på harddisken.

937
00:45:19,240 --> 00:45:20,450
Jeg er OK med at lige nu.

938
00:45:20,450 --> 00:45:23,212
Fordi jeg tror, ​​jeg kan
vandret skala.

939
00:45:23,212 --> 00:45:26,420
Ligesom hvis jeg kører lavt, vil jeg bare få
en fjerde server, måske en femte server,

940
00:45:26,420 --> 00:45:30,820
og derefter øge vores kapacitet
med yderligere 30% eller 50% eller whatnot.

941
00:45:30,820 --> 00:45:32,759
Så jeg er OK med det, i hvert fald for nu.

942
00:45:32,759 --> 00:45:33,634
PUBLIKUM: [uhørligt]

943
00:45:33,634 --> 00:45:37,314

944
00:45:37,314 --> 00:45:38,980
DAVID MALAN: OK, så det er en god pointe.

945
00:45:38,980 --> 00:45:42,340
Så formoder serverne
er ikke identiske.

946
00:45:42,340 --> 00:45:45,260
Og kundeservice
eller e-mail ækvivalent

947
00:45:45,260 --> 00:45:48,690
er at få nogle besked fra en bruger
siger, er dette ikke fungerer rigtigt.

948
00:45:48,690 --> 00:45:52,070
Det er meget muligt, nogle gange,
at måske en eller flere servere

949
00:45:52,070 --> 00:45:55,000
handler lidt skævt, men ikke
de andre, der kan helt sikkert

950
00:45:55,000 --> 00:45:57,096
gøre det sværere at jagte problemet.

951
00:45:57,096 --> 00:45:58,720
Du har måske til at se flere steder.

952
00:45:58,720 --> 00:46:00,960
>> Det er manifestation
af anden slags fejl,

953
00:46:00,960 --> 00:46:03,950
som er, at du sandsynligvis skal
har designet din infrastruktur, så

954
00:46:03,950 --> 00:46:06,200
at alt er virkelig identiske.

955
00:46:06,200 --> 00:46:10,390
Men det gør afslører et nyt problem
at vi ikke havde før.

956
00:46:10,390 --> 00:46:11,715
Hvad ellers?

957
00:46:11,715 --> 00:46:12,590
PUBLIKUM: [uhørligt]

958
00:46:12,590 --> 00:46:16,390

959
00:46:16,390 --> 00:46:19,500
>> DAVID MALAN: Ja,
der er mere kompleksitet.

960
00:46:19,500 --> 00:46:20,792
Der er fysisk flere ledninger.

961
00:46:20,792 --> 00:46:21,750
Der er en anden enhed.

962
00:46:21,750 --> 00:46:26,310
Faktisk har jeg indført en fundamental
koncept og et grundlæggende problem her

963
00:46:26,310 --> 00:46:28,300
kendt som et enkelt punkt
af svigt, som,

964
00:46:28,300 --> 00:46:30,110
selv hvis du aldrig har hørt
sætningen, kan du sikkert

965
00:46:30,110 --> 00:46:31,780
nu arbejde baglæns og finde ud af det.

966
00:46:31,780 --> 00:46:35,560
Hvad betyder det, at jeg har en enkelt
fejlpunkt i min arkitektur?

967
00:46:35,560 --> 00:46:39,694
Og ved arkitektur, jeg bare
betyde topologien af ​​det.

968
00:46:39,694 --> 00:46:40,610
>> PUBLIKUM: [uhørligt]

969
00:46:40,610 --> 00:46:42,901
>> DAVID MALAN: Ja, hvad nu hvis
belastningen balancer går ned?

970
00:46:42,901 --> 00:46:46,290
Jeg har indsat denne midterste mand, hvis
formål i livet er at løse et problem.

971
00:46:46,290 --> 00:46:47,740
Men jeg har introduceret et nyt problem.

972
00:46:47,740 --> 00:46:49,350
En ny lækage er sprunget i slangen.

973
00:46:49,350 --> 00:46:53,500
Fordi nu hvis load balancer
dør eller pauser eller misfunctions,

974
00:46:53,500 --> 00:46:56,350
nu mister jeg adgang til
alle tre af mine servere.

975
00:46:56,350 --> 00:46:58,880
Og før, jeg ikke
har denne mellemmand.

976
00:46:58,880 --> 00:47:03,020
Og så dette er et nyt problem, velsagtens.

977
00:47:03,020 --> 00:47:05,245
Vi kommer tilbage til
hvordan vi kan løse det.

978
00:47:05,245 --> 00:47:06,734
>> PUBLIKUM: [uhørligt]

979
00:47:06,734 --> 00:47:08,400
DAVID MALAN: Det ville være en tilgang.

980
00:47:08,400 --> 00:47:13,926
Ja, og så det kommer til at være ganske
rottens hul vi begynder at gå ned.

981
00:47:13,926 --> 00:47:15,800
Men lad os vende tilbage til
at på bare et øjeblik.

982
00:47:15,800 --> 00:47:17,299
Hvilke andre problemer har vi skabt?

983
00:47:17,299 --> 00:47:25,540

984
00:47:25,540 --> 00:47:27,470
>> Så Dan nævnte database før.

985
00:47:27,470 --> 00:47:29,500
Og selv hvis du ikke er
alt for bekendt teknisk,

986
00:47:29,500 --> 00:47:33,220
en database er blot en server, hvor
ændring af data lagres typisk,

987
00:47:33,220 --> 00:47:36,430
måske en ordre nogen har placeret,
din brugerprofil, dit navn,

988
00:47:36,430 --> 00:47:40,810
din e-mailadresse, ting, der kunne
indlæses eller ændret sig over tid.

989
00:47:40,810 --> 00:47:44,599
>> Tidligere min database var på
den samme server som min webserver.

990
00:47:44,599 --> 00:47:46,390
Fordi jeg havde bare en
webhotel.

991
00:47:46,390 --> 00:47:48,480
Alt var alle i samme sted.

992
00:47:48,480 --> 00:47:54,200
Hvor skal jeg sætte min database
nu, på server 1, 2 eller 3?

993
00:47:54,200 --> 00:47:55,100
>> PUBLIKUM: 4.

994
00:47:55,100 --> 00:47:58,070
>> DAVID MALAN: 4, OK, alle
ret, så lad os gå der.

995
00:47:58,070 --> 00:48:01,650
Så jeg har tænkt mig at sætte min
database-- og lad os

996
00:48:01,650 --> 00:48:06,520
begynde mærkning disse www, www, www.

997
00:48:06,520 --> 00:48:08,780
Og jeg har tænkt mig at sige,
dette er nummer fire.

998
00:48:08,780 --> 00:48:11,270
Og jeg vil sige db til databasen.

999
00:48:11,270 --> 00:48:12,870
OK, jeg kan lide dette.

1000
00:48:12,870 --> 00:48:17,021
Hvad linje skal jeg
formentlig tegning her?

1001
00:48:17,021 --> 00:48:18,850
>> PUBLIKUM: [uhørligt]

1002
00:48:18,850 --> 00:48:22,740
>> DAVID MALAN: Ja, så koden,
som vi vil diskutere i morgen,

1003
00:48:22,740 --> 00:48:24,900
formentlig er den samme
på alle tre servere.

1004
00:48:24,900 --> 00:48:28,374
Men det må nu forbinde ikke til en
database kører lokalt, men andre steder.

1005
00:48:28,374 --> 00:48:29,040
Og det er fint.

1006
00:48:29,040 --> 00:48:31,623
Vi kan bare give databasen en
navn, som vi har, eller et tal.

1007
00:48:31,623 --> 00:48:33,930
Og at alt fungerer fint.

1008
00:48:33,930 --> 00:48:35,820
Men hvad har vi gjort?

1009
00:48:35,820 --> 00:48:40,640
Vi har vandret skaleret ved at have
tre servere i stedet for én, der

1010
00:48:40,640 --> 00:48:41,140
er god.

1011
00:48:41,140 --> 00:48:44,240
Fordi nu kan vi håndtere
tre gange så meget belastning.

1012
00:48:44,240 --> 00:48:47,710
>> Og endnu bedre, hvis en eller to
af disse servere går ned,

1013
00:48:47,710 --> 00:48:49,350
min virksomhed kan fortsætte med at fungere.

1014
00:48:49,350 --> 00:48:53,960
Fordi jeg stadig har en, selv om jeg er
slags halter performance-wise.

1015
00:48:53,960 --> 00:49:01,020
Men hvad nyt problem har jeg
indført ved at bevæge databasen

1016
00:49:01,020 --> 00:49:04,350
til denne separat server
i stedet for den 1., 2. og 3?

1017
00:49:04,350 --> 00:49:05,412
>> PUBLIKUM: [uhørligt]

1018
00:49:05,412 --> 00:49:08,120
DAVID MALAN: Ja, så nu har jeg
anden single point of failure.

1019
00:49:08,120 --> 00:49:12,330
Hvis min database dør, eller skal
opgraderes, eller hvad, nu sikker,

1020
00:49:12,330 --> 00:49:13,610
min hjemmeside er online.

1021
00:49:13,610 --> 00:49:16,270
Og jeg kan tjene statisk,
uforanderlig indhold.

1022
00:49:16,270 --> 00:49:21,210
Men jeg kan ikke lade brugerne logge ind eller ændring
noget eller bestille noget, værre endnu.

1023
00:49:21,210 --> 00:49:24,120
For hvis 4 er offline,
derefter 1, 2, og 3

1024
00:49:24,120 --> 00:49:27,710
virkelig kan ikke tale med den definition.

1025
00:49:27,710 --> 00:49:31,560
>> OK så ja, og så det er derfor,
Jeg tøver med at trække dette.

1026
00:49:31,560 --> 00:49:32,690
Så lad os komme tilbage til.

1027
00:49:32,690 --> 00:49:33,700
Jeg mener ikke at holde skubber dig væk.

1028
00:49:33,700 --> 00:49:36,030
Men billedet er meget
hurtigt vil få stressende.

1029
00:49:36,030 --> 00:49:38,620
Fordi du har brug for at starte
har to af alting.

1030
00:49:38,620 --> 00:49:41,850
Faktisk, hvis du nogensinde har set
film Kontakt et par år siden

1031
00:49:41,850 --> 00:49:45,310
med Jodie Foster-- nej?

1032
00:49:45,310 --> 00:49:47,410
>> OK, så for de to af
os, der har set Kontakt,

1033
00:49:47,410 --> 00:49:50,800
der er en sammenhæng der, hvor de
væsentlige købt to af noget

1034
00:49:50,800 --> 00:49:53,250
snarere end en, om end
til to gange prisen.

1035
00:49:53,250 --> 00:49:55,922
Så det var en slags legende
kommentere på filmen.

1036
00:49:55,922 --> 00:49:57,130
Det er lidt relateret til dette.

1037
00:49:57,130 --> 00:49:58,290
Vi kunne absolut gøre det.

1038
00:49:58,290 --> 00:50:00,123
Og du har bare koste
os dobbelt så mange penge.

1039
00:50:00,123 --> 00:50:01,300
Men vi vil vende tilbage til.

1040
00:50:01,300 --> 00:50:02,400
>> Så vi har løst dette.

1041
00:50:02,400 --> 00:50:03,108
Så ved du hvad?

1042
00:50:03,108 --> 00:50:04,450
Det er ligesom en glidebane.

1043
00:50:04,450 --> 00:50:07,033
Jeg ønsker ikke at beskæftige sig med at have
at have en kopi database.

1044
00:50:07,033 --> 00:50:08,037
Det er for mange penge.

1045
00:50:08,037 --> 00:50:08,620
Du ved hvad?

1046
00:50:08,620 --> 00:50:12,880
Jeg vil gerne have min database
ligesom i version én

1047
00:50:12,880 --> 00:50:17,450
hvor hver server har
sin egen lokale database.

1048
00:50:17,450 --> 00:50:19,480
Så jeg vil blot
trækker db på hver af disse.

1049
00:50:19,480 --> 00:50:22,240
>> Så nu hver webserver
er identisk i det omfang

1050
00:50:22,240 --> 00:50:25,650
da det har den samme kode, den samme
statiske aktiver, samme billeder og tekst

1051
00:50:25,650 --> 00:50:26,720
og så videre.

1052
00:50:26,720 --> 00:50:29,580
Og hver har sin egen database.

1053
00:50:29,580 --> 00:50:31,450
Jeg fast enkelt punkt
af svigt problem.

1054
00:50:31,450 --> 00:50:32,570
Nu har jeg en database.

1055
00:50:32,570 --> 00:50:36,210
Ligegyldigt hvor to eller en af ​​disse
ting dør, er der altid én venstre.

1056
00:50:36,210 --> 00:50:41,156
Men hvad nyt problem har jeg oprettet
at Dan løsning undgås?

1057
00:50:41,156 --> 00:50:42,470
>> PUBLIKUM: [uhørligt]

1058
00:50:42,470 --> 00:50:44,386
>> DAVID MALAN: Ja, jeg
nødt til at synkronisere dem, ikke?

1059
00:50:44,386 --> 00:50:47,860
Fordi enten jeg har brug for at synkronisere
hvem kommer where-- med andre ord,

1060
00:50:47,860 --> 00:50:50,570
hvis Alice besøger min
site, der skete, og hun

1061
00:50:50,570 --> 00:50:55,070
at komme tilfældigt eller rund robined
eller hvad, til server nummer et,

1062
00:50:55,070 --> 00:50:58,770
derefter jeg altid
sende hende til server 1.

1063
00:50:58,770 --> 00:50:59,420
Hvorfor?

1064
00:50:59,420 --> 00:51:01,540
Fordi hvis jeg sender hende
til server 2, går det

1065
00:51:01,540 --> 00:51:03,140
at ligne hun ikke eksisterer der.

1066
00:51:03,140 --> 00:51:04,450
>> Jeg har ikke tænkt mig at have hende ordre historie.

1067
00:51:04,450 --> 00:51:06,300
Jeg har ikke tænkt mig at have hende profil der.

1068
00:51:06,300 --> 00:51:09,360
Og der bare føles
det er indbydende problemer.

1069
00:51:09,360 --> 00:51:11,400
Og når Bob besøger, jeg
nødt til at sende ham altid

1070
00:51:11,400 --> 00:51:14,800
til den samme server, 2 eller alt efter
en, og Charlie til en tredje én,

1071
00:51:14,800 --> 00:51:15,797
og konsekvent.

1072
00:51:15,797 --> 00:51:17,130
Dette er ikke urimeligt, selv om.

1073
00:51:17,130 --> 00:51:19,270
Dette kaldes
partitionering din database.

1074
00:51:19,270 --> 00:51:21,270
Og i virkeligheden var dette hvad
Facebook gjorde tidligt.

1075
00:51:21,270 --> 00:51:24,020
>> Hvis du har fulgt historien om
Facebook, det startede her på campus

1076
00:51:24,020 --> 00:51:25,770
som www.thefacebook.com.

1077
00:51:25,770 --> 00:51:29,260
Så det udviklet sig engang Mark startede
breder sig til andre campusser

1078
00:51:29,260 --> 00:51:34,450
at være harvard.thefacebook.com og
mit.thefacebook.com, og sandsynligvis

1079
00:51:34,450 --> 00:51:37,027
bu.thefacebook.com og lignende.

1080
00:51:37,027 --> 00:51:38,860
Og det var fordi
tidligt, tror jeg ikke

1081
00:51:38,860 --> 00:51:40,484
du kunne have venner på tværs campusser.

1082
00:51:40,484 --> 00:51:41,410
Men det er fint.

1083
00:51:41,410 --> 00:51:43,930
Fordi nogen fra Harvard
fik sendt til denne server.

1084
00:51:43,930 --> 00:51:45,744
Nogen fra BU fik sendt til denne server.

1085
00:51:45,744 --> 00:51:47,910
Nogen fra MIT blev smidt
til denne server-- i teorien.

1086
00:51:47,910 --> 00:51:50,540
Jeg ved ikke helt, alle de
underliggende implementeringsdetaljer.

1087
00:51:50,540 --> 00:51:55,610
Men han formentlig partitioneret folk ved
deres campus, hvor deres netværk var.

1088
00:51:55,610 --> 00:51:58,772
>> Så det er godt indtil det punkt
hvor du har brug for to servere til Harvard,

1089
00:51:58,772 --> 00:51:59,980
eller tre servere til Harvard.

1090
00:51:59,980 --> 00:52:01,800
Og så er enkelhed
slags bryder ned.

1091
00:52:01,800 --> 00:52:03,174
Men det er en rimelig fremgangsmåde.

1092
00:52:03,174 --> 00:52:04,950
Lad os altid sende Alice
til det samme sted,

1093
00:52:04,950 --> 00:52:06,366
altid sende Bob til det samme sted.

1094
00:52:06,366 --> 00:52:09,680
Men hvad sker der, hvis Alices
server går offline?

1095
00:52:09,680 --> 00:52:12,300
Bob og Charlie kan stadig købe
ting og logge ind på webstedet.

1096
00:52:12,300 --> 00:52:13,462
Men Alice kan ikke.

1097
00:52:13,462 --> 00:52:15,170
Så du har mistet en tredjedel
af din brugerbase.

1098
00:52:15,170 --> 00:52:16,980
Måske det er bedre end 100%?

1099
00:52:16,980 --> 00:52:20,580
Men måske det ville være rart, hvis vi kunne
støtter stadig 100% af vores brugere

1100
00:52:20,580 --> 00:52:23,470
selv når en tredjedel af vores
servere går offline.

1101
00:52:23,470 --> 00:52:24,760
>> Så vi kunne synkronisere hvad?

1102
00:52:24,760 --> 00:52:29,250
Ikke brugerne, per se, men den
database på tværs af alle disse servere.

1103
00:52:29,250 --> 00:52:33,350
Så nu vi slags brug for nogle
form for sammenkobling

1104
00:52:33,350 --> 00:52:37,880
her, så selve serverne
kan sync-- ikke urimeligt.

1105
00:52:37,880 --> 00:52:40,090
Og i virkeligheden findes denne teknologi.

1106
00:52:40,090 --> 00:52:45,550
I en verden af ​​databaser, der er
begrebet master-slave-databaser,

1107
00:52:45,550 --> 00:52:48,240
eller primær-sekundær,
hvor blandt funktionerne

1108
00:52:48,240 --> 00:52:51,050
er ikke kun at lagre data
og svare med data,

1109
00:52:51,050 --> 00:52:53,375
men også bare til konstant
synkronisere med hinanden.

1110
00:52:53,375 --> 00:52:56,480
Så hver gang du skriver eller gemme
noget til denne database,

1111
00:52:56,480 --> 00:53:00,040
det straks bliver "replikeret"
til de andre databaser samt.

1112
00:53:00,040 --> 00:53:02,870
>> Og helst du læse fra den,
det er ligegyldigt hvor du er.

1113
00:53:02,870 --> 00:53:05,170
For hvis i teorien
de har alle synkroniseret, er du

1114
00:53:05,170 --> 00:53:07,710
vil få den samme visning af data.

1115
00:53:07,710 --> 00:53:10,800
Så det lyder perfekt.

1116
00:53:10,800 --> 00:53:11,883
Der er nødt til at være en fangst.

1117
00:53:11,883 --> 00:53:15,200

1118
00:53:15,200 --> 00:53:18,990
Hvad kan fangsten være?

1119
00:53:18,990 --> 00:53:21,790
>> PUBLIKUM: [uhørligt]

1120
00:53:21,790 --> 00:53:25,830
>> DAVID Malan: Ja, så tre gange
så meget ting kunne gå galt.

1121
00:53:25,830 --> 00:53:26,930
Det er en realitet.

1122
00:53:26,930 --> 00:53:28,480
Det kan alle være den samme i ånden.

1123
00:53:28,480 --> 00:53:30,404
Men nogen har brug for at konfigurere disse.

1124
00:53:30,404 --> 00:53:33,070
Der er en højere sandsynlighed for, at
noget kommer til at gå galt.

1125
00:53:33,070 --> 00:53:38,130
Bare kombinatorisk du har
flere ting udsat for fejl.

1126
00:53:38,130 --> 00:53:40,505
Hvad er dårlig potentielt?

1127
00:53:40,505 --> 00:53:41,380
PUBLIKUM: [uhørligt]

1128
00:53:41,380 --> 00:53:44,100

1129
00:53:44,100 --> 00:53:46,180
>> DAVID MALAN: Ja, så
synkronisering kan være dårligt.

1130
00:53:46,180 --> 00:53:48,110
Selv som du måske ved
fra sikkerhedskopier og sådan,

1131
00:53:48,110 --> 00:53:50,520
hvis du bare blindt gør
backups, hvad nu hvis noget gør

1132
00:53:50,520 --> 00:53:51,560
gå galt på én database?

1133
00:53:51,560 --> 00:53:53,018
Du sletter noget, du ikke bør.

1134
00:53:53,018 --> 00:53:56,299
Du har straks gentaget
dette problem alle andre steder.

1135
00:53:56,299 --> 00:53:58,840
Så Victoria var talking-- backups
ville være en god ting her.

1136
00:53:58,840 --> 00:54:00,549
Og så vender vi tilbage til.

1137
00:54:00,549 --> 00:54:03,090
Og for at være klar, vi taler
ikke om sikkerhedskopier her sig selv.

1138
00:54:03,090 --> 00:54:08,240
Vi taler om sand replikation
eller synkronisering tværs servere.

1139
00:54:08,240 --> 00:54:09,110
De er alle levende.

1140
00:54:09,110 --> 00:54:12,074
De er ikke beregnet til at
bruges til sikkerhedskopiering.

1141
00:54:12,074 --> 00:54:13,294
>> PUBLIKUM: [uhørligt]

1142
00:54:13,294 --> 00:54:14,335
DAVID MALAN: Hvad er det?

1143
00:54:14,335 --> 00:54:14,710
PUBLIKUM: Higher--

1144
00:54:14,710 --> 00:54:15,751
DAVID MALAN: Højere omkostninger.

1145
00:54:15,751 --> 00:54:20,180
Vi har tredoblet prisen for
sikker, selv om det mindste hvad angår

1146
00:54:20,180 --> 00:54:21,100
af hardwaren.

1147
00:54:21,100 --> 00:54:23,200
Fordi en database er
blot et stykke software.

1148
00:54:23,200 --> 00:54:25,189
Og en web-server er et stykke software.

1149
00:54:25,189 --> 00:54:27,980
Det er nok gratis, hvis vi bruger
vilkårligt antal open source ting.

1150
00:54:27,980 --> 00:54:30,480
Men hvis vi bruger
noget som Oracle,

1151
00:54:30,480 --> 00:54:36,574
vi betaler Oracle flere penge per
licenser eller Microsoft for adgang.

1152
00:54:36,574 --> 00:54:38,240
Der må være en anden fangst her.

1153
00:54:38,240 --> 00:54:39,240
Det kan ikke være denne enkle.

1154
00:54:39,240 --> 00:54:42,990

1155
00:54:42,990 --> 00:54:47,300
>> Så for at din pointe, jeg tror, ​​det var
Kareem, til geografi earlier-- eller nej,

1156
00:54:47,300 --> 00:54:50,870
Roman, var det, for geography-- antage
at vi være smart om dette,

1157
00:54:50,870 --> 00:54:54,080
og vi sætter en af ​​vores servere,
og til gengæld vores databaser, i USA,

1158
00:54:54,080 --> 00:54:56,910
og en anden i Europa, en anden i
Sydamerika, en anden i Afrika,

1159
00:54:56,910 --> 00:55:00,290
en anden i Asien, hvor som helst vi
måske ønsker hele verden.

1160
00:55:00,290 --> 00:55:04,220
Vi ved allerede, fra vores spor
ruter, punkt A og punkt

1161
00:55:04,220 --> 00:55:06,910
B, hvis de er længere fra hinanden,
kommer til at tage længere tid.

1162
00:55:06,910 --> 00:55:10,312
>> Og hvis nogle af jer har brugt
værktøjer, som Facebook eller Twitter

1163
00:55:10,312 --> 00:55:13,520
eller nogen af ​​disse websteder disse dage, at
er under konstant forandring på grund af brugerens

1164
00:55:13,520 --> 00:55:16,880
oprettede data, nogle gange, hvis du
hit Genindlæs eller åbne den samme side

1165
00:55:16,880 --> 00:55:20,270
i en anden browser, kan du se
forskellige versioner, næsten.

1166
00:55:20,270 --> 00:55:22,875
Du kan se en persons status
opdatere her, men ikke her,

1167
00:55:22,875 --> 00:55:25,500
og så skal du genindlæse, og så er det
vises, og du genindlæse igen,

1168
00:55:25,500 --> 00:55:26,640
og det forsvinder.

1169
00:55:26,640 --> 00:55:29,076
Med andre ord, holde
øje med dette, i det mindste

1170
00:55:29,076 --> 00:55:30,950
hvis du bruger sociale
netværkssamarbejde især.

1171
00:55:30,950 --> 00:55:33,320
>> Igen, bare fordi
data ændrer sig så hurtigt,

1172
00:55:33,320 --> 00:55:35,710
nogle gange servere får ud af sync.

1173
00:55:35,710 --> 00:55:37,230
Og måske er det en super lille vindue.

1174
00:55:37,230 --> 00:55:39,970
Men 200 millisekunder, måske
endnu mere end at-- det er

1175
00:55:39,970 --> 00:55:43,415
kommer til at tage nogle ikke-nul beløb
af tid for disse databaser til synkronisering.

1176
00:55:43,415 --> 00:55:45,290
Og vi er ikke bare
taler om en anmodning.

1177
00:55:45,290 --> 00:55:48,540
Hvis en virksomhed har tusindvis af
brugere bruger det samtidigt,

1178
00:55:48,540 --> 00:55:49,460
de kunne buffer.

1179
00:55:49,460 --> 00:55:52,240
Med andre ord, kan der
være en kø eller en vente linje

1180
00:55:52,240 --> 00:55:54,950
før alle disse database
forespørgsler kan få synkroniseret.

1181
00:55:54,950 --> 00:55:56,610
Så måske er det faktisk et par sekunder.

1182
00:55:56,610 --> 00:55:59,820
>> Og ja det er sandt, jeg tror endda
til denne dag med Facebook, hvorved

1183
00:55:59,820 --> 00:56:02,010
når de synkroniserer fra
Østkysten til vestkysten,

1184
00:56:02,010 --> 00:56:06,026
den har en ikke-triviel
formering forsinkelse, så at sige,

1185
00:56:06,026 --> 00:56:07,650
at du lige slags nødt til at tolerere.

1186
00:56:07,650 --> 00:56:11,210
Og så er det ikke så meget
en fejl, som det er en realitet

1187
00:56:11,210 --> 00:56:14,230
at dine brugere ikke kan se
de korrekte data i mindst

1188
00:56:14,230 --> 00:56:14,970
et par sekunder.

1189
00:56:14,970 --> 00:56:17,410
>> Jeg ser dette på Twitter en masse
faktisk, hvor nogle gange jeg vil

1190
00:56:17,410 --> 00:56:21,227
tweet i et vindue, åbne et andet til
så se det for at bekræfte, at det faktisk

1191
00:56:21,227 --> 00:56:22,560
gik op, og det er ikke der endnu.

1192
00:56:22,560 --> 00:56:25,340
Og jeg er nødt til at slags genindlæse,
genindlæse, reload-- Åh, der er det.

1193
00:56:25,340 --> 00:56:27,150
Og det er ikke fordi det ikke blev gemt.

1194
00:56:27,150 --> 00:56:29,850
Det er netop ikke formeret
til andre servere.

1195
00:56:29,850 --> 00:56:33,120
>> Så denne afvejning, too-- gør du virkelig
ønsker at udsætte dig selv for risikoen

1196
00:56:33,120 --> 00:56:37,254
at hvis brugeren går til deres rækkefølge
historie, er det faktisk ikke der endnu?

1197
00:56:37,254 --> 00:56:38,420
Jeg ser dette på visse banker.

1198
00:56:38,420 --> 00:56:42,100
Det altid irriterer mig, når, godt, for en,
du kan kun gå ligesom seks måneder tilbage

1199
00:56:42,100 --> 00:56:45,160
i dine kontoudtog i nogle banker,
selv om de i teorien burde

1200
00:56:45,160 --> 00:56:46,576
kunne have alt online.

1201
00:56:46,576 --> 00:56:48,630
De bare tage ting offline tider.

1202
00:56:48,630 --> 00:56:51,430
Nogle gange, too-- hvad hjemmeside er det?

1203
00:56:51,430 --> 00:56:53,570
Der er en-- åh, det er GoDaddy, tror jeg.

1204
00:56:53,570 --> 00:56:56,620
GoDaddy, når du tjekker
købe et domænenavn eller noget,

1205
00:56:56,620 --> 00:56:58,630
de vil ofte give dig
et link til din kvittering.

1206
00:56:58,630 --> 00:57:01,470
Og hvis du klikker dette link til højre
væk, er det ofte ikke virker.

1207
00:57:01,470 --> 00:57:03,290
Det bare siger, blindgyde, ikke noget her.

1208
00:57:03,290 --> 00:57:05,450
>> Og det er også på grund af
disse udbredelsesforsinkelser.

1209
00:57:05,450 --> 00:57:08,290
Fordi uanset årsagen, de
tager en lille smule tid

1210
00:57:08,290 --> 00:57:09,670
til rent faktisk at generere det.

1211
00:57:09,670 --> 00:57:12,070
Så dette er lidt ligesom du vil
trække dit hår ud på et tidspunkt.

1212
00:57:12,070 --> 00:57:14,486
Fordi alt du forsøger at
gøre, er at løse et simpelt problem.

1213
00:57:14,486 --> 00:57:16,590
Og vi holde skabe nye
problemer for os selv.

1214
00:57:16,590 --> 00:57:18,770
Så lad os se om vi
kan slags fortryde dette.

1215
00:57:18,770 --> 00:57:22,730
>> Det viser sig at kombinere
databaser på alle dine web-servere

1216
00:57:22,730 --> 00:57:25,090
er egentlig ikke den bedste praksis.

1217
00:57:25,090 --> 00:57:27,950
Generelt hvad en ingeniør
ville gøre, eller systemer arkitekt,

1218
00:57:27,950 --> 00:57:30,340
ville være at have forskellige
niveauer af servere.

1219
00:57:30,340 --> 00:57:33,160
Og bare for plads skyld, vil jeg
trække deres database op her.

1220
00:57:33,160 --> 00:57:38,060
>> Vi kunne have database og
server nummer fire her

1221
00:57:38,060 --> 00:57:42,430
der gør har forbindelser til
hver af disse servere her.

1222
00:57:42,430 --> 00:57:45,400
Så det kunne være vores forside
ende tier, som folk ville sige.

1223
00:57:45,400 --> 00:57:47,770
Og det ville være vores back-end tier.

1224
00:57:47,770 --> 00:57:50,580
Og det betyder blot, at
disse står brugeren.

1225
00:57:50,580 --> 00:57:53,010
Og databaserne ikke står brugeren.

1226
00:57:53,010 --> 00:57:55,480
Ingen bruger kan direkte
adgang til databasen.

1227
00:57:55,480 --> 00:57:59,280
>> Så lad os nu måske gå ned
ruten Victoria foreslået.

1228
00:57:59,280 --> 00:58:00,940
Dette er et single point of failure.

1229
00:58:00,940 --> 00:58:02,290
Det gør mig utilpas.

1230
00:58:02,290 --> 00:58:05,790
Så hvad er der måske
mest oplagte løsning?

1231
00:58:05,790 --> 00:58:06,665
PUBLIKUM: [uhørligt]

1232
00:58:06,665 --> 00:58:09,979

1233
00:58:09,979 --> 00:58:11,437
DAVID MALAN: Beklager, sige det igen.

1234
00:58:11,437 --> 00:58:12,352
PUBLIKUM: [uhørligt]

1235
00:58:12,352 --> 00:58:13,810
DAVID MALAN: Non-produktion server.

1236
00:58:13,810 --> 00:58:15,364
Hvad mener du?

1237
00:58:15,364 --> 00:58:17,120
>> PUBLIKUM: [uhørligt]

1238
00:58:17,120 --> 00:58:19,120
>> DAVID MALAN: Åh, OK, så backups.

1239
00:58:19,120 --> 00:58:21,110
OK, så vi kunne gøre det, helt sikkert.

1240
00:58:21,110 --> 00:58:23,790
Og faktisk det er meget almindeligt gjort.

1241
00:58:23,790 --> 00:58:26,470
Dette kan være database nummer fem.

1242
00:58:26,470 --> 00:58:28,510
Men det er kun
forbundet til nummer fire.

1243
00:58:28,510 --> 00:58:31,110
Og man kan kalde det en hot spare.

1244
00:58:31,110 --> 00:58:35,080
Disse to databaser kunne konfigureres
til bare konstant synkronisere

1245
00:58:35,080 --> 00:58:35,850
hinanden.

1246
00:58:35,850 --> 00:58:39,010
Og så hvis denne maskine dør, for
uanset dum reason-- harddisken

1247
00:58:39,010 --> 00:58:42,100
dør, nogen snubler lidt den
snor, noget software er fejlbehæftet

1248
00:58:42,100 --> 00:58:46,560
og maskinen hænger eller crashes--
du kunne have en menneskelig bogstaveligt

1249
00:58:46,560 --> 00:58:51,090
tag denne ene fra væggen
og i stedet sætte denne ene i.

1250
00:58:51,090 --> 00:58:56,340
Og så inden for, lad os sige, en
par minutter, måske en halv time,

1251
00:58:56,340 --> 00:58:57,210
du er online igen.

1252
00:58:57,210 --> 00:58:59,259
>> Det er ikke stor, men
det er heller ikke forfærdeligt.

1253
00:58:59,259 --> 00:59:01,800
Og du behøver ikke at bekymre sig
om eventuelle synkroniseringsproblemer.

1254
00:59:01,800 --> 00:59:03,080
Fordi alt er der allerede.

1255
00:59:03,080 --> 00:59:05,000
Fordi du havde en perfekt
backup klar til at gå.

1256
00:59:05,000 --> 00:59:07,100
>> Du kunne være lidt
amatør om dette,

1257
00:59:07,100 --> 00:59:12,990
som nogle mennesker ofte gør, hvor man
kunne have database nummer fire her,

1258
00:59:12,990 --> 00:59:17,480
database nummer fem her,
der taler med hinanden.

1259
00:59:17,480 --> 00:59:24,120
Men du har også denne
slags arrangement--

1260
00:59:24,120 --> 00:59:27,440
og det bevidst
ser rodet, fordi det

1261
00:59:27,440 --> 00:59:30,220
is-- hvor alle
frontend servere kan

1262
00:59:30,220 --> 00:59:32,870
tale med alle de back end-servere.

1263
00:59:32,870 --> 00:59:38,130
Og så hvis denne database ikke
reagere, disse frontend servere har

1264
00:59:38,130 --> 00:59:40,212
at have programmering
kode i dem, der siger,

1265
00:59:40,212 --> 00:59:42,170
hvis du ikke får en
forbindelse til denne database,

1266
00:59:42,170 --> 00:59:45,830
den primære starter straks
taler med den sekundære.

1267
00:59:45,830 --> 00:59:48,310
>> Men det nu skubber
kompleksitet til koden.

1268
00:59:48,310 --> 00:59:52,070
Og nu dine udviklere, din software
udviklere, nødt til at vide om dette.

1269
00:59:52,070 --> 00:59:56,454
Og du slags binde den kode,
du skriver til din faktiske bagenden

1270
00:59:56,454 --> 00:59:58,370
gennemførelsen detaljer,
hvilket gør det sværere,

1271
00:59:58,370 --> 01:00:00,670
især i en større
selskab eller en større hjemmeside,

1272
01:00:00,670 --> 01:00:05,020
hvor du ikke nødvendigvis
ønsker programmører at have

1273
01:00:05,020 --> 01:00:10,890
at vide, hvordan databasen
ingeniører gør deres job.

1274
01:00:10,890 --> 01:00:13,810
Du vil måske beholde disse roller
slags funktionelt distinkt så

1275
01:00:13,810 --> 01:00:16,810
at der er dette lag af
abstraktion mellem de to.

1276
01:00:16,810 --> 01:00:17,940
>> Så hvordan kan vi løse dette?

1277
01:00:17,940 --> 01:00:20,290
Nå, vi slags løst
dette problem en gang før.

1278
01:00:20,290 --> 01:00:25,680
Hvorfor vi ikke sætte en af
disse ting her, hvor

1279
01:00:25,680 --> 01:00:30,947
den taler til gengæld til nummer fire og
fem, alle af forenden webservere

1280
01:00:30,947 --> 01:00:33,780
tale med denne mellemmand, og
mellemmand til gengæld ruter deres data?

1281
01:00:33,780 --> 01:00:38,494
Faktisk hvad der kunne være en
godt navn for denne ting?

1282
01:00:38,494 --> 01:00:39,704
>> PUBLIKUM: [uhørligt]

1283
01:00:39,704 --> 01:00:41,120
DAVID MALAN: OK, database manager.

1284
01:00:41,120 --> 01:00:48,030
Men hvad kunne et begreb, at
vi kunne genbruge til denne enhed?

1285
01:00:48,030 --> 01:00:49,760
Vi balancering.

1286
01:00:49,760 --> 01:00:52,480
Ja, så faktisk er jeg
ikke være fair her.

1287
01:00:52,480 --> 01:00:56,760
Så en load balancer ville indebære, at
vi skifte frem og tilbage her,

1288
01:00:56,760 --> 01:00:58,836
der behøver faktisk ikke være tilfældet.

1289
01:00:58,836 --> 01:01:00,460
Så der er et par måder, vi kunne gøre dette.

1290
01:01:00,460 --> 01:01:03,920
>> Hvis dette er i virkeligheden en load balancer, den
historie er nøjagtig den samme som før.

1291
01:01:03,920 --> 01:01:05,230
Nogle af anmodningerne går til fire.

1292
01:01:05,230 --> 01:01:06,150
Nogle af dem gå til 5.

1293
01:01:06,150 --> 01:01:06,710
Og det er godt.

1294
01:01:06,710 --> 01:01:08,835
Fordi nu kan vi håndtere
dobbelt så meget gennemløb.

1295
01:01:08,835 --> 01:01:11,120
Men denne forbindelse
her er super vigtigt.

1296
01:01:11,120 --> 01:01:14,050
De skal forblive konstant
synkroniseret og forhåbentlig

1297
01:01:14,050 --> 01:01:17,670
er ikke geografisk for langt fra hinanden, så
at synkroniseringen er væsentlige

1298
01:01:17,670 --> 01:01:18,520
øjeblikkelig.

1299
01:01:18,520 --> 01:01:20,410
Ellers kan vi har et problem.

1300
01:01:20,410 --> 01:01:21,330
>> Så det er ikke dårligt.

1301
01:01:21,330 --> 01:01:25,132
Men igen, vi har
indført et nyt problem.

1302
01:01:25,132 --> 01:01:26,590
Hvilket problem har jeg lige genskabt?

1303
01:01:26,590 --> 01:01:30,000

1304
01:01:30,000 --> 01:01:31,020
Single point of failure.

1305
01:01:31,020 --> 01:01:32,390
Så hvad er løsningen på dette?

1306
01:01:32,390 --> 01:01:39,270
Så som Victorias fond til at bruge penge,
vi kan tage denne fyr ud og gøre dette.

1307
01:01:39,270 --> 01:01:41,731
Og jeg bare til
flytte her plads nok.

1308
01:01:41,731 --> 01:01:43,230
Og det kommer til at være lidt rodet.

1309
01:01:43,230 --> 01:01:44,563
Jeg har tænkt mig at holde tegning linjer.

1310
01:01:44,563 --> 01:01:47,080
Antag, at alle
disse linjer går ind i både?

1311
01:01:47,080 --> 01:01:52,670
>> En meget almindelig teknik her ville være
at bruge en teknik kaldet hjerteslag

1312
01:01:52,670 --> 01:01:57,390
hvorved hver af disse enheder,
venstre og højre load balancers,

1313
01:01:57,390 --> 01:02:00,740
eller hvad vi vil kalde dem,
konstant siger, jeg er i live,

1314
01:02:00,740 --> 01:02:03,220
Jeg er i live, jeg er i live, jeg er i live.

1315
01:02:03,220 --> 01:02:05,910
En af dem som standard
fungerer som den primære.

1316
01:02:05,910 --> 01:02:09,620
Så al trafik bliver ført gennem
den ene til venstre, for eksempel,

1317
01:02:09,620 --> 01:02:11,260
som standard, vilkårligt.

1318
01:02:11,260 --> 01:02:16,890
>> Men så snart fyr på højre
ikke hører fra venstre fyr længere,

1319
01:02:16,890 --> 01:02:20,440
den ene til højre er programmeret
til automatisk, for eksempel,

1320
01:02:20,440 --> 01:02:24,110
overtage IP-adressen
den ene til venstre,

1321
01:02:24,110 --> 01:02:28,240
og derfor bliver den primære, og
måske sende en e-mail eller en tekstbesked

1322
01:02:28,240 --> 01:02:31,570
til de mennesker til at sige, hey,
venstre primære er offline.

1323
01:02:31,570 --> 01:02:33,310
Jeg vil blive den primære for nu.

1324
01:02:33,310 --> 01:02:35,760
Så vicepræsident bliver
præsident, så at sige.

1325
01:02:35,760 --> 01:02:38,180
Og nogen skal gå redde
præsidenten, hvis du ønsker.

1326
01:02:38,180 --> 01:02:41,090
Fordi nu har vi en midlertidig
single point of failure.

1327
01:02:41,090 --> 01:02:45,020
>> Så som kompliceret eller stressende som
dette kan synes at begynde at være,

1328
01:02:45,020 --> 01:02:46,990
dette er, hvordan du løser disse problemer.

1329
01:02:46,990 --> 01:02:48,190
Du gør smide penge på det.

1330
01:02:48,190 --> 01:02:49,370
Du smider hardware på det.

1331
01:02:49,370 --> 01:02:52,170
Men desværre du
tilføje kompleksitet for det.

1332
01:02:52,170 --> 01:02:56,450
Men resultatet i sidste ende er, at
du har en langt mere, i teorien,

1333
01:02:56,450 --> 01:02:57,670
robust arkitektur.

1334
01:02:57,670 --> 01:02:58,850
Det er stadig ikke perfekt.

1335
01:02:58,850 --> 01:03:02,470
For selv når vi have-- vi måske
ikke har et single point of failure.

1336
01:03:02,470 --> 01:03:05,240
Vi har nu dobbelt fejlkilder.

1337
01:03:05,240 --> 01:03:07,630
Men hvis to ting går galt,
som absolut kunne,

1338
01:03:07,630 --> 01:03:09,030
vi stadig kommer til at være offline.

1339
01:03:09,030 --> 01:03:11,660
>> Og så meget almindelig i
industrien er at beskrive

1340
01:03:11,660 --> 01:03:14,000
din up tid i form af niere.

1341
01:03:14,000 --> 01:03:18,610
Og slags målet
at stræbe efter at er 99,999%

1342
01:03:18,610 --> 01:03:21,580
af tiden dit websted er online.

1343
01:03:21,580 --> 01:03:24,170
Eller endnu bedre, tilføje en
nogle flere niere til det.

1344
01:03:24,170 --> 01:03:28,159
Desværre er disse
niere er meget dyre.

1345
01:03:28,159 --> 01:03:29,450
Og lad os rent faktisk gør det ud.

1346
01:03:29,450 --> 01:03:35,510
Så hvis jeg åbner min store lommeregner igen,
365 dage i et år, 24 timer på en dag,

1347
01:03:35,510 --> 01:03:44,780
60 minutter i en time, og
60 sekunder i et minut,

1348
01:03:44,780 --> 01:03:48,690
det er, hvor mange sekunder der er
i et år, hvis jeg gjorde det korrekt.

1349
01:03:48,690 --> 01:03:55,740
Så hvis vi gange dette ved 0,99999, det er
hvor meget tid, vi ønsker at stræbe efter.

1350
01:03:55,740 --> 01:04:00,600
Så det betyder, at vi bør være op
dette mange sekunder i løbet af året.

1351
01:04:00,600 --> 01:04:03,920
Så hvis jeg nu trække
oprindelige værdi, eller rettere

1352
01:04:03,920 --> 01:04:07,480
denne nye værdi fra
first-- 316 sekunder,

1353
01:04:07,480 --> 01:04:09,640
hvilket naturligvis er fem minutter.

1354
01:04:09,640 --> 01:04:13,770
>> Så hvis dit websted eller din virksomhed er
hævder "fem niere", hvor du er

1355
01:04:13,770 --> 01:04:17,050
op 99,99% af tiden,
det betyder at du bedre

1356
01:04:17,050 --> 01:04:23,470
har været smart nok og hurtig
nok og skyl nok med ressourcer

1357
01:04:23,470 --> 01:04:27,890
at dine servere er kun offline
fem minutter ud af året.

1358
01:04:27,890 --> 01:04:29,980
Det er et dyrt og
hård ting at stræbe efter.

1359
01:04:29,980 --> 01:04:31,430
>> Så det er en afvejning, også.

1360
01:04:31,430 --> 01:04:35,866
99,999% af tiden er temmelig
darn hårdt og dyrt.

1361
01:04:35,866 --> 01:04:38,740
Fem minutes-- du næsten ikke kan få
til serveren til fysisk at erstatte

1362
01:04:38,740 --> 01:04:40,040
noget, der er gået galt.

1363
01:04:40,040 --> 01:04:42,810
Og det er derfor, vi begynder ledninger
ting sammen mere komplicerede

1364
01:04:42,810 --> 01:04:48,240
Apriori således, at computerne
kan slags reparere sig selv.

1365
01:04:48,240 --> 01:04:49,446
Ja.

1366
01:04:49,446 --> 01:04:52,344
>> PUBLIKUM: [uhørligt]

1367
01:04:52,344 --> 01:05:02,014

1368
01:05:02,014 --> 01:05:04,430
DAVID MALAN: Problemet kunne
være i flere afdelinger.

1369
01:05:04,430 --> 01:05:05,090
Og i fact--

1370
01:05:05,090 --> 01:05:07,101
>> PUBLIKUM: [uhørligt]

1371
01:05:07,101 --> 01:05:08,600
DAVID MALAN: Absolut, absolut.

1372
01:05:08,600 --> 01:05:10,720
Og som billedet er
bliver mere kompliceret,

1373
01:05:10,720 --> 01:05:12,110
det kunne være webservere.

1374
01:05:12,110 --> 01:05:14,690
Det kunne være strømmen til bygningen.

1375
01:05:14,690 --> 01:05:17,900
Det kunne være noget fysisk, ligesom
kablerne fik flosset eller smidt ud.

1376
01:05:17,900 --> 01:05:19,879
Det kunne være databasen
svarer ikke.

1377
01:05:19,879 --> 01:05:22,920
Det kunne de opdateret deres drift
systemet og noget hænger.

1378
01:05:22,920 --> 01:05:24,634
Så der er så mange andre bevægelige dele.

1379
01:05:24,634 --> 01:05:27,050
Og så en masse af den mekaniske
der har at gå bag dette

1380
01:05:27,050 --> 01:05:30,431
er egentlig bare handle offs, ligesom hvordan
meget tid, hvor mange penge er det faktisk

1381
01:05:30,431 --> 01:05:32,930
værd, og hvad er truslerne
du er virkelig bekymret?

1382
01:05:32,930 --> 01:05:35,471
For eksempel i
kurser, jeg underviser på Harvard,

1383
01:05:35,471 --> 01:05:38,470
vi bruger en masse af cloud computing, som
vi begynder at tage et kig på nu,

1384
01:05:38,470 --> 01:05:41,107
i virkeligheden, hvor vi bruger
Amazon Web Services.

1385
01:05:41,107 --> 01:05:42,940
Bare fordi det er den
en vi startede med.

1386
01:05:42,940 --> 01:05:45,856
Men der er stadig mere i disse dage
fra Google og Microsoft og andre.

1387
01:05:45,856 --> 01:05:50,030
Og vi bevidst vælger at sætte alle
af vores kurser 'virtuelle maskiner,

1388
01:05:50,030 --> 01:05:55,400
som de kaldes, i tror jeg
det er vestlige Virginia datacenter.

1389
01:05:55,400 --> 01:05:57,560
De fleste af vores elever
tilfældigvis fra USA,

1390
01:05:57,560 --> 01:05:59,820
selvom der er sikkert
nogle internationalt.

1391
01:05:59,820 --> 01:06:02,630
>> Men virkeligheden er det bare
enklere og det er billigere for os

1392
01:06:02,630 --> 01:06:05,540
at sætte alle vores æg
i Virginia kurven,

1393
01:06:05,540 --> 01:06:08,050
selvom jeg ved, hvis noget
går galt i Virginia,

1394
01:06:08,050 --> 01:06:12,760
som har lejlighedsvis happened-- ligesom
hvis der er en orkan eller nogle vejr

1395
01:06:12,760 --> 01:06:15,890
begivenhed som, at hvis der er nogle
elnet udstedelsen eller like-- alle

1396
01:06:15,890 --> 01:06:20,240
af vores kurser data kan gå offline
for nogle antal minutter eller timer

1397
01:06:20,240 --> 01:06:21,600
eller endnu længere.

1398
01:06:21,600 --> 01:06:24,020
>> Men mængden af ​​kompleksitet
der ville være påkrævet,

1399
01:06:24,020 --> 01:06:26,895
og mængden af ​​penge, der ville
være påkrævet, at betjene alt

1400
01:06:26,895 --> 01:06:31,420
parallelt i Europa eller i Californien
bare ikke giver så meget mening.

1401
01:06:31,420 --> 01:06:35,080
Så det er en rationel handel
off, men en smertefuld en

1402
01:06:35,080 --> 01:06:37,740
når du er faktisk
har denne nedetid.

1403
01:06:37,740 --> 01:06:41,830
>> Nå, lad os overgang lige nu til
nogle af cloud-baserede løsninger

1404
01:06:41,830 --> 01:06:43,320
til nogle af disse problemer.

1405
01:06:43,320 --> 01:06:45,040
Alt, hvad vi har været
diskuterer hidtil

1406
01:06:45,040 --> 01:06:47,527
er slags problemer, der har
været med os i nogen tid,

1407
01:06:47,527 --> 01:06:49,610
uanset om du har din egen
servere i din virksomhed,

1408
01:06:49,610 --> 01:06:52,740
uanset om du går til en co-location
placere ligesom et datacenter og dele

1409
01:06:52,740 --> 01:06:55,110
plads med en anden,
eller dag i skyen.

1410
01:06:55,110 --> 01:06:57,040
>> Og hvad er rart om
skyen er, at alle

1411
01:06:57,040 --> 01:06:59,540
af disse ting, jeg er
tegning som fysiske genstande

1412
01:06:59,540 --> 01:07:02,400
kan nu betragtes som
slags virtuelle objekter

1413
01:07:02,400 --> 01:07:04,659
i skyen, der er
simuleret med software.

1414
01:07:04,659 --> 01:07:07,700
Med andre ord, den computere i dag,
servere i dag, ligesom Dell billedet

1415
01:07:07,700 --> 01:07:11,720
Jeg viste tidligere, er så hurtigt, har
så meget RAM, så meget CPU, så meget disk

1416
01:07:11,720 --> 01:07:16,140
plads, som folk har skrevet
software til næsten partition

1417
01:07:16,140 --> 01:07:21,130
én server op i illusionen om det
være to servere, eller 200 servere, så

1418
01:07:21,130 --> 01:07:24,150
at hver af os kunder
har illusionen af ​​at have

1419
01:07:24,150 --> 01:07:29,110
ikke bare en konto på nogle web
vært, men vores egen maskine, at vi er

1420
01:07:29,110 --> 01:07:30,490
leje fra en anden.

1421
01:07:30,490 --> 01:07:34,140
>> Men det er en virtuel maskine i
idet den ene Dell server,

1422
01:07:34,140 --> 01:07:39,160
den igen kan blive delt op i
to eller 200 eller flere virtuelle maskiner,

1423
01:07:39,160 --> 01:07:43,770
som alle giver nogen administrativ
adgang, men på en måde, hvor ingen af ​​os

1424
01:07:43,770 --> 01:07:48,040
ved eller kan få adgang til andre virtuelle
maskiner på samme hardware.

1425
01:07:48,040 --> 01:07:53,430
Så for at male et billede i dagens lysbilleder,
Jeg har det skudt her fra en hjemmeside

1426
01:07:53,430 --> 01:07:54,160
kaldet Docker.

1427
01:07:54,160 --> 01:07:56,970
>> Så det er lidt mere
detaljer end vi faktisk har brug for.

1428
01:07:56,970 --> 01:07:59,830
Men hvis du ser dette som
din infrastructure--

1429
01:07:59,830 --> 01:08:02,910
så bare den hardware dine egne,
dine servere, stativerne, data

1430
01:08:02,910 --> 01:08:06,480
center, og alle at-- du ville
typisk kører en host operativsystemet.

1431
01:08:06,480 --> 01:08:08,275
Så noget like-- det kunne være Windows.

1432
01:08:08,275 --> 01:08:09,430
Det ville ikke være Mac OS.

1433
01:08:09,430 --> 01:08:11,430
Fordi det er ikke rigtig
virksomhed i disse dage.

1434
01:08:11,430 --> 01:08:15,670
Så det ville være Linux eller Solaris
eller Unix eller BSD eller FreeBSD

1435
01:08:15,670 --> 01:08:19,779
eller en række andre operativsystemer
der er enten gratis eller kommerciel.

1436
01:08:19,779 --> 01:08:22,120
>> Og så skal du køre en
program, særligt program,

1437
01:08:22,120 --> 01:08:26,479
kaldet en hypervisor, eller
virtuel maskine monitor, VMM.

1438
01:08:26,479 --> 01:08:31,649
Og disse er produkter, hvis du er
velkendt, ligesom VMware eller VirtualBox

1439
01:08:31,649 --> 01:08:34,080
eller Virtual PC eller andre.

1440
01:08:34,080 --> 01:08:38,430
Og hvad disse programmer gør er præcis
denne funktion jeg beskrev tidligere.

1441
01:08:38,430 --> 01:08:41,779
Det skaber en illusion
at en fysisk maskine

1442
01:08:41,779 --> 01:08:44,550
kan være flere virtuelle maskiner.

1443
01:08:44,550 --> 01:08:48,260
>> Og så disse farverige kasser op toppen er
maler et billede af følgende.

1444
01:08:48,260 --> 01:08:50,260
Denne hypervisor, dette
stykke software, kalder det

1445
01:08:50,260 --> 01:08:54,090
VMware, der kører på en anden
operativsystem, kalder det Linux,

1446
01:08:54,090 --> 01:08:56,910
er at skabe den illusion, at
denne fysiske computer er faktisk

1447
01:08:56,910 --> 01:09:00,149
en, to, tre virtuelle computere.

1448
01:09:00,149 --> 01:09:04,270
Så jeg har nu købt, som ejer af
denne hardware, én fysisk computer.

1449
01:09:04,270 --> 01:09:06,200
Og nu er jeg leje
det til tre kunder.

1450
01:09:06,200 --> 01:09:09,731
>> Og disse tre kunder tror
de har en dedikeret virtuel maskine.

1451
01:09:09,731 --> 01:09:10,939
Og det er ikke agn og switch.

1452
01:09:10,939 --> 01:09:13,750
Det er mere afsløring, der
du bruger en virtuel maskine.

1453
01:09:13,750 --> 01:09:17,589
Men teknologisk, vi alle
har fuld administrativ kontrol

1454
01:09:17,589 --> 01:09:19,880
over hver af disse gæst
operativsystemer, som kunne

1455
01:09:19,880 --> 01:09:21,370
være et vilkårligt antal operativsystemer.

1456
01:09:21,370 --> 01:09:23,029
>> Jeg kan installere noget jeg vil.

1457
01:09:23,029 --> 01:09:24,640
Jeg kan opgradere det, som jeg vil.

1458
01:09:24,640 --> 01:09:27,470
Og jeg behøver ikke engang at vide eller
bekymrer sig om andre driftsindtægter

1459
01:09:27,470 --> 01:09:29,678
på den pågældende computer,
de andre virtuelle maskiner,

1460
01:09:29,678 --> 01:09:35,290
medmindre ejeren af ​​alt dette grå
ting er at være lidt grådige

1461
01:09:35,290 --> 01:09:37,540
og overselling hans eller hendes ressourcer.

1462
01:09:37,540 --> 01:09:40,800
>> Så hvis du tager en
fysisk maskine og sælge det

1463
01:09:40,800 --> 01:09:44,399
til ikke 200 men 400
kunder, på et tidspunkt

1464
01:09:44,399 --> 01:09:47,270
vi kommer til at rejse ind i dem,
samme problemer med ydeevnen som før.

1465
01:09:47,270 --> 01:09:50,460
Fordi du kun har en begrænset
mængde disk og RAM og så videre.

1466
01:09:50,460 --> 01:09:53,450
Og en virtuel maskine
er bare et program, der er

1467
01:09:53,450 --> 01:09:56,140
foregiver at være en
fuldt udbygget computer.

1468
01:09:56,140 --> 01:09:58,040
Så du får hvad du betaler for her.

1469
01:09:58,040 --> 01:10:02,150
>> Så finder du online du kan betale en
velrenommeret selskab måske $ 100 om måneden

1470
01:10:02,150 --> 01:10:05,660
for din egen virtuelle maskine, eller
din egen virtual private server,

1471
01:10:05,660 --> 01:10:07,090
som er et andet ord for det.

1472
01:10:07,090 --> 01:10:10,400
Eller du kan finde nogle flyve ved
nat, hvor du betaler $ 5,99 om måneden

1473
01:10:10,400 --> 01:10:12,080
for din egen virtuelle maskine.

1474
01:10:12,080 --> 01:10:15,614
Men odds er du ikke har næsten
så meget ydelse til rådighed for dig,

1475
01:10:15,614 --> 01:10:18,530
fordi de har været overselling det
så, end du ville med den højere

1476
01:10:18,530 --> 01:10:22,340
tier for service eller bedre leverandør.

1477
01:10:22,340 --> 01:10:24,590
>> Så hvad betyder det egentlig for os?

1478
01:10:24,590 --> 01:10:26,110
Så lad mig gå til denne.

1479
01:10:26,110 --> 01:10:29,580
Jeg har tænkt mig at gå til aws.amazon.com.

1480
01:10:29,580 --> 01:10:31,590
Bare fordi de har
en dejlig menu med valgmuligheder.

1481
01:10:31,590 --> 01:10:34,700
Men de samme lektioner gælder for en
hel masse andre cloud-leverandører.

1482
01:10:34,700 --> 01:10:38,201
Desværre er det ofte mere
markedsføring taler end noget.

1483
01:10:38,201 --> 01:10:39,200
Og dette holder forandring.

1484
01:10:39,200 --> 01:10:41,820
Så du går til en hjemmeside som denne.

1485
01:10:41,820 --> 01:10:44,560
Og det er virkelig ikke
fortælle dig meget af noget.

1486
01:10:44,560 --> 01:10:47,780
>> Og selv jeg, som jeg ser på dette, gør ikke
virkelig vide, hvad nogen af ​​disse ting

1487
01:10:47,780 --> 01:10:49,334
nødvendigvis gøre indtil jeg dykke i.

1488
01:10:49,334 --> 01:10:50,875
Men lad os starte på venstre, Compute.

1489
01:10:50,875 --> 01:10:52,980
Og jeg har tænkt mig at klikke på dette.

1490
01:10:52,980 --> 01:10:56,960
Og nu Amazon har helt ærligt en
overvældende antal tjenester

1491
01:10:56,960 --> 01:10:57,960
disse dage.

1492
01:10:57,960 --> 01:11:01,040
Men Amazon EC2 er måske den enkleste.

1493
01:11:01,040 --> 01:11:05,840
>> Amazon EC2 vil skabe for os præcis
det billede, vi så et øjeblik siden.

1494
01:11:05,840 --> 01:11:10,240
Det er, hvordan de gør en masse
deres penge i skyen.

1495
01:11:10,240 --> 01:11:12,910
Tilsyneladende Netflix og andre
er i skyen med dem.

1496
01:11:12,910 --> 01:11:16,260
Dette er alle typisk
fluffy markedsføring tale.

1497
01:11:16,260 --> 01:11:19,720
Så hvad jeg vil gøre, er at gå til Pricing--
eller rettere lad os gå til forekomster

1498
01:11:19,720 --> 01:11:23,790
først bare for at male et billede af dette.

1499
01:11:23,790 --> 01:11:25,800
>> Så dette vil variere fra leverandør.

1500
01:11:25,800 --> 01:11:29,590
Og vi behøver ikke at få alt for dybt ind
ukrudt her for hvordan det hele fungerer.

1501
01:11:29,590 --> 01:11:34,720
Men den måde Amazon, for eksempel,
lejer du en virtuel maskine eller en server

1502
01:11:34,720 --> 01:11:37,200
i skyen er de got
disse slags sjove navne,

1503
01:11:37,200 --> 01:11:41,000
lignende t2.nano, hvilket betyder små,
eller t2.large, hvilket betyder store.

1504
01:11:41,000 --> 01:11:43,970
Hver af dem giver dig enten
en eller to virtuelle CPU'er.

1505
01:11:43,970 --> 01:11:45,470
>> Hvorfor er det en virtuel CPU?

1506
01:11:45,470 --> 01:11:49,440
Tja, måske den fysiske maskine
har 64 eller flere faktiske CPU'er.

1507
01:11:49,440 --> 01:11:52,125
Men igen, ved hjælp af software,
de skaber illusionen

1508
01:11:52,125 --> 01:11:55,410
at denne ene maskine kan være
divvied op til flere brugere.

1509
01:11:55,410 --> 01:11:58,765
Så vi kan tænke på dette som
har én Intel CPU eller to.

1510
01:11:58,765 --> 01:12:01,290
CPU credits pr hour-- jeg ville
nødt til at læse det med småt

1511
01:12:01,290 --> 01:12:02,581
, hvad dette egentlig betyder.

1512
01:12:02,581 --> 01:12:05,850
Det betyder, hvor meget af maskinen
du kan bruge timen vis-a-vis

1513
01:12:05,850 --> 01:12:07,730
andre kunder på denne hardware.

1514
01:12:07,730 --> 01:12:11,560
>> Her er, hvor meget RAM eller hukommelse, du
get-- enten en halv gigabyte, eller 500

1515
01:12:11,560 --> 01:12:14,120
megabyte, eller 1 gigabyte, eller 2.

1516
01:12:14,120 --> 01:12:17,390
Og derefter lagring refererer blot til
hvilken slags diske, de giver dig.

1517
01:12:17,390 --> 01:12:19,950
Der er forskellige opbevaring
teknologier, som de tilbyder.

1518
01:12:19,950 --> 01:12:22,870
Men mere interessant end dette
så måske prissætningen.

1519
01:12:22,870 --> 01:12:25,860
>> Så hvis du er CTO eller
en ingeniør, der ikke gør

1520
01:12:25,860 --> 01:12:28,420
ønsker at køre en server i dit
kontor, uanset årsagen,

1521
01:12:28,420 --> 01:12:30,230
og det er alt for
kompliceret eller dyrt

1522
01:12:30,230 --> 01:12:33,930
at købe servere og co-lokalisere dem og
betale husleje i nogle fysiske bur plads

1523
01:12:33,930 --> 01:12:36,670
somewhere-- du blot ønsker at sidde
på din bærbare computer sent om natten,

1524
01:12:36,670 --> 01:12:40,480
indtaste dine kreditkortoplysninger,
og leje servere i cloud-- godt,

1525
01:12:40,480 --> 01:12:41,920
vi kan gøre det her.

1526
01:12:41,920 --> 01:12:45,769
Jeg har tænkt mig at gå ned at-- Linux
er et populært operativsystem.

1527
01:12:45,769 --> 01:12:47,310
Og lad os bare få en fornemmelse af ting.

1528
01:12:47,310 --> 01:12:48,990
Whoops-- for stor.

1529
01:12:48,990 --> 01:12:53,670
>> Så lad os se på deres mindste
virtuel maskine, som synes at have,

1530
01:12:53,670 --> 01:12:57,440
til vores formål, en CPU
og 500 megabyte RAM.

1531
01:12:57,440 --> 01:12:58,440
Det er temmelig lille.

1532
01:12:58,440 --> 01:13:00,820
Men helt ærligt, webservere ikke
nødt til at gøre så meget.

1533
01:13:00,820 --> 01:13:02,630
Du har bedre specs i din bærbare computer.

1534
01:13:02,630 --> 01:13:04,990
Men du behøver ikke dem,
specs disse dage for ting.

1535
01:13:04,990 --> 01:13:11,490
Du kommer til at betale $ ,0065 per time.

1536
01:13:11,490 --> 01:13:12,080
>> Så lad os se.

1537
01:13:12,080 --> 01:13:15,970
Hvis der er 24 timer på en dag, og
vi betaler så meget i timen,

1538
01:13:15,970 --> 01:13:20,680
det vil koste dig $ 0,15 til leje, at
bestemt server i skyen.

1539
01:13:20,680 --> 01:13:22,210
Og det er kun for en dag.

1540
01:13:22,210 --> 01:13:27,050
Hvis vi gør det 365-- $ 57 til
leje det pågældende server.

1541
01:13:27,050 --> 01:13:28,420
Så det lyder super billigt.

1542
01:13:28,420 --> 01:13:31,100
>> Det er også super lav ydelse.

1543
01:13:31,100 --> 01:13:37,169
Så vi, til kurser jeg underviser her, har tendens
at bruge Jeg tror t2.smalls eller t2.mediums.

1544
01:13:37,169 --> 01:13:39,960
Og vi har måske et par hundrede
brugere, et par tusinde brugere, alt.

1545
01:13:39,960 --> 01:13:40,900
Det er ret beskedent.

1546
01:13:40,900 --> 01:13:42,360
Så lad os se, hvad det ville koste.

1547
01:13:42,360 --> 01:13:49,260
Så hvis jeg gør dette cost gange 24
time gange 365, denne her er $ 225.

1548
01:13:49,260 --> 01:13:51,160
Og for kurserne
Jeg underviser, vi generelt

1549
01:13:51,160 --> 01:13:54,970
køre to af alting, for
redundans og også for ydeevne.

1550
01:13:54,970 --> 01:13:59,230
Så vi kan bruge, derfor
$ 500 for serverne

1551
01:13:59,230 --> 01:14:00,860
at vi måske har brug for om året.

1552
01:14:00,860 --> 01:14:05,210
>> Nu, hvis du har brug for mere performance--
lad os tage et kig på hukommelsen.

1553
01:14:05,210 --> 01:14:06,810
Vi har talt om hukommelse ganske lidt.

1554
01:14:06,810 --> 01:14:09,330
Og hvis du har brug for mere
memory-- og 64 gigabyte

1555
01:14:09,330 --> 01:14:12,310
er antallet jeg holdt mentioning--
det er næsten $ 1 pr time.

1556
01:14:12,310 --> 01:14:16,180
Og du kan ret hurtigt se, hvor
dette goes-- så 24 timer gange 365.

1557
01:14:16,180 --> 01:14:20,580
Så nu er det $ 8000 om året
for en smuk anstændigt server.

1558
01:14:20,580 --> 01:14:23,010
>> Så på et tidspunkt, der er
dette vendepunktet

1559
01:14:23,010 --> 01:14:29,510
hvor nu vi kunne tilbringe $ 6000
formentlig og købe en maskine som der

1560
01:14:29,510 --> 01:14:33,800
og afskrive sin koste over måske to,
tre år, at maskinens levetid.

1561
01:14:33,800 --> 01:14:38,880
Men hvad der kan skubbe dig i
begunstiger eller unåde af leje

1562
01:14:38,880 --> 01:14:41,230
en maskine i skyen som denne?

1563
01:14:41,230 --> 01:14:44,110
Igen, dette er sammenlignelige, sandsynligvis,
til en af ​​disse Dell-servere

1564
01:14:44,110 --> 01:14:47,208
vi så afbilledet lidt siden.

1565
01:14:47,208 --> 01:14:51,016
>> PUBLIKUM: [uhørligt]

1566
01:14:51,016 --> 01:14:54,350

1567
01:14:54,350 --> 01:14:56,190
>> DAVID MALAN: Ja, det er en kæmpe upside.

1568
01:14:56,190 --> 01:14:58,640
Fordi vi ikke køber
maskine, har vi ikke at Unbox det.

1569
01:14:58,640 --> 01:14:59,600
Vi behøver ikke at løfte den.

1570
01:14:59,600 --> 01:15:01,110
Vi behøver ikke at sætte den ind i vores rack.

1571
01:15:01,110 --> 01:15:02,080
Vi behøver ikke at sætte den i.

1572
01:15:02,080 --> 01:15:03,140
Vi behøver ikke at betale
den elektriske regningen.

1573
01:15:03,140 --> 01:15:05,120
>> Vi behøver ikke at vende
luftkonditionering på.

1574
01:15:05,120 --> 01:15:07,620
Når en harddisk dør, har vi ikke
at køre i midt i natten

1575
01:15:07,620 --> 01:15:08,172
at ordne det.

1576
01:15:08,172 --> 01:15:09,630
Vi behøver ikke at oprette overvågning.

1577
01:15:09,630 --> 01:15:13,750
Vi har ikke at-- listen fortsætter
og på af alle de fysiske ting

1578
01:15:13,750 --> 01:15:15,810
du behøver ikke at gøre
på grund af "skyen".

1579
01:15:15,810 --> 01:15:18,620
>> Og for at være klar, cloud computing
er dette meget overused sigt.

1580
01:15:18,620 --> 01:15:22,790
Det er virkelig bare betyder betale nogen
andet at køre servere for dig,

1581
01:15:22,790 --> 01:15:25,300
eller leje plads på
andres servere.

1582
01:15:25,300 --> 01:15:27,110
Så udtrykket "cloud computing" er nyt.

1583
01:15:27,110 --> 01:15:30,260
Ideen er årtier gammel.

1584
01:15:30,260 --> 01:15:32,070
Så det er temmelig overbevisende.

1585
01:15:32,070 --> 01:15:33,960
>> Og hvad mere får du?

1586
01:15:33,960 --> 01:15:38,287
Nå, du får også mulighed for at
gøre alt på en bærbar computer derhjemme.

1587
01:15:38,287 --> 01:15:40,620
Med andre ord, alle de
billeder Jeg var bare drawing--

1588
01:15:40,620 --> 01:15:44,010
og det var ikke så længe siden, at selv
Jeg kravlede rundt på en server gulv

1589
01:15:44,010 --> 01:15:46,680
tilslutte kablerne i for
hver af de linjer, du ser,

1590
01:15:46,680 --> 01:15:49,590
og opgradering af operativsystemet
systemer, og skiftende drev omkring.

1591
01:15:49,590 --> 01:15:51,610
Der er en masse
kropslighed til alt dette.

1592
01:15:51,610 --> 01:15:55,300
>> Men hvad er smukt om virtuel
maskiner, som navnet antyder slags,

1593
01:15:55,300 --> 01:15:57,600
nu er der web-baseret
grænseflader hvorved

1594
01:15:57,600 --> 01:15:59,900
hvis du vil have det, der svarer
af en linje fra denne server

1595
01:15:59,900 --> 01:16:03,959
til en anden, så skriv, type, type,
klik og træk, klik på Send, og voila,

1596
01:16:03,959 --> 01:16:05,250
du har det kablede op virtuelt.

1597
01:16:05,250 --> 01:16:07,235
Fordi det hele foregår i software.

1598
01:16:07,235 --> 01:16:09,110
Og grunden til at det er gjort
i software er igen

1599
01:16:09,110 --> 01:16:12,650
fordi vi har så meget RAM og så
meget CPU til rådighed for os i disse dage,

1600
01:16:12,650 --> 01:16:14,880
selv om alle
at ting tager tid,

1601
01:16:14,880 --> 01:16:18,450
den er langsommere til at køre tingene
i software end hardware,

1602
01:16:18,450 --> 01:16:23,710
lige som det er langsommere til at bruge en mekanisk
enhed som en harddisk end RAM,

1603
01:16:23,710 --> 01:16:25,190
noget rent elektronisk.

1604
01:16:25,190 --> 01:16:27,490
Vi har så mange ressourcer
til rådighed for os.

1605
01:16:27,490 --> 01:16:29,920
Vi mennesker er en slags invariantly langsom.

1606
01:16:29,920 --> 01:16:33,840
Og så nu maskinerne kan gøre
så meget mere per tidsenhed.

1607
01:16:33,840 --> 01:16:36,640
Vi har disse evner
at gøre tingene virtuelt.

1608
01:16:36,640 --> 01:16:39,120
>> Og jeg vil sige til kurser
Jeg underviser for eksempel her,

1609
01:16:39,120 --> 01:16:43,464
vi har om måske et dusin eller
så alt virtuelle maskiner

1610
01:16:43,464 --> 01:16:45,880
ligesom der kører på et givet
tid gør frontend ting,

1611
01:16:45,880 --> 01:16:47,620
gør bagenden ting.

1612
01:16:47,620 --> 01:16:50,237
Vi har alle vores lager.

1613
01:16:50,237 --> 01:16:52,820
Så nogle videoer, herunder ting
som dette, at vi skyder,

1614
01:16:52,820 --> 01:16:54,330
Vi ender med at sætte ind i skyen.

1615
01:16:54,330 --> 01:16:58,710
Amazon har tjenester kaldet Amazon S3,
deres enkle opbevaring service, der

1616
01:16:58,710 --> 01:17:00,397
er ligesom diskplads i skyen.

1617
01:17:00,397 --> 01:17:02,230
De har noget
Kaldet CloudFront, som

1618
01:17:02,230 --> 01:17:06,040
er en CDN service, indhold
Delivery Network service, som

1619
01:17:06,040 --> 01:17:10,190
betyder, at de tager alle dine filer og
for dig automagisk kopiere det

1620
01:17:10,190 --> 01:17:11,290
jorden rundt.

1621
01:17:11,290 --> 01:17:12,780
>> Så de gør det ikke forebyggende.

1622
01:17:12,780 --> 01:17:15,159
Men den første gang nogen
i Indien anmoder om din fil,

1623
01:17:15,159 --> 01:17:16,700
de vil potentielt cache det lokalt.

1624
01:17:16,700 --> 01:17:19,325
Første gang i Kina,
første gang i Brasilien det sker,

1625
01:17:19,325 --> 01:17:20,880
de vil begynde caching det lokalt.

1626
01:17:20,880 --> 01:17:22,730
Og du behøver ikke at gøre noget af det.

1627
01:17:22,730 --> 01:17:26,710
Og så er det så utroligt
overbevisende i disse dage til at flytte tingene

1628
01:17:26,710 --> 01:17:27,890
ind i skyen.

1629
01:17:27,890 --> 01:17:31,890
Fordi du har denne evne bogstaveligt
for ikke at have mennesker gør nær så meget

1630
01:17:31,890 --> 01:17:32,390
arbejde.

1631
01:17:32,390 --> 01:17:35,930
Og du bogstaveligt talt ikke har brug for så mange
mennesker gør disse job anymore--

1632
01:17:35,930 --> 01:17:38,450
"ops" eller operationelle roller, længere.

1633
01:17:38,450 --> 01:17:43,150
Du har virkelig bare brug for
udviklere og færre ingeniører

1634
01:17:43,150 --> 01:17:44,840
der bare kan gøre tingene virtuelt.

1635
01:17:44,840 --> 01:17:46,590
Faktisk bare for at give
dig en følelse af dette,

1636
01:17:46,590 --> 01:17:51,800
lad mig gå til prisfastsættelse for
ét andet produkt her.

1637
01:17:51,800 --> 01:17:58,170
Lad os se noget lignende CDN S3.

1638
01:17:58,170 --> 01:18:01,140
Så dette er hovedsagelig en
virtuel harddisk i skyen.

1639
01:18:01,140 --> 01:18:14,360
Og hvis vi rulle ned for at pricing--
så det er ,007 $ per gigabyte.

1640
01:18:14,360 --> 01:18:16,300
Og that's-- hvordan gør vi det?

1641
01:18:16,300 --> 01:18:17,410
Jeg tror, ​​det er om måneden.

1642
01:18:17,410 --> 01:18:21,530
>> Så hvis det er pr month-- eller per dag?

1643
01:18:21,530 --> 01:18:23,200
Dan, er det om dagen?

1644
01:18:23,200 --> 01:18:24,700
Dette er per måned, OK.

1645
01:18:24,700 --> 01:18:28,280
Så hvis dette er pr month--
undskyld, det er $ 0,03 per måned.

1646
01:18:28,280 --> 01:18:29,820
Der er 12 måneder ud af året.

1647
01:18:29,820 --> 01:18:32,250
Så hvor meget data kan
du gemmer i skyen?

1648
01:18:32,250 --> 01:18:37,410
En gigabyte er ikke stor, men jeg
ved det ikke, ligesom en terabyte,

1649
01:18:37,410 --> 01:18:38,460
så ligesom 1.000 af dem.

1650
01:18:38,460 --> 01:18:39,501
Det er ikke så meget.

1651
01:18:39,501 --> 01:18:44,382
Det er $ 368 til at gemme en terabyte
af data i Amazons sky.

1652
01:18:44,382 --> 01:18:46,090
Så hvad er nogle af
de afvejninger, så?

1653
01:18:46,090 --> 01:18:47,970
Det kan ikke alle være god.

1654
01:18:47,970 --> 01:18:52,260
Intet vi har talt om i dag, er
slags uden en fangst eller en omkostning.

1655
01:18:52,260 --> 01:18:55,269
Så hvad er dårligt om at flytte
alt i skyen?

1656
01:18:55,269 --> 01:18:56,060
PUBLIKUM: Sikkerhed.

1657
01:18:56,060 --> 01:18:57,721
DAVID MALAN: OK, hvad mener du?

1658
01:18:57,721 --> 01:18:58,596
PUBLIKUM: [uhørligt]

1659
01:18:58,596 --> 01:19:01,589

1660
01:19:01,589 --> 01:19:02,630
DAVID MALAN: Yeah, højre.

1661
01:19:02,630 --> 01:19:05,130
Og vil du virkelig ønsker
nogle tilfældige ingeniører

1662
01:19:05,130 --> 01:19:08,750
på Amazon, at du aldrig vil mødes med
fysisk adgang til disse computere,

1663
01:19:08,750 --> 01:19:11,010
og hvis de virkelig
ønskede, virtuel adgang?

1664
01:19:11,010 --> 01:19:15,070
Og selv om i
teori software-- godt,

1665
01:19:15,070 --> 01:19:17,442
kryptering kan absolut
beskytte dig mod dette.

1666
01:19:17,442 --> 01:19:19,150
Så hvis hvad du er
lagring på dine servere

1667
01:19:19,150 --> 01:19:21,470
er encrypted-- mindre bekymrende.

1668
01:19:21,470 --> 01:19:25,010
>> Men så snart et menneske har fysisk
adgang til en maskine, kryptering til side,

1669
01:19:25,010 --> 01:19:26,100
alle spil slags slukket.

1670
01:19:26,100 --> 01:19:28,240
Du har måske kender fra gårsdagens
at pc'er især,

1671
01:19:28,240 --> 01:19:30,360
selv hvis du havde disse ting
kaldet "BIOS passwords,"

1672
01:19:30,360 --> 01:19:33,360
var, da dit skrivebord startet op,
ville du blive bedt med en adgangskode,

1673
01:19:33,360 --> 01:19:35,980
har intet at gøre med
Windows, kan du typisk

1674
01:19:35,980 --> 01:19:39,750
bare åbne chassis
maskine, finde bittesmå ben,

1675
01:19:39,750 --> 01:19:42,240
og bruge noget, der hedder
en jumper og bare slutte

1676
01:19:42,240 --> 01:19:45,690
disse to ledninger til omkring et sekund,
derved færdiggøre et kredsløb.

1677
01:19:45,690 --> 01:19:47,360
Og det ville fjerne adgangskoden.

1678
01:19:47,360 --> 01:19:49,800
>> Så når du har fysisk adgang til en
enhed, kan du gøre sådan noget.

1679
01:19:49,800 --> 01:19:51,110
Du kan fjerne harddisken.

1680
01:19:51,110 --> 01:19:53,060
Du kan få adgang til det på den måde.

1681
01:19:53,060 --> 01:19:55,442
Og så dette er grunden til,
tilfældet med Dropbox,

1682
01:19:55,442 --> 01:19:57,900
for eksempel, det er lidt
bekymrende, at ikke kun de

1683
01:19:57,900 --> 01:20:02,860
have data, selv om det er
krypteret, de har også nøglen.

1684
01:20:02,860 --> 01:20:04,993
Andre bekymringer?

1685
01:20:04,993 --> 01:20:08,430
>> PUBLIKUM: [uhørligt]

1686
01:20:08,430 --> 01:20:27,740

1687
01:20:27,740 --> 01:20:30,240
DAVID MALAN: Ja, det er meget
true-- den Googles, æblerne,

1688
01:20:30,240 --> 01:20:31,406
de Microsofts af verden.

1689
01:20:31,406 --> 01:20:34,400
Og i virkeligheden, hvor længe har
du havde din iPhone til?

1690
01:20:34,400 --> 01:20:35,885
Ja, give eller tage.

1691
01:20:35,885 --> 01:20:36,760
PUBLIKUM: [uhørligt]

1692
01:20:36,760 --> 01:20:37,780
DAVID MALAN: Jeg er ked af?

1693
01:20:37,780 --> 01:20:39,667
Du er blandt dem, der
har en iPhone, ikke?

1694
01:20:39,667 --> 01:20:40,250
PUBLIKUM: Ja.

1695
01:20:40,250 --> 01:20:42,208
DAVID MALAN: Hvor længe
har du haft din iPhone?

1696
01:20:42,208 --> 01:20:43,372
PUBLIKUM: [uhørligt]

1697
01:20:43,372 --> 01:20:45,080
DAVID MALAN: OK, så
Apple bogstaveligt kender

1698
01:20:45,080 --> 01:20:49,030
hvor du har været hver time af
dag for de sidste fem år.

1699
01:20:49,030 --> 01:20:51,112
>> PUBLIKUM: [uhørligt]

1700
01:20:51,112 --> 01:20:54,626

1701
01:20:54,626 --> 01:20:56,375
DAVID MALAN: Hvilket er
en vidunderlig funktion.

1702
01:20:56,375 --> 01:20:57,860
PUBLIKUM: [uhørligt]

1703
01:20:57,860 --> 01:21:00,875
DAVID MALAN: Ja, men
trade off for sikker.

1704
01:21:00,875 --> 01:21:01,750
PUBLIKUM: [uhørligt]

1705
01:21:01,750 --> 01:21:04,720

1706
01:21:04,720 --> 01:21:07,813
>> DAVID MALAN: Ja, det er meget nemt at.

1707
01:21:07,813 --> 01:21:08,688
PUBLIKUM: [uhørligt]

1708
01:21:08,688 --> 01:21:12,040

1709
01:21:12,040 --> 01:21:13,248
DAVID MALAN: Andre ulemper?

1710
01:21:13,248 --> 01:21:16,995
PUBLIKUM: [uhørligt]

1711
01:21:16,995 --> 01:21:26,151

1712
01:21:26,151 --> 01:21:27,900
DAVID MALAN: Absolutely--
teknologisk,

1713
01:21:27,900 --> 01:21:31,550
økonomisk, er det temmelig overbevisende til
slags vinde disse stordriftsfordele

1714
01:21:31,550 --> 01:21:33,579
og flytte alt ind
den såkaldte sky.

1715
01:21:33,579 --> 01:21:35,870
Men du sandsynligvis ønsker at
gå med nogle af de største

1716
01:21:35,870 --> 01:21:39,380
fisk, Amazonerne, at Googles, den
Microsofts-- Rackspace er temmelig big--

1717
01:21:39,380 --> 01:21:42,200
og et par andre, og ikke
nødvendigvis flyve om natten folk

1718
01:21:42,200 --> 01:21:45,640
for hvem det er meget let at gøre
denne form for teknik i dag.

1719
01:21:45,640 --> 01:21:49,140
Og det er, som du kan
betale $ 5,99 per måned til.

1720
01:21:49,140 --> 01:21:50,890
Men du vil helt sikkert
får hvad du betaler for.

1721
01:21:50,890 --> 01:21:54,014
>> Når du siger [uhørligt], det er når
ting som disse fem niere kommer op,

1722
01:21:54,014 --> 01:21:58,017
hvorved selv om teknologisk
vi kan ikke rigtig garantere 99.999,

1723
01:21:58,017 --> 01:22:00,350
vi vil bare bygge i en slags
af straf til kontrakten

1724
01:22:00,350 --> 01:22:03,910
således at hvis der sker, i det mindste
der er nogle omkostninger for os, sælgeren.

1725
01:22:03,910 --> 01:22:07,950
Og det er, hvad du typisk ville
være at få dem til at acceptere.

1726
01:22:07,950 --> 01:22:09,590
>> PUBLIKUM: [uhørligt]

1727
01:22:09,590 --> 01:22:12,290
>> DAVID MALAN: Og
en slags velsignelse

1728
01:22:12,290 --> 01:22:15,630
er, at selv når vi går ned, for
eksempel, eller endda visse selskaber,

1729
01:22:15,630 --> 01:22:17,800
virkeligheden er Amazon,
for eksempel, har så mange

1730
01:22:17,800 --> 01:22:21,780
darn kunder, kendte kunder,
opererer ud af visse datacentre

1731
01:22:21,780 --> 01:22:26,224
at når noget virkelig går galt,
ligesom force majeure og vejr og sådan,

1732
01:22:26,224 --> 01:22:29,390
hvis der er nogen form for blå himmel,
det er, at du er i meget godt selskab.

1733
01:22:29,390 --> 01:22:30,680
Din hjemmeside kan være offline.

1734
01:22:30,680 --> 01:22:32,750
Men så er ligesom halvdelen af
den populære internet.

1735
01:22:32,750 --> 01:22:36,230
Og så det er velsagtens lidt
mere spiselig for dine kunder

1736
01:22:36,230 --> 01:22:38,780
hvis det er mere af en internet
ting end en acme.com ting.

1737
01:22:38,780 --> 01:22:41,780
Men det er lidt af en snyde.

1738
01:22:41,780 --> 01:22:46,740
>> Så med hensyn til andre ting at se på,
bare så vi ikke udelukke andre,

1739
01:22:46,740 --> 01:22:51,210
hvis du går til Azure, de
har både Linux og Windows stuff

1740
01:22:51,210 --> 01:22:53,190
der er sammenlignelig med Amazons.

1741
01:22:53,190 --> 01:22:57,540
Hvis du går til Google Compute Engine,
de har noget lignende så godt.

1742
01:22:57,540 --> 01:23:00,500
Og bare for at afrunde
disse cloud tilbud,

1743
01:23:00,500 --> 01:23:02,762
Jeg vil gøre omtale af en anden ting.

1744
01:23:02,762 --> 01:23:04,720
Dette er et populært websted
det er repræsentativt

1745
01:23:04,720 --> 01:23:08,590
af en klasse af teknologier.

1746
01:23:08,590 --> 01:23:12,350
Dem vi bare talte
om, Amazon, ville være IAAS,

1747
01:23:12,350 --> 01:23:17,150
Infrastruktur som en tjeneste, hvor du
form for fysisk hardware som en service.

1748
01:23:17,150 --> 01:23:18,757
Der er SAAS.

1749
01:23:18,757 --> 01:23:20,090
Faktisk, lad mig notere disse ned.

1750
01:23:20,090 --> 01:23:23,290

1751
01:23:23,290 --> 01:23:28,190
>> IAAS-- Infrastruktur
Som en service, SAAS,

1752
01:23:28,190 --> 01:23:31,870
og PAAS, som er
bemærkelsesværdigt forvirrende akronymer

1753
01:23:31,870 --> 01:23:34,400
, der beskriver tre
forskellige typer af ting.

1754
01:23:34,400 --> 01:23:36,400
Og de akronymer selv
ikke rigtig noget.

1755
01:23:36,400 --> 01:23:38,360
Dette er alt af skyen ting
vi har netop talt om,

1756
01:23:38,360 --> 01:23:41,570
det lavere niveau stuff, den
virtualisering af hardware og opbevaring

1757
01:23:41,570 --> 01:23:44,890
i den såkaldte sky, uanset om det er
Amazon, Microsoft, Google, eller andet.

1758
01:23:44,890 --> 01:23:47,270
>> Software som en service--
alle os slags bruge dette.

1759
01:23:47,270 --> 01:23:49,810
Hvis du bruger Google Apps
for Gmail eller kalender,

1760
01:23:49,810 --> 01:23:52,530
nogen af ​​disse webbaseret
applikationer, der for 10 år siden vi

1761
01:23:52,530 --> 01:23:55,560
ville have dobbelt klikket ikoner på
vores desktop, software som en service

1762
01:23:55,560 --> 01:23:57,400
er nu virkelig webapplikation.

1763
01:23:57,400 --> 01:24:00,110
Og platform som en
tjeneste slags afhænger af.

1764
01:24:00,110 --> 01:24:03,140
>> Og et eksempel jeg vil give dig her
i forbindelse med cloud computing--

1765
01:24:03,140 --> 01:24:06,250
der er et selskab, der er helt
populære i disse dage, Heroku.

1766
01:24:06,250 --> 01:24:08,940
Og de er en service,
en platform, hvis du vil,

1767
01:24:08,940 --> 01:24:11,730
der kører på toppen af
Amazons infrastruktur.

1768
01:24:11,730 --> 01:24:15,800
Og de bare gør det endnu nemmere
for udviklere og ingeniører

1769
01:24:15,800 --> 01:24:18,330
at få web-baserede applikationer online.

1770
01:24:18,330 --> 01:24:22,170
>> Det er en smerte, i første omgang, at bruge
Amazon Web Services og andre ting.

1771
01:24:22,170 --> 01:24:24,170
Fordi du rent faktisk har
at kende og forstå

1772
01:24:24,170 --> 01:24:27,617
om databaser og web-servere og
load balancers og alle de ting

1773
01:24:27,617 --> 01:24:28,450
Jeg har lige talt om.

1774
01:24:28,450 --> 01:24:32,780
Fordi alle Amazon har gjort, er ikke
skjult disse design udfordringer.

1775
01:24:32,780 --> 01:24:35,790
De har lige virtualiserede dem
og flytte dem ind i en browser,

1776
01:24:35,790 --> 01:24:37,770
i software i stedet for hardware.

1777
01:24:37,770 --> 01:24:43,020
>> Men virksomheder som Heroku og andre
PaaS udbydere, Platform as a Service,

1778
01:24:43,020 --> 01:24:46,900
de bruger disse barebone fundamentals
at vi bare talte om,

1779
01:24:46,900 --> 01:24:50,340
og de bygger lettere at
bruge software på toppen af ​​det

1780
01:24:50,340 --> 01:24:54,241
så hvis du ønsker at få en web-baseret
ansøgning online i disse dage,

1781
01:24:54,241 --> 01:24:55,990
du helt sikkert nødt til at
vide, hvordan man programmerer.

1782
01:24:55,990 --> 01:25:00,280
Du skal vide, Java eller Python eller PHP
eller Ruby eller en masse andre sprog.

1783
01:25:00,280 --> 01:25:02,180
>> Men du har også brug for et sted at sætte det.

1784
01:25:02,180 --> 01:25:04,790
Og vi talte tidligere om
at få en web-hosting firma.

1785
01:25:04,790 --> 01:25:08,630
Det er slags lignende midten af ​​2000'erne
tilgang til at få noget online.

1786
01:25:08,630 --> 01:25:12,140
I dag kan du i stedet betale nogen
som Heroku et par dollars om måneden.

1787
01:25:12,140 --> 01:25:15,370
Og væsentlige, når du har
gjort nogle indledende konfiguration,

1788
01:25:15,370 --> 01:25:18,704
at opdatere din hjemmeside, du
bare skrive en kommando i et vindue.

1789
01:25:18,704 --> 01:25:21,370
Og uanset hvad kode du har skrevet
her på din bærbare computer med det samme

1790
01:25:21,370 --> 01:25:24,350
distribueres til et vilkårligt antal
af servere i skyen.

1791
01:25:24,350 --> 01:25:26,440
>> Og Heroku tager sig af
alle af kompleksitet.

1792
01:25:26,440 --> 01:25:28,930
De tal hele databasen
ting, hele load balancing,

1793
01:25:28,930 --> 01:25:31,480
alle de hovedpiner, som vi har
lige skrevet på tavlen,

1794
01:25:31,480 --> 01:25:33,320
og skjule alt dette for dig.

1795
01:25:33,320 --> 01:25:36,170
Og til gengæld, du bare
betale dem lidt mere.

1796
01:25:36,170 --> 01:25:39,810
Så du har disse infrastrukturer som
en tjeneste, platforme som en service,

1797
01:25:39,810 --> 01:25:41,400
og derefter software som en service.

1798
01:25:41,400 --> 01:25:45,390
Det er, igen, denne
abstraktion eller lagdeling.

1799
01:25:45,390 --> 01:25:51,187
>> Eventuelle spørgsmål om skyen eller
bygge sin egen infrastruktur?

1800
01:25:51,187 --> 01:25:52,270
Okay, der var en masse.

1801
01:25:52,270 --> 01:25:54,200
Skal vi ikke gå videre og
tage vores 15 minutters pause her.

1802
01:25:54,200 --> 01:25:57,241
Vi kommer tilbage med et par nye koncepter
og lidt af hands-on mulighed

1803
01:25:57,241 --> 01:25:59,110
før aftenen er slut.

1804
01:25:59,110 --> 01:26:00,332