WEBVTT

00:00.090 --> 00:00.923
ผู้สอน: ทุกวันนี้

00:00.923 --> 00:02.880
คลาวด์คอมพิวติ้งสามารถพบได้ทุกที่

00:02.880 --> 00:07.290
และนั่นเป็นเพราะมีประโยชน์มากมายในการใช้คลาวด์คอมพิวติ้ง

00:07.290 --> 00:10.343
และนั่นคือสิ่งที่เราจะเน้นในบทเรียนนี้เมื่อเราเริ่มพูดถึงลักษณะต่างๆ

00:10.343 --> 00:12.930
ของคลาวด์

00:12.930 --> 00:19.680
เมื่อเราพูดถึงคลาวด์คอมพิวติ้ง มีประโยชน์หรือคุณลักษณะบางอย่างที่เราเห็นเมื่อเราเลือกใช้คลาวด์

00:19.680 --> 00:23.460
ซึ่งรวมถึงความพร้อมใช้งานสูง ความสามารถในการปรับขนาด ความยืดหยุ่น

00:23.460 --> 00:24.750
การใช้งานแบบมิเตอร์ ทรัพยากรที่ใช้ร่วมกัน

00:24.750 --> 00:27.540
และการซิงโครไนซ์ไฟล์

00:27.540 --> 00:29.040
ลองมาดูสิ่งเหล่านี้กัน

00:29.040 --> 00:31.350
ประการแรก เรามีความพร้อมใช้งานสูง

00:31.350 --> 00:34.410
ขณะนี้ ความพร้อมใช้งานสูงหมายถึงข้อเท็จจริงที่ว่าบริการต่างๆ

00:34.410 --> 00:37.800
ประสบปัญหาการหยุดทำงานน้อยมากเมื่อคุณใช้งานระบบคลาวด์

00:37.800 --> 00:43.200
นี่เป็นเพราะบริการส่วนใหญ่ที่สร้างขึ้นบนคลาวด์นั้นถูกสร้างขึ้นให้มีความน่าเชื่อถือสูงและทนทานต่อข้อผิดพลาดได้สูง

00:43.200 --> 00:45.900
ซึ่งหมายความว่าเราสามารถรับประกันความพร้อมใช้งานในระดับสูงได้

00:45.900 --> 00:47.610
ตอนนี้ เมื่อพูดถึงความพร้อมใช้งาน

00:47.610 --> 00:53.760
เรามักจะวัดสิ่งนี้เป็นเปอร์เซ็นต์ของระยะเวลาที่พร้อมใช้งานเทียบกับระยะเวลาที่หยุดทำงาน

00:53.760 --> 00:55.920
ตัวอย่างเช่น มาตรฐานทองคำภายในเครือข่ายเรียกว่า

00:55.920 --> 00:58.860
Five Nines

00:58.860 --> 01:02.970
ห้าเก้าหมายถึง 99 เวลาทำงานหรือความพร้อมใช้งาน

01:02.970 --> 01:06.390
999% ตามประสบการณ์ของผู้ใช้ปลายทางของคุณ

01:06.390 --> 01:09.030
ซึ่งหมายความว่าเราจะมีเวลาหยุดทำงานเพียงห้านาที

01:09.030 --> 01:11.980
15 วินาทีทุกปีเท่านั้น

01:11.980 --> 01:15.090
ใช่แล้ว เพียงห้านาที 15 วินาทีตลอด

01:15.090 --> 01:18.570
365 วันในหนึ่งปี

01:18.570 --> 01:23.430
ในการทำเช่นนั้น นั่นหมายความว่าคุณต้องมีระบบที่มีความน่าเชื่อถือสูงและพร้อมใช้งานสูง

01:23.430 --> 01:29.123
ดังนั้นหากคุณมีเว็บไซต์เดียว คุณจะต้องมีเว็บเซิร์ฟเวอร์อย่างน้อยสองตัวที่โฮสต์เว็บไซต์นั้น

01:29.123 --> 01:30.300
ดังนั้นหากเครื่องหนึ่งหยุดทำงาน

01:30.300 --> 01:35.730
อีกเครื่องหนึ่งยังคงแบกภาระอยู่ และนั่นหมายความว่าผู้ใช้ปลายทางจะไม่พบปัญหาการหยุดทำงานใดๆ

