क्लाउड कंप्यूटिंग समझाया गया: 11 आर्किटेक्चर अवधारणाएं जिन्हें आपको जानना चाहिए (4K मास्टरक्लास)।

इस वीडियो में क्या शामिल है

• - आर्किटेक्चर वॉल और मास्टर ब्लूप्रिंट
• - 01. वर्टिकल बनाम हॉरिजॉन्टल स्केलिंग
• - 02. लोड बैलेंसिंग आर्किटेक्चर (L4 बनाम L7 और हेल्थ चेक)
• - 03. ऑटोस्केलिंग और इलास्टिसिटी
• - 04. सर्वरलेस (FaaS और फायरक्रैकर माइक्रोवीएम)

अनुवादित प्रतिलेख

मूल अंग्रेजी कथन से अनुवादित। उपलब्ध ऑडियो और कैप्शन YouTube द्वारा नियंत्रित होते हैं।

- आर्किटेक्चर वॉल और मास्टर ब्लूप्रिंट

0:00 हर सॉफ्टवेयर इंजीनियर अंततः क्लाउड आर्किटेक्चर वॉल का सामना करता है। आप अपने लैपटॉप पर एक एप्लिकेशन बनाते हैं, इसे उत्पादन में धकेलते हैं, और जैसे ही वास्तविक उपयोगकर्ता आते हैं, सर्वर क्रैश हो जाते हैं, डेटाबेस कनेक्शन पूल खत्म हो जाते हैं, और आपका AWS बिल एक फोन नंबर जैसा दिखता है। अधिकांश डेवलपर्स सैकड़ों अलग-अलग AWS उत्पाद परिवर्णी शब्दों को याद करके क्लाउड इंजीनियरिंग को हल करने की कोशिश करते हैं। लेकिन वास्तविक क्लाउड कंप्यूटिंग वेंडर कैटलॉग को याद करने के बारे में नहीं है: यह ग्यारह मौलिक आर्किटेक्चरल प्रिमिटिव्स पर आधारित है।

0:34 इस मास्टरक्लास में, हम पूरे एंटरप्राइज ब्लूप्रिंट पर चलेंगे: स्केलिंग और लोड बैलेंसिंग से लेकर सर्वरलेस, इवेंट-ड्रिवन डिकूपलिंग, स्टोरेज हायरार्की और क्लाउड नेटवर्किंग तक। इन ग्यारह अवधारणाओं में महारत हासिल करें, और आप AWS, GCP, या Azure पर किसी भी बैकएंड को डिज़ाइन कर सकते हैं। यह द डेली डिफ है, पर्दे के पीछे।

- 01. वर्टिकल बनाम हॉरिजॉन्टल स्केलिंग

0:57 अवधारणा संख्या एक: स्केलिंग। जब आपका एप्लिकेशन ट्रैफिक वृद्धि का अनुभव करता है, तो आपके पास लोड को संभालने के लिए दो मौलिक रूप से अलग तरीके होते हैं: वर्टिकल स्केलिंग, या हॉरिजॉन्टल स्केलिंग। वर्टिकल स्केलिंग, या स्केलिंग अप, का मतलब है आपकी मौजूदा मशीन लेना और अधिक संसाधन जोड़ना: चार सीपीयू कोर से बत्तीस तक अपग्रेड करना, या बत्तीस गीगाबाइट रैम को एक सौ अट्ठाईस से बदलना। वर्टिकल स्केलिंग के लिए शून्य आर्किटेक्चरल परिवर्तनों की आवश्यकता होती है: आपका कोड और डेटाबेस बिल्कुल वैसे ही रहते हैं।

1:28 लेकिन यह एक क्रूर हार्डवेयर सीमा से टकराता है। दुनिया में किसी भी एक मशीन में दस हजार सीपीयू कोर नहीं होते हैं, और टॉप-टियर इंस्टेंस एक घातीय मूल्य प्रीमियम लेते हैं। हॉरिजॉन्टल स्केलिंग, या स्केलिंग आउट, का मतलब है आपके सर्वर को छोटा और कमोडिटी-कीमत वाला रखना, लेकिन एक राउटर के पीछे समानांतर में कई इंस्टेंस चलाना। यदि एक इंस्टेंस क्रैश हो जाता है, तो शेष नोड शून्य डाउनटाइम के साथ ट्रैफिक को अवशोषित करते हैं। हॉरिजॉन्टल स्केलिंग का सुनहरा नियम स्टेटलेसनेस है: आपके एप्लिकेशन सर्वर अपनी स्थानीय डिस्क पर उपयोगकर्ता सत्रों,

