क्लाउड कंप्युटिंग समजावले: ११ आर्किटेक्चर संकल्पना ज्या तुम्हाला माहित असणे आवश्यक आहे (4K मास्टरक्लास).

या व्हिडिओमध्ये काय समाविष्ट आहे

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

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

मूळ इंग्रजी निवेदनातून अनुवादित. उपलब्ध ऑडिओ आणि मथळे YouTube द्वारे नियंत्रित आहेत.

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

0:00 प्रत्येक सॉफ्टवेअर अभियंता शेवटी क्लाउड आर्किटेक्चरच्या भिंतीसमोर येतो. तुम्ही तुमच्या लॅपटॉपवर एक ॲप्लिकेशन बनवता, ते उत्पादनात ढकलून देता, आणि जसा वास्तविक वापरकर्ते येतात, सर्व्हर क्रॅश होतात, डेटाबेस कनेक्शन संपून जातात आणि तुमचे AWS बिल एका फोन नंबरसारखे दिसते. बहुतेक विकसक तीनशे वेगवेगळ्या AWS उत्पादन संक्षेप पाठ करून क्लाउड अभियांत्रिकी सोडवण्याचा प्रयत्न करतात. परंतु वास्तविक क्लाउड कंप्युटिंग हे विक्रेता कॅटलॉग पाठ करण्याबद्दल नाही: ते अकरा मूलभूत आर्किटेक्चरल प्रिमिटिव्ह्जवर आधारित आहे.

0:34 या मास्टरक्लासमध्ये, आम्ही संपूर्ण एंटरप्राइझ ब्लूप्रिंटमधून जाऊ: स्केलिंग आणि लोड बॅलन्सिंगपासून सर्वरलेस, इव्हेंट-ड्रिव्हन डीकप्लिंग, स्टोरेज पदानुक्रम आणि क्लाउड नेटवर्किंगपर्यंत. या अकरा संकल्पनांवर प्रभुत्व मिळवा, आणि तुम्ही AWS, GCP किंवा Azure वर कोणतेही बॅकएंड डिझाइन करू शकता. हे The Daily Diff आहे, पडद्यामागे.

- 01. उभ्या विरुद्ध आडव्या स्केलिंग

0:57 संकल्पना क्रमांक एक: स्केलिंग. जेव्हा तुमच्या ॲप्लिकेशनला रहदारीची वाढ अनुभवते, तेव्हा तुमच्याकडे लोड हाताळण्याचे दोन मूलभूतपणे भिन्न मार्ग आहेत: उभ्या स्केलिंग, किंवा आडव्या स्केलिंग. उभ्या स्केलिंग, किंवा स्केलिंग अप, म्हणजे तुमची विद्यमान मशीन घेऊन अधिक संसाधने जोडणे: चार CPU कोअरमधून बत्तीसमध्ये अपग्रेड करणे, किंवा बत्तीस गिगाबाईट रॅमच्या ऐवजी एकशे अठ्ठावीस गिगाबाईट रॅम वापरणे. उभ्या स्केलिंगसाठी शून्य आर्किटेक्चरल बदलांची आवश्यकता असते: तुमचा कोड

1:28 आणि डेटाबेस तसाच राहतो. पण तो एका क्रूर हार्डवेअर सीलिंगला धडकतो. जगात एकाही मशीनमध्ये दहा हजार CPU कोअर नाहीत, आणि उच्च-स्तरीय इन्स्टन्सना अफाट किंमत प्रीमियम असतो. आडव्या स्केलिंग, किंवा स्केलिंग आउट, म्हणजे तुमचे सर्व्हर लहान आणि सामान्य किमतीचे ठेवणे, परंतु राउटरच्या मागे समांतर अनेक इन्स्टन्स चालवणे. जर एक इन्स्टन्स क्रॅश झाला, तर उर्वरित नोड्स शून्य डाउनटाईमसह रहदारी शोषून घेतात. आडव्या स्केलिंगचा सुवर्ण नियम आहे स्टेटलेसनेस: तुमचे ॲप्लिकेशन सर्व्हर वापरकर्त्यांचे सत्र,

2:01 अपलोड केलेल्या फाईल्स किंवा स्थिती त्यांच्या स्थानिक डिस्कवर साठवू शकत नाहीत. स्थिती बाह्य डेटाबेस किंवा कॅशेमध्ये असणे आवश्यक आहे, कोणत्याही नोडला कोणत्याही वापरकर्त्याची विनंती हाताळण्याची परवानगी देणे. संकल्पना क्रमांक दोन: लोड बॅलन्सिंग.