01:35.730 --> 01:38.640
นั่นคือสิ่งที่เรากำลังพูดถึงเมื่อเราพูดถึงความพร้อมใช้งานสูง

01:38.640 --> 01:47.280
ตัวอย่างเช่นกับเว็บไซต์ของฉันเอง diontraining จริง ๆ แล้วเรามีการตั้งค่าที่พร้อมใช้งานสูงมากซึ่งสร้างขึ้นโดยใช้บริการคลาวด์

01:47.280 --> 01:55.680
ดังนั้นขึ้นอยู่กับว่าคุณมาจากที่ใดในโลก คุณจะไปถึงหนึ่งในเซิร์ฟเวอร์หลายแห่งของเราที่ตั้งอยู่ทั่วโลกซึ่งอยู่ใกล้คุณที่สุดเพื่อรับประสบการณ์ที่ดียิ่งขึ้น

01:55.680 --> 01:57.627
ตอนนี้ หากเซิร์ฟเวอร์ของคุณหยุดทำงานด้วยเหตุผลบางประการ

01:57.627 --> 02:00.300
คุณจะถูกนำไปยังเซิร์ฟเวอร์อื่นโดยอัตโนมัติ ซึ่งอยู่ห่างจากคุณเล็กน้อย

02:00.300 --> 02:02.490
แต่เซิร์ฟเวอร์ยังคงทำงานอยู่

02:02.490 --> 02:04.980
ด้วยวิธีนี้ คุณยังคงได้รับบริการที่คุณต้องการ

02:04.980 --> 02:08.460
และนั่นเป็นวิธีที่ทำให้มั่นใจว่ามีความพร้อมใช้งานสูง

02:08.460 --> 02:12.480
ลักษณะที่สองของคลาวด์ที่เราจะพูดถึงนี้เรียกว่าความสามารถในการขยายขนาด

02:12.480 --> 02:15.150
ตอนนี้ เมื่อเราพูดถึงความสามารถในการปรับขยาย

02:15.150 --> 02:23.220
นี่คือการพูดถึงข้อเท็จจริงที่ว่า เราสามารถเพิ่มจำนวนคนหรือจำนวนสิ่งของในระบบของเราในอัตราเชิงเส้นหรือน้อยกว่าอัตราเชิงเส้น

02:23.220 --> 02:24.053
ทีนี้ สิ่งที่ฉันหมายถึงก็คือ

02:24.053 --> 02:26.850
สมมติว่าฉันมีผู้ใช้ 100 รายที่ใช้ระบบของฉัน และมีค่าใช้จ่าย

02:26.850 --> 02:28.620
10 ดอลลาร์

02:28.620 --> 02:31.282
ถ้าฉันใส่ผู้ใช้ 200 คนในระบบของฉัน ฉันควรจะเสียค่าใช้จ่าย

02:31.282 --> 02:35.010
$20 หรือน้อยกว่านั้น และนั่นจะเป็นสเกลเชิงเส้น

02:35.010 --> 02:37.860
ตอนนี้ ถ้าฉันเปลี่ยนจากผู้ใช้ 100 คนเป็น 200 คน และราคาเปลี่ยนจาก

02:37.860 --> 02:40.500
10 ดอลลาร์เป็น 100 ดอลลาร์ นั่นจะเป็นสเกลแบบเอ็กซ์โปเนนเชียล

02:40.500 --> 02:43.380
และเราไม่ต้องการให้เป็นอย่างนั้น

02:43.380 --> 02:45.180
ในขณะที่เรากำลังสร้างระบบคลาวด์ เรามักจะมองหาความสามารถในการปรับขยาย

02:45.180 --> 02:47.070
และนั่นหมายความว่าแม้ว่าเราจะมีผู้ใช้เพียง

02:47.070 --> 02:51.090
10 รายในวันนี้ แต่พรุ่งนี้เราอาจมี 100 ราย

02:51.090 --> 02:52.590
วันต่อมาเรามี 1,000 วันหลังจากนั้น

02:52.590 --> 02:55.260
เราอาจมี 10,000 ไปเรื่อยๆ

02:55.260 --> 02:56.093
หากคุณดูบริษัทขนาดใหญ่บางแห่ง

02:56.093 --> 03:02.160
เช่น Facebook และ Google และ LinkedIn และ UNI พวกเขามีผู้ใช้ปลายทางหลายล้านคนที่เข้าถึงแพลตฟอร์มของพวกเขาทุกวัน