2:01 अपलोड की गई फ़ाइलों, या स्थिति को संग्रहीत नहीं कर सकते हैं। स्थिति एक बाहरी डेटाबेस या कैश में रहनी चाहिए, जिससे कोई भी नोड किसी भी उपयोगकर्ता अनुरोध को संभाल सके। अवधारणा संख्या दो: लोड बैलेंसिंग।

- 02. लोड बैलेंसिंग आर्किटेक्चर (L4 बनाम L7 और हेल्थ चेक)

2:17 हॉरिजॉन्टल स्केलिंग कागज पर बहुत अच्छी लगती है, लेकिन यह एक तत्काल समस्या पैदा करती है: जब दस हजार उपयोगकर्ता आपके डोमेन नाम पर आते हैं, तो कौन सा विशिष्ट सर्वर उनका ट्रैफिक प्राप्त करता है? एक लोड बैलेंसर सार्वजनिक इंटरनेट और आपके निजी बैकएंड क्लस्टर के बीच बैठने वाले एक रिवर्स प्रॉक्सी के रूप में कार्य करता है। यह आने वाले TCP या HTTP कनेक्शन स्वीकार करता है और आपके स्वस्थ इंस्टेंस में अनुरोधों को वितरित करता है। लोड बैलेंसर दो प्राथमिक नेटवर्क परतों पर काम करते हैं।

2:47 लेयर 4 नेटवर्क लोड बैलेंसर ट्रांसपोर्ट लेयर पर काम करते हैं, IP एड्रेस और पोर्ट के आधार पर कच्चे TCP और UDP पैकेट को माइक्रोसेकंड विलंबता और प्रति सेकंड लाखों अनुरोधों के साथ रूट करते हैं। लेयर 7 एप्लिकेशन लोड बैलेंसर HTTP प्रोटोकॉल की ही जांच करते हैं: URL पाथ, रिक्वेस्ट हेडर, कुकीज़ और HTTP तरीके पढ़ना। यह पाथ-आधारित रूटिंग को सक्षम बनाता है: स्लैश-एपीआई अनुरोधों को आपके बैकएंड क्लस्टर पर भेजना और स्लैश-स्टेटिक अनुरोधों को एक ऑब्जेक्ट स्टोर पर भेजना। महत्वपूर्ण रूप से, लोड बैलेंसर सक्रिय स्वास्थ्य

3:25 जांच करते हैं। हर कुछ सेकंड में, बैलेंसर हर इंस्टेंस पर एक हेल्थ एंडपॉइंट को पिंग करता है। यदि कोई इंस्टेंस लगातार तीन पांच सौ त्रुटियां फेंकता है या प्रतिक्रिया देने में विफल रहता है, तो इसे पूल से स्वचालित रूप से शून्य ड्रॉप किए गए अनुरोधों के साथ हटा दिया जाता है। अवधारणा संख्या तीन: ऑटोस्केलिंग।

- 03. ऑटोस्केलिंग और इलास्टिसिटी

3:45 यदि आपके वेब ऐप को सुबह तीन बजे दो सर्वर की आवश्यकता है, लेकिन दोपहर के लॉन्च के दौरान बीस सर्वर की, तो क्लाउड कंसोल में मैन्युअल रूप से बटन क्लिक करना डाउनटाइम और दिवालिएपन का एक गारंटीकृत मार्ग है। ऑटोस्केलिंग हॉरिजॉन्टल सर्वर पूलों में गतिशील लचीलापन लाता है। एक ऑटो स्केलिंग ग्रुप औसत सीपीयू उपयोग, नेटवर्क आई-ओ, या कतार बैकलॉग गहराई जैसे प्रदर्शन मेट्रिक्स की निगरानी करता है। जब औसत सीपीयू एक परिभाषित सीमा को पार करता है - कहते हैं, लगातार तीन मिनट के लिए सत्तर प्रतिशत - तो ऑटोस्केलर स्वचालित रूप से