- 02. लोड बॅलन्सिंग आर्किटेक्चर (L4 विरुद्ध L7 आणि हेल्थ चेक)

2:17 आडव्या स्केलिंग कागदावर खूप चांगले वाटते, परंतु ते त्वरित एक समस्या निर्माण करते: जेव्हा दहा हजार वापरकर्ते तुमच्या डोमेन नावावर येतात, तेव्हा कोणत्या विशिष्ट सर्व्हरला त्यांची रहदारी मिळते? एक लोड बॅलन्सर सार्वजनिक इंटरनेट आणि तुमच्या खाजगी बॅकएंड क्लस्टरमध्ये बसलेला एक रिव्हर्स प्रॉक्सी म्हणून कार्य करतो. ते येणाऱ्या TCP किंवा HTTP कनेक्शन स्वीकारते आणि तुमच्या निरोगी इन्स्टन्समध्ये विनंत्या वितरित करते. लोड बॅलन्सर दोन प्राथमिक नेटवर्क स्तरांवर कार्य करतात.

2:47 लेअर 4 नेटवर्क लोड बॅलन्सर ट्रान्सपोर्ट लेअरवर कार्य करतात, आयपी ॲड्रेस आणि पोर्टवर आधारित रॉ TCP आणि UDP पॅकेट्सना मायक्रोसेकंद लेटन्सी आणि प्रति सेकंद दशलक्ष विनंत्यांसह रूट करतात. लेअर 7 ॲप्लिकेशन लोड बॅलन्सर HTTP प्रोटोकॉलची स्वतः तपासणी करतात: URL पाथ, विनंती शीर्षलेख (headers), कुकीज आणि HTTP पद्धती वाचतात. हे पाथ-आधारित राउटिंग सक्षम करते: स्लॅश-एपीआय विनंत्या तुमच्या बॅकएंड क्लस्टरला आणि स्लॅश-स्टॅटिक विनंत्या एका ऑब्जेक्ट स्टोअरला पाठवतात. महत्त्वाचे म्हणजे, लोड बॅलन्सर सक्रिय आरोग्य तपासणी करतात.

3:25 प्रत्येक काही सेकंदांनी, बॅलन्सर प्रत्येक इन्स्टन्सवरील आरोग्य एंडपॉईंटला पिंग करतो. जर एखाद्या इन्स्टन्सने सलग तीन पाचशे (500) त्रुटी दिल्या किंवा प्रतिसाद देण्यात अयशस्वी झाला, तर तो शून्य ड्रॉप केलेल्या विनंत्यांसह पूल मधून स्वयंचलितपणे बाहेर काढला जातो. संकल्पना क्रमांक तीन: ऑटोस्केलिंग.

- 03. ऑटोस्केलिंग आणि इलॅस्टिसिटी

3:45 जर तुमच्या वेब ॲपला सकाळी तीन वाजता दोन सर्व्हरची गरज असेल, परंतु दुपारच्या लॉन्च दरम्यान वीस सर्व्हरची गरज असेल, तर क्लाउड कन्सोलमध्ये मॅन्युअली बटणे क्लिक करणे म्हणजे डाउनटाईम आणि दिवाळखोरीचा हमी मार्ग आहे. ऑटोस्केलिंग आडव्या सर्व्हर पूल्समध्ये डायनॅमिक इलॅस्टिसिटी आणते. एक ऑटो स्केलिंग ग्रुप सरासरी CPU वापर, नेटवर्क I-O, किंवा रांगेतील बॅकलॉगची खोली यासारख्या कार्यप्रदर्शन मेट्रिक्सचे निरीक्षण करतो. जेव्हा सरासरी CPU परिभाषित मर्यादा ओलांडतो — उदाहरणार्थ, सलग तीन मिनिटांसाठी सत्तर टक्के — तेव्हा ऑटोस्केलर आपोआप नवीन

