आप इसे Virtualize नहीं कर सकते!

IT में हमें यह बात अक्सर सुनने को मिलती है — कोई vendor हमें बताता है कि किसी system को virtualize नहीं किया जा सकता। इसके कारण अनेक हैं। IT की तरफ से हम हमेशा हैरान रहते हैं कि कोई vendor ऐसा बेतुका दावा कैसे कर सकता है; और अक्सर हम उतने ही हैरान होते हैं जब कोई customer (या manager) उन पर भरोसा कर लेता है। Vendors ने वर्षों में इस sales pitch को पूर्ण करने में खूब मेहनत की है और मुझे लगता है कि इसे ठीक से समझना जरूरी है।

समस्याओं की जड़ यह है कि vendors लगभग हमेशा अपनी लागत कम करने और customers से मुनाफा बढ़ाने के रास्ते खोजते रहते हैं। यही प्रवृत्ति बहुत सी ऐसी बातों को जन्म देती है जो अन्यथा अजीब लगती हैं।

एक काम जो बहुत से vendors करने की कोशिश करते हैं वह है — उन परिस्थितियों को सीमित करना जिनमें उनके product को support मिलेगी। ऐसा करके वे खुद को इस स्थिति में रखते हैं कि वे बस support न दें — support महंगी और अविश्वसनीय होती है। यह एक सामान्य रणनीति है। कुछ मामलों में यह इतनी आक्रामक होती है कि कोई भी स्वीकार्य, production deployment scenario अस्तित्व में ही नहीं रह पाता।

इसका एक बहुत आम तरीका है किसी भी supported operating system को support न करना, जिससे vendor का अपना software de facto deprecated हो जाता है (उदाहरण के लिए, आज इसका मतलब होगा केवल Windows XP और उससे पुराने को support करना)। एक और उदाहरण है ऐसे products को support करना जो उस use case के लिए licensed नहीं हैं (जैसे Windows 10 को server के रूप में उपयोग करने की मांग करना)। और सबसे आम मामलों में से एक है virtualization को प्रतिबंधित करना।

ये परिस्थितियां customers को कठिन स्थिति में डालती हैं क्योंकि एक तरफ उनके पास industry best practices, standard deployment guidelines, in-house tooling और पालन करने की नीतियां हैं; और दूसरी तरफ vendors अक्सर उचित system design, planning और management को प्रतिबंधित करते हैं। ये दोनों जरूरतें आपस में टकराती हैं।

निश्चित रूप से, कोई भी यह उम्मीद नहीं करता कि हर vendor हर संभावित परिस्थिति को support करे। सीमाएं तो लगानी ही होती हैं। लेकिन उचित, ठीक से deploy किए गए systems को support करने और जानबूझकर अस्वीकार्य रूप से खराब deployments की मांग करने के बीच एक बहुत बड़ा अंतर है। हम उम्मीद करते हैं कि हमारे vendors business partners की तरह व्यवहार करेंगे और हमारी सफलता में — या कम से कम अपने product की सफलता में — सामान्य रुचि रखेंगे। हम यह उम्मीद करेंगे कि कम से कम किसी भी उचित deployment scenario के लिए best effort support मिले और properly engineered, best practice scenarios के लिए guaranteed support की संभावना हो।

कल्पना कीजिए एक ऐसी दुनिया जहां speed limit पर गाड़ी चलाना और seatbelt पहनना आपकी car warranty को रद्द कर दे, और आपको support तभी मिले जब आप लापरवाही और बिना सुरक्षा के गाड़ी चलाएं!

Virtualization के बारे में कुछ महत्वपूर्ण बातें समझनी जरूरी हैं। पहली यह कि virtualization एक पुरानी industry best practice है और किसी भी production deployment scenario में इसका उपयोग अपेक्षित है। Virtualization कोई नई चीज नहीं है — small business market में भी यह एक दशक से अधिक समय से best practice की श्रेणी में है और enterprise space में तो कई दशकों से। हम उस बिंदु को बहुत पीछे छोड़ आए हैं जहां non-virtualized systems को स्वीकार्य माना जाता था, और इसमें वे legacy deployments भी शामिल हैं जो लंबे समय से चल रहे हैं।

