2011-01-08 14 views
9

मैं समझना चाहता हूं क्लाउड-आधारित सिस्टम के लिए विक्रेता लॉक-इन के जोखिम को कम करने का सबसे अच्छा तरीका क्या है।क्लाउड लॉक-इन जोखिम को कम करने के लिए आर्किटेक्चरल रणनीतियों?

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

कम से कम, ऐसा लगता है कि मैं विक्रेता-विशिष्ट समाधान (जैसे अमेज़ॅन कतार सेवा) पर भरोसा करता हूं, उतना ही मैं निहित रूप से बंद कर रहा हूं (कम से कम मुझे ऐसा लगता है), लेकिन मैं चाहूंगा इस जोखिम को बेहतर समझें और इससे परे कोई भी।

क्या आर्किटेक्चरल रणनीतियों का उपयोग मैं इसे कम करने के लिए कर सकता हूं (उदाहरण के लिए, मानचित्र को कम करने पर भरोसा करें, क्योंकि मेरी स्क्रिप्ट क्लाउड एनवी को कम करने के लिए पोर्टेबल होगी)? क्या ओ/एस या स्टैक हैं जो दूसरों की तुलना में बेहतर हैं (लिनक्स, लैंप?)। JClouds का उपयोग कर उपयोगी है?

आदर्श रूप से, मैं वर्चुअल सिस्टम को डिज़ाइन करना चाहता हूं जिसे ईसी 2 पर तैनात किया जा सकता है, उदाहरण के लिए, लेकिन फिर आसानी से एज़ूर या ऐप इंजन (या इसके विपरीत) में माइग्रेट किया गया।

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

अग्रिम धन्यवाद। आशा है कि मैं यहां बहुत अवास्तविक नहीं हूं।

उत्तर

5

मेरी राय में, समस्या आप का वर्णन करने के केवल वास्तु पैटर्न है: अमूर्त

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

उम्मीद है कि इससे मदद मिलती है। क्लाउड प्रदाताओं में सेवाओं की विविधता को देखते हुए मुझे यह एक बहुत ही सरल काम नहीं लगता है,

1

मैं इगोरके से सहमत हूं - यदि आप कोड में ऐसा कर रहे हैं, तो यह बहुत ही अमूर्तता लेगा, इसके बारे में।

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

+0

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

-2

ईमानदारी से, आपका प्रश्न झूठी आधार पर आधारित है। आप जिस प्लेटफॉर्म का उपयोग करने के लिए चुने गए हैं उसका पूर्ण लाभ लेने की कोशिश करने के बजाए लॉक-इन से बचने के लिए देख रहे हैं।

मुद्दा आ के बेहतर तरीका है करने के लिए अपने बुनियादी ढांचे गर्म swappable हो (उदाहरण के लिए, विक्रेता लॉक-इन बचने के लिए) की कोशिश करने का नहीं है, लेकिन वास्तव में को IaaS प्रदाता के बारे में कोई फैसला आप उपयोग करना चाहते बनाने के लिए और जितना संभव हो सके उतना ही उतना ही लाभ उठाएं।

0

माइक्रोसॉफ्ट के ग्राहक सलाहकार टीम के पास उत्कृष्ट sample on how to do that है (मुझे लगता है कि मैंने यहां से परियोजना डाउनलोड की है)। इसमें बहुत सारे कोड हैं, और चीजों को "मुक्त" बनाने के लिए कुछ वाकई अच्छे अबास्ट्रक्शन हैं। जाहिर है, किसी भी अमूर्तता के साथ, आप जटिलता की एक नई परत भी पेश करते हैं ताकि आप इसे लागू करने से पहले सुनिश्चित कर सकें।

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