4:19 व्हर्च्युअल मशीन्स लॉन्च करतो, त्यांना तुमच्या लोड बॅलन्सरमध्ये नोंदणी करतो, आणि रहदारी रूट करणे सुरू करतो. त्याचप्रमाणे, स्केलिंग इन (scaling in) महत्त्वाचे आहे: जेव्हा रहदारीची लाट कमी होते, तेव्हा ऑटोस्केलर अतिरिक्त इन्स्टन्स बंद करतो जेणेकरून तुम्हाला निष्क्रिय कंप्यूटसाठी पैसे द्यावे लागणार नाहीत. फ्लॅपिंग टाळण्यासाठी — जेथे सर्व्हर एका अंतहीन थ्रॅशिंग लूपमध्ये वेगाने तयार केले आणि नष्ट केले जातात — क्लाउड आर्किटेक्ट कूलडाउन कालावधी कॉन्फिगर करतात. संकल्पना क्रमांक चार: सर्वरलेस. वर्षानुवर्षे, मार्केटिंग टीम्सनी सर्वरलेसला आकाशात चालणारा जादूचा कोड

- 04. सर्वरलेस (FaaS आणि फायरक्रॅकर मायक्रोव्हीएम)

4:53 म्हणून सादर केले. वास्तविकतेत, सर्वरलेस अजूनही सर्व्हर वापरतो — परंतु जेव्हा कोणताही कोड चालत नसतो, तेव्हा तुम्ही त्यांच्या मालकीचे नसता, त्यांना पॅच करत नाही किंवा त्यांच्यासाठी पैसे देत नाही. AWS लॅम्बडा किंवा गुगल क्लाउड फंक्शन्ससारख्या फंक्शन-ॲज-ए-सर्व्हिससह, तुम्ही एक स्वतंत्र हँडलर फंक्शन लिहिता. जेव्हा HTTP विनंती, S3 फाईल अपलोड, किंवा डेटाबेसमध्ये बदल होतो, तेव्हा क्लाउड रनटाइम पाच मिलिसेकंदांपेक्षा कमी वेळेत

5:23 फायरक्रॅकरसारख्या तात्पुरत्या मायक्रो-व्हर्च्युअल-मशीनला बूट करतो. तुमचा कोड कार्यान्वित होतो, प्रतिसाद परत करतो आणि बंद होतो. जर तीन महिन्यांपर्यंत कोणीही तुमच्या वेबसाइटला भेट दिली नाही, तर तुमचे कंप्यूट बिल नेमके शून्य डॉलर आणि शून्य सेंट असते. जर एकाच वेळी दहा लाख वापरकर्त्यांनी भेट दिली, तर प्रदाता दहा लाख एकत्रित मायक्रोव्हीएम फिरवतो. अभियांत्रिकीमधील देवाणघेवाण वास्तविक आहेत: नवीन रनटाईम फिरवताना कोल्ड स्टार्ट लेटन्सी, लॅम्बडावर पंधरा मिनिटांची कठोर एक्झिक्युशन मर्यादा, आणि कठोर स्टेटलेसनेस.

5:55 सर्वरलेस इव्हेंट पाईपलाईन आणि तुरळक APIs साठी अतुलनीय आहे, परंतु सततच्या वेबसॉकेट्स किंवा अनेक तासांच्या प्रशिक्षण रनसाठी ते चांगले नाही.

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

6:05 संकल्पना क्रमांक पाच: इव्हेंट-ड्रिव्हन आर्किटेक्चर, किंवा EDA. पारंपारिक आर्किटेक्चरमध्ये, सेवा समक्रमितपणे संवाद साधतात. तुमची चेकआउट सेवा पेमेंटला कॉल करते, पेमेंट इन्व्हेंटरीला कॉल करते, इन्व्हेंटरी फ्रॉडला कॉल करते, आणि फ्रॉड ईमेलला कॉल करते. हे विनाशाचे समक्रमित कॅस्केड तयार करते. जर तृतीय-पक्ष ईमेल प्रदात्याला नेटवर्कमध्ये अडचण आली आणि प्रतिसाद देण्यासाठी दहा सेकंद लागतील, तर तुमच्या ग्राहकाची संपूर्ण चेकआउट विनंती त्रुटीसह वेळेबाहेर जाते. इव्हेंट-ड्रिव्हन आर्किटेक्चरमध्ये, सेवा पूर्णपणे decoupled असतात.

6:37 जेव्हा ग्राहक खरेदीवर क्लिक करतो, तेव्हा चेकआउट सेवा डाउनस्ट्रीम सेवांना कॉल करत नाही. ती फक्त OrderPlaced नावाचा एक इव्हेंट केंद्रीय इव्हेंट बसवर (उदा. Amazon EventBridge किंवा SNS टॉपिक) प्रकाशित करते. चेकआउट पन्नास मिलिसेकंदात पूर्ण होते. पेमेंट, इन्व्हेंटरी कपात आणि ईमेल पावत्यांसाठी डाउनस्ट्रीम कामगार त्यांच्या स्वतःच्या समर्पित SQS रांगेतून स्वतंत्रपणे संदेश खेचतात. जर ईमेल सेवा एका तासासाठी बंद झाली, तर संदेश रांगेत सुरक्षितपणे बफर केलेले राहतात, एकही ऑर्डर गमावल्याशिवाय.

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

