समाधान की सुंदरता (Solution Elegance)

IT में काम करते समय बड़े, जटिल समाधानों पर ध्यान केंद्रित करना बहुत आसान है। ऐसा लगता है कि अच्छे समाधान यहीं मिलते हैं – बड़े समाधान, बहुत सारा software, सभी नवीनतम gadgets। हम जो करते हैं वह रोमांचक है और इस गति में बह जाना बहुत आसान है। चुनौतीपूर्ण, बड़े projects करना मज़ेदार है। अन्य IT professionals क्या कर रहे हैं, अन्य कंपनियां चुनौतियों को कैसे हल करती हैं, और vendors से बड़े systems बेचने की बातें सुनना – यह सब उत्साह बढ़ाता है और scope तथा लक्ष्य का बोध खो देना बहुत आसान है। सरल समस्याओं के लिए बड़े, अत्यधिक समाधान देखना इतना सामान्य है कि लगता है IT ऐसी ही होती है।

लेकिन ऐसा होना ज़रूरी नहीं। जटिलता विश्वसनीयता और security दोनों की दुश्मन है। अनावश्यक रूप से जटिल समाधान acquisition और implementation के साथ-साथ maintenance में भी लागत बढ़ाते हैं, और आमतौर पर धीमे, अधिक नाजुक होते हैं तथा एक बड़ी attack surface रखते हैं जिसे समझना और सुरक्षित करना कठिन होता है। सरल, या अधिक उचित रूप से, elegant समाधान सबसे अच्छा दृष्टिकोण है। इसका मतलब यह नहीं कि सभी designs सरल होंगी। जटिल designs की अक्सर आवश्यकता होती है। IT ऐसा क्षेत्र नहीं है जहाँ जटिलता की कमी हो। वास्तव में, यह अक्सर माना जाता है कि software development शायद सभी मानवीय प्रयासों में सबसे जटिल है। एक सामान्य IT installation में लाखों lines of code, सैकड़ों या हजारों protocols, आपस में जुड़े बड़ी संख्या में systems, unique software configurations की परतें, इतनी settings होती हैं जिन्हें कोई भी team पूरी तरह नहीं जान सकती – और फिर इसमें सैकड़ों, हजारों या लाखों अप्रत्याशित, अतार्किक मनुष्यों की जटिलता भी जुड़ जाती है जो इन systems को अपने-अपने तरीके से उपयोग करते हैं। IT निस्संदेह जटिल है।

महत्वपूर्ण यह है कि हम यह स्वीकार करें कि IT जटिल है, इसे पूरी तरह से टाला नहीं जा सकता – लेकिन समाधानों को जितना संभव हो उतना सरल, graceful… elegant बनाने पर ध्यान केंद्रित करें। यह design विचार, कम से कम मेरे मन में, software engineering से आता है जहाँ जटिल code को एक गलती माना जाता है और सरल, सुंदर code जिसे पढ़ना और समझना आसान हो, सफल माना जाता है। एक software engineer को दी जा सकने वाली सबसे बड़ी प्रशंसा यह है कि उसके code को elegant कहा जाए। यह कितना उचित है कि Blaise Pascal को यह प्रसिद्ध उद्धरण दिया जाता है, जिनके नाम पर 1970s और 1980s की सबसे लोकप्रिय programming languages में से एक का नाम रखा गया (फ्रेंच से अनुवाद): “मुझे खेद है कि मुझे आपको इतना लंबा पत्र लिखना पड़ा, लेकिन मेरे पास एक छोटा पत्र लिखने का समय नहीं था।”

जटिल, उलझे हुए समाधान design करना अक्सर यह निर्धारित करने से कहीं अधिक आसान होता है कि कौन सा सरल दृष्टिकोण पर्याप्त होगा। चाहे हम जल्दी में हों या यह न जानते हों कि investigation कहाँ से शुरू करें, elegance हमेशा एक चुनौती है। Industry का momentum कठिन रास्ते को बढ़ावा देने का है। Vendors के हित में है अधिक equipment बेचना – न केवल प्रारंभिक sale के लिए बल्कि इसलिए भी क्योंकि वे जानते हैं कि अधिक equipment के साथ अधिक support dollars आते हैं। और यदि पर्याप्त नया, जटिल equipment बेचा जाए तो support की आवश्यकता रैखिक रूप से नहीं बल्कि ज्यामितीय रूप से बढ़ती है। जटिलता के पीछे वित्तीय प्रभाव बड़े हैं, और वे vendors तक ही सीमित नहीं हैं। IT professionals hardware और software के बड़े sets का प्रबंधन करके नौकरी की सुरक्षा, या उसका भ्रम, प्राप्त करते हैं।

अक्सर जटिलता इतनी मानी हुई, इतनी अपेक्षित होती है कि समाधान चुनने की प्रक्रिया बिना किसी विचार के बड़ी जटिलता से शुरू होती है। मुझे वास्तव में यह देखकर आश्चर्य हुआ है कि एक सरल समाधान कीमत, performance और विश्वसनीयता में एक जटिल से बेहतर हो सकता है।

