3.11 क्लाउड आर्किटेक्चर

अवलोकन और प्रेरणा

क्लाउड कंप्यूटिंग किसी और के बुनियादी ढाँचे को माँग पर, नेटवर्क के ज़रिए किराए पर लेना है, आप जो इस्तेमाल करते हैं उसके लिए बिल किया जाता है, और जब आप कर चुके हों तो इसे छोड़ दिया जाता है। क्लाउड आर्किटेक्चर उन किराए के संसाधनों को अपनी पुरानी डेटा-सेंटर की किराए की नक़ल के बजाय उनका मूल घर मानकर प्रणालियाँ डिज़ाइन करने का अनुशासन है। वह अंतर इस पूरे अध्याय की मुख्य बात है। आप किसी विरासती ऐप्लिकेशन को किसी क्लाउड-प्रदाता में ले जा सकते हैं और उसके डिज़ाइन में कुछ नहीं बदल सकते, और आपको बड़ा बिल और लगभग वही भंगुरता मिलेगी। या आप क्लाउड के लिए डिज़ाइन कर सकते हैं और लोच (इलास्टिसिटी), अविभेदित काम की पूरी श्रेणियों को मिटाने वाली प्रबंधित सेवाएँ, और किसी को पेज किए बिना पूरी इमारत की विफलता झेलने की क्षमता पा सकते हैं। यह अध्याय 3.1 की बुनियादी बातों पर सीधे बनता है: क्लाउड आर्किटेक्चर आर्किटेक्चर ही है, वही ट्रेड-ऑफ़ और गुणवत्ता-गुण, बस ऐसे आधार पर लागू जिसके आप मालिक नहीं हैं।

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

उद्यम और सरकारें दोनों किनारे तीखे ढंग से महसूस करते हैं। उद्यम दशकों की मौजूदा प्रणालियों के साथ आते हैं, इसलिए उनकी क्लाउड-कहानी आमतौर पर एक प्रवासन-कहानी है, हाइब्रिड कनेक्टिविटी और कठिन बनाना-बनाम-ख़रीदना फ़ैसलों से भरी। सरकारें संप्रभुता, प्राधिकरण-व्यवस्थाओं, और नागरिकों के डेटा का अतिरिक्त बोझ ढोती हैं जो क़ानूनी रूप से कुछ सीमाओं से बाहर नहीं जा सकता। यहाँ के फ़ैसले (कौन-सा सेवा-मॉडल, कितने प्रदाता, विफलता-डोमेन कहाँ बैठते हैं, प्रबंधित सेवा के रूप में क्या चलता है बनाम आपका अपना कोड) एक दशक के लिए लागत और जोख़िम आकार देते हैं।

मुख्य सिद्धांत

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

सिफ़ारिशें

सेवा-मॉडल जान-बूझकर चुनें, और प्रबंधित को डिफ़ॉल्ट बनाएँ

क्लाउड-प्रदाता अज़-ए-सर्विस मॉडलों से पकड़े गए स्पेक्ट्रम में बेचते हैं: इंफ्रास्ट्रक्चर एज़ अ सर्विस (IaaS) कच्चा कंप्यूट, स्टोरेज, और नेटवर्किंग किराए पर देता है; प्लेटफ़ॉर्म एज़ अ सर्विस (PaaS) एक प्रबंधित रनटाइम किराए पर देता है ताकि आप बिना सर्वर संभाले कोड डिप्लॉय करें; सॉफ़्टवेयर एज़ अ सर्विस (SaaS) तैयार ऐप्लिकेशन किराए पर देता है। सर्वरलेस कंप्यूटिंग, जिसमें फ़ंक्शन और प्रबंधित इवेंट-ड्रिवन सेवाएँ शामिल हैं, इसे और आगे धकेलती है: आप कोड या कॉन्फ़िगरेशन देते हैं और प्रदाता सारा प्रावधान संभालता है, निष्क्रिय होने पर शून्य तक स्केल करते हुए। स्पेक्ट्रम में हर क़दम ऊपर नियंत्रण को लाभ से बदलता है, सबसे ज़्यादा नियंत्रण और सबसे ज़्यादा परिचालन-बोझ वाले IaaS से लेकर दोनों में सबसे कम वाले सर्वरलेस तक।

