# ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು ವಿವರಿಸಲಾಗಿದೆ: ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ 11 ಆರ್ಕಿಟೆಕ್ಚರ್ ಪರಿಕಲ್ಪನೆಗಳು (4K ಮಾಸ್ಟರ್‌ಕ್ಲಾಸ್).

Published: 2026-09-15

ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್‌ಗಳು AWS, GCP, ಮತ್ತು Azure ನಲ್ಲಿ ನೂರಾರು ಮಾರಾಟಗಾರರ ಉತ್ಪನ್ನಗಳ ಅಕ್ರೊನಿಮ್‌ಗಳನ್ನು ಕಂಠಪಾಠ ಮಾಡುವ ಮೂಲಕ ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕಲಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಆದರೆ ನೈಜ-ಪ್ರಪಂಚದ ಕ್ಲೌಡ್ ಇಂಜಿನಿಯರಿಂಗ್ ಹನ್ನೊಂದು ಮೂಲಭೂತ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿತವಾಗಿದೆ. ಈ 4K ರಿಮಾಸ್ಟರ್ ಮಾಸ್ಟರ್‌ಕ್ಲಾಸ್‌ನಲ್ಲಿ, ನಿಕೋ ಸಂಪೂರ್ಣ ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲೂಪ್ರಿಂಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತಾರೆ: ಲಂಬ ಮತ್ತು ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್, ಲೇಯರ್ 7 ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್‌ನಿಂದ ಹಿಡಿದು ಡೈನಾಮಿಕ್ ಆಟೋಸ್ಕೇಲಿಂಗ್, ಸರ್ವರ್‌ಲೆಸ್ ಮೈಕ್ರೋವಿಎಂ ಎಕ್ಸಿಕ್ಯೂಷನ್, ಅಸಿಂಕ್ರೋನಸ್ ಈವೆಂಟ್-ಡ್ರೈವನ್ ಡಿಕಪ್ಲಿಂಗ್, ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್, ನಾಲ್ಕು-ಸ್ತಂಭಗಳ ಶೇಖರಣಾ ಕ್ರಮಾನುಗತ, ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು 11 ನೈನ್ಸ್ ಆಫ್ ಡ್ಯೂರಬಿಲಿಟಿ ನಡುವಿನ ನಿರ್ಣಾಯಕ ವ್ಯತ್ಯಾಸ, ಡಿಕ್ಲರೇಟಿವ್ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಆಸ್ ಕೋಡ್, ಮತ್ತು ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕಿಂಗ್. ಈ ಹನ್ನೊಂದು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಿ, ಮತ್ತು ನೀವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಯಾವುದೇ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಆರ್ಕಿಟೆಕ್ಟ್ ಮಾಡಬಹುದು. ತೀರ್ಪು: SHIP IT.

Canonical: https://thedailydiff.dev/kn/video/2026-09-14-cloud-computing-explained-4k/

## ಈ ವೀಡಿಯೊ ಏನನ್ನು ಒಳಗೊಂಡಿದೆ

- - ಆರ್ಕಿಟೆಕ್ಚರ್ ವಾಲ್ ಮತ್ತು ಮಾಸ್ಟರ್ ಬ್ಲೂಪ್ರಿಂಟ್
- - 01. ಲಂಬ ವರ್ಸಸ್ ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್
- - 02. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (L4 ವರ್ಸಸ್ L7 ಮತ್ತು ಹೆಲ್ತ್ ಚೆಕ್‌ಗಳು)
- - 03. ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಎಲಾಸ್ಟಿಸಿಟಿ
- - 04. ಸರ್ವರ್‌ಲೆಸ್ (FaaS ಮತ್ತು ಫೈರ್‌ಕ್ರ್ಯಾಕರ್ ಮೈಕ್ರೋವಿಎಮ್‌ಗಳು)

## ಅಧ್ಯಾಯಗಳು

- 0:00 - ಆರ್ಕಿಟೆಕ್ಚರ್ ವಾಲ್ ಮತ್ತು ಮಾಸ್ಟರ್ ಬ್ಲೂಪ್ರಿಂಟ್
- 0:57 - 01. ಲಂಬ ವರ್ಸಸ್ ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್
- 2:17 - 02. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (L4 ವರ್ಸಸ್ L7 ಮತ್ತು ಹೆಲ್ತ್ ಚೆಕ್‌ಗಳು)
- 3:45 - 03. ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಎಲಾಸ್ಟಿಸಿಟಿ
- 4:50 - 04. ಸರ್ವರ್‌ಲೆಸ್ (FaaS ಮತ್ತು ಫೈರ್‌ಕ್ರ್ಯಾಕರ್ ಮೈಕ್ರೋವಿಎಮ್‌ಗಳು)
- 6:05 - 05. ಈವೆಂಟ್-ಡ್ರೈವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (EDA ಮತ್ತು ಡಿಕಪ್ಲಿಂಗ್)
- 7:13 - 06. ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್ (ಡಾಕರ್ ಮತ್ತು ಕ್ಯೂಬರ್ನೆಟಿಸ್)
- 8:16 - 07. 4 ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಪಿಲ್ಲರ್‌ಗಳು (S3, EBS, DBs ಮತ್ತು Redis)
- 9:44 - 08. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು ನೈನ್ಸ್ (ಮಲ್ಟಿ-AZ ಫೇಲ್ಓವರ್)
- 10:53 - 09. ಡ್ಯೂರಬಿಲಿಟಿ ವರ್ಸಸ್ ಲಭ್ಯತೆ (ಏಕೆ 11 ನೈನ್ಸ್ ಅಪ್‌ಟೈಮ್ ಅಲ್ಲ)
- 12:14 - 10. ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಆಸ್ ಕೋಡ್ (ಟೆರಾಫಾರ್ಮ್ ವರ್ಸಸ್ ಕನ್ಸೋಲ್ ಡ್ರಿಫ್ಟ್)
- 13:20 - 11. ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ (VPC, ಸಬ್‌ನೆಟ್‌ಗಳು, NAT ಮತ್ತು ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು)
- 14:26 - 12. ಸಂಪೂರ್ಣ ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲೂಪ್ರಿಂಟ್ ಮತ್ತು ತೀರ್ಪು

## ಅನುವಾದಿತ ಪ್ರತಿಲೇಖನ

ಮೂಲ ಇಂಗ್ಲಿಷ್ ನಿರೂಪಣೆಯಿಂದ ಅನುವಾದಿಸಲಾಗಿದೆ. ಲಭ್ಯವಿರುವ ಆಡಿಯೋ ಮತ್ತು ಶೀರ್ಷಿಕೆಗಳನ್ನು YouTube ನಿಯಂತ್ರಿಸುತ್ತದೆ.

### - ಆರ್ಕಿಟೆಕ್ಚರ್ ವಾಲ್ ಮತ್ತು ಮಾಸ್ಟರ್ ಬ್ಲೂಪ್ರಿಂಟ್