निश्चित रूप से, लगभग हर नियम के कुछ दुर्लभ अपवाद होते हैं। कुछ systems को बहुत विशेष hardware तक पहुंच की जरूरत होती है और virtualization संभव नहीं हो सकता, हालांकि आधुनिक hardware passthrough के साथ आज यह लगभग अनसुना है। और कुछ super low latency systems को virtualize नहीं किया जा सकता लेकिन ये आमतौर पर केवल सबसे बड़े international investment banks और सबसे aggressive hedge funds तक सीमित हैं — और उन परंपरागत use cases में से अधिकांश को भी virtualization में सुधार ने समाप्त कर दिया है। लेकिन निष्कर्ष यह है — अगर आप virtualize नहीं कर सकते तो आपको दुख होना चाहिए, और आपको स्पष्ट रूप से पता होगा कि आपकी स्थिति में यह क्यों असंभव है। अन्य सभी मामलों में, आपके server को virtual होना चाहिए।

क्या यह महत्वपूर्ण नहीं है?

यदि कोई vendor आपको स्वस्थ deployments के लिए standard best practices का पालन नहीं करने देता, तो यह vendor की अपने ही product के प्रति राय के बारे में क्या कहता है? यदि हम किसी अन्य deployment की बात करते, तो हम तुरंत सवाल करते कि हम किसी system को इतनी खराब तरह से क्यों deploy कर रहे हैं जब हम उस पर निर्भर रहने की योजना बना रहे हैं। यदि हमारा vendor हमें इस तरह व्यवहार करने पर मजबूर करता है, तो हमें उसी तरह प्रतिक्रिया देनी चाहिए — यदि vendor अपने product को उस स्तर तक गंभीरता से नहीं लेता जितना हम अपनी सबसे कम महत्वपूर्ण IT सेवाओं को लेते हैं, तो हम क्यों लें?

यह एक "impedance mismatch" है, जैसा कि हम engineering circles में कहते हैं — हमारी जरूरतों (production systems) और vendor द्वारा उन systems को देखने के तरीके (hobby या entertainment systems) के बीच। यदि हमें इस product पर अपने business के लिए निर्भर रहना है, तो हमें एक ऐसे vendor की जरूरत है जो साथ हो और business की जरूरतों को समझे — एक production mindset रखता हो। यदि product business-targeted या business-ready नहीं है, तो हमें इसकी जानकारी होनी चाहिए। हमें सवाल करना चाहिए कि हम किसी ऐसी service को production में क्यों उपयोग करना चाहते हैं, जिस पर हम निर्भर हैं और जिससे support की उम्मीद करते हैं, जबकि वह उस तरीके से उपयोग के लिए बनाई ही नहीं गई।

क्या यह supported है? क्या इसे test किया जा रहा है?

Customers के नजरिए से अक्सर जो बात अनदेखी रह जाती है वह है कि किसी product के लिए जरूरी support resources मौजूद हैं या नहीं। यह असामान्य नहीं है कि किसी product को support करने वाली team छोटी हो जाए, या गायब ही हो जाए, लेकिन company product बेचती रहे — इस उम्मीद में कि जितना हो सके उससे कमाई की जाए और किसी समस्या की स्थिति में या तो किसी तरह से काम चलाया जाए या customer का पैसा वापस कर दिया जाए।

अधिकांश software contracts में लिखा होता है कि vendor से अधिकतम जो नुकसान वसूला जा सकता है वह product की कीमत या खरीदने में खर्च की गई राशि है। ऐसे में vendor को ऐसा product offer करने में कोई जोखिम नहीं है जिसे वे support नहीं कर सकते — चाहे support के लिए premium charge क्यों न कर रहे हों। यदि customer product उपयोग कर लेता है, तो उन्हें पैसे मिलते हैं। यदि customer नहीं कर पाता और vendor support नहीं कर सकता, तो वे केवल वह पैसा खोते हैं जो वैसे भी नहीं मिलता। सारा जोखिम customer का है, vendor का नहीं।

यह निश्चित रूप से सुझाव देता है कि product की कोई निरंतर testing भी नहीं होती, और यह एक अतिरिक्त चिंता का विषय होना चाहिए। सिर्फ इसलिए कि product चलता है, इसका मतलब यह नहीं कि वह चलता रहेगा। एक unsupported — या इससे भी बुरा, unsupportable — product पर निर्भर होने का मतलब है कि आप समय के साथ एक ऐसे product पर और अधिक निर्भर होते जा रहे हैं जिसकी potential support शायद घटती जा रही है।

यदि किसी proprietary product को production में deploy किया जाता है और support की मांगों को पूरा करने के लिए best practice deployments को छोड़ने का निर्णय लिया जाता है, तो यह किसी decision matrix में कैसे फिट होगा? क्या इसका अर्थ यह है कि उचित support मौजूद ही नहीं है? फिर से, यह हमारी जरूरतों के साथ एक mismatch दर्शाता है।

 

क्या इसे अभी भी develop किया जा रहा है?