डिफ़ॉल्ट यह होना चाहिए कि आपकी आवश्यकताएँ जितना इजाज़त दें उतना ऊँचा उस स्पेक्ट्रम में चढ़ें। पैचिंग, बैकअप, फ़ेलओवर, और स्केलिंग संभालने वाला कोई प्रबंधित डेटाबेस लगभग हमेशा आपके इंजीनियरों का ख़ुद-चलाए जाने वाले से बेहतर इस्तेमाल है। निचले-स्तर के IaaS को उन मामलों के लिए रखें जिन्हें वाक़ई इसकी ज़रूरत है: विशेष हार्डवेयर, असामान्य अनुपालन-सीमाएँ, लाइसेंसिंग-बाधाएँ, या ऐसा प्रदर्शन जो प्रबंधित पेशकश पूरा नहीं कर सकती। कारण को आर्किटेक्चर डिसीज़न रिकॉर्ड (अध्याय 3.1) के रूप में लिख लें, क्योंकि “हम अपना ख़ुद का मैसेज-ब्रोकर चलाते हैं” एक दावा है जिसे हर साल फिर से उचित ठहराना चाहिए।

क्षेत्रों और उपलब्धता-क्षेत्रों के आर-पार स्पष्ट विफलता-डोमेन के रूप में डिज़ाइन करें

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

बहु-रीजन एक भारी फ़ैसला है, आपके लचीलापन और पुनर्प्राप्ति लक्ष्यों (अध्याय 3.5) और आपकी आपदा-पुनर्प्राप्ति योजना (अध्याय 9.5) से जुड़ा। रीजन के आर-पार फैलना पूरे-रीजन की विफलता से बचाव ख़रीदता है और डेटा को उपयोगकर्ताओं के क़रीब रख सकता है, पर यह असली लागत, विलंब, और संगति-समस्याएँ लाता है, क्योंकि क्रॉस-रीजन सिंक्रोनस प्रतिकृति धीमी है और असिंक्रोनस प्रतिकृति का मतलब है फ़ेलओवर पर डेटा-हानि स्वीकार करना। “अत्यधिक उपलब्ध” होने की धुंधली इच्छा के बजाय स्पष्ट पुनर्प्राप्ति-समय और पुनर्प्राप्ति-बिंदु उद्देश्यों के आधार पर तय करें। ज़्यादातर प्रणालियों को मज़बूत बहु-क्षेत्र और परीक्षित बहु-रीजन पुनर्प्राप्ति-रास्ता चाहिए; बहुत कम को वाक़ई रीजन के आर-पार सक्रिय-सक्रिय चाहिए, और जो बिना ज़रूरत के इसे बनाते हैं वे हर दिन जटिलता की क़ीमत चुकाते हैं।

साझा-ज़िम्मेदारी मॉडल को एक आर्किटेक्चरल सीमा मानें

क्लाउड सुरक्षा एक साझा-ज़िम्मेदारी मॉडल पर चलती है: प्रदाता क्लाउड को सुरक्षित करता है (भौतिक सुविधाएँ, हाइपरवाइज़र, प्रबंधित-सेवा का आंतरिक भाग) और आप क्लाउड में जो डालते हैं उसे सुरक्षित करते हैं (आपका डेटा, पहुँच-नियंत्रण, नेटवर्क-कॉन्फ़िगरेशन, और कोड)। सटीक रेखा सेवा-स्पेक्ट्रम में आपके चढ़ने के साथ हिलती है। IaaS के साथ आप ऑपरेटिंग-सिस्टम पैच करते हैं; किसी प्रबंधित डेटाबेस के साथ आप नहीं करते, पर आप अब भी मालिक हैं कि कौन जुड़ सकता है और क्या डेटा एन्क्रिप्टेड है। सबसे महँगी घटनाएँ इस रेखा को ग़लत पढ़ने से आती हैं, सबसे मशहूर वह खुला स्टोरेज-बकेट जो लाखों रिकॉर्ड लीक करता है क्योंकि किसी ने मान लिया कि प्रदाता ने इसे डिफ़ॉल्ट रूप से निजी बना दिया।

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