0:00 ಪ್ರತಿಯೊಬ್ಬ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್ ಅಂತಿಮವಾಗಿ ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಗೋಡೆಯನ್ನು ಎದುರಿಸುತ್ತಾರೆ. ನೀವು ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ತಳ್ಳುತ್ತೀರಿ, ಮತ್ತು ನಿಜವಾದ ಬಳಕೆದಾರರು ಬಂದ ತಕ್ಷಣ, ಸರ್ವರ್‌ಗಳು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ, ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳು ಖಾಲಿಯಾಗುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ AWS ಬಿಲ್ ಫೋನ್ ಸಂಖ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಹೆಚ್ಚಿನ ಡೆವಲಪರ್‌ಗಳು ಮೂರು ನೂರು ವಿಭಿನ್ನ AWS ಉತ್ಪನ್ನಗಳ ಅಕ್ರೊನಿಮ್‌ಗಳನ್ನು ಕಂಠಪಾಠ ಮಾಡುವ ಮೂಲಕ ಕ್ಲೌಡ್ ಇಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಮೂರು ನೂರು ವಿಭಿನ್ನ AWS ಉತ್ಪನ್ನಗಳ ಅಕ್ರೊನಿಮ್‌ಗಳು. ಆದರೆ ನಿಜವಾದ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮಾರಾಟಗಾರರ ಕ್ಯಾಟಲಾಗ್‌ಗಳನ್ನು ಕಂಠಪಾಠ ಮಾಡುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ: ಇದು ಹನ್ನೊಂದು ಮೂಲಭೂತ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಪ್ರಿಮಿಟಿವ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿತವಾಗಿದೆ.

0:34 ಈ ಮಾಸ್ಟರ್‌ಕ್ಲಾಸ್‌ನಲ್ಲಿ, ನಾವು ಸಂಪೂರ್ಣ ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲೂಪ್ರಿಂಟ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ: ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್‌ನಿಂದ ಹಿಡಿದು ಸರ್ವರ್‌ಲೆಸ್, ಈವೆಂಟ್-ಡ್ರೈವನ್ ಡಿಕಪ್ಲಿಂಗ್, ಶೇಖರಣಾ ಕ್ರಮಾನುಗತಗಳು ಮತ್ತು ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕಿಂಗ್. ಈ ಹನ್ನೊಂದು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಿ, ಮತ್ತು ನೀವು AWS, GCP, ಅಥವಾ Azure ನಲ್ಲಿ ಯಾವುದೇ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು. GCP, ಅಥವಾ Azure. ಇದು The Daily Diff, ತೆರೆಮರೆಯಲ್ಲಿ.

### - 01. ಲಂಬ ವರ್ಸಸ್ ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್

0:57 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಒಂದು: ಸ್ಕೇಲಿಂಗ್. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಬೆಳವಣಿಗೆಯನ್ನು ಅನುಭವಿಸಿದಾಗ, ಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಎರಡು ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನ ಮಾರ್ಗಗಳಿವೆ: ಲಂಬ ಸ್ಕೇಲಿಂಗ್, ಅಥವಾ ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್. ಲಂಬ ಸ್ಕೇಲಿಂಗ್, ಅಥವಾ ಸ್ಕೇಲಿಂಗ್ ಅಪ್, ನಿಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯಂತ್ರವನ್ನು ತೆಗೆದುಕೊಂಡು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇರಿಸುವುದು ಎಂದರ್ಥ: ನಾಲ್ಕು CPU ಕೋರ್‌ಗಳಿಂದ ಮೂವತ್ತೆರಡಕ್ಕೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು, ನಾಲ್ಕು CPU ಕೋರ್‌ಗಳಿಂದ ಮೂವತ್ತೆರಡಕ್ಕೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು, ಅಥವಾ ಮೂವತ್ತೆರಡು ಗಿಗಾಬೈಟ್‌ಗಳ RAM ಅನ್ನು ನೂರಾ ಇಪ್ಪತ್ತೆಂಟಕ್ಕೆ ಬದಲಾಯಿಸುವುದು. ಮೂವತ್ತೆರಡು ಗಿಗಾಬೈಟ್‌ಗಳ RAM ಅನ್ನು ನೂರಾ ಇಪ್ಪತ್ತೆಂಟಕ್ಕೆ ಬದಲಾಯಿಸುವುದು. ನೂರಾ ಇಪ್ಪತ್ತೆಂಟಕ್ಕೆ. ಲಂಬ ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಶೂನ್ಯ ವಾಸ್ತುಶಿಲ್ಪದ ಬದಲಾವಣೆಗಳು ಬೇಕಾಗುತ್ತವೆ: ನಿಮ್ಮ ಕೋಡ್

1:28 ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಇರುತ್ತದೆ. ಆದರೆ ಅದು ಕ್ರೂರ ಹಾರ್ಡ್‌ವೇರ್ ಸೀಲಿಂಗ್ ಅನ್ನು ಹೊಡೆಯುತ್ತದೆ. ಪ್ರಪಂಚದ ಯಾವುದೇ ಒಂದು ಯಂತ್ರವು ಹತ್ತು ಸಾವಿರ CPU ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಉನ್ನತ ದರ್ಜೆಯ ನಿದರ್ಶನಗಳು ಘಾತೀಯ ಬೆಲೆಯ ಪ್ರೀಮಿಯಂ ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್, ಅಥವಾ ಸ್ಕೇಲಿಂಗ್ ಔಟ್, ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳನ್ನು ಸಣ್ಣ ಮತ್ತು ಸರಕು-ಬೆಲೆಯಿರಿಸುವುದು ಎಂದರ್ಥ, ಆದರೆ ರೂಟರ್‌ನ ಹಿಂದೆ ಸಮಾನಾಂತರವಾಗಿ ಅನೇಕ ನಿದರ್ಶನಗಳನ್ನು ಚಲಾಯಿಸುವುದು. ಒಂದು ನಿದರ್ಶನವು ಕ್ರ್ಯಾಶ್ ಆಗಿದರೆ, ಉಳಿದ ನೋಡ್‌ಗಳು ಶೂನ್ಯ ಅಡಚಣೆಯೊಂದಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೀರಿಕೊಳ್ಳುತ್ತವೆ. ಶೂನ್ಯ ಅಡಚಣೆ. ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್‌ನ ಸುವರ್ಣ ನಿಯಮವು

2:01 ನಿರ್ಬಂಧಿತವಲ್ಲದ ಸ್ಥಿತಿ (statelessness): ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ಬಳಕೆದಾರರ ಸೆಷನ್‌ಗಳನ್ನು, ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು, ಅಥವಾ ತಮ್ಮ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು, ಅಥವಾ ತಮ್ಮ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸ್ಥಿತಿ. ಸ್ಥಿತಿಯು ಬಾಹ್ಯ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಕ್ಯಾಷ್‌ನಲ್ಲಿ ಇರಬೇಕು, ಯಾವುದೇ ನೋಡ್ ಯಾವುದೇ ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

### - 02. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (L4 ವರ್ಸಸ್ L7 ಮತ್ತು ಹೆಲ್ತ್ ಚೆಕ್‌ಗಳು)

2:17 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಎರಡು: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್. ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್ ಕಾಗದದ ಮೇಲೆ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ತಕ್ಷಣದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ: ಹತ್ತು ಸಾವಿರ ಬಳಕೆದಾರರು ನಿಮ್ಮ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಹೊಡೆದಾಗ, ಯಾವ ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ಅವರ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ? ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್ ಮತ್ತು ನಿಮ್ಮ ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲಸ್ಟರ್ ನಡುವೆ ಕುಳಿತಿರುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ನಿಮ್ಮ ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲಸ್ಟರ್. ಇದು ಒಳಬರುವ TCP ಅಥವಾ HTTP ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಆರೋಗ್ಯಕರ ನಿದರ್ಶನಗಳಾದ್ಯಂತ ವಿನಂತಿಗಳನ್ನು ವಿತರಿಸುತ್ತದೆ.