03:02.160 --> 03:14.490
และพวกเขาสามารถขยายขนาดตามความสามารถในการปรับขนาดของระบบคลาวด์ เพราะฉันไม่ต้องไปซื้อเซิร์ฟเวอร์มูลค่า 10,000 ดอลลาร์อีกเครื่องเพื่อวางในศูนย์ข้อมูลในพื้นที่ของฉัน เพราะฉันสามารถใช้ของ Amazon

03:14.490 --> 03:19.560
และใช้ความสามารถบางส่วนแทนได้ตามต้องการ

03:19.560 --> 03:20.970
ตอนนี้ เมื่อพูดถึงความสามารถในการปรับขนาด

03:20.970 --> 03:22.650
มีสองวิธีที่คุณสามารถปรับขนาดได้

03:22.650 --> 03:25.560
หนึ่งคือการขยายขนาด ซึ่งเรียกว่ามาตราส่วนแนวตั้ง

03:25.560 --> 03:29.010
นี่คือการเพิ่มทรัพยากรเพิ่มเติมให้กับเซิร์ฟเวอร์หรือโหนดเฉพาะ

03:29.010 --> 03:31.020
ตัวอย่างเช่น หากคุณใช้เซิร์ฟเวอร์บนคลาวด์ที่มี

03:31.020 --> 03:32.970
CPU เสมือนสองตัว คุณสามารถเพิ่ม

03:32.970 --> 03:35.730
CPU เสมือนเป็นสี่ตัวได้

03:35.730 --> 03:37.170
นี่คือแนวคิดในการขยายขนาด

03:37.170 --> 03:38.610
คุณกำลังเพิ่มทรัพยากรมากขึ้น ไม่ว่าจะเป็นโปรเซสเซอร์ที่มากขึ้น

03:38.610 --> 03:41.040
RAM ที่มากขึ้น ที่เก็บข้อมูลที่มากขึ้น แบนด์วิธที่มากขึ้น

03:41.040 --> 03:43.110
หรืออะไรทำนองนั้น

03:43.110 --> 03:45.120
ในทางกลับกัน คุณยังสามารถปรับขนาดออก

03:45.120 --> 03:47.100
ซึ่งเรียกว่ามาตราส่วนแนวนอน

03:47.100 --> 03:50.280
ที่นี่คุณยังคงใช้เครื่องจักรขนาดเล็กลง แต่คุณใช้เครื่องจักรจำนวนมากขึ้น

03:50.280 --> 03:53.400
ซึ่งทั้งหมดทำงานควบคู่กันอยู่เบื้องหลังโหลดบาลานเซอร์

03:53.400 --> 03:55.080
ดังนั้น แทนที่จะมีเซิร์ฟเวอร์เดียวที่จัดการโหลดทั้งหมดของคุณ

03:55.080 --> 03:57.316
และปรับขนาดให้สูงขึ้นโดยการเพิ่ม CPU และเพิ่มหน่วยความจำ

03:57.316 --> 04:02.520
คุณสามารถขยายขนาดและเปลี่ยนจากเซิร์ฟเวอร์หนึ่งเป็นสองเซิร์ฟเวอร์ หรือสองเซิร์ฟเวอร์เป็นสี่ หรือสี่เป็นแปด

04:02.520 --> 04:11.940
และคุณ สามารถก้าวออกไปด้านนอกได้โดยการเพิ่มเซิร์ฟเวอร์เพิ่มเติมที่อยู่เบื้องหลังโหลดบาลานเซอร์ของคุณ ซึ่งคุณสามารถจัดการทราฟฟิกเพิ่มเติมได้

04:11.940 --> 04:13.710
สิ่งนี้นำเราไปสู่พื้นที่ที่สามของเรา

04:13.710 --> 04:15.864
ซึ่งเรียกว่าความยืดหยุ่นอย่างรวดเร็ว

04:15.864 --> 04:22.731
ตอนนี้ เมื่อเราพูดถึงความยืดหยุ่นอย่างรวดเร็ว เรากำลังพูดถึงข้อเท็จจริงที่ว่าเราสามารถปรับขนาดขึ้นหรือลงได้อย่างรวดเร็ว

04:22.731 --> 04:29.970
ตอนนี้เสร็จสิ้นเพราะเราใช้ระบบอัตโนมัติและการประสานกับเครื่องเสมือนจำนวนมากบนเซิร์ฟเวอร์จริงเหล่านี้ซึ่งเป็นของ