यदि software की deployment जरूरतें पुरानी, outdated practices का पालन करती हैं, या outdated (या उचित रूप से current नहीं) software या design की मांग करती हैं, तो हमें सवाल करना होगा कि product का active development कितनी संभावना से हो रहा है। कुछ मामलों में हम software release cycle को कुछ समय देखकर यह पता लगा सकते हैं, लेकिन सभी में नहीं। यह एक उचित डर है कि product dead हो सकता है, जिसमें कोई development team काम नहीं कर रही। Code शायद पुराना, technical debt हो जिसे एक abandoned codebase से अंतिम कुछ रुपये कमाने की उम्मीद में बेचा जा रहा है। यह प्रक्रिया वास्तव में अक्सर सोचे जाने से कहीं अधिक सामान्य है।

छोटी software shops अक्सर एक initial software package develop करने, उसे market में लाने और बिक्री के लिए उपलब्ध कराने में सफल हो जाती हैं, लेकिन initial release(s) के बाद development team को retain या restaff करने का खर्च नहीं उठा पातीं। यह वास्तव में एक बहुत सामान्य scenario है। इससे customers के पास एक ऐसा product रह जाता है जो समय के साथ कम और कम viable होता जाता है।

 

Platform Supported न हो तो Software को कैसे Support किया जा सकता है?

कुछ अधिक extreme situations का एक सामान्य paradox वह software है जो "supported" माने जाने के लिए ऐसे अन्य software की मांग करता है जो या तो support से बाहर है या इच्छित use case के लिए कभी supported था ही नहीं। इसके सामान्य उदाहरण हैं server system को desktop operating system पर चलाने की मांग करना, या operating systems, databases या अन्य components के ऐसे versions की मांग करना जो अब बिल्कुल supported नहीं हैं। यह आखिरी scenario डरावने रूप से सामान्य है। ऐसी स्थिति में किसी को यह पूछना होगा कि क्या कोई ऐसा deployment हो सकता है जिसमें software को "supported" माना जाए? यदि stack का कोई हिस्सा हमेशा support से बाहर है, तो पूरा stack unsupported है। हमेशा कोई न कोई कारण होगा जिससे support से इनकार किया जा सके। वही कारण जिसकी वजह से हम best practices से दूर रहते हैं, वह software को पहली जगह में चुनने को भी रद्द कर देता है।

क्या Industry Skills और ज्ञान की कमी है?

शायद इस प्रकार के software support समस्याओं का कारण यह है कि software बनाने वाली team(s) को पता ही नहीं है कि अच्छा software कैसे बनाया जाता है और/या अच्छे systems कैसे deploy किए जाते हैं। यह उन सबसे उचित और valid कारणों में से है जो हमें इस स्थिति में ला सकते हैं। लेकिन, अन्य hypothetical कारणों की तरह, यह हमें software की quality और support की उपलब्धता के बारे में चिंतित करता है। यदि हम vendor पर system के सबसे visible हिस्सों को ठीक से संभालने का भरोसा नहीं कर सकते, तो हम उन हिस्सों के लिए उन पर विशेषज्ञ के रूप में क्यों भरोसा करें जिन्हें हम verify नहीं कर सकते?

बड़ी समस्या

Software जिसकी deployment और maintenance practice demands के बदले में अन्यथा रोकी गई support को unlock करना पड़े — उसकी बड़ी, overarching समस्या समग्र software quality का नहीं, बल्कि viable support और development practices का प्रश्न है। यह issues long-term support के लिए एक महत्वपूर्ण चिंता का सुझाव देती हैं जो हमें शुरू में ही इन packages को चुनने पर मजबूर सवाल करना चाहिए, जबकि हम उनसे strong support की उम्मीद रखते हैं।

निश्चित रूप से, ऐसे मामले हैं जहां किसी जरूरत को पूरा करने के लिए कोई अन्य software product नहीं है। यह situation अत्यंत दुर्लभ होनी चाहिए और यदि ऐसी situation exists है तो इसे उस विशेष space में प्रवेश करने के इच्छुक vendor के लिए एक बड़ा market opportunity माना जाना चाहिए।

Business perspective से, यह अनिवार्य है कि technical infrastructure best practices को vendor requirements के अंधे पालन के बदले में पूरी तरह से नजरअंदाज न किया जाए — जो किसी अन्य instance में लापरवाह या अव्यावसायिक माना जाता। हम ऐसे core products से excellence की मांग करना क्यों अक्सर भूल जाते हैं जिन पर हमारे businesses निर्भर करते हैं? यह हमारे businesses को जोखिम में डालता है — न केवल उस action से, बल्कि उन जोखिमों से और भी अधिक जो ऐसी मांग के अस्तित्व से implied होते हैं।