2:47 ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಎರಡು ಪ್ರಾಥಮಿಕ ನೆಟ್‌ವರ್ಕ್ ಲೇಯರ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಲೇಯರ್ 4 ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಆಧರಿಸಿ ಕಚ್ಚಾ TCP ಮತ್ತು UDP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡುವುದು ಮೈಕ್ರೋಸೆಕೆಂಡ್ ಸುಪ್ತತೆ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಮಿಲಿಯನ್‌ಗಳಷ್ಟು ವಿನಂತಿಗಳೊಂದಿಗೆ. ಲೇಯರ್ 7 ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು HTTP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ. ಸ್ವತಃ: URL ಮಾರ್ಗಗಳು, ವಿನಂತಿ ಹೆಡರ್‌ಗಳು, ಕುಕಿಗಳು ಮತ್ತು HTTP ವಿಧಾನಗಳನ್ನು ಓದುವುದು. ವಿಧಾನಗಳು. ಇದು ಮಾರ್ಗ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ: ಸ್ಲಾಶ್-ಎಪಿಐ ವಿನಂತಿಗಳನ್ನು ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಮತ್ತು ಸ್ಲಾಶ್-ಸ್ಟ್ಯಾಟಿಕ್ ವಿನಂತಿಗಳನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರ್‌ಗೆ ಕಳುಹಿಸುವುದು. ವಿನಂತಿಗಳನ್ನು ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಮತ್ತು ಸ್ಲಾಶ್-ಸ್ಟ್ಯಾಟಿಕ್ ವಿನಂತಿಗಳನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರ್‌ಗೆ ಕಳುಹಿಸುವುದು.

3:25 ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರ್. ನಿರ್ಣಾಯಕವಾಗಿ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಸಕ್ರಿಯ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ. ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ, ಬ್ಯಾಲೆನ್ಸರ್ ಪ್ರತಿ ನಿದರ್ಶನದಲ್ಲಿ ಆರೋಗ್ಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಪಿಂಗ್ ಮಾಡುತ್ತದೆ. ಒಂದು ನಿದರ್ಶನವು ಸತತ ಮೂರು ಐದು ನೂರು ದೋಷಗಳನ್ನು ಎಸೆದರೆ ಅಥವಾ ಪ್ರತಿಕ್ರಿಯಿಸಲು ವಿಫಲವಾದರೆ, ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪೂಲ್‌ನಿಂದ ಹೊರಹಾಕಲ್ಪಡುತ್ತದೆ ಶೂನ್ಯ ಕೈಬಿಟ್ಟ ವಿನಂತಿಗಳು.

### - 03. ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಎಲಾಸ್ಟಿಸಿಟಿ

3:45 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಮೂರು: ಆಟೋಸ್ಕೇಲಿಂಗ್. ನಿಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬೆಳಿಗ್ಗೆ ಮೂರು ಗಂಟೆಗೆ ಎರಡು ಸರ್ವರ್‌ಗಳು ಬೇಕಾದರೆ, ಆದರೆ ಮಧ್ಯಾಹ್ನ ಬಿಡುಗಡೆಯ ಸಮಯದಲ್ಲಿ ಇಪ್ಪತ್ತು ಸರ್ವರ್‌ಗಳು ಬೇಕಾದರೆ, ಕ್ಲೌಡ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಬಟನ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡುವುದು ಅಡಚಣೆ ಮತ್ತು ದಿವಾಳಿತನಕ್ಕೆ ಖಾತರಿಯ ಮಾರ್ಗವಾಗಿದೆ. ಕ್ಲೌಡ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಬಟನ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡುವುದು ಅಡಚಣೆ ಮತ್ತು ದಿವಾಳಿತನಕ್ಕೆ ಖಾತರಿಯ ಮಾರ್ಗವಾಗಿದೆ. ಆಟೋಸ್ಕೇಲಿಂಗ್ ಅಡ್ಡ ಸರ್ವರ್ ಪೂಲ್‌ಗಳಿಗೆ ಡೈನಾಮಿಕ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ತರುತ್ತದೆ. ಆಟೋ ಸ್ಕೇಲಿಂಗ್ ಗುಂಪು ಸರಾಸರಿ CPU ಬಳಕೆ, ನೆಟ್‌ವರ್ಕ್ I-O, ಅಥವಾ ಕ್ಯೂ ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಂತಹ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ I-O, ಅಥವಾ ಕ್ಯೂ ಬ್ಯಾಕ್‌ಲಾಗ್ ಆಳ. ಸರಾಸರಿ CPU ವ್ಯಾಖ್ಯಾನಿತ ಮಿತಿಯನ್ನು ದಾಟಿದಾಗ - ಉದಾಹರಣೆಗೆ, ಸತತ ಮೂರು ನಿಮಿಷಗಳ ಕಾಲ ಎಪ್ಪತ್ತು ಪ್ರತಿಶತ - ಆಳ. ಸರಾಸರಿ CPU ವ್ಯಾಖ್ಯಾನಿತ ಮಿತಿಯನ್ನು ದಾಟಿದಾಗ - ಉದಾಹರಣೆಗೆ, ಸತತ ಮೂರು ನಿಮಿಷಗಳ ಕಾಲ ಎಪ್ಪತ್ತು ಪ್ರತಿಶತ -

4:19 ಸತತ ಮೂರು ನಿಮಿಷಗಳ ಕಾಲ ಎಪ್ಪತ್ತು ಪ್ರತಿಶತ - ಆಟೋಸ್ಕೇಲರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ನಿಮ್ಮ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನೊಂದಿಗೆ ಅವುಗಳನ್ನು ನೋಂದಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ರೂಟ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಅದೇ ರೀತಿ ಮುಖ್ಯವಾದುದು ಸ್ಕೇಲಿಂಗ್ ಇನ್: ಟ್ರಾಫಿಕ್ ಅಲೆ ಕಡಿಮೆಯಾದಾಗ, ಆಟೋಸ್ಕೇಲರ್ ಹೆಚ್ಚುವರಿ ನಿದರ್ಶನಗಳನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ ಆದ್ದರಿಂದ ನೀವು ನಿಷ್ಕ್ರಿಯ ಕಂಪ್ಯೂಟ್‌ಗಾಗಿ ಪಾವತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಫ್ಲಾಪಿಂಗ್ ಅನ್ನು ತಡೆಯಲು - ಸರ್ವರ್‌ಗಳನ್ನು ಅತೀವ ವೇಗದಲ್ಲಿ ರಚಿಸಿ ಮತ್ತು ಅಂತ್ಯವಿಲ್ಲದ ಥ್ರಾಶಿಂಗ್ ಲೂಪ್‌ನಲ್ಲಿ ನಾಶಪಡಿಸುವಲ್ಲಿ - ಅಂತ್ಯವಿಲ್ಲದ ಥ್ರಾಶಿಂಗ್ ಲೂಪ್‌ನಲ್ಲಿ ನಾಶಪಡಿಸುವಲ್ಲಿ - ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳು ಕೂಲ್‌ಡೌನ್ ಅವಧಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತಾರೆ. ಕೂಲ್‌ಡೌನ್ ಅವಧಿಗಳು. ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ನಾಲ್ಕು: ಸರ್ವರ್‌ಲೆಸ್.

### - 04. ಸರ್ವರ್‌ಲೆಸ್ (FaaS ಮತ್ತು ಫೈರ್‌ಕ್ರ್ಯಾಕರ್ ಮೈಕ್ರೋವಿಎಮ್‌ಗಳು)