04:29.970 --> 04:32.220
Amazon, Google, Microsoft และบริษัทอื่น

04:32.220 --> 04:35.040
ๆ ที่อนุญาตให้เราใช้บางส่วนหรือบริการทั้งหมดของพวกเขาตามที่เราต้องการตามความต้องการ

04:35.040 --> 04:38.104
.

04:38.104 --> 04:41.040
และนี่ทำให้เรามีความยืดหยุ่นอย่างรวดเร็ว

04:41.040 --> 04:43.200
เมื่อคุณได้ยินคำว่า ความยืดหยุ่นอย่างรวดเร็ว

04:43.200 --> 04:50.370
หรือ ความยืดหยุ่นโดยทั่วไป ให้คิดว่านี่คือข้อเท็จจริงของความสามารถของระบบในการจัดการกับการเปลี่ยนแปลงตามความต้องการแบบเรียลไทม์

04:50.370 --> 04:51.410
ย้อนกลับไปที่ตัวอย่างการใช้เว็บไซต์ของผมที่

04:51.410 --> 04:54.780
diontraining คอม

04:54.780 --> 04:56.490
ถ้าตอนนี้ฉันตรวจสอบเว็บไซต์ของฉัน

04:56.490 --> 05:00.330
และมีนักเรียน 1,000 คนเข้าสู่ระบบ และอีก 5 นาทีนับจากนี้ฉันตรวจสอบ และมีนักเรียน

05:00.330 --> 05:10.230
10,000 คนเข้าสู่ระบบ ระบบของฉันได้รับการออกแบบให้หมุนทรัพยากรบนคลาวด์เพิ่มเติมและผลักดันโหลดบางส่วนจากสิ่งเหล่านั้น ผู้ใช้ใหม่ไปยังบริการเพิ่มเติมเหล่านั้น

05:10.230 --> 05:12.810
นั่นคือแนวคิดของความยืดหยุ่นอย่างรวดเร็ว

05:12.810 --> 05:14.580
โดยทั่วไป เมื่อคุณทำงานในระบบคลาวด์

05:14.580 --> 05:16.470
หากคุณออกแบบระบบของคุณอย่างถูกต้อง

05:16.470 --> 05:18.949
คุณจะมีความยืดหยุ่นอย่างรวดเร็วและขยายขนาดได้เร็วมาก

05:18.949 --> 05:21.150
และในทำนองเดียวกัน เมื่อความต้องการหมดไป

05:21.150 --> 05:27.120
คุณก็สามารถกำจัดได้อย่างรวดเร็ว เซิร์ฟเวอร์พิเศษเหล่านั้นและนำกลับลงมา

05:27.120 --> 05:31.166
และเหตุผลที่คุณต้องการทำเช่นนั้นก็เพราะว่าเซิร์ฟเวอร์เสริมเหล่านั้นจะทำให้คุณเสียเงินมากขึ้น

05:31.166 --> 05:40.140
และถ้าคุณมีผู้ใช้ไม่มากพอ คุณก็ไม่ต้องการจ่ายเงินสำหรับสิ่งนั้น จะปล่อยสิ่งเหล่านั้นคืนให้กับผู้ให้บริการของคุณเพื่อให้พวกเขาสามารถเช่าบริการนั้นให้กับคนอื่นได้

05:40.140 --> 05:42.750
แต่ถ้าคุณกำลังสร้างแบบจำลองภายในองค์กร สมมติว่าวันนี้ฉันมีนักเรียน

05:42.750 --> 05:45.000
1,000 คน

05:45.000 --> 05:48.150
สำหรับนักเรียน 1,000 คน ฉันอาจต้องการเว็บเซิร์ฟเวอร์สามเครื่อง

05:48.150 --> 05:49.830
แต่ถ้าฉันไปหานักเรียน 10,000 คน ฉันจะต้องการเว็บเซิร์ฟเวอร์อีก

05:49.830 --> 05:51.956
15 เครื่อง

05:51.956 --> 05:55.080
ในการทำเช่นนั้น ฉันจะต้องซื้อเซิร์ฟเวอร์เพิ่มอีก 15 เครื่อง

05:55.080 --> 05:55.950
ฉันจะต้องวางพวกเขา