7:13 संकल्पना क्रमांक सहा: कंटेनर ऑर्केस्ट्रेशन. डॉकरने पॅकेजिंगची समस्या सोडवली: ते तुमच्या ॲप्लिकेशन कोडला, सिस्टम लायब्ररी, कॉन्फिगरेशन आणि रनटाईमला एका अपरिवर्तनीय इमेजमध्ये गुंडाळते जे तुमच्या मॅकबुकवर आणि क्लाउडमध्ये एकसारखे चालते. पण कंटेनर पॅकेज करणे सोपे आहे. पन्नास भौतिक व्हर्च्युअल मशीन्सवर पाचशे कंटेनर चालवणे हे अभियांत्रिकी कोठे बिघडते ते आहे. म्हणूनच कुबेरनेट्स आणि AWS ECS सारखे कंटेनर ऑर्केस्ट्रेटर

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

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

8:16 शेड्युल करतो. संकल्पना क्रमांक सात: क्लाउड स्टोरेज पदानुक्रम. नवीन शिकणारे अनेकदा क्लाउड स्टोरेजला एकच बकेट मानतात जिथे तुम्ही फाईल्स टाकून देता. उत्पादन आर्किटेक्चरमध्ये, स्टोरेजला ॲक्सेस पॅटर्न आणि लेटन्सीवर आधारित चार वेगवेगळ्या स्तंभांमध्ये विभागले जाते. पहिला आहे ऑब्जेक्ट स्टोरेज, जसे की ॲमेझॉन S3 किंवा गुगल क्लाउड स्टोरेज. तुम्ही HTTP REST APIs द्वारे फाईल्स ॲक्सेस करता, साधे PUT आणि GET कॉल्स वापरून. ते प्रति गिगाबाईट प्रति महिना दोन सेंटमध्ये अनंत आडवी क्षमता देते,

8:49 ते व्हिडिओ, वापरकर्त्यांचे अपलोड, लॉग आणि बॅकअपसाठी आदर्श बनवते. दुसरा आहे ब्लॉक स्टोरेज, जसे की ॲमेझॉन EBS. हे व्हर्च्युअल हार्ड ड्राइव्ह आहेत जे थेट विशिष्ट व्हर्च्युअल मशीनला उच्च-गती इंटरकनेक्टद्वारे जोडलेले असतात. ते ext4 सारख्या मानक फाइलसिस्टममध्ये फॉरमॅट होतात, डेटाबेस इंजिनद्वारे आवश्यक जलद रँडम रीड आणि राईट ॲक्सेसला समर्थन देतात. तिसरे आहेत व्यवस्थापित डेटाबेस: RDS वर PostgreSQL सारखे रिलेशनर इंजिन जे ACID व्यवहार आणि जटिल जॉइन्स प्रदान करतात,

9:21 आणि डायनॅमोडीबी सारखे NoSQL इंजिन जे मोठ्या प्रमाणात सिंगल-डिजिट मिलीसेकंद लेटन्सी देतात. आणि चौथे आहेत रेडिससारखे इन-मेमरी कॅशेस. रॅममधून डेटा वाचण्यासाठी मिलीसेकंदांऐवजी मायक्रोसेकंद लागतात. कॅशे तुमच्या डेटाबेससमोर बसतात, त्याला वारंवार वाचलेल्या रहदारीपासून संरक्षित करतात आणि अस्थिर वापरकर्त्यांचे सत्र टोकन व्यवस्थापित करतात.

- 08. उच्च उपलब्धता आणि द नाईन्स (मल्टी-AZ फेलओव्हर)