4:53 ವರ್ಷಗಳಿಂದ, ಮಾರ್ಕೆಟಿಂಗ್ ತಂಡಗಳು ಸರ್ವರ್‌ಲೆಸ್ ಅನ್ನು ಆಕಾಶದಲ್ಲಿ ಚಲಿಸುವ ಮ್ಯಾಜಿಕ್ ಕೋಡ್ ಎಂದು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತಿದ್ದವು. ಆಕಾಶದಲ್ಲಿ ಚಲಿಸುವ ಕೋಡ್. ವಾಸ್ತವದಲ್ಲಿ, ಸರ್ವರ್‌ಲೆಸ್ ಇನ್ನೂ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ - ಆದರೆ ಯಾವುದೇ ಕೋಡ್ ಚಾಲನೆಯಲ್ಲಿಲ್ಲದಿದ್ದಾಗ ನೀವು ಅವುಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಪ್ಯಾಚ್ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಪಾವತಿಸುವುದಿಲ್ಲ. ಪ್ಯಾಚ್ ಮಾಡುವುದಿಲ್ಲ, ಅಥವಾ ಅವುಗಳಿಗಾಗಿ ಪಾವತಿಸುವುದಿಲ್ಲ. AWS ಲ್ಯಾಂಬ್ಡಾ ಅಥವಾ Google ಕ್ಲೌಡ್ ಫಂಕ್ಷನ್‌ಗಳಂತಹ ಫಂಕ್ಷನ್-ಆಸ್-ಎ-ಸರ್ವೀಸ್‌ನೊಂದಿಗೆ, ನೀವು ಸ್ವತಂತ್ರ ಹ್ಯಾಂಡ್ಲರ್ ಕಾರ್ಯವನ್ನು ಬರೆಯುತ್ತೀರಿ. HTTP ವಿನಂತಿ, S3 ಫೈಲ್ ಅಪ್‌ಲೋಡ್, ಅಥವಾ ಡೇಟಾಬೇಸ್ ಬದಲಾವಣೆ ಸಂಭವಿಸಿದಾಗ, ಸಂಭವಿಸುತ್ತದೆ, ಕ್ಲೌಡ್ ರನ್‌ಟೈಮ್ ಐದು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳೊಳಗೆ ಫೈರ್‌ಕ್ರ್ಯಾಕರ್‌ನಂತಹ ಎಫೆಮರಲ್ ಮೈಕ್ರೋ-ವರ್ಚುವಲ್-ಯಂತ್ರವನ್ನು ಬೂಟ್ ಮಾಡುತ್ತದೆ.

5:23 ಮೈಕ್ರೋ-ವರ್ಚುವಲ್-ಯಂತ್ರವನ್ನು ಐದು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳೊಳಗೆ ಬೂಟ್ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ. ಮೂರು ತಿಂಗಳ ಕಾಲ ಯಾರೂ ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡದಿದ್ದರೆ, ನಿಮ್ಮ ಕಂಪ್ಯೂಟ್ ಬಿಲ್ ನಿಖರವಾಗಿ ಶೂನ್ಯ ಡಾಲರ್‌ಗಳು ಮತ್ತು ಶೂನ್ಯ ಸೆಂಟ್‌ಗಳು. ಶೂನ್ಯ ಡಾಲರ್‌ಗಳು ಮತ್ತು ಶೂನ್ಯ ಸೆಂಟ್‌ಗಳು. ಒಂದು ಮಿಲಿಯನ್ ಬಳಕೆದಾರರು ಏಕಕಾಲದಲ್ಲಿ ಅದನ್ನು ಹೊಡೆದರೆ, ಪೂರೈಕೆದಾರರು ಒಂದು ಮಿಲಿಯನ್ ಏಕಕಾಲೀನ ಮೈಕ್ರೋವಿಎಮ್‌ಗಳನ್ನು ಸ್ಪಿನ್ ಅಪ್ ಮಾಡುತ್ತಾರೆ. ಏಕಕಾಲೀನ ಮೈಕ್ರೋವಿಎಮ್‌ಗಳು. ಇಂಜಿನಿಯರಿಂಗ್ ವಿನಿಮಯಗಳು ನೈಜವಾಗಿವೆ: ಹೊಸ ರನ್‌ಟೈಮ್‌ಗಳನ್ನು ಸ್ಪಿನ್ ಅಪ್ ಮಾಡುವಾಗ ಕೋಲ್ಡ್ ಸ್ಟಾರ್ಟ್ ಸುಪ್ತತೆ, ಲ್ಯಾಂಬ್ಡಾದಲ್ಲಿ ಹದಿನೈದು ನಿಮಿಷಗಳ ಕಠಿಣ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಿತಿ, ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿರ್ಬಂಧಿತವಲ್ಲದ ಸ್ಥಿತಿ. ಲ್ಯಾಂಬ್ಡಾದಲ್ಲಿ ಹದಿನೈದು ನಿಮಿಷಗಳ ಕಠಿಣ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಿತಿ, ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿರ್ಬಂಧಿತವಲ್ಲದ ಸ್ಥಿತಿ.

5:55 ಸರ್ವರ್‌ಲೆಸ್ ಈವೆಂಟ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಮತ್ತು ವಿರಳ API ಗಳಿಗೆ ಅಜೇಯವಾಗಿದೆ, ಆದರೆ ನಿರಂತರ ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು ಅಥವಾ ಹಲವು-ಗಂಟೆಗಳ ತರಬೇತಿ ರನ್‌ಗಳಿಗೆ ಇದು ಸೂಕ್ತವಲ್ಲ.

### - 05. ಈವೆಂಟ್-ಡ್ರೈವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (EDA ಮತ್ತು ಡಿಕಪ್ಲಿಂಗ್)

6:05 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಐದು: ಈವೆಂಟ್-ಡ್ರೈವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್, ಅಥವಾ EDA. ಸಾಂಪ್ರದಾಯಿಕ ವಾಸ್ತುಶಿಲ್ಪಗಳಲ್ಲಿ, ಸೇವೆಗಳು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ನಿಮ್ಮ ಚೆಕ್‌ಔಟ್ ಸೇವೆ ಪಾವತಿಯನ್ನು ಕರೆಯುತ್ತದೆ, ಪಾವತಿ ಇನ್ವೆಂಟರಿಯನ್ನು ಕರೆಯುತ್ತದೆ, ಇನ್ವೆಂಟರಿ ವಂಚನೆಯನ್ನು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ವಂಚನೆ ಇಮೇಲ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಇನ್ವೆಂಟರಿ ವಂಚನೆಯನ್ನು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ವಂಚನೆ ಇಮೇಲ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಇದು ಸಿಂಕ್ರೊನಸ್ ದುರಂತದ ಹಾದಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಥರ್ಡ್-ಪಾರ್ಟಿ ಇಮೇಲ್ ಪೂರೈಕೆದಾರರು ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸಿದರೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಿಸಲು ಹತ್ತು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ನಿಮ್ಮ ಗ್ರಾಹಕರ ಸಂಪೂರ್ಣ ಚೆಕ್‌ಔಟ್ ವಿನಂತಿಯು ದೋಷದೊಂದಿಗೆ ಕಾಲಾವಧಿ ಮುಗಿಯುತ್ತದೆ. ದೋಷದೊಂದಿಗೆ. ಈವೆಂಟ್-ಡ್ರೈವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಸೇವೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಂಗತವಾಗಿರುತ್ತವೆ.