05:55.950 --> 05:57.270
ฉันต้องติดตั้งซอฟต์แวร์ทั้งหมด

05:57.270 --> 05:58.440
ฉันต้องกำหนดค่า

05:58.440 --> 06:04.980
ทั้งหมดนี้ต้องใช้เวลา ดังนั้นการวัดความยืดหยุ่นจึงไม่ได้รวดเร็วมากนักเพื่อให้เราสามารถขยายขนาดเพื่อตอบสนองความต้องการดังกล่าวได้

06:04.980 --> 06:07.860
หากคุณมีรูปแบบธุรกิจที่เติบโตช้ามาก ก็ไม่เป็นไร

06:07.860 --> 06:12.171
แต่ถ้าคุณต้องรับมือกับบางสิ่งที่มีความเร็วสูงหรือแพลตฟอร์มโซเชียลมีเดียสมัยใหม่เหล่านี้

06:12.171 --> 06:16.920
และสิ่งที่คุณทำไปแล้วกลายเป็นไวรัล และทุกคนไปที่เว็บไซต์ของคุณและเริ่มท่วมท้นคุณ หากคุณไม่มีความสามารถ

06:16.920 --> 06:23.880
หากต้องการขยายขนาดอย่างรวดเร็ว คุณจะพลาดความสามารถในการจับทราฟฟิกที่มาจากเหตุการณ์ไวรัสนั้น

06:23.880 --> 06:25.620
คุณจึงต้องการสร้างสิ่งต่างๆ ในลักษณะที่ยืดหยุ่นได้อย่างรวดเร็ว

06:25.620 --> 06:29.700
และนั่นคือสิ่งที่ระบบคลาวด์ช่วยให้เราทำได้

06:29.700 --> 06:32.910
สิ่งที่สี่ที่เรามีเรียกว่าการใช้มิเตอร์

06:32.910 --> 06:36.510
ตอนนี้กลับไปที่การสนทนาเกี่ยวกับความยืดหยุ่นอย่างรวดเร็วที่เราเพิ่งมี

06:36.510 --> 06:38.686
ตอนนี้ เมื่อเรากำลังพูดถึงการใช้งานแบบมิเตอร์

06:38.686 --> 06:43.800
เรากำลังพูดถึงข้อเท็จจริงที่ว่าเราจ่ายค่าบริการแบบจ่ายต่อการใช้งาน

06:43.800 --> 06:46.650
ดังนั้น เมื่อเราใช้บริการแบบตรวจวัด เช่น ฐานข้อมูล

06:46.650 --> 06:49.170
พวกเขาอาจเรียกเก็บเงินจากเราตามจำนวนผู้ใช้หรือจำนวนการเชื่อมต่อ

06:49.170 --> 06:52.050
หรือจำนวนข้อมูลที่จัดเก็บ

06:52.050 --> 06:56.910
โดยพื้นฐานแล้ว เราจะถูกเรียกเก็บเงินตามการใช้งานจริงของบริการที่มีการใช้งาน

06:56.910 --> 06:59.262
และเราทำเป็นรายวินาที รายนาที

06:59.262 --> 07:03.480
รายชั่วโมง หรือรายวัน หรือแม้แต่รายเดือน

07:03.480 --> 07:05.211
ตัวอย่างเช่น ฉันใช้ AWS Lambda

07:05.211 --> 07:08.153
สำหรับการทำงานอัตโนมัติและฟังก์ชันแบ็กเอนด์จำนวนมาก

07:08.153 --> 07:11.010
และพวกเขาคิดค่าบริการตามการใช้งานของฉัน

07:11.010 --> 07:13.290
ตอนนี้ ทุกๆ 1 ล้านคำขอที่ฉันขอ พวกเขาคิดเงินฉัน

07:13.290 --> 07:14.760
20 เซ็นต์

07:14.760 --> 07:17.880
ดังนั้นมันจึงเป็นวิธีที่มีประสิทธิภาพมากสำหรับฉันในการทำระบบอัตโนมัติให้เสร็จ

07:17.880 --> 07:20.092
เพราะมันเป็นสิ่งที่มีต้นทุนที่ต่ำมาก

07:20.092 --> 07:22.620
ฉันสามารถมีคำขอเป็นล้านๆ ล้านคำขอได้ และมีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์เท่านั้น

07:22.620 --> 07:27.090
และนั่นคือแนวคิดของบริการแบบตรวจสอบตามปริมาณข้อมูล