4:19 नई वर्चुअल मशीन लॉन्च करता है, उन्हें आपके लोड बैलेंसर के साथ पंजीकृत करता है, और ट्रैफिक को रूट करना शुरू कर देता है। उतना ही महत्वपूर्ण स्केलिंग इन है: जब ट्रैफिक लहर कम हो जाती है, तो ऑटोस्केलर अतिरिक्त इंस्टेंस को समाप्त कर देता है ताकि आप निष्क्रिय कंप्यूट के लिए भुगतान करना बंद कर दें। फ्लैपिंग को रोकने के लिए - जहां सर्वर तेजी से बनाए जाते हैं और नष्ट किए जाते हैं। एक अंतहीन थ्रैशिंग लूप में नष्ट हो गए — क्लाउड आर्किटेक्ट कॉन्फ़िगर करते हैं कूलडाउन अवधि। अवधारणा संख्या चार: सर्वर रहित।

- 04. सर्वरलेस (FaaS और फायरक्रैकर माइक्रोवीएम)

4:53 वर्षों से, मार्केटिंग टीमें सर्वर रहित को जादुई कोड के रूप में प्रचारित करती थीं आकाश में चल रहा है। वास्तव में, सर्वर रहित अभी भी सर्वर का उपयोग करता है — लेकिन आपके पास उनका स्वामित्व नहीं है, जब कोई कोड नहीं चल रहा हो तो उनके लिए पैच करें या भुगतान करें। एडब्ल्यूएस लैम्ब्डा या गूगल क्लाउड फंक्शंस जैसी फंक्शन-एज-ए-सर्विस के साथ, आप एक स्टैंडअलोन हैंडलर फ़ंक्शन लिखते हैं। जब एक HTTP अनुरोध, S3 फ़ाइल अपलोड, या डेटाबेस परिवर्तन होता है, तो क्लाउड रनटाइम पांच मिलीसेकंड से भी कम समय में एक अल्पकालिक

5:23 माइक्रो-वर्चुअल-मशीन जैसे फायरक्रैकर को बूट करता है। आपका कोड निष्पादित होता है, एक प्रतिक्रिया देता है, और बंद हो जाता है। यदि कोई तीन महीने तक आपकी वेबसाइट पर नहीं जाता है, तो आपका कंप्यूट बिल ठीक शून्य डॉलर और शून्य सेंट है। यदि दस लाख उपयोगकर्ता एक साथ उस पर हिट करते हैं, तो प्रदाता दस लाख समवर्ती माइक्रोवीएम्स को स्पिन करता है। इंजीनियरिंग व्यापार-बंद वास्तविक हैं: कोल्ड स्टार्ट ताजा रनटाइम को स्पिन करते समय विलंबता, लैम्ब्डा पर एक कठिन पंद्रह मिनट की निष्पादन सीमा और सख्त स्टेटलेसनेस।

5:55 सर्वर रहित इवेंट पाइपलाइन और छिटपुट एपीआई के लिए अपराजेय है, लेकिन लगातार वेबसॉकेट या कई घंटों के प्रशिक्षण के लिए खराब है।

- 05. इवेंट-ड्रिवन आर्किटेक्चर (EDA और डिकूपलिंग)

6:05 अवधारणा संख्या पांच: इवेंट-ड्रिवन आर्किटेक्चर, या EDA। पारंपरिक आर्किटेक्चर में, सेवाएं समकालिक रूप से संचार करती हैं। आपकी चेकआउट सेवा भुगतान को कॉल करती है, भुगतान इन्वेंट्री को कॉल करता है, इन्वेंट्री धोखाधड़ी को कॉल करती है, और धोखाधड़ी ईमेल को कॉल करती है। यह सर्वनाश के समकालिक झरने का निर्माण करता है। यदि तृतीय-पक्ष ईमेल प्रदाता को नेटवर्क हिचकी का अनुभव होता है और उसे दस सेकंड लगते हैं प्रतिक्रिया देने में, तो आपके ग्राहक का पूरा चेकआउट अनुरोध एक त्रुटि के साथ टाइम आउट हो जाता है। एक इवेंट-ड्रिवन आर्किटेक्चर में, सेवाएं पूरी तरह से डीकपल्ड होती हैं।