Rhetoric आसान है, लेकिन वास्तविक दुनिया का उदाहरण क्या है? आज जो सबसे अच्छे उदाहरण मुझे दिखते हैं वे mostly virtualization से संबंधित हैं – चाहे storage हो, cloud management layer हो, software हो या virtualization ही। मैं अक्सर देखता हूँ कि सिर्फ एक व्यक्ति के लिए virtualization की बातचीत तुरंत networked, shared block storage, महंगे virtualization management software, कई redundant virtualization nodes और complex high availability software की आवश्यकता का भाव पैदा करती है – जिनमें से कोई भी virtualization का अंतर्निहित हिस्सा नहीं है। व्यावसायिक आवश्यकताओं से काम करने के बजाय, ये अवधारणाएं प्रौद्योगिकी की पूर्वधारणाओं से उभरती हैं। जटिलता की ओर इशारा करना और एक समस्या हल करते हुए दिखना आसान है – जटिलता सुकून का एहसास देती है। कई तर्कों को सरल करने पर आप सुनेंगे: “यह काम कैसे नहीं करेगा, यह तो जटिल है!” जटिलता पूर्णता का भ्रम देती है, लेकिन यह इस तथ्य को छुपा सकती है कि एक समाधान वास्तव में पूर्ण या कार्यात्मक नहीं है।

इसका एक बड़ा उदाहरण यह है कि हम reliability के बजाय redundancy पर चर्चा करने लगते हैं। Reliability को मापना कठिन है, redundancy को quantify करना आसान है। एक ईंट अत्यधिक reliable होती है, यहाँ तक कि अकेली भी। ईंट को stable और robust होने के लिए redundancy की आवश्यकता नहीं है। उसका design सरल है। आप कई redundant छड़ियों से एक supporting structure बना सकते हैं जो एक अकेली ईंट जितना reliable नहीं होगा। यदि आप reliability की बात करें – कि structure fail नहीं होगी – तो यह स्पष्ट है कि ईंट कई छड़ियों से बेहतर है। लेकिन computers और computer systems में हम ऐसी systems पाते हैं जो इतनी जटिल हैं कि लोग शायद ही पहचान पाते हैं कि उनके पास ईंट है या छड़ी।

इसे RAID में भी देखा जा सकता है। Mirrored RAID सरल है – एक disk या disk का set दूसरे set की exact copy है। यह इतना सरल है। Parity RAID जटिल है जिसमें कई devices में variable stripe पर calculations होती हैं जिन्हें लिखते समय encode और device fail होने पर decode करना पड़ता है। Mirrored RAID में यह जटिलता नहीं है और यह disk reliability की समस्या को सरल, elegant copy operations से हल करता है जो highly reliable और अच्छी तरह से समझे जाते हैं। Parity RAID अनावश्यक रूप से जटिल है जिससे यह नाजुक बन जाती है। फिर भी ऐसा करके और अपनी समस्या-समाधान क्षमता को कमज़ोर करके यह एक साथ, अपनी जटिलता के अलावा किसी अन्य कारण से अधिक reliable लगने लगती है।

सरलता खोजने का कोई सरल उत्तर नहीं है। यह जानना कि जटिलता स्वभाव से बुरी है लेकिन कभी-कभी अपरिहार्य है, हमें सजग रहना सिखाता है, लेकिन यह नहीं सिखाता कि कब अत्यधिक जटिलता का संदेह करें। हमें हमेशा यह निर्धारित करने की कोशिश करते रहना चाहिए कि क्या कोई अधिक elegant उत्तर मौजूद है और जटिलता को केवल इसलिए सही उत्तर न मान लें क्योंकि वह जटिल है। हमें प्रस्तावित समाधानों पर और खुद पर सवाल उठाने चाहिए: “क्या यह समाधान वाकई उतना सरल है जितना होना चाहिए?” “क्या यह जटिलता आवश्यक है?” “क्या इसे उतनी जटिलता की जरूरत है जितनी मैंने मान ली थी?”

मेरे अधिकांश system design recommendations में, पहला तकनीकी निर्धारण कदम जो मैं सामान्यतः उठाता हूँ – business की आवश्यकता जानने के बाद – जटिलता पर सवाल उठाना है। यदि जटिलता की रक्षा नहीं की जा सकती, तो यह शायद अनावश्यक है।

“क्या उन drives को कई अलग-अलग arrays में विभाजित करना वाकई जरूरी है? यदि हाँ, तो इसका तकनीकी औचित्य क्या है?”

“क्या आप जिस काम के लिए इसे propose कर रहे हैं उसके लिए shared storage वाकई आवश्यक है?”

“क्या business distributed high availability technologies के उपयोग को वास्तव में justify करता है?”

“हम एक सरल system को जो कल पर्याप्त था, कल एक बहुत अधिक जटिल system से क्यों बदल रहे हैं? ऐसा क्या बदल गया है जो एक बड़े सुधार को – सरल रहते हुए – पर्याप्त नहीं बनाता और orders of magnitude अधिक जटिलता और खर्च की आवश्यकता है जो पहले justified नहीं था?”

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