07:27.090 --> 07:33.000
ตอนนี้ อีกอย่างที่คุณจะเห็นคือบางครั้งคุณจะเห็นความแตกต่างระหว่างบริการตามมิเตอร์และบริการที่วัดได้

07:33.000 --> 07:35.640
ตอนนี้ เมื่อเราพูดถึงบริการแบบวัดปริมาณหรือวัดได้

07:35.640 --> 07:41.160
เรากำลังพูดถึงสิ่งเดียวกันจริงๆ และนั่นคือความสามารถของเราที่จะจ่ายสำหรับบางสิ่งตามปริมาณการใช้

07:41.160 --> 07:42.840
แต่มีความแตกต่างที่นี่

07:42.840 --> 07:44.850
เมื่อคุณใช้บริการแบบคิดค่าบริการตามปริมาณข้อมูล

07:44.850 --> 07:46.073
คุณจะจ่ายเงินสำหรับสิ่งต่างๆ

07:46.073 --> 07:49.380
ตามการใช้งานจริงของสิ่งที่คุณทำ

07:49.380 --> 07:52.500
ดังนั้นหากคุณนึกถึงค่าน้ำค่าไฟที่บ้าน

07:52.500 --> 07:55.650
หากคุณเปิดสายฉีดน้ำและเติมน้ำในสระว่ายน้ำในเดือนนี้

07:55.650 --> 07:59.670
คุณจะจ่ายค่าน้ำเพิ่มขึ้นมากเพราะคุณใช้น้ำมากขึ้น

07:59.670 --> 08:04.950
ในทางกลับกัน เมื่อคุณจัดการกับบริการที่วัดได้ สิ่งนี้จะเหมือนกับแผนโทรศัพท์มือถือของคุณมากกว่า

08:04.950 --> 08:08.160
ในสถานที่ส่วนใหญ่ คุณจะจ่ายค่าธรรมเนียมรายเดือนสำหรับการใช้งานโทรศัพท์มือถือเครื่องนั้นตามจำนวนที่กำหนด

08:08.160 --> 08:14.100
ไม่ว่าจะเป็นจำนวนข้อความ จำนวนนาที หรือข้อมูลที่คุณได้รับอนุญาตให้ใช้

08:14.100 --> 08:15.390
และเมื่อคุณใช้ถึงขีดจำกัดนั้น

08:15.390 --> 08:19.440
พวกเขาจะหยุดบริการของคุณและไม่ให้อะไรคุณอีกจนกว่าคุณจะชำระเงินอีกครั้ง

08:19.440 --> 08:23.310
ดังนั้นเมื่อคุณนึกถึงบริการที่วัดได้ ให้นึกถึงข้อเท็จจริงที่ว่าคุณชำระเงินล่วงหน้าตามปริมาณที่กำหนด

08:23.310 --> 08:27.660
และไม่ว่าคุณจะใช้งานหรือไม่ก็ตาม คุณได้ชำระเงินตามจำนวนนั้นแล้ว

08:27.660 --> 08:28.493
แต่เมื่อคุณใช้บริการแบบคิดค่าบริการตามปริมาณข้อมูล

08:28.493 --> 08:31.253
คุณจะต้องจ่ายตามจำนวนที่คุณใช้จริง

08:31.253 --> 08:33.480
และนี่คือข้อดีประการหนึ่งของการใช้ระบบคลาวด์

08:33.480 --> 08:37.883
นั่นคือ สิ่งต่างๆ ส่วนใหญ่จะทำแบบวัดผลโดยที่คุณจ่ายเฉพาะส่วนที่คุณใช้เท่านั้น

08:37.883 --> 08:41.160
สิ่งต่อไปที่เราจะพูดถึงคือทรัพยากรที่ใช้ร่วมกัน

08:41.160 --> 08:43.740
ตอนนี้ เมื่อเราพูดถึงทรัพยากรที่ใช้ร่วมกัน เรากำลังพูดถึงความสามารถในการลดค่าใช้จ่าย

08:43.740 --> 08:50.220
เนื่องจากเราสามารถวางเครื่องเสมือนของเราบนเซิร์ฟเวอร์ของผู้อื่นได้

08:50.220 --> 08:51.930
เมื่อคุณดูที่เซิร์ฟเวอร์ที่เราใช้สำหรับ

