सर्वर खरीदें, किराये पर लें या क्लाउड इस्तेमाल करें? हर एप्लिकेशन के अनुसार निर्णय लें

चार मॉडल जिन्हें कोटेशन स्पष्ट अलग करें

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

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

क्लाउड ऐसी वर्चुअल मशीनें हो सकती हैं, लेकिन प्रबंधित डेटाबेस, ऑब्जेक्ट स्टोरेज और ऐप-केंद्रित सेवाएँ भी। इसलिए अंतर केवल मासिक भुगतान नहीं। सवाल है कि कौन-सा तकनीकी काम आप करें और सेवा वास्तव में क्या लेती है। ठोस सेवा विवरण बिना 'managed' जैसा प्रचार शब्द उत्तर नहीं देता।

पहली कीमत तुलना से पहले छह प्रश्न

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

हर ऐप के उत्तर दर्ज करें। फ़ाइल सेवा, व्यवसाय प्रबंधन सिस्टम और सार्वजनिक पोर्टल की जरूरतें अक्सर अलग हैं। तीनों को एक ही कारण से ले जाने पर स्थानीय निर्भरता छूट सकती है या स्थिर सेवा के लिए अनुपयोगी लचीलेपन का भुगतान हो सकता है।

वास्तविक प्रतितर्कों वाला निर्णय मैट्रिक्स

आवश्यकता शीट पूरी होने के बाद ही मानदंडों को भार दें। इंटरनेट कटने पर उत्पादन मशीन चलती रहनी चाहिए तो यह कठोर शर्त है, कुल रैंकिंग में कम अंक नहीं। शेष विकल्पों में मेहनत, लागत और अनुकूलन क्षमता तौली जा सकती है। गणितीय रैंकिंग अनुपयुक्तता न छिपाए।

तीन ऐप, तीन संभावित निर्णय

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

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

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

अपडेट, बैकअप और पुनर्प्राप्ति कौन सँभालता है?

EC2 में AWS गेस्ट ऑपरेटिंग सिस्टम और स्थापित ऐप जैसी जिम्मेदारियाँ ग्राहक को देता है। प्रदाता नीचे का बुनियादी ढाँचा चलाता है। दूसरी सेवाओं में विभाजन बदलता है। हर पेशकश पर सिद्धांत लागू करके हर स्तर की जिम्मेदारी का नाम माँगें। AWS: साझा जिम्मेदारी मॉडल ↗

अच्छी संचालन शीट हार्डवेयर, ऑपरेटिंग सिस्टम, डेटाबेस, ऐप, उपयोगकर्ता पहुँच और बैकअप की जिम्मेदार भूमिका बताती है। उसमें स्थानापन्न, प्रतिक्रिया समय और बदलाव प्रक्रिया भी हैं। 'होस्ट शायद करता होगा' जैसे शब्द बचें। वरना कमी तभी दिखेगी जब डेटाबेस बहाल करना हो और दोनों पक्ष केवल एक हिस्से के जिम्मेदार हों।

RTO लक्ष्य पुनर्प्राप्ति अवधि है; RPO समय में सहनीय डेटा नुकसान है। लक्ष्य व्यवसाय से निकलते हैं। AWS दस्तावेज़ इसलिए घटक उपलब्धता और बड़ी विफलता के बाद पूरे ऐप की पुनर्प्राप्ति अलग करते हैं। AWS: आपदा पुनर्प्राप्ति योजना ↗

लचीलेपन का मूल्य और प्रतिबद्धता के परिणाम हैं

कम सूचना पर बंद हो सकने वाले परीक्षण वातावरण को वर्षों चलने वाले डेटाबेस जैसी गणना से खरीदना जरूरी नहीं। AWS बदलते भार, अल्पकालिक उपयोग और लंबे उपयोग वादों के अलग मूल्य मॉडल बताता है। प्रतिबद्धता लागत घटा सकती है, लेकिन वादा किया उपयोग वास्तव में हो तभी। छूट मांग पूर्वानुमान का विकल्प नहीं। AWS: मूल्य मॉडल को कार्यभार से मिलाएँ ↗

हर विकल्प में समान डेटा मात्रा, संचालन समय, प्रतिधारण अवधि और सहायता कार्य की गणना माँगें। अधिक मांग वाला महीना और अनुबंध का अंत भी गिनें। अपने सिस्टम में हार्डवेयर प्रतिस्थापन; बाहरी सेवाओं में निर्यात, ट्रांसफ़र और पुनर्निर्माण शामिल हों। कम शुरुआती कीमत पूरी अवधि में अलग दिख सकती है।

छोटे निर्यात परीक्षण से पोर्टेबिलिटी दिखाएँ

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

अवधि भी मापें। प्रभावी 100 Mbit/s कनेक्शन पर काल्पनिक 2 TB निर्यात में दशमलव इकाइयों से केवल ट्रांसफ़र लगभग 44.4 घंटे लेता है। तैयारी, जाँच और अवरोध अतिरिक्त हैं। आर्काइव ले जाने में यह स्वीकार्य हो सकता है, तेज पुनर्प्राप्ति में नहीं। इसलिए निर्यात और बहाली की क्षमता अलग परीक्षण माँगती हैं।

सीमित पायलट से निर्णय लें

प्रतिनिधि ऐप चुनकर पसंदीदा विकल्प वास्तविक परिस्थितियों में जाँचें। पायलट के पहले मापनीय मानदंड हों: सहमत उपयोगकर्ता संख्या पर प्रतिक्रिया समय, पूरा बैकअप, लक्ष्य के भीतर बहाली और समझने योग्य मासिक लागत रिपोर्ट। उत्पादन डेटा ले जाने से पहले वापसी मार्ग भी तय करें।

परीक्षण के बाद छोटे दस्तावेज़ में निर्णय लिखें: मॉडल, स्वीकृत जिम्मेदारियाँ, लागत मान्यताएँ, स्वीकार सीमाएँ और अगली समीक्षा। सबसे अच्छी वास्तुकला वह है जिसे टीम विश्वसनीय चला और बाद में बदल सके। हर ऐप का मॉडल अलग हो सकता है, बशर्ते बदलाव और जिम्मेदारियाँ स्पष्ट हों।