6:37 ಗ್ರಾಹಕರು ಖರೀದಿಸಲು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಚೆಕ್‌ಔಟ್ ಸೇವೆ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಗಳನ್ನು ಕರೆಯುವುದಿಲ್ಲ. ಇದು ಆರ್ಡರ್‌ಪ್ಲೇಸ್ಡ್ ಎಂಬ ಈವೆಂಟ್ ಅನ್ನು Amazon EventBridge ಅಥವಾ SNS ವಿಷಯದಂತಹ ಕೇಂದ್ರೀಯ ಈವೆಂಟ್ ಬಸ್‌ಗೆ ಪ್ರಕಟಿಸುತ್ತದೆ. ಈವೆಂಟ್ ಬಸ್ ಲೈಕ್ Amazon EventBridge ಅಥವಾ SNS ವಿಷಯ. ಚೆಕ್‌ಔಟ್ ಐವತ್ತು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಪಾವತಿ, ದಾಸ್ತಾನು ಕಡಿತ, ಮತ್ತು ಇಮೇಲ್ ರಸೀದಿಗಳಿಗಾಗಿ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ವರ್ಕರ್‌ಗಳು ತಮ್ಮದೇ ಆದ ಮೀಸಲಾದ SQS ಕ್ಯೂಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಎಳೆಯುತ್ತವೆ. ತಮ್ಮದೇ ಆದ ಮೀಸಲಾದ SQS ಕ್ಯೂಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಎಳೆಯುತ್ತವೆ. ಒಂದು ಗಂಟೆ ಇಮೇಲ್ ಸೇವೆ ಸ್ಥಗಿತಗೊಂಡರೆ, ಸಂದೇಶಗಳು ಕ್ಯೂನಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿ ಬಫರ್ ಆಗಿ ಕಾಯುತ್ತವೆ, ಒಂದೇ ಒಂದು ಆರ್ಡರ್ ಸಹ ಕೈಬಿಡುವುದಿಲ್ಲ. ಒಂದೇ ಒಂದು ಆರ್ಡರ್ ಸಹ ಕೈಬಿಡುವುದಿಲ್ಲ.

### - 06. ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್ (ಡಾಕರ್ ಮತ್ತು ಕ್ಯೂಬರ್ನೆಟಿಸ್)

7:13 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಆರು: ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್. ಡಾಕರ್ ಪ್ಯಾಕೇಜಿಂಗ್ ಅನ್ನು ಪರಿಹರಿಸಿದೆ: ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್, ಸಿಸ್ಟಮ್ ಲೈಬ್ರರಿಗಳು, ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ರನ್‌ಟೈಮ್ ಅನ್ನು ನಿಮ್ಮ ಮ್ಯಾಕ್‌ಬುಕ್‌ನಲ್ಲಿ ಮತ್ತು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬದಲಾಯಿಸಲಾಗದ ಚಿತ್ರವಾಗಿ ಸುತ್ತಿಡುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಲೈಬ್ರರಿಗಳು, ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ರನ್‌ಟೈಮ್ ಅನ್ನು ನಿಮ್ಮ ಮ್ಯಾಕ್‌ಬುಕ್‌ನಲ್ಲಿ ಮತ್ತು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬದಲಾಯಿಸಲಾಗದ ಚಿತ್ರವಾಗಿ ಸುತ್ತಿಡುತ್ತದೆ. ಆದರೆ ಕಂಟೈನರ್ ಅನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡುವುದು ಸುಲಭ. ಐವತ್ತು ಭೌತಿಕ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಾದ್ಯಂತ ಐನೂರು ಕಂಟೈನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಎಲ್ಲಿ ಎಂಜಿನಿಯರಿಂಗ್ ಕುಸಿಯುತ್ತದೆ. ಎಂಜಿನಿಯರಿಂಗ್ ಕುಸಿಯುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ಕ್ಯೂಬರ್ನೆಟಿಸ್ ಮತ್ತು AWS ECS ನಂತಹ ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ.

7:41 ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಿಯಂತ್ರಣ ಫಲಕವನ್ನು ಒದಗಿಸುತ್ತದೆ: ಒಂದು API ಸರ್ವರ್, ಒಂದು etcd ಸ್ಟೇಟ್ ಸ್ಟೋರ್, ಮತ್ತು ಒಂದು ಬುದ್ಧಿವಂತ ಶೆಡ್ಯೂಲರ್. ಒಂದು etcd ಸ್ಟೇಟ್ ಸ್ಟೋರ್, ಮತ್ತು ಒಂದು ಬುದ್ಧಿವಂತ ಶೆಡ್ಯೂಲರ್. ನಿಮ್ಮ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ನೀವು ಘೋಷಿಸುತ್ತೀರಿ: ನನಗೆ ನನ್ನ ದೃಢೀಕರಣ ಸೇವೆಗಾಗಿ ಹತ್ತು ಪ್ರತಿಕೃತಿಗಳು ಬೇಕು, ಪ್ರತಿಯೊಂದೂ ಎರಡು ಗಿಗಾಬೈಟ್‌ಗಳ RAM ನೊಂದಿಗೆ. ಶೆಡ್ಯೂಲರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಖಾಲಿ ಮೆಮೊರಿ ಹೊಂದಿರುವ ನೋಡ್‌ಗಳಲ್ಲಿ ಪಾಡ್‌ಗಳನ್ನು ಇರಿಸುತ್ತದೆ, ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ನಿರಂತರವಾಗಿ ವಾಸ್ತವವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಒಂದು ನೋಡ್ ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯವನ್ನು ಅನುಭವಿಸಿದರೆ, ಕ್ಯೂಬರ್ನೆಟಿಸ್ ನಷ್ಟವನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ತಕ್ಷಣವೇ ಎಲ್ಲಾ ಸ್ಥಳಾಂತರಗೊಂಡ ಪಾಡ್‌ಗಳನ್ನು ಆರೋಗ್ಯಕರ ನೋಡ್‌ಗಳಿಗೆ ಮರು-ನಿಗದಿಪಡಿಸುತ್ತದೆ.

### - 07. 4 ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಪಿಲ್ಲರ್‌ಗಳು (S3, EBS, DBs ಮತ್ತು Redis)

8:16 ಆರೋಗ್ಯಕರ ನೋಡ್‌ಗಳು. ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಏಳು: ಕ್ಲೌಡ್ ಸಂಗ್ರಹಣೆ ಕ್ರಮಾನುಗತ. ಆರಂಭಿಕರು ಹೆಚ್ಚಾಗಿ ಕ್ಲೌಡ್ ಸಂಗ್ರಹಣೆಯನ್ನು ನೀವು ಫೈಲ್‌ಗಳನ್ನು ಎಸೆಯುವ ಒಂದೇ ಬಕೆಟ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ. ಫೈಲ್‌ಗಳು. ಉತ್ಪಾದನಾ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ, ಸಂಗ್ರಹಣೆಯನ್ನು ಪ್ರವೇಶ ಮಾದರಿಗಳು ಮತ್ತು ಸುಪ್ತತೆಯ ಆಧಾರದ ಮೇಲೆ ನಾಲ್ಕು ವಿಭಿನ್ನ ಸ್ತಂಭಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಪ್ರವೇಶ ಮಾದರಿಗಳು ಮತ್ತು ಸುಪ್ತತೆ. ಮೊದಲನೆಯದು ಆಬ್ಜೆಕ್ಟ್ ಸಂಗ್ರಹಣೆ, Amazon S3 ಅಥವಾ Google ಕ್ಲೌಡ್ ಸಂಗ್ರಹಣೆಯಂತೆ. ಸಂಗ್ರಹಣೆ. ನೀವು HTTP REST API ಗಳ ಮೂಲಕ ಫೈಲ್‌ಗಳನ್ನು ಸರಳ PUT ಮತ್ತು GET ಕರೆಗಳನ್ನು ಬಳಸಿ ಪ್ರವೇಶಿಸುತ್ತೀರಿ. ಸರಳ PUT ಮತ್ತು GET ಕರೆಗಳು. ಇದು ಪ್ರತಿ ತಿಂಗಳು ಪ್ರತಿ ಗಿಗಾಬೈಟ್‌ಗೆ ಎರಡು ಸೆಂಟ್‌ಗಳಿಗೆ ಅನಂತ ಅಡ್ಡ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ,