08:51.930 --> 08:54.238
Amazon และ Azure และ Google Cloud สิ่งเหล่านี้คือ

08:54.238 --> 08:58.980
10, 20, 30,000 ดอลลาร์ต่อเครื่องสำหรับเซิร์ฟเวอร์คุณภาพดี

08:58.980 --> 09:00.151
ดังนั้นหากคุณต้องการซื้อหนึ่งในนั้นเพื่อให้สามารถโฮสต์บล็อก

09:00.151 --> 09:08.100
WordPress ของคุณได้ คุณจะไม่ได้ใช้ความสามารถทั้งหมดนั้นจริงๆ เพราะถ้าคุณมีผู้อ่านเพียงไม่กี่ร้อยคน มันจะไม่ใช้โหลดมากขนาดนั้น

09:08.100 --> 09:10.020
ดังนั้น แทนที่จะใช้เซิร์ฟเวอร์ที่มีราคาแพงมากๆ

09:10.020 --> 09:18.450
เครื่องหนึ่ง หั่นมันเป็นชิ้นเล็กๆ แล้วแจกจ่ายในเครื่องเสมือน ให้กับทุกคนที่ต้องการใช้แทน มันสมเหตุสมผลกว่ามาก

09:18.450 --> 09:20.816
ดังนั้น เราอาจสามารถโฮสต์บล็อก WordPress ได้ 50 หรือ

09:20.816 --> 09:24.480
100 บล็อกบนเซิร์ฟเวอร์เครื่องเดียว แทนที่จะโฮสต์เพียงเครื่องเดียว

09:24.480 --> 09:26.760
นั่นคือแนวคิดของการใช้ทรัพยากรร่วมกัน

09:26.760 --> 09:28.330
เมื่อเราพูดถึงทรัพยากรที่ใช้ร่วมกัน

09:28.330 --> 09:33.150
เรากำลังพูดถึงการดึงฮาร์ดแวร์ทั้งหมดมารวมกันเพื่อสร้างศูนย์ข้อมูลของผู้ให้บริการระบบคลาวด์

09:33.150 --> 09:35.215
และด้วยวิธีนั้น มันไม่ได้ทุ่มเทให้กับบุคคลใดบุคคลหนึ่ง

09:35.215 --> 09:37.987
แต่เราทุกคนสามารถใช้มันได้โดยยึดตามความยืดหยุ่นที่รวดเร็ว

09:37.987 --> 09:48.090
เพราะหวังว่าสิ่งที่ Amazon และ Google และ Azure กำลังคิดก็คือ เมื่อมีความต้องการสูงสำหรับบริษัทของฉัน อาจมีช่วงเวลาที่ต่ำ สำหรับบริษัทของคุณและในทางกลับกัน

09:48.090 --> 09:51.480
ดังนั้น แทนที่จะต้องทุ่มเททรัพยากรฮาร์ดแวร์ให้กับแต่ละบริษัท

09:51.480 --> 09:54.009
เราสามารถแบ่งปันทรัพยากรทั่วทั้งกระดานได้

09:54.009 --> 09:58.710
และคุณสมบัติสุดท้ายของคลาวด์คือความสามารถในการซิงโครไนซ์ไฟล์

09:58.710 --> 10:04.649
ตอนนี้ สิ่งที่ยอดเยี่ยมเกี่ยวกับการใช้ทรัพยากรบนระบบคลาวด์คือคุณสามารถใส่บางอย่างไว้ในที่เดียว

10:04.649 --> 10:07.500
แล้วกระจายไปยังที่อื่นตามวิธีที่คุณกำหนดค่า

10:07.500 --> 10:11.428
ตัวอย่างเช่น ในบริษัทของฉัน เราพึ่งพาการซิงโครไนซ์ไฟล์เป็นอย่างมาก

10:11.428 --> 10:14.249
เพราะคนของเราส่วนใหญ่เป็นพนักงานทางไกลที่ทำงานทั่วโลก

10:14.249 --> 10:17.640
ไม่ใช่แค่ในสำนักงานของเราเอง

10:17.640 --> 10:18.473
ขณะที่ฉันกำลังนั่งบันทึกสิ่งนี้ในออฟฟิศ

10:18.473 --> 10:24.690
ฉันต้องการวิธีมอบไฟล์นี้ให้กับนักออกแบบกราฟิกของฉัน เพื่อที่เธอจะได้สร้างสิ่งต่าง ๆ ที่คุณเห็นบนหน้าจอในขณะที่ฉันกำลังพูด