सब कुछ कोड के रूप में प्रावधान करें, एक शासित लैंडिंग-ज़ोन के भीतर

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

उस कोड को एक लैंडिंग-ज़ोन में लपेटें: खातों (या सब्सक्रिप्शन या प्रोजेक्ट), नेटवर्किंग, पहचान, लॉगिंग, और गार्डरेल की एक पहले से बनी, शासित नींव जिस पर हर टीम बनाती है। अलग खातों को प्रभाव-दायरे और बिलिंग-सीमाओं के रूप में इस्तेमाल करें, ताकि एक टीम की ग़लती दूसरी के डेटा तक न पहुँचे और हर डॉलर किसी मालिक तक ट्रेस हो। गार्डरेल को पॉलिसी-एज़-कोड के रूप में लागू करें जो निषिद्ध कॉन्फ़िगरेशन (सार्वजनिक डेटाबेस, अनएन्क्रिप्टेड वॉल्यूम, अस्वीकृत क्षेत्र में कोई संसाधन) रोकता है, बाद-की समीक्षा पर निर्भर रहने के बजाय। एक केंद्रीय प्लेटफ़ॉर्म टीम आमतौर पर लैंडिंग-ज़ोन की मालिक होती है, यह अध्याय को प्लेटफ़ॉर्म इंजीनियरिंग (अध्याय 8.4) और कंटेनर व क्लाउड-नेटिव रनटाइम (अध्याय 8.3) से जोड़ती है।

लॉक-इन को ईमानदारी से आँकें, और बहु-क्लाउड के प्रति संदेहपूर्ण रहें

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

यही कारण है कि सच्चा बहु-क्लाउड (एक ही वर्कलोड को दो प्रदाताओं में चलाना) आमतौर पर रणनीति के बजाय एक कार्गो-कल्ट है। यह आपको सबसे कम-साझा-भाजक तक धकेलता है, आपकी परिचालन-सतह दोगुनी करता है, और आपकी टीमों को रखनी पड़ने वाली विशेषज्ञता गुणा करता है, यह सब एक ऐसे जोख़िम को हेज करने के लिए जो शायद ही वास्तविक होता है। एक से ज़्यादा प्रदाता छूने के वैध कारण हैं: किसी दूसरे विक्रेता से बेस्ट-ऑफ़-ब्रीड सास, किसी नियामक का लचीलापन-अधिदेश, या कोई जान-बूझकर संप्रभुता-आवश्यकता (अध्याय 10.11)। हाइब्रिड क्लाउड, क्लाउड से जुड़े हुए कुछ प्रणालियों को परिसर में रखना, उद्यम-प्रवासन के दौरान और ऐसे डेटा के लिए जो क़ानूनी रूप से हिल नहीं सकता, अक्सर अपरिहार्य है। इन्हें स्पष्ट आँखों और लिखित औचित्य से चुनें, इसलिए नहीं कि किसी स्लाइड-डेक ने “मल्टी-क्लाउड” कहा।

लागत के लिए आर्किटेक्ट करें, और वेल-आर्किटेक्टेड सोच अपनाएँ

क्लाउड में, आर्किटेक्चरल फ़ैसला एक ख़र्च-फ़ैसला है: “किसी भी स्थिति के लिए” अति-प्रावधान अगले महीने के चालान पर दिखता है। लागत को एक गुणवत्ता-गुण मानें जिसके लिए आप डिज़ाइन करते हैं, और फ़िनऑप्स अभ्यास अपनाएँ, क्लाउड-ख़र्च के लिए साझा वित्तीय जवाबदेही का अनुशासन (अध्याय 9.4), ताकि इंजीनियरिंग, वित्त, और उत्पाद बिल के साझा मालिक बनें। हर संसाधन को किसी मालिक से टैग करें, लागत को प्रति-टीम और प्रति-सेवा दृश्यमान बनाएँ, लगातार सही-आकार करें, ऑटोस्केलिंग इस्तेमाल करें ताकि आप चोटी के बजाय लोड के लिए भुगतान करें, और क़ीमत-लीवर (प्रतिबद्ध-उपयोग छूट, बाधित काम के लिए स्पॉट-क्षमता) का फ़ायदा उठाएँ जो क्लाउड देता है।

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

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