8:49 ವೀಡಿಯೊ, ಬಳಕೆದಾರರ ಅಪ್‌ಲೋಡ್‌ಗಳು, ಲಾಗ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕಪ್‌ಗಳಿಗೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ. ಎರಡನೆಯದು ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆ, Amazon EBS ನಂತೆ. ಇವುಗಳು ನಿರ್ದಿಷ್ಟ ವರ್ಚುವಲ್ ಯಂತ್ರಕ್ಕೆ ಹೆಚ್ಚಿನ ವೇಗದ ಇಂಟರ್‌ಕನೆಕ್ಟ್‌ಗಳ ಮೂಲಕ ನೇರವಾಗಿ ಮೌಂಟ್ ಮಾಡಲಾದ ವರ್ಚುವಲ್ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳಾಗಿವೆ. ಹೆಚ್ಚಿನ ವೇಗದ ಇಂಟರ್‌ಕನೆಕ್ಟ್‌ಗಳ ಮೂಲಕ. ಅವು ext4 ನಂತಹ ಪ್ರಮಾಣಿತ ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ಗಳಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಆಗುತ್ತವೆ, ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್‌ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ವೇಗದ ಯಾದೃಚ್ಛಿಕ ಓದು ಮತ್ತು ಬರವಣಿಗೆ ಪ್ರವೇಶವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಎಂಜಿನ್‌ಗಳು. ಮೂರನೆಯದು ನಿರ್ವಹಿಸಲಾದ ಡೇಟಾಬೇಸ್‌ಗಳು: PostgreSQL ನಂತಹ ಸಂಬಂಧಿತ ಎಂಜಿನ್‌ಗಳು RDS ನಲ್ಲಿ ACID ವಹಿವಾಟುಗಳು ಮತ್ತು ಸಂಕೀರ್ಣ ಸೇರ್ಪಡೆಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ,

9:21 ಮತ್ತು DynamoDB ನಂತಹ NoSQL ಎಂಜಿನ್‌ಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಏಕ-ಅಂಕಿಯ ಮಿಲಿಸೆಕೆಂಡ್ ಸುಪ್ತತೆಯನ್ನು ನೀಡುತ್ತವೆ. ಮಿಲಿಸೆಕೆಂಡ್ ಸುಪ್ತತೆ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ. ಮತ್ತು ನಾಲ್ಕನೆಯದು Redis ನಂತಹ ಇನ್-ಮೆಮೊರಿ ಕ್ಯಾಶ್‌ಗಳು. RAM ನಿಂದ ಡೇಟಾವನ್ನು ಓದಲು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಬದಲಿಗೆ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಕ್ಯಾಶ್‌ಗಳು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ಮುಂದೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ, ಪುನರಾವರ್ತಿತ ಓದುವ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಅದನ್ನು ರಕ್ಷಿಸುತ್ತವೆ ಮತ್ತು ಅಸ್ಥಿರ ಬಳಕೆದಾರ ಸೆಷನ್ ಟೋಕನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ.

### - 08. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು ನೈನ್ಸ್ (ಮಲ್ಟಿ-AZ ಫೇಲ್ಓವರ್)

9:44 ಪರಿಕಲ್ಪನೆ ಸಂಖ್ಯೆ ಎಂಟು: ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ, ಅಥವಾ HA. ಲಭ್ಯತೆಯು ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತಲುಪುತ್ತದೆ? ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತಲುಪುತ್ತದೆ? ಎಂಟರ್‌ಪ್ರೈಸ್ ಒಪ್ಪಂದಗಳಲ್ಲಿ, ಲಭ್ಯತೆಯನ್ನು ನೈನ್ಸ್‌ನಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ. ಎರಡು ನೈನ್ಸ್, ಅಥವಾ ತೊಂಬತ್ತೊಂಬತ್ತು ಪ್ರತಿಶತ ಲಭ್ಯತೆ, ಪ್ರತಿ ವರ್ಷ ಮೂರೂವರೆ ದಿನಗಳಿಗಿಂತ ಹೆಚ್ಚು ಅಡಚಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಅರ್ಧ ದಿನಗಳ ಅಡಚಣೆ ಪ್ರತಿ ವರ್ಷ. ನಾಲ್ಕು ನೈನ್ಸ್ ಅನುಮತಿಸಲಾದ ಅಡಚಣೆಯನ್ನು ಐವತ್ತೆರಡು ನಿಮಿಷಗಳಿಗೆ ಇಳಿಸುತ್ತದೆ, ಮತ್ತು ಐದು ನೈನ್ಸ್ ಪ್ರತಿ ವರ್ಷ ಕೇವಲ ಐದು ನಿಮಿಷಗಳ ಒಟ್ಟು ಅಡಚಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

10:15 ಪ್ರತಿ ವರ್ಷ. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಸಾಧಿಸಲು, ನೀವು ವೈಫಲ್ಯದ ಡೊಮೇನ್‌ಗಳಾದ್ಯಂತ ಏಕ ವೈಫಲ್ಯದ ಅಂಶಗಳನ್ನು ತೆಗೆದುಹಾಕಬೇಕು. ವೈಫಲ್ಯದ ಡೊಮೇನ್‌ಗಳಾದ್ಯಂತ. ಕ್ಲೌಡ್‌ನಲ್ಲಿ, ಅಂದರೆ ಅನೇಕ ಲಭ್ಯತಾ ವಲಯಗಳಾದ್ಯಂತ ನಿಯೋಜಿಸುವುದು. ಒಂದು ಲಭ್ಯತಾ ವಲಯವು ಒಂದೇ ರ್ಯಾಕ್ ಅಲ್ಲ: ಇದು ಸ್ವತಂತ್ರ ವಿದ್ಯುತ್ ಮತ್ತು ಕೂಲಿಂಗ್ ಹೊಂದಿರುವ ಮೈಲಿಗಟ್ಟಲೆ ಅಂತರದಲ್ಲಿರುವ ಒಂದು ಅಥವಾ ಹೆಚ್ಚು ವಿಭಿನ್ನ ಭೌತಿಕ ಡೇಟಾ ಕೇಂದ್ರಗಳಾಗಿವೆ. ಭೌತಿಕ ಡೇಟಾ ಕೇಂದ್ರಗಳು ಮೈಲಿಗಟ್ಟಲೆ ಅಂತರದಲ್ಲಿ ಸ್ವತಂತ್ರ ವಿದ್ಯುತ್ ಮತ್ತು ಕೂಲಿಂಗ್‌ನೊಂದಿಗೆ. ಸಿಂಕ್ರೊನಸ್ ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ವಲಯ A ಮತ್ತು ವಲಯ B ಯಲ್ಲಿ ಸಕ್ರಿಯ ನಿದರ್ಶನಗಳನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ, ಸಿಂಕ್ರೊನಸ್ ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿ, ಸಂಪೂರ್ಣ ಭೌತಿಕ ಸೌಲಭ್ಯವನ್ನು ಕೆಳಗೆ ತರುವ ಮಿಂಚಿನ ಹೊಡೆತ ಅಥವಾ ಫೈಬರ್ ಕಡಿತವು ಸಂಪೂರ್ಣ ಭೌತಿಕ ಸೌಲಭ್ಯವು ಸ್ವಯಂಚಾಲಿತ ಫೇಲ್ಓವರ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

10:50 ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಯಾವುದೇ ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ.

### - 09. ಡ್ಯೂರಬಿಲಿಟಿ ವರ್ಸಸ್ ಲಭ್ಯತೆ (ಏಕೆ 11 ನೈನ್ಸ್ ಅಪ್‌ಟೈಮ್ ಅಲ್ಲ)

