Redis को देखते हुए: क्या हम सच में आविष्कार करने वाले डेवलपर हैं?

Redis ecosystem को देखते हुए, मैं फिर से सोचता हूँ कि क्या मैं सच में गर्व से खुद को आविष्कार करने वाला डेवलपर कह सकता हूँ।

Key-Value स्टोरेज का जन्म

• 2000 के दशक के बाद Web 2.0 युग आने पर वेब सर्विस कंपनियों को बहुत बड़ी संख्या में users को संभालने की स्थिति का सामना करना पड़ा
• इस भारी traffic को संभालने के लिए बड़े और शानदार servers नहीं, बल्कि छोटे लेकिन सस्ते large-scale distributed systems की ज़रूरत पड़ी
• सौभाग्य से ज़्यादातर data structures सरल थे (उदा. userid = 1234 की जानकारी लाना)
• relational database (RDBMS) का उपयोग करना बहुत भारी, महँगा और जटिल था
• CAP Theorem सामने आया
• तो फिर consistency छोड़नी पड़े, तब भी availability और speed को पकड़ सकते हैं
• key देने पर value लौटाने वाला एक सरल database पैदा हुआ (Memcached-2003, Amazon Dynamo-2007)

Redis का जन्म

• pasta की जन्मभूमि Italy में Salvatore Sanfilippo नाम के एक डेवलपर LLOOGG नाम का startup चला रहे थे (Log की spelling में सचमुच दो o हैं)
• LLOOGG वेबसाइट visitors की real-time tracking service देता था
• छोटा होने के बावजूद उसके वास्तविक users भी थे
• उस समय real-time analytics काफ़ी कठिन काम था
• data जमा होना शुरू हुआ → मौजूदा RDBMS धीरे-धीरे slow होता गया → real-time responsiveness नहीं मिल रही थी
• real-time प्रतिक्रिया के लिए memory का उपयोग करना ज़रूरी था → उस समय Memcached सिर्फ string रूप में साधारण GET, PUT ही support करता था
• INCR, DECR, LIST जैसी थोड़ी अधिक विस्तारित dictionary functionality चाहिए थी, लेकिन ऐसी कोई DB नहीं थी? → चलो, मैं ही बना देता हूँ
• बहुत साधारण TCP server पर चलने वाला शुरुआती version पैदा हुआ (cluster, AOF, replication जैसी कोई high-end features नहीं थीं)

Redis का विकास

• Redis cache नहीं, बल्कि real-time processing के लिए data structure store बनने के उद्देश्य से पैदा हुआ था
• लेकिन लोगों ने इसे cache के रूप में इस्तेमाल करना शुरू कर दिया
• मौजूदा दिग्गजों (Facebook, Twitter, GitHub, Stack Overflow आदि) की cache से आगे बढ़ी data structure requirements बढ़ने लगीं
• session storage, login token management, real-time counters, ranking systems, likes की गिनती जैसी छोटी सुविधाओं से इसका क्रमिक उपयोग शुरू हुआ
• ज़रूरत के अनुसार features और data structures विकसित होते हुए जोड़े गए (Sorted Set, HASH, Cluster, persistence...)
• यह एक लचीला data processing platform बन गया

Community, UX और डेवलपर की philosophy

• Redis के आधार में यह philosophy है कि features बहुत हों, फिर भी वह जटिल नहीं होना चाहिए
• official docs CLI-आधारित, तुरंत चलाए जा सकने वाले samples और स्पष्ट behavior explanation देती हैं
• intuitive commands (SET, GET, LPUSH, ZADD, HGETALL आदि) को official docs में बस एक बार सरसरी नज़र से देखने पर ही अंदाज़ा हो जाता है कि वे क्या करती हैं
• यह intuitiveness सिर्फ सुविधा से आगे बढ़कर tool के प्रति मनोवैज्ञानिक बाधा को कम करती है और developer productivity बढ़ाती है
• इस संरचना से निकलने वाली versatility users, cloud providers और open source contributors, सभी के लिए फ़ायदेमंद होती है
• एक-दूसरे के हितों से बने ecosystem में Redis थोपा हुआ नहीं, बल्कि चुना गया विकल्प बनकर In-memory DB का de facto standard बन गया

Redis ecosystem को देखते हुए

• Redis की शुरुआत website visitor real-time analytics जैसी, शायद आम-सी लगने वाली idea को लागू करने के साधन के रूप में हुई
• इसने SQL जैसी मौजूदा पद्धति की सीमाओं (slow और expensive) को एक नए approach से तोड़ा
• यह vendor नेटवर्क का इस्तेमाल, suppliers पर दबाव, hardware tuning या usage restriction जैसी पुरानी rules की optimization नहीं थी
• इसने memory को DB का केंद्रीय तत्व बना देने वाला एक नया rule बनाया
• tool को खुद design करना, पहले से न रहे flow का प्रस्ताव रखना, और फिर पूरी दुनिया से उसे स्वीकार करवाना हो, तो applications के लिए fundamental knowledge महत्वपूर्ण होती है
• सिर्फ shopping cart storage की समस्या हल करने के लिए बनाए गए Amazon Dynamo को देखें, तो भी complex distributed systems knowledge के application की ज़रूरत पड़ती है
• जब यह सबकी स्वैच्छिक पसंद से industry standard बनता है, तो विशाल अतिरिक्त मूल्य और रोज़गार पैदा होते हैं
• Redis विशेषज्ञ मानव संसाधन, hardware infrastructure, learning content, managed services (AWS, Azure), और specialized solutions (Redis Enterprise) को देखकर यह बात महसूस की जा सकती है
• यह सब किसी xx industry को बचाने या छोटे व्यवसायों वगैरह जैसी सरकारी policies या क़ानूनों से पैदा नहीं हुआ

हमें यह सोचना चाहिए कि क्या हम अब भी सिर्फ़ बाहरी रूप से विकसित देश जैसे दिखते हुए, शायद manufacturing era की सोच में जी रहे हैं, और डेवलपर को knowledge service industry का कर्मचारी समझने की ग़लतफ़हमी पाल रहे हैं।

• क्या हम साबित कर सकते हैं कि foundational technologies (उदा. algorithms) क्यों महत्वपूर्ण हैं, वह भी परिणामों से
• क्या समस्या हल करने के लिए tools बना सकने वाली डेवलपर संस्कृति और शिक्षा प्रणाली हमारे पास है
• सब कहते हैं कि failure को स्वीकार करने वाली culture बनानी चाहिए, लेकिन क्या मैं खुद दूसरों की गलती पर ग़ुस्सा या गाली नहीं देता
• क्या हम knowledge service industry के असली value addition को सच में समझकर उसे लगातार आगे बढ़ा सकते हैं

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

[roxie]

मुझे लगता है मैं नकली हूँ टीटी

[iolothebard]

उपयोगिता का आविष्कार…