दृष्टिकोण	फ़ायदे	नुक़सान
लिफ़्ट-एंड-शिफ़्ट (रीहोस्ट)	तेज़, कम अग्रिम प्रयास, डेटा-सेंटर से जल्दी बाहर निकलता है	पुरानी भंगुरता बनाए रखता है, लोच और प्रबंधित सेवाएँ चूकता है, अक्सर ज़्यादा महँगा
क्लाउड-नेटिव पुनर्डिज़ाइन	पूर्ण लोच, लचीलापन, प्रबंधित-सेवा लाभ	ऊँचा अग्रिम प्रयास और कौशल; अवशोषित करने के लिए बड़ा बदलाव
एकल क्लाउड, गहरा एकीकरण	सरलता, अधिकतम लाभ, कम परिचालन-सतह	केंद्रित लॉक-इन और प्रदाता-जोख़िम
बहु-क्लाउड (एक वर्कलोड, दो प्रदाता)	प्रदाता-विफलता हेज, बातचीत-लाभ	सबसे-कम-साझा-भाजक डिज़ाइन, दोगुना संचालन और विशेषज्ञता
हाइब्रिड (क्लाउड प्लस परिसर)	डेटा-निवास और विरासती बाधाएँ पूरी करता है, चरणबद्ध प्रवासन	नेटवर्क-जटिलता, एक साथ चलाने के लिए दो परिचालन-मॉडल
सर्वरलेस / उच्च प्रबंधित	न्यूनतम टॉइल, शून्य तक स्केल, तेज़ डिलीवरी	कम नियंत्रण, प्रदाता-विशिष्ट, कोल्ड-स्टार्ट और कोटा-सीमाएँ

केंद्रीय तनाव है नियंत्रण बनाम लाभ, और यह हर पंक्ति से होकर गुज़रता है। आप प्रदाता को जितना ज़्यादा सौंपते हैं, उतनी तेज़ी से आप चलते हैं और उतना कम आप चलाते हैं, गहरे युग्मन की क़ीमत पर। समाधान एक ध्रुव चुनना नहीं है बल्कि हर वर्कलोड को जान-बूझकर रखना है: कमोडिटी प्लंबिंग के लिए प्रबंधित स्पेक्ट्रम में ऊँचा चढ़ें, वहाँ नीचे रहें जहाँ नियंत्रण वाक़ई अपनी क़ीमत कमाता है, और लॉक-इन को दोनों दिशाओं में आँकें, पोर्टेबिलिटी को मुफ़्त और निर्भरता को पाप मानने के बजाय। बड़े संगठन तब मुसीबत में पड़ते हैं जब वे डर (लॉक-इन का, क्लाउड का, लागत का) को विश्लेषण के बजाय प्रतिवर्त से यह चुनाव करने देते हैं।

अपनी टीम के साथ चर्चा के लिए प्रश्न

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

2. जब कोई उपलब्धता-क्षेत्र या पूरा रीजन विफल हो, वाक़ई क्या होता है, और क्या हमने इसका परीक्षण किया है? कई टीमें मानती हैं कि वे लचीली हैं क्योंकि उन्होंने क्लाउड में डिप्लॉय किया, बिना अपने विफलता-डोमेन डिज़ाइन किए या कभी जाँचने के लिए प्लग खींचे। ठोस संस्करण: हर गंभीर प्रणाली के लिए, यह कितने क्षेत्रों में फैली है, दस्तावेज़ित पुनर्प्राप्ति-समय और पुनर्प्राप्ति-बिंदु उद्देश्य क्या है, और हमने आख़िरी बार कब कोई गेम-डे चलाया जिसने कोई क्षेत्र विफल किया या रीजन-पुनर्प्राप्ति का पूर्वाभ्यास किया? बहु-क्षेत्र अविशिष्ट आधार-रेखा होनी चाहिए, इसलिए कोई भी गंभीर एकल-क्षेत्र वर्कलोड एक निष्कर्ष है; बहु-रीजन एक भारी, महँगा फ़ैसला है जो स्पष्ट पुनर्प्राप्ति-लक्ष्यों से जुड़ा है, डिफ़ॉल्ट रूप से नहीं अपनाया गया। अपना निर्भरता-नक़्शा लाएँ, क्योंकि जो विफलता चोट पहुँचाती है वह आमतौर पर कोई साझा सेवा (कोई डेटाबेस, कोई पहचान-प्रदाता) होती है जिसका विफलता-डोमेन किसी ने चार्ट नहीं किया। ऐसा लचीलापन जिसका आपने कभी परीक्षण नहीं किया, एक परिकल्पना है, कोई गुण नहीं।