10:24.690 --> 10:27.060
.

10:27.060 --> 10:31.320
แล้วเธอจะไปส่งที่ประเทศอื่นที่มีโปรแกรมตัดต่อวิดีโอของฉันอยู่

10:31.320 --> 10:33.060
และเมื่อดำเนินการเสร็จแล้ว ก็จะส่งกลับไปที่สำนักงานของฉัน

10:33.060 --> 10:41.040
ซึ่งเจ้าหน้าที่คนหนึ่งของฉันจะทำการตรวจสอบการรับประกันคุณภาพของเรา จากนั้นเราจะส่งไปยังประเทศอื่นซึ่งกำลังจะอัปโหลด ไปยังไซต์สุดท้ายที่คุณจะได้เห็น

10:41.040 --> 10:43.779
ดังนั้น วิดีโอนี้อาจเดินทางไปถึงสี่หรือห้าแห่ง

10:43.779 --> 10:49.470
เพื่อให้ได้เป็นผลิตภัณฑ์สำเร็จรูปที่คุณเห็นบนหน้าจอตอนนี้

10:49.470 --> 10:50.303
นี่คือแนวคิดของการซิงโครไนซ์ไฟล์

10:50.303 --> 10:55.129
เพราะเมื่อฉันบันทึกสิ่งนี้ ฉันกำลังบันทึกไปยังเซิร์ฟเวอร์ไฟล์บนระบบคลาวด์ ทุกคนในทีมของฉันสามารถเข้าถึงไฟล์นั้นได้

10:55.129 --> 11:05.430
เพราะเรามีสำเนาที่ซิงโครไนซ์บนอุปกรณ์ทั้งหมดของพวกเขาและในอุปกรณ์ทั้งหมดของเรา เซิร์ฟเวอร์ทั่วโลกเพื่อให้พวกเขาสามารถเข้าถึงและทำในสิ่งที่ต้องการได้

11:05.430 --> 11:06.630
และในขณะที่พวกเขากำลังทำเช่นนั้น

11:06.630 --> 11:08.190
มันไม่ได้นั่งอยู่บนคอมพิวเตอร์ของพวกเขาเท่านั้น

11:08.190 --> 11:20.730
แต่กำลังซิงโครไนซ์กับเซิร์ฟเวอร์คลาวด์ทั้งหมดของเรา ดังนั้นทุกคนในเส้นทางนั้นจำเป็นต้องเกิดขึ้นระหว่างการบันทึกและการเผยแพร่ และจากนั้นคุณดูก็สามารถเกิดขึ้นได้ เซิร์ฟเวอร์เหล่านั้นทั้งหมดในลักษณะที่คล่องตัวมาก

11:20.730 --> 11:22.200
และนั่นเป็นหนึ่งในข้อดีที่แท้จริงของการทำระบบคลาวด์จากมุมมองทางธุรกิจ

11:22.200 --> 11:26.970
นั่นคือคุณไม่มีเซิร์ฟเวอร์นี้อยู่ในสำนักงานของคุณ

11:26.970 --> 11:28.201
ตอนนี้มันนั่งอยู่ในระบบคลาวด์ในศูนย์ข้อมูลที่ได้รับการปกป้อง

11:28.201 --> 11:37.740
พร้อมใช้งานสูง มีความสามารถในการปรับขนาดได้ และสามารถยืดหยุ่นในการตอบสนองต่อความต้องการในช่วงเวลาที่สูงขึ้นและต่ำลง

11:37.740 --> 11:39.015
เราต้องจ่ายเฉพาะสิ่งที่เราใช้

11:39.015 --> 11:45.480
และเราสามารถแบ่งปันทรัพยากรกับคนอื่นๆ ที่เราอาจไม่รู้ด้วยซ้ำ เพราะเราทุกคนนั่งอยู่บนเซิร์ฟเวอร์จริงเครื่องเดียวกัน

11:45.480 --> 11:49.110
และนี่คือทุกสิ่งที่เรากำลังพูดถึงเมื่อเราเริ่มพูดถึงคุณลักษณะของคลาวด์

11:49.110 --> 11:53.740
และเหตุใดจึงมีการโยกย้ายครั้งใหญ่นี้ไปยังคลาวด์โดยหลายบริษัททั่วโลก