10:53 ಸಂಕಲ್ಪ ಒಂಬತ್ತು: ಬಾಳಿಕೆ ವಿರುದ್ಧ ಲಭ್ಯತೆ. ಇದು ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸಂದರ್ಶನಗಳಲ್ಲಿ ಕಂಡುಬರುವ ಏಕೈಕ ಸಾಮಾನ್ಯ ಕಲ್ಪನಾತ್ಮಕ ತಪ್ಪು. ಎಂಜಿನಿಯರ್‌ಗಳು ಪದಗಳನ್ನು ಪರಸ್ಪರ ಬದಲಿಯಾಗಿ ಬಳಸುತ್ತಾರೆ, ಆದರೆ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅಳೆಯುತ್ತವೆ. ಲಭ್ಯತೆಯು ಅಪ್‌ಟೈಮ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆ: ನನ್ನ ಡೇಟಾವನ್ನು ಓದಲು ಅಥವಾ ಬರೆಯಲು ನಾನು API ಕರೆಯನ್ನು ಇದೀಗ ಮಾಡಬಹುದೇ? ಡೇಟಾವನ್ನು ಇದೀಗ ಓದಲು ಅಥವಾ ಬರೆಯಲು API ಕರೆ ಮಾಡಬಹುದೇ? ಬಾಳಿಕೆ ಸಂರಕ್ಷಣೆಯನ್ನು ಅಳೆಯುತ್ತದೆ: ನನ್ನ ಡೇಟಾವು ಹತ್ತು ವರ್ಷಗಳಲ್ಲಿ ಶಾಶ್ವತ ಬಿಟ್ ಕೊಳೆತ, ಭ್ರಷ್ಟಾಚಾರ ಅಥವಾ ನಾಶವಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆಯೇ? ಬಿಟ್ ಕೊಳೆತ, ಭ್ರಷ್ಟಾಚಾರ ಅಥವಾ ನಾಶವಿಲ್ಲದೆ ಹತ್ತು ವರ್ಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆಯೇ?

11:24 Amazon S3 Standard ಅನ್ನು ನೋಡಿ. ಅದರ ಸೇವಾ ಮಟ್ಟದ ಒಪ್ಪಂದವು ತೊಂಬತ್ತೊಂಬತ್ತು ದಶಮಾಂಶ ಒಂಬತ್ತು ಪ್ರತಿಶತದಷ್ಟು ಲಭ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ, ಇದು ಪ್ರತಿ ತಿಂಗಳು ಸರಿಸುಮಾರು ನಲವತ್ತಮೂರು ನಿಮಿಷಗಳ ನಿಷ್ಕ್ರಿಯ ಸಮಯವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಅಲ್ಲಿ API ವಿನಂತಿಯು ಐನೂರು ದೋಷವನ್ನು ಹಿಂದಿರುಗಿಸಬಹುದು. ಆದರೆ S3 ಹನ್ನೊಂದು ಒಂಬತ್ತುಗಳ ಬಾಳಿಕೆಗೆ ಭರವಸೆ ನೀಡುತ್ತದೆ: ತೊಂಬತ್ತೊಂಬತ್ತು ದಶಮಾಂಶ ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಒಂಬತ್ತು ಪ್ರತಿಶತ. ನೀವು S3 ನಲ್ಲಿ ಹತ್ತು ಮಿಲಿಯನ್ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ಪ್ರತಿ ಹತ್ತು ಸಾವಿರ ವರ್ಷಗಳಲ್ಲಿ ಒಂದು ಫೈಲ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುವಿರಿ ಎಂದು ನೀವು ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ನಿರೀಕ್ಷಿಸಬಹುದು.

11:56 ಸರಾಸರಿ ಒಂದು ಫೈಲ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುವಿರಿ ಎಂದು ನಿರೀಕ್ಷಿಸಬಹುದು. ಕನಿಷ್ಠ ಮೂರು ಭೌಗೋಳಿಕವಾಗಿ ಬೇರ್ಪಟ್ಟ ಡೇಟಾ ಸೌಲಭ್ಯಗಳಾದ್ಯಂತ ಅಳಿಸುವಿಕೆ-ಕೋಡಿಂಗ್ ವಸ್ತುಗಳು ಮತ್ತು ಪ್ರತಿಕೃತಿ ಚಂಕ್‌ಗಳ ಮೂಲಕ S3 ಇದನ್ನು ಸಾಧಿಸುತ್ತದೆ. ಕನಿಷ್ಠ ಮೂರು ಭೌಗೋಳಿಕವಾಗಿ ಬೇರ್ಪಟ್ಟ ಡೇಟಾ ಸೌಲಭ್ಯಗಳಾದ್ಯಂತ ಚಂಕ್‌ಗಳನ್ನು ಪ್ರತಿಕೃತಿ ಮಾಡುವ ಮೂಲಕ S3 ಇದನ್ನು ಸಾಧಿಸುತ್ತದೆ. ಪ್ರಮುಖ ಪ್ರಾದೇಶಿಕ ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ, S3 ತಾತ್ಕಾಲಿಕವಾಗಿ ಲಭ್ಯವಿಲ್ಲದಿರಬಹುದು, ಆದರೆ ನಿಮ್ಮ ಡೇಟಾ ಎಂದಿಗೂ ನಾಶವಾಗುವುದಿಲ್ಲ.

### - 10. ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಆಸ್ ಕೋಡ್ (ಟೆರಾಫಾರ್ಮ್ ವರ್ಸಸ್ ಕನ್ಸೋಲ್ ಡ್ರಿಫ್ಟ್)

12:14 ಸಂಕಲ್ಪ ಹತ್ತು: ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ, ಅಥವಾ IaC. ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್‌ನ ಆರಂಭಿಕ ದಿನಗಳಲ್ಲಿ, ಇಂಜಿನಿಯರ್‌ಗಳು AWS ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಿದರು ವೆಬ್ ನಿರ್ವಹಣಾ ಕನ್ಸೋಲ್ ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಲು, ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಮತ್ತು ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು ಲಗತ್ತಿಸಲು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡಿದರು. ಯಂತ್ರಗಳನ್ನು ರಚಿಸಲು, ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಮತ್ತು ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು ಲಗತ್ತಿಸಲು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡಿದರು. ಕೈಗಾರಿಕೆಯು ಇದನ್ನು ClickOps ಎಂದು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ, ಇದು ಸಂಪೂರ್ಣ ದುರಂತ. ಹಸ್ತಚಾಲಿತ ಕನ್ಸೋಲ್ ಬದಲಾವಣೆಗಳಿಗೆ ಯಾವುದೇ ಆಡಿಟ್ ಟ್ರಯಲ್, ರೋಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ, ಮತ್ತು ಅನಿವಾರ್ಯವಾಗಿ ಸ್ಟೇಜಿಂಗ್ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರಗಳ ನಡುವೆ ಸಂರಚನಾ ಡ್ರಿಫ್ಟ್ ಉಂಟಾಗುತ್ತದೆ. ಉತ್ಪಾದನಾ ಪರಿಸರಗಳ ನಡುವೆ ಸಂರಚನಾ ಡ್ರಿಫ್ಟ್ ಉಂಟಾಗುತ್ತದೆ. ಟೆರಾಫಾರ್ಮ್‌ನಂತಹ ಮೂಲಸೌಕರ್ಯ

12:48 ಕೋಡ್ ಪರಿಕರಗಳಾಗಿ, OpenTofu, Pulumi, ಅಥವಾ AWS CDK, ನೀವು ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು Git ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಡಿಕ್ಲರೇಟಿವ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ. ಸಂಪೂರ್ಣ ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು Git ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಡಿಕ್ಲರೇಟಿವ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ. ಒಂದು ತೆರೆದ ಪೋರ್ಟ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಗೆ ಪ್ರತಿ ಬದಲಾವಣೆಯು ಪುಲ್ ವಿನಂತಿ ಮತ್ತು ಪೀರ್ ವಿಮರ್ಶೆಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಪುಲ್ ವಿನಂತಿ ಮತ್ತು ಪೀರ್ ವಿಮರ್ಶೆಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ. terraform plan ಅನ್ನು ಚಲಾಯಿಸುವುದು ಏನನ್ನೂ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ನಿಖರವಾದ API ಡಿಫ್ ಅನ್ನು ಪೂರ್ವವೀಕ್ಷಿಸುತ್ತದೆ, ಏನನ್ನೂ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ನಿಖರವಾದ API ಡಿಫ್ ಅನ್ನು ಪೂರ್ವವೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಸ್ಟಾಕ್‌ನ ಒಂದೇ ರೀತಿಯ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾಲ್ಕು ವಾರಗಳ ಬದಲಿಗೆ ನಾಲ್ಕು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