9:44 संकल्पना क्रमांक आठ: उच्च उपलब्धता, किंवा HA. उपलब्धता एका प्रश्नाची उत्तरे देते: तुमचा ॲप्लिकेशन किती टक्के वेळ कार्यरत आहे आणि वापरकर्त्यांसाठी उपलब्ध आहे? एंटरप्राइझ करारांमध्ये, उपलब्धता नऊमध्ये मोजली जाते. दोन नऊ, किंवा नव्व्याण्णव टक्के उपलब्धता, दरवर्षी साडेतीन दिवसांपेक्षा जास्त डाउनटाईमला परवानगी देते. चार नऊ (four nines) परवानगी असलेला डाउनटाईम बावन्न मिनिटांपर्यंत कमी करतो, आणि पाच नऊ (five nines) दरवर्षी फक्त पाच मिनिटांचा एकूण डाउनटाईम

10:15 परवानगी देते. उच्च उपलब्धता प्राप्त करण्यासाठी, तुम्हाला फॉल्ट डोमेन्समध्ये अपयशाचे एकल बिंदू काढून टाकावे लागतात. क्लाउडमध्ये, याचा अर्थ अनेक उपलब्धता झोनमध्ये (Availability Zones) डिप्लॉय करणे. एक उपलब्धता झोन एकच रॅक नाही: तो एक किंवा अधिक भिन्न भौतिक डेटा सेंटर्स आहे जे मैलभर दूर स्वतंत्र वीज आणि कूलिंगसह आहेत. झोन ए आणि झोन बी मध्ये सक्रिय इन्स्टन्स सिन्क्रोनस डेटाबेस प्रतिकृतीसह चालवून, विजेचा धक्का किंवा फायबर कट ज्यामुळे संपूर्ण भौतिक सुविधा बंद पडते, त्याचा परिणाम स्वयंचलित फेलओव्हरमध्ये होतो.

10:50 शून्य मानवी हस्तक्षेपासह तीस सेकंदात.

- 09. टिकाऊपणा विरुद्ध उपलब्धता (11 नऊ अपटाईम का नाही)

10:53 संकल्पना क्रमांक नऊ: टिकाऊपणा विरुद्ध उपलब्धता. क्लाउड आर्किटेक्चरमधील हा सर्वात सामान्य वैचारिक सापळा आहे मुलाखती. अभियंते वारंवार हे शब्द अदलाबदल करून वापरतात, परंतु ते पूर्णपणे भिन्न गुणधर्म मोजतात. उपलब्धता अपटाइम मोजते: मी माझ्या डेटा वाचण्यासाठी किंवा लिहिण्यासाठी API कॉल करू शकतो का? आत्ता या क्षणी डेटा? टिकाऊपणा जतन मोजते: माझा डेटा कायमस्वरूपी टिकून राहील का? दहा वर्षांपेक्षा जास्त काळ बिट रॉट, भ्रष्टाचार किंवा विनाश?

11:24 Amazon S3 Standard पहा. त्याचा सेवा स्तर करार नव्व्याण्णव पूर्णांक नऊ टक्के ऑफर करतो उपलब्धता, जी दरमहा अंदाजे चाळीस-तीन मिनिटांचा डाउनटाइम देते जिथे API विनंती पाचशे त्रुटी परत करू शकते. परंतु S3 अकरा नऊ टिकाऊपणाचे वचन देतो: नव्व्याण्णव पूर्णांक नऊ नऊ नऊ नऊ नऊ नऊ नऊ नऊ नऊ टक्के. तुम्ही S3 मध्ये एक कोटी फाइल्स साठवल्यास, तुम्ही सांख्यिकीयदृष्ट्या एक फाइल गमावण्याची अपेक्षा करू शकता

11:56 दर दहा हजार वर्षांनी सरासरी एक फाइल. S3 हे इरेझर-कोडिंग ऑब्जेक्ट्सद्वारे आणि किमान तीन भौगोलिकदृष्ट्या वेगळ्या डेटा सुविधांमध्ये चंक्सची प्रतिकृती करून साध्य करते. किमान तीन भौगोलिकदृष्ट्या वेगळ्या डेटा सुविधा. मोठ्या प्रादेशिक नेटवर्क आउटेज दरम्यान, S3 तात्पुरते असू शकते अनुपलब्ध, परंतु तुमचा डेटा कधीही नष्ट होत नाही.

- 10. इन्फ्रास्ट्रक्चर अॅज कोड (टेराफॉर्म विरुद्ध कन्सोल ड्रिफ्ट)