6:37 जब कोई ग्राहक खरीद पर क्लिक करता है, तो चेकआउट सेवा डाउनस्ट्रीम सेवाओं को कॉल नहीं करती है। यह बस OrderPlaced नामक एक इवेंट को एक केंद्रीय इवेंट बस जैसे अमेज़ॅन इवेंटब्रिज या एक SNS विषय पर प्रकाशित करती है। चेकआउट पचास मिलीसेकंड में पूरा हो जाता है। भुगतान, इन्वेंट्री कटौती और ईमेल रसीदों के लिए डाउनस्ट्रीम कार्यकर्ता अपने स्वयं के समर्पित SQS कतारों से स्वतंत्र रूप से संदेश खींचते हैं। यदि ईमेल सेवा एक घंटे के लिए बंद हो जाती है, तो संदेश सुरक्षित रूप से प्रतीक्षा करते हैं एक भी ऑर्डर छूटे बिना कतार में बफर किए गए।

- 06. कंटेनर ऑर्केस्ट्रेशन (डॉकर और कुबरनेट्स)

7:13 अवधारणा संख्या छह: कंटेनर ऑर्केस्ट्रेशन। डॉकर ने पैकेजिंग को हल किया: यह आपके एप्लिकेशन कोड, सिस्टम लाइब्रेरी, कॉन्फ़िगरेशन और रनटाइम को एक अपरिवर्तनीय छवि में लपेटता है जो आपके मैकबुक पर और क्लाउड में समान रूप से चलता है। लेकिन एक कंटेनर को पैकेज करना आसान है। पचास भौतिक वर्चुअल मशीनों में पांच सौ कंटेनर चलाना वह जगह है जहाँ इंजीनियरिंग टूट जाती है। इसलिए कुबेरनेट्स और एडब्ल्यूएस ईसीएस जैसे कंटेनर ऑर्केस्ट्रेटर

7:41 मौजूद हैं। एक ऑर्केस्ट्रेटर एक कंट्रोल प्लेन प्रदान करता है: एक एपीआई सर्वर, एक etcd स्टेट स्टोर, और एक बुद्धिमान शेड्यूलर। आप अपनी वांछित स्थिति घोषित करते हैं: मुझे अपनी प्रमाणीकरण सेवा के दस प्रतिकृतियां चाहिए, प्रत्येक में दो गीगाबाइट रैम हो। शेड्यूलर क्लस्टर का निरीक्षण करता है, पॉड्स को खाली मेमोरी वाले नोड्स पर रखता है, आंतरिक नेटवर्किंग को कॉन्फ़िगर करता है, और लगातार वास्तविकता को समेटता है। यदि किसी नोड में हार्डवेयर विफलता होती है, तो कुबेरनेट्स नुकसान का पता लगाता है और तुरंत सभी विस्थापित पॉड्स को स्वस्थ

- 07. 4 क्लाउड स्टोरेज पिलर्स (S3, EBS, DBs और रेडिस)

8:16 नोड्स पर पुनर्निर्धारित करता है। अवधारणा संख्या सात: क्लाउड स्टोरेज पदानुक्रम। शुरुआती अक्सर क्लाउड स्टोरेज को एक ही बकेट मानते हैं जहाँ आप फाइलें डंप करते हैं। प्रोडक्शन आर्किटेक्चर में, स्टोरेज को एक्सेस पैटर्न और लेटेंसी के आधार पर चार अलग-अलग स्तंभों में विभाजित किया जाता है। पहला ऑब्जेक्ट स्टोरेज है, जैसे अमेज़ॅन S3 या गूगल क्लाउड स्टोरेज। आप HTTP REST API पर सरल PUT और GET कॉल का उपयोग करके फ़ाइलों तक पहुँचते हैं। यह प्रति माह प्रति गीगाबाइट दो सेंट पर असीमित क्षैतिज क्षमता प्रदान करता है,

8:49 जो इसे वीडियो, उपयोगकर्ता अपलोड, लॉग और बैकअप के लिए आदर्श बनाता है। दूसरा ब्लॉक स्टोरेज है, जैसे अमेज़ॅन EBS। ये वर्चुअल हार्ड ड्राइव हैं जो सीधे एक विशिष्ट वर्चुअल मशीन से उच्च-गति इंटरकनेक्ट पर माउंट की जाती हैं। वे ext4 जैसे मानक फाइलसिस्टम में प्रारूपित होते हैं, जो डेटाबेस इंजनों द्वारा आवश्यक तेज़ यादृच्छिक पढ़ने और लिखने की पहुँच का समर्थन करते हैं। तीसरा प्रबंधित डेटाबेस हैं: PostgreSQL जैसे संबंधपरक इंजन RDS पर ACID लेनदेन और जटिल जॉइन प्रदान करते हैं,

9:21 और DynamoDB जैसे NoSQL इंजन बड़े पैमाने पर एकल-अंक मिलीसेकंड विलंबता प्रदान करते हैं। और चौथा Redis जैसे इन-मेमोरी कैश हैं। RAM से डेटा पढ़ने में मिलीसेकंड के बजाय माइक्रोसेकंड लगते हैं। कैश आपके डेटाबेस के सामने बैठते हैं, इसे बार-बार पढ़ने वाले ट्रैफ़िक से बचाते हैं और अस्थिर उपयोगकर्ता सत्र टोकन का प्रबंधन करते हैं।

- 08. उच्च उपलब्धता और द नाइन्स (मल्टी-AZ फेलओवर)

9:44 अवधारणा संख्या आठ: उच्च उपलब्धता, या HA। उपलब्धता एक प्रश्न का उत्तर देती है: आपका एप्लिकेशन उपयोगकर्ताओं द्वारा कितने प्रतिशत समय तक चालू और पहुंच योग्य है? एंटरप्राइज़ अनुबंधों में, उपलब्धता को नाइन में मापा जाता है। दो नाइन, या निन्यानबे प्रतिशत उपलब्धता, हर साल तीन और आधे दिनों के डाउनटाइम की अनुमति देती है। चार नाइन अनुमत डाउनटाइम को बावन मिनट तक गिरा देता है, और पांच नाइन प्रति वर्ष कुल डाउनटाइम के मुश्किल से पांच मिनट की अनुमति

10:15 देता है। उच्च उपलब्धता प्राप्त करने के लिए, आपको दोष डोमेन में विफलता के एकल बिंदुओं को समाप्त करना होगा। क्लाउड में, इसका मतलब कई उपलब्धता क्षेत्रों में परिनियोजन करना है। एक उपलब्धता क्षेत्र एक सिंगल रैक नहीं है: यह स्वतंत्र बिजली और कूलिंग के साथ मीलों दूर एक या एक से अधिक अलग भौतिक डेटा सेंटर हैं। समकालिक डेटाबेस प्रतिकृति के साथ ज़ोन ए और ज़ोन बी में सक्रिय इंस्टेंस चलाकर, एक बिजली का झटका या फाइबर कट जो एक पूरी भौतिक सुविधा को नीचे ले आता है, एक स्वचालित फ़ेलओवर का परिणाम होता है

10:50 तीस सेकंड में बिना किसी मानवीय हस्तक्षेप के।

- 09. स्थायित्व बनाम उपलब्धता (11 नाइन अपटाइम क्यों नहीं है)

10:53 अवधारणा संख्या नौ: ड्यूरेबिलिटी बनाम अवेलेबिलिटी। क्लाउड आर्किटेक्चर इंटरव्यू में यह सबसे आम वैचारिक जाल है। इंजीनियर अक्सर इन शब्दों का परस्पर उपयोग करते हैं, लेकिन वे पूरी तरह से अलग गुणों को मापते हैं। अवेलेबिलिटी अपटाइम को मापती है: क्या मैं अपने डेटा को अभी पढ़ने या लिखने के लिए एक API कॉल कर सकता हूँ? अभी इसी क्षण? ड्यूरेबिलिटी संरक्षण को मापती है: क्या मेरा डेटा दस वर्षों तक स्थायी बिट रॉट, भ्रष्टाचार या विनाश के बिना जीवित रहेगा? दस वर्षों में?

11:24 Amazon S3 स्टैंडर्ड देखें। इसका सर्विस लेवल एग्रीमेंट निन्यानवे दशमलव नौ प्रतिशत अवेलेबिलिटी प्रदान करता है, जो हर महीने लगभग तैंतालीस मिनट के डाउनटाइम की अनुमति देता है, जहाँ एक API रिक्वेस्ट पाँच-सौ एरर दे सकती है। लेकिन S3 ड्यूरेबिलिटी के ग्यारह नौ का वादा करता है: निन्यानवे दशमलव नौ नौ नौ नौ नौ नौ नौ नौ नौ प्रतिशत। यदि आप S3 में एक करोड़ फाइलें स्टोर करते हैं, तो आप सांख्यिकीय रूप से हर दस हज़ार वर्षों में औसतन एक फ़ाइल खोने की उम्मीद कर सकते हैं।

11:56 औसतन एक फ़ाइल हर दस हजार साल में। S3 इसे ऑब्जेक्ट्स को इरेज़र-कोडिंग करके और कम से कम तीन भौगोलिक रूप से अलग डेटा सुविधाओं में चंक्स को रेप्लिकेट करके प्राप्त करता है। कम से कम तीन भौगोलिक रूप से अलग डेटा सुविधाओं में। एक बड़े क्षेत्रीय नेटवर्क आउटेज के दौरान, S3 अस्थायी रूप से अनुपलब्ध हो सकता है, लेकिन आपका डेटा कभी नष्ट नहीं होता।

- 10. इंफ्रास्ट्रक्चर एज़ कोड (टेराफॉर्म बनाम कंसोल ड्रिफ्ट)

12:14 अवधारणा संख्या दस: इंफ्रास्ट्रक्चर ऐज़ कोड, या IaC। क्लाउड कंप्यूटिंग के शुरुआती दिनों में, इंजीनियर AWS वेब मैनेजमेंट कंसोल में लॉग इन करते थे और मैन्युअल रूप से वर्चुअल मशीनें बनाने, सबनेट कॉन्फ़िगर करने और सिक्योरिटी ग्रुप्स अटैच करने के लिए क्लिक करते थे। उद्योग इसे क्लिकऑप्स कहता है, और उत्पादन में, यह एक पूर्ण आपदा है। मैनुअल कंसोल परिवर्तनों का कोई ऑडिट ट्रेल नहीं होता, कोई रोलबैक मैकेनिज़्म नहीं होता, और यह अनिवार्य रूप से स्टेजिंग और उत्पादन वातावरण के बीच कॉन्फ़िगरेशन ड्रिफ्ट का कारण बनता है। Infrastructure

12:48 as Code टूल्स जैसे टेराफॉर्म, ओपनटोफू, पु्लुमी, या AWS CDK के साथ, आप अपनी पूरी क्लाउड आर्किटेक्चर को Git में संग्रहीत डिक्लेरेटिव कॉन्फ़िगरेशन फ़ाइलों में परिभाषित करते हैं। एक खुले पोर्ट या डेटाबेस प्रतिकृति में हर बदलाव एक पुल रिक्वेस्ट और पीयर रिव्यू से होकर गुजरता है। टेराफॉर्म प्लान चलाने से सटीक API डिफ का पूर्वावलोकन होता है इससे पहले कि कुछ भी छुआ जाए, और आपके प्रोडक्शन स्टैक की एक समान प्रतिकृति को स्पिन अप करने में चार सप्ताह की बजाय चार मिनट लगते हैं। स्टैक को चार सप्ताह के बजाय चार मिनट लगते हैं।

- 11. क्लाउड नेटवर्किंग (VPC, सबनेट्स, NAT और सुरक्षा समूह)

13:20 अवधारणा संख्या ग्यारह: क्लाउड नेटवर्किंग और वर्चुअल प्राइवेट क्लाउड्स। जब आप सर्वर को क्लाउड पर डिप्लॉय करते हैं, तो वे कच्चे सार्वजनिक इंटरनेट पर खुले नहीं बैठते हैं। वे एक सॉफ्टवेयर-परिभाषित पृथक सीमा के अंदर रहते हैं, जिसे VPC कहा जाता है। अपने VPC के अंदर, आप एक निजी IP एड्रेस स्पेस आवंटित करते हैं जैसे दस-दशमलव-शून्य-दशमलव-शून्य-दशमलव-शून्य स्लैश सोलह, और इसे सार्वजनिक और निजी सबनेट में विभाजित करते हैं। एक सार्वजनिक सबनेट का इंटरनेट गेटवे तक सीधा मार्ग होता है।

13:51 इसमें आपके एप्लिकेशन लोड बैलेंसर और NAT जैसे सार्वजनिक-सामने वाले एसेट होते हैं। गेटवे। यह आपके नेटवर्क का एकमात्र हिस्सा है जिसके पास सार्वजनिक IP एड्रेस होते हैं। आपके एप्लिकेशन सर्वर और प्रोडक्शन डेटाबेस निजी सबनेट में रहते हैं, जिनमें कोई सार्वजनिक IP नहीं होता और इंटरनेट से कोई इनबाउंड मार्ग नहीं होता। जब आपके बैकएंड सर्वर को सुरक्षा अपडेट डाउनलोड करने की आवश्यकता होती है, इंटरनेट। जब आपके बैकएंड सर्वर को सुरक्षा अपडेट डाउनलोड करने की आवश्यकता होती है, उनका आउटबाउंड ट्रैफिक सार्वजनिक सबनेट में NAT गेटवे के माध्यम से रूट होता है। सबनेट। हर इंस्टेंस के चारों ओर सिक्योरिटी ग्रुप्स होते हैं: स्टेटफुल वर्चुअल फ़ायरवॉल जो न्यूनतम विशेषाधिकार के सिद्धांत को लागू करते हैं।

- 12. पूर्ण एंटरप्राइज ब्लूप्रिंट और निर्णय

14:28 आपका डेटाबेस सिक्योरिटी ग्रुप पोर्ट 5432 पर केवल आपके एप्लिकेशन सर्वर के सिक्योरिटी ग्रुप से ही कनेक्शन स्वीकार करता है, जिससे बाहरी घुसपैठ गणितीय रूप से असंभव हो जाती है। जब आप ज़ूम आउट करते हैं, तो ये ग्यारह प्रिमिटिव एक सुसंगत प्रणाली में जुड़ जाते हैं। आपका DNS एक सार्वजनिक सबनेट में लोड बैलेंसर पर रूट होता है, ऑटोस्केलिंग ग्रुप कई अवेलेबिलिटी ज़ोन में ट्रैफिक सर्जेस को संभालते हैं, इवेंट बसें बैकएंड वर्कर्स को अलग करती हैं, और आपका पूरा स्टैक इंफ्रास्ट्रक्चर ऐज़ कोड का उपयोग करके Git से डिप्लॉय किया जाता है।

15:02 आज के मास्टरक्लास का फैसला: शिप इट। सैकड़ों क्लाउड मार्केटिंग एक्रोनिम याद करना बंद करें। इन ग्यारह आर्किटेक्चर पैटर्न में महारत हासिल करें, अपनी स्थिति को अलग करें, और ऐसी सिस्टम बनाएँ जो विफल न हो सकें। मुझे बताएं कि जब आपने पहली बार क्लाउड में निर्माण करना शुरू किया था, तब किस क्लाउड कॉन्सेप्ट ने आपको सबसे ज्यादा सिरदर्द दिया था, टिप्पणियों में। और पूरी आर्किटेक्चर चीट शीट प्राप्त करने के लिए, The Daily Diff डॉट देव पर न्यूज़लेटर की सदस्यता लें,

15:28 लिंक नीचे दिया गया है। और आज के लिए बस इतना ही। मैं एक्सीरिसी से निको हूँ। जिम्मेदारी से मर्ज करें।

स्रोत

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io