### - 11. ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ (VPC, ಸಬ್‌ನೆಟ್‌ಗಳು, NAT ಮತ್ತು ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು)

13:20 ಸಂಕಲ್ಪ ಹನ್ನೊಂದು: ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಮತ್ತು ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಕ್ಲೌಡ್‌ಗಳು. ನೀವು ಸರ್ವರ್‌ಗಳನ್ನು ಕ್ಲೌಡ್‌ಗೆ ನಿಯೋಜಿಸಿದಾಗ, ಅವು ಕಚ್ಚಾ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಬಹಿರಂಗವಾಗಿರುವುದಿಲ್ಲ. ಅವು VPC ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಾಫ್ಟ್‌ವೇರ್-ವ್ಯಾಖ್ಯಾನಿತ ಪ್ರತ್ಯೇಕ ಗಡಿಯೊಳಗೆ ವಾಸಿಸುತ್ತವೆ. VPC ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಾಫ್ಟ್‌ವೇರ್-ವ್ಯಾಖ್ಯಾನಿತ ಪ್ರತ್ಯೇಕ ಗಡಿಯೊಳಗೆ ವಾಸಿಸುತ್ತವೆ. ನಿಮ್ಮ VPC ಯೊಳಗೆ, ನೀವು ಹತ್ತು-ದಶಮಾಂಶ-ಶೂನ್ಯ-ದಶಮಾಂಶ-ಶೂನ್ಯ-ದಶಮಾಂಶ-ಶೂನ್ಯ ಸ್ಲಾಷ್ ಹದಿನಾರು ನಂತಹ ಖಾಸಗಿ IP ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಹಂಚಿಕೆ ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಅದನ್ನು ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೀರಿ. ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೀರಿ. ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್ ಇಂಟರ್ನೆಟ್ ಗೇಟ್‌ವೇಗೆ ನೇರ ಮಾರ್ಗವನ್ನು ಹೊಂದಿದೆ.

13:51 ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಮತ್ತು NAT ಗೇಟ್‌ವೇಗಳಂತಹ ಸಾರ್ವಜನಿಕ-ಮುಖಿ ಸ್ವತ್ತುಗಳನ್ನು ಹೊಂದಿದೆ. ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನ ಸಾರ್ವಜನಿಕ IP ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿರುವ ಏಕೈಕ ಭಾಗ ಇದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್‌ಗಳು ಸಾರ್ವಜನಿಕ IP ಗಳಿಲ್ಲದ ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ಗಳಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ವಾಸಿಸುತ್ತವೆ ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಶೂನ್ಯ ಒಳಬರುವ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳು ಭದ್ರತಾ ನವೀಕರಣಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾದಾಗ, ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಶೂನ್ಯ ಒಳಬರುವ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳು ಭದ್ರತಾ ನವೀಕರಣಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾದಾಗ, ಅವುಗಳ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿರುವ NAT ಗೇಟ್‌ವೇ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಪ್ರತಿ ನಿದರ್ಶನವನ್ನು ಸುತ್ತುವರೆದಿರುವ ಭದ್ರತಾ ಗುಂಪುಗಳು: ರಾಜ್ಯತ್ವ ಕನಿಷ್ಠ ಸವಲತ್ತುಗಳ ತತ್ವವನ್ನು ಜಾರಿಗೊಳಿಸುವ ವರ್ಚುವಲ್ ಫೈರ್‌ವಾಲ್‌ಗಳು.

### - 12. ಸಂಪೂರ್ಣ ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲೂಪ್ರಿಂಟ್ ಮತ್ತು ತೀರ್ಪು

14:28 ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಭದ್ರತಾ ಗುಂಪು ಪೋರ್ಟ್ 5432 ನಲ್ಲಿ ಸಂಪರ್ಕಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳ ಭದ್ರತಾ ಗುಂಪಿನಿಂದ ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ, 5432 ನಲ್ಲಿ ಸಂಪರ್ಕಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳ ಭದ್ರತಾ ಗುಂಪಿನಿಂದ ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಹೊರಗಿನ ನುಗ್ಗುವಿಕೆಯನ್ನು ಗಣಿತೀಯವಾಗಿ ಅಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ನೀವು ಹೊರಗೆ ಜೂಮ್ ಮಾಡಿದಾಗ, ಈ ಹನ್ನೊಂದು ಪ್ರಾಥಮಿಕಗಳು ಒಂದು ಸುಸಂಬದ್ಧ ವ್ಯವಸ್ಥೆಯಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ. ನಿಮ್ಮ DNS ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿರುವ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಮಾರ್ಗಗಳನ್ನು ನೀಡುತ್ತದೆ, ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್ ಗುಂಪುಗಳು ಬಹು ಲಭ್ಯತೆ ವಲಯಗಳಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಉಲ್ಬಣಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತವೆ, ಈವೆಂಟ್ ಬಸ್‌ಗಳು ಬ್ಯಾಕೆಂಡ್ ಕಾರ್ಯಕರ್ತರನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸ್ಟಾಕ್ ಅನ್ನು ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು Git ನಿಂದ ನಿಯೋಜಿಸಲಾಗಿದೆ.

15:02 ಇಂದಿನ ಮಾಸ್ಟರ್‌ಕ್ಲಾಸ್ ತೀರ್ಪು: SHIP IT. ನೂರಾರು ಕ್ಲೌಡ್ ಮಾರ್ಕೆಟಿಂಗ್ ಸಂಕ್ಷಿಪ್ತ ರೂಪಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಈ ಹನ್ನೊಂದು ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾದರಿಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಿ, ನಿಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ಬೇರ್ಪಡಿಸಿ, ಮತ್ತು ವಿಫಲವಾಗದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಿ. ನೀವು ಮೊದಲು ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಯಾವ ಕ್ಲೌಡ್ ಪರಿಕಲ್ಪನೆಯು ನಿಮಗೆ ದೊಡ್ಡ ತಲೆನೋವು ನೀಡಿತು ಎಂದು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ತಿಳಿಸಿ. ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಯಾವ ಕ್ಲೌಡ್ ಪರಿಕಲ್ಪನೆಯು ನಿಮಗೆ ದೊಡ್ಡ ತಲೆನೋವು ನೀಡಿತು ಎಂದು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ತಿಳಿಸಿ. ಮತ್ತು ಸಂಪೂರ್ಣ ಆರ್ಕಿಟೆಕ್ಚರ್ ಚೀಟ್ ಶೀಟ್ ಪಡೆಯಲು, daily diff dot dev ನಲ್ಲಿ ಸುದ್ದಿಪತ್ರಕ್ಕೆ ಚಂದಾದಾರರಾಗಿ,

15:28 ಲಿಂಕ್ ಕೆಳಗಿದೆ. ಮತ್ತು ಅದು ಇಂದಿನ ಡಿಫ್ ಆಗಿದೆ. ನಾನು Axrisi ನಿಂದ Niko. ಜವಾಬ್ದಾರಿಯುತವಾಗಿ ವಿಲೀನಗೊಳಿಸಿ.

## ಮೂಲಗಳು

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io