12:14 संकल्पना क्रमांक दहा: इन्फ्रास्ट्रक्चर एज कोड, किंवा IaC. क्लाउड कंप्युटिंगच्या सुरुवातीच्या काळात, अभियंते AWS मध्ये लॉग इन करत होते वेब व्यवस्थापन कन्सोल आणि व्हर्च्युअल तयार करण्यासाठी व्यक्तिचलितपणे क्लिक केले मशीन, सबनेट कॉन्फिगर करा आणि सुरक्षा गट संलग्न करा. उद्योग याला ClickOps म्हणतो आणि उत्पादनात, ही एक पूर्णपणे आहे आपत्ती. मॅन्युअल कन्सोल बदलांमध्ये कोणताही ऑडिट ट्रेल नसतो, रोलबॅक नसतो यंत्रणा, आणि अपरिहार्यपणे स्टेजिंग आणि उत्पादन वातावरणादरम्यान कॉन्फिगरेशन भिन्नता निर्माण करते. उत्पादन वातावरण. टेराफॉर्म सारख्या इन्फ्रास्ट्रक्चर एज कोड साधनांसह,

12:48 कोड साधनांसह टेराफॉर्म, OpenTofu, Pulumi, किंवा AWS CDK, तुम्ही तुमचे परिभाषित करता Git मध्ये संग्रहित केलेल्या घोषणात्मक कॉन्फिगरेशन फाइल्समध्ये संपूर्ण क्लाउड आर्किटेक्चर. खुले पोर्ट किंवा डेटाबेस प्रतिकृतीमधील प्रत्येक बदल पुल रिक्वेस्ट आणि पीअर रिव्ह्यूमधून जातो. पुल रिक्वेस्ट आणि पीअर रिव्ह्यूमधून जातो. काहीही बदलण्यापूर्वी terraform plan नेमक्या API भिन्नतेचे पूर्वावलोकन करते, काहीही बदलण्यापूर्वी, आणि तुमच्या उत्पादन स्टॅकची एकसारखी प्रतिकृती तयार करण्यासाठी स्टॅक तयार करण्यासाठी चार आठवड्यांऐवजी चार मिनिटे लागतात.

- 11. क्लाउड नेटवर्किंग (VPC, सबनेट, NAT आणि सिक्युरिटी ग्रुप्स)

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

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

- 12. संपूर्ण एंटरप्राइझ ब्लूप्रिंट आणि निकाल

14:28 तुमचा डेटाबेस सुरक्षा गट फक्त पोर्ट 5432 वरून तुमच्या ऍप्लिकेशन सर्व्हर्सच्या सुरक्षा गटाकडून कनेक्शन स्वीकारतो, 5432 काटेकोरपणे तुमच्या ऍप्लिकेशन सर्व्हर्सच्या सुरक्षा गटाकडून, बाह्य प्रवेश गणितीयदृष्ट्या अशक्य बनवणे. जेव्हा तुम्ही झूम आउट करता, तेव्हा हे अकरा प्रिमिटिव्ह एका सुसंगत प्रणालीमध्ये जोडले जातात. तुमचा DNS सार्वजनिक सबनेटमधील लोड बैलेंसरवर मार्गस्थ होतो, ऑटोस्केलिंग गट एकाधिक उपलब्धता झोनमध्ये रहदारीच्या वाढीस हाताळतात, इव्हेंट बस बॅकएंड कामगारांना वेगळे करतात, आणि तुमचा संपूर्ण स्टॅक इन्फ्रास्ट्रक्चर एज कोड वापरून Git मधून तैनात केला जातो. इन्फ्रास्ट्रक्चर एज कोड वापरून Git मधून तैनात केले जाते.

15:02 आजचा मास्टरक्लास निकाल: SHIP IT. शेकडो क्लाउड मार्केटिंग संक्षेप लक्षात ठेवणे थांबवा. या अकरा आर्किटेक्चर पॅटर्नमध्ये प्रभुत्व मिळवा, तुमची स्थिती वेगळी करा, आणि अयशस्वी होऊ शकत नाहीत अशा प्रणाली तयार करा. तुम्ही प्रथम बांधकाम सुरू केल्यावर कोणत्या क्लाउड संकल्पनेने तुम्हाला सर्वात जास्त डोकेदुखी दिली हे मला टिप्पण्यांमध्ये सांगा. बांधकाम सुरू केले टिप्पण्यांमध्ये. आणि संपूर्ण आर्किटेक्चर चीट शीट मिळवण्यासाठी, daily diff dot dev येथे वृत्तपत्राची सदस्यता घ्या,

15:28 खालील लिंक. आणि आजसाठी हा फरक आहे. मी Axrisi कडून Niko आहे. जबाबदारीने विलीन करा.

स्रोत

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