3. हमारी सबसे बड़ी प्रदाता-निर्भरताओं के लिए, छोड़ने में वाक़ई क्या लागत आएगी, और क्या यह बचने लायक़ क़ीमत है? लॉक-इन बहसें संख्याओं के बजाय विचारधारा पर चलती हैं, एक ख़ेमा पोर्टेबल रहने के लिए हर प्रबंधित सेवा को अमूर्त करता है और दूसरा एकाग्रता-जोख़िम को पूरी तरह अनदेखा करता है। इसे ज़मीन पर लाएँ: अपनी तीन सबसे गहरी निर्भरताएँ चुनें, हर एक को बदलने की असली इंजीनियरिंग-लागत और बीता समय अनुमानित करें, और इसे उसके मुक़ाबले तौलें जो सेवा आज आपको बचाती है और आप कितनी संभावना से कभी बदलेंगे। उन जोख़िमों को परत करें जिन्हें पोर्टेबिलिटी ठीक नहीं करती, जैसे कोई नियामक दूसरे स्रोत की माँग करे या डेटा कहाँ रह सकता है इसका कोई संप्रभुता-नियम, क्योंकि वे शुद्ध अर्थशास्त्र के न होने पर भी बहु-क्लाउड या हाइब्रिड को उचित ठहरा सकते हैं। लक्ष्य है हर निर्भरता के लिए एक जान-बूझकर, लिखित रुख़, कोई सामान्य नीति नहीं। एक बार आप इसकी क़ीमत आँक लें, ज़्यादातर डरा हुआ लॉक-इन उस अमूर्तन-परत से सस्ता स्वीकार करना निकलता है जो इससे बचने के लिए बनाई गई थी।

4. हम कौन-सी सेवाएँ ख़ुद चला रहे हैं जिन्हें प्रदाता ख़ुशी से हमारे लिए चलाएगा, और वह चुनाव इंजीनियर-घंटों में क्या लागत ले रहा है? क्लाउड का पूरा लाभ पैचिंग, बैकअप, फ़ेलओवर, और स्केलिंग किसी ऐसे को सौंपना है जिसका पूर्णकालिक काम यही चीज़ें हैं, फिर भी टीमें नियमित रूप से आदत या ग़लत जगह के गर्व से कोई ख़ुद-चलाया डेटाबेस, मैसेज-ब्रोकर, या सर्च-क्लस्टर रखती हैं। बड़े संगठन के लिए लागत किसी एक टीम की मेहनत नहीं बल्कि एक दर्जन कोनों में फिर से ईजाद किया गया वही अविभेदित संचालन है, हर एक एक ऑन-कॉल-रोटेशन और बहाव का स्रोत। प्रतिस्पर्धी विचार वास्तविक है: विशेष हार्डवेयर, लाइसेंसिंग-शर्तें, असामान्य अनुपालन-सीमा, या ऐसा प्रदर्शन जो प्रबंधित पेशकश पूरा नहीं कर सकती, स्पेक्ट्रम में नीचे रहना उचित ठहरा सकता है, इसलिए उत्तर सामान्य नहीं बल्कि प्रति-सेवा है। ख़ुद-चलाई सेवाओं की सूची, रखरखाव और घटनाओं में हर एक जो इंजीनियर-घंटे खाती है, और प्रबंधित विकल्प की क़ीमत लाएँ, और हर “हम अपना ख़ुद का चलाते हैं” के लिए एक आर्किटेक्चर डिसीज़न रिकॉर्ड माँगें जो सालाना फिर से उचित ठहराया जाए। उद्यम और सरकारी परिवेश में, जोड़ें कि क्या ख़ुद-चलाया चुनाव वाक़ई कोई अनुपालन या लाइसेंसिंग-बाधा है या सिर्फ़ जड़ता है जो एक जैसी सजी है, क्योंकि ऑडिटर और बजट-मालिक वही सवाल पूछेंगे।

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

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

क्षेत्र-लेंस

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

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

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

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

उदाहरण

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

उद्यम। तीन सौ विरासती ऐप्लिकेशन वाला बहुराष्ट्रीय बीमाकर्ता “6 R” (रीहोस्ट, री-प्लेटफ़ॉर्म, रीपर्चेज़, रीफ़ैक्टर, रिटायर, रिटेन) से शासित एक बहु-वर्षीय प्रवासन चलाता है। कम-मूल्य वाले कमोडिटी ऐप एक समय-सीमा पर दो डेटा-सेंटर से बाहर निकलने के लिए जल्दी रीहोस्ट किए जाते हैं; मुख्य पॉलिसी-प्लेटफ़ॉर्म को क्लाउड-नेटिव बनाने के लिए रीफ़ैक्टर किया जाता है; घर-में-बने टूल सास के रूप में रीपर्चेज़ किए जाते हैं; और अप्रचलित प्रणालियाँ रिटायर होती हैं। एक केंद्रीय प्लेटफ़ॉर्म टीम प्रति-व्यावसायिक-इकाई खातों, डिफ़ॉल्ट रूप से एन्क्रिप्टेड गार्डरेल, और सार्वजनिक डेटा-स्टोर रोकने वाले पॉलिसी-एज़-कोड वाला एक लैंडिंग-ज़ोन रखती है, जबकि हाइब्रिड कनेक्टिविटी क्लाउड को उन मेनफ़्रेम सिस्टम-ऑफ़-रिकॉर्ड से जोड़ती है जो वर्षों तक नहीं हिलेंगे। लागत प्रति-इकाई शोबैक वाले फ़िनऑप्स अभ्यास से शासित होती है, और एक वेल-आर्किटेक्टेड समीक्षा हर ऐप्लिकेशन के उत्पादन-लॉन्च को गेट करती है।

सरकार। नागरिक लाभ-सेवा दे रही एक राष्ट्रीय एजेंसी को क़ानूनी रूप से निवासी-डेटा राष्ट्रीय सीमाओं के भीतर रखना और प्राधिकृत बुनियादी ढाँचे पर चलना ज़रूरी है। यह प्रदाता के सरकारी क्लाउड-क्षेत्र में डिप्लॉय करती है और अमेरिका में FedRAMP जैसी किसी व्यवस्था के तहत प्राधिकरण अपनाती है (अनुपालन-काम अध्याय 4.6 में), ऑडिटरों के लिए साझा-ज़िम्मेदारी सीमा को पंक्ति-दर-पंक्ति दस्तावेज़ित करती है। डेटा-निवास और व्यापक संप्रभुता-चिंताएँ (अध्याय 10.11) एक ऐसे आर्किटेक्चर को चलाती हैं जो स्टोरेज व प्रोसेसिंग को देश-के-भीतर क्षेत्रों पर टिकाता है और पॉलिसी-एज़-कोड के ज़रिए किसी अस्वीकृत क्षेत्र में किसी संसाधन को रोकता है। प्रणाली एक परीक्षित क्रॉस-ज़ोन पुनर्प्राप्ति-योजना के साथ तीन उपलब्धता-क्षेत्रों में फैली है और सब कुछ कोड के रूप में प्रावधान करती है, इसलिए ऑडिट-प्रमाण हड़बड़ी के बजाय एक गिट-इतिहास है।

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

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

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

एंटी-पैटर्न और नुक़सान

• लिफ़्ट-एंड-शिफ़्ट करना और इसे “क्लाउड” कहना। डेटा-सेंटर डिज़ाइन को किराए के बुनियादी ढाँचे पर रीहोस्ट करना लागत पकड़ता है, फ़ायदे में से कुछ नहीं।
• कंसोल-क्लिक किया गया बुनियादी ढाँचा। हाथ से बनाए गए संसाधन अदोहराने-योग्य, अदस्तावेज़ित, और पुनर्प्राप्त या ऑडिट करना असंभव हैं; किसी भी मैनुअल उत्पादन-बदलाव को दोष मानें।
• कार्गो-कल्ट बहु-क्लाउड। किसी दुर्लभ जोख़िम को हेज करने के लिए एक ही वर्कलोड को दो प्रदाताओं में चलाना, हर दिन जटिलता और सबसे-कम-साझा-भाजक डिज़ाइन में चुकाना।
• एकल-क्षेत्र “उच्च उपलब्धता”। यह मानना कि क्लाउड डिफ़ॉल्ट रूप से लचीला है जबकि गंभीर वर्कलोड बिना परीक्षित फ़ेलओवर के एक क्षेत्र में चलाना।
• साझा-ज़िम्मेदारी ग़लत पढ़ना। यह मानना कि प्रदाता वह सुरक्षित करता है जिसके आप वाक़ई मालिक हैं, लाखों रिकॉर्ड लीक करते सार्वजनिक बकेट का क्लासिक रास्ता।
• बाद का सोचा हुआ लागत। ख़र्च की परवाह किए बिना डिज़ाइन करना, फिर पता लगाना कि चालान ने आपके आर्किटेक्चरल फ़ैसले ख़ुद ले लिए।

परिपक्वता मॉडल

• स्तर 1, आरंभ: क्लाउड-इस्तेमाल तदर्थ और प्रतिक्रियात्मक है। टीमें साझा खातों में क्लिक करके संसाधन अस्तित्व में लाती हैं, वर्कलोड लिफ़्ट-एंड-शिफ़्ट किए जाते हैं, और कोई लैंडिंग-ज़ोन नहीं, कोई लागत-दृश्यता नहीं, और लचीलापन डिज़ाइन के बजाय मान लिया जाता है। पहली गंभीर आउटेज या बिल-झटका एक आश्चर्य है।
• स्तर 2, विकास: बुनियादी अभ्यास दिखते हैं पर टीम-दर-टीम बदलते हैं। कुछ मुख्य बुनियादी ढाँचा कोड के रूप में प्रावधानित है और कुछ वर्कलोड बहु-क्षेत्र चलते हैं, कुछ खाते अलग किए गए हैं, पर कवरेज असमान है: सेवा-मॉडल और लॉक-इन चुनाव आदत से लिए जाते हैं, लागत बाद में देखी जाती है, गार्डरेल असंगत हैं, और बहु-रीजन पुनर्प्राप्ति अपरीक्षित है।
• स्तर 3, मानकीकरण: पॉलिसी-एज़-कोड गार्डरेल वाला एक शासित लैंडिंग-ज़ोन पूरे संगठन में दस्तावेज़ित और लागू है। एक प्लेटफ़ॉर्म टीम नींव की मालिक है, हर उत्पादन-चीज़ कोड के रूप में प्रावधानित है, वेल-आर्किटेक्टेड समीक्षाएँ महत्वपूर्ण डिज़ाइनों को गेट करती हैं, और ख़रीदना-बनाम-बनाना व विफलता-डोमेन फ़ैसले हर टीम में सुविचारित और संगत रूप से दर्ज होते हैं।
• स्तर 4, प्रबंधन: संपत्ति को आधार-रेखाओं के मुक़ाबले मापा और नियंत्रित किया जाता है। प्रति-टीम और प्रति-सेवा लागत लक्ष्यों के मुक़ाबले फ़िनऑप्स के ज़रिए ट्रैक होती है, पुनर्प्राप्ति-समय और पुनर्प्राप्ति-बिंदु उद्देश्य दावे के बजाय सत्यापित होते हैं, गार्डरेल-उल्लंघन और कॉन्फ़िगरेशन-बहाव मेट्रिक्स के रूप में सामने आते हैं, सही-आकार उपयोग-डेटा से चलता है, और हर जाओ या न-जाओ फ़ैसला लागत, विश्वसनीयता, और सुरक्षा डैशबोर्ड के प्रमाण से समर्थित है।
• स्तर 5, संयोजन: क्लाउड आर्किटेक्चर लगातार सुधारा जाता है और व्यावसायिक व जोख़िम-योजना के साथ एकीकृत है। विफलता-डोमेन नियमित गेम-डे के ज़रिए अभ्यास किए जाते हैं, सही-आकार और क़ीमत-निर्धारण स्वचालित हैं, संप्रभुता और निवास पॉलिसी से लागू होते हैं, सेवा-मॉडल और लॉक-इन रुख़ नियमित लय पर फिर से क़ीमत आँके जाते हैं, और बाज़ार, क़ीमत, और जोख़िम-तस्वीर बदलने के साथ वर्कलोड-पोर्टफ़ोलियो अनुकूली रूप से फिर से संतुलित होता है।

चर्चा के लिए विचार

1. आपका हर मुख्य वर्कलोड IaaS-से-सर्वरलेस स्पेक्ट्रम में कहाँ बैठता है, और क्या कोई वाक़ई ज़रूरी नियंत्रण खोए बिना परिचालन-टॉइल छोड़ने के लिए ऊँचा चढ़ सकता है?
2. अगर आपका मुख्य प्रदाता तेज़ी से क़ीमतें बढ़ाए या बहु-दिवसीय क्षेत्रीय आउटेज झेले, आपकी असली योजना क्या है, और क्या यह आपकी रखी किसी बहु-क्लाउड या हाइब्रिड जटिलता को उचित ठहराती है?
3. आपके लैंडिंग-ज़ोन और उसके गार्डरेल का मालिक कौन है, और क्या कोई टीम आज ग़ैर-अनुपालक संसाधन (सार्वजनिक डेटा-स्टोर, अनएन्क्रिप्टेड वॉल्यूम, अस्वीकृत क्षेत्र) शिप कर सकती है?
4. किसी विनियमित या संप्रभु वर्कलोड के लिए, क्या आप बिना किसी आग-अभ्यास के साझा-ज़िम्मेदारी सीमा और प्राधिकृत कॉन्फ़िगरेशन को प्रमाण के रूप में पेश कर सकते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• पीटर मेल और टिमोथी ग्रांस, द निस्ट डेफ़िनिशन ऑफ़ क्लाउड कंप्यूटिंग (एनआईएसटी स्पेशल पब्लिकेशन 800-145)
• अमेज़न वेब सर्विसेज़, एडब्ल्यूएस वेल-आर्किटेक्टेड फ़्रेमवर्क
• माइक्रोसॉफ़्ट, एज़्योर वेल-आर्किटेक्टेड फ़्रेमवर्क और क्लाउड अडॉप्शन फ़्रेमवर्क
• गूगल क्लाउड, गूगल क्लाउड आर्किटेक्चर फ़्रेमवर्क
• स्टीफ़न ऑर्बन, अहेड इन द क्लाउड: बेस्ट प्रैक्टिसेज़ फ़ॉर नेविगेटिंग द फ़्यूचर ऑफ़ एंटरप्राइज़ आईटी (और “6 R” प्रवासन-रणनीतियाँ)
• जे.आर. स्टॉर्मेंट और माइक फ़ुलर, क्लाउड फ़िनऑप्स: कोलैबोरेटिव, रियल-टाइम क्लाउड फ़ाइनेंशियल मैनेजमेंट
• ग्रेगर होप, क्लाउड स्ट्रैटेजी: अ डिसीज़न-बेस्ड अप्रोच टू सक्सेसफ़ुल क्लाउड माइग्रेशन
• यूएस जनरल सर्विसेज़ एडमिनिस्ट्रेशन, FedRAMP कार्यक्रम-दस्तावेज़ीकरण और सुरक्षा-आधार-रेखाएँ
• क्लाउड सिक्योरिटी अलायंस, सिक्योरिटी गाइडेंस फ़ॉर क्रिटिकल एरियाज़ ऑफ़ फ़ोकस इन क्लाउड कंप्यूटिंग