प्रिय Google क्लाउड, बैकवर्ड संगत न होना आपको मार रहा है।

लानत है गूगल, मैं दोबारा ब्लॉग नहीं करना चाहता था। मुझे बहुत कुछ करना है. ब्लॉगिंग में समय, ऊर्जा और रचनात्मकता लगती है, जिसका मैं अच्छा उपयोग कर सकता हूँ: मेरी किताबें, музыка, मेरा खेल इत्यादि। लेकिन आपने मुझे इतना परेशान कर दिया है कि मुझे यह लिखना पड़ा।

तो चलिए इसे ख़त्म करते हैं।

मैं एक छोटी लेकिन शिक्षाप्रद कहानी से शुरुआत करता हूँ, जब मैंने पहली बार Google में काम करना शुरू किया था। मैं जानता हूं कि मैं हाल ही में Google के बारे में बहुत सारी बुरी बातें कह रहा हूं, लेकिन जब मेरी अपनी कंपनी नियमित रूप से अक्षम व्यावसायिक निर्णय लेती है तो मुझे निराशा होती है। साथ ही, हमें इसे इसका हक देना चाहिए: Google का आंतरिक बुनियादी ढांचा वास्तव में असाधारण है, यह कहना सुरक्षित है कि आज इससे बेहतर कुछ नहीं है। Google के संस्थापक मुझसे कहीं बेहतर इंजीनियर थे, और यह कहानी केवल इस तथ्य की पुष्टि करती है।

सबसे पहले, थोड़ी पृष्ठभूमि: Google के पास डेटा स्टोरेज तकनीक है जिसे कहा जाता है बड़ी मेज. यह एक उल्लेखनीय तकनीकी उपलब्धि थी, पहली (यदि पहली नहीं तो) "असीम रूप से स्केलेबल" की-वैल्यू स्टोर (K/V) में से एक: अनिवार्य रूप से NoSQL की शुरुआत। इन दिनों बिगटेबल अभी भी भीड़-भाड़ वाले के/वी स्टोरेज स्पेस में अच्छा प्रदर्शन कर रहा है, लेकिन उस समय (2005) यह आश्चर्यजनक रूप से अच्छा था।

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

एक और दिलचस्प विवरण यह है कि कुछ समय के लिए बिगटेबल Google के भीतर लोकप्रिय और सर्वव्यापी हो गया, प्रत्येक टीम के पास अपना भंडार था। तो शुक्रवार की एक बैठक में, लैरी पेज ने लापरवाही से पूछा: “हमारे पास एक से अधिक बिगटेबल क्यों हैं? सिर्फ एक ही क्यों नहीं?” सिद्धांत रूप में, Google की सभी संग्रहण आवश्यकताओं के लिए एक संग्रहण पर्याप्त होना चाहिए। बेशक, वे व्यावहारिक विकास कारणों (जैसे संभावित विफलता के परिणाम) के लिए कभी भी किसी एक के पास नहीं गए, लेकिन सिद्धांत दिलचस्प था। संपूर्ण ब्रह्मांड के लिए एक भंडार (वैसे, क्या किसी को पता है कि अमेज़न ने अपने सेबल के साथ ऐसा किया है?)

वैसे भी, यहाँ मेरी कहानी है.

उस समय, मैं Google में केवल दो वर्षों से अधिक समय से काम कर रहा था, और एक दिन मुझे बिगटेबल इंजीनियरिंग टीम से एक ईमेल प्राप्त हुआ जो कुछ इस प्रकार था:

प्रिय स्टीव,

बिगटेबल टीम की ओर से नमस्कार। हम आपको सूचित करना चाहेंगे कि [डेटा सेंटर नाम] पर आप एक बहुत, बहुत पुरानी बिगटेबल बाइनरी का उपयोग कर रहे हैं। यह संस्करण अब समर्थित नहीं है और हम नवीनतम संस्करण में अपग्रेड करने में आपकी सहायता करना चाहते हैं।

कृपया मुझे बताएं कि क्या आप इस मुद्दे पर साथ मिलकर काम करने के लिए कुछ समय निर्धारित कर सकते हैं।

शुभकामनाएं,
बिगटेबल टीम

Google पर आपको बहुत सारे मेल मिलते हैं, इसलिए पहली नज़र में मुझे कुछ इस तरह पढ़ा:

प्रिय प्राप्तकर्ता,

कुछ टीम की ओर से नमस्ते. हम यह संचार करना चाहते हैं कि ब्ला ब्ला ब्ला ब्ला ब्ला। ब्ला ब्ला ब्ला ब्ला ब्ला ब्ला, और तुरंत ब्ला ब्ला ब्ला।

कृपया हमें बताएं कि क्या आप अपना कुछ कीमती समय ब्ला ब्ला ब्ला के लिए निर्धारित कर सकते हैं।

शुभकामनाएं,
किसी प्रकार का आदेश

मैंने इसे लगभग तुरंत ही हटा दिया था, लेकिन अपनी चेतना के किनारे पर मुझे एक दर्दनाक, परेशान करने वाली अनुभूति महसूस हुई कि यह वास्तव में नहीं हालाँकि यह एक औपचारिक पत्र जैसा लगता है स्पष्ट रूप से, कि प्राप्तकर्ता ग़लत था क्योंकि मैंने बिगटेबल का उपयोग नहीं किया था।

लेकिन यह अजीब था.

मैंने शेष दिन बारी-बारी से काम के बारे में और माइक्रो-किचन में किस प्रकार के शार्क मांस का प्रयास किया जाए, इसके बारे में सोचने में बिताया, जिनमें से कम से कम तीन इतने करीब थे कि मेरी सीट से एक बिस्किट फेंककर मारा जा सके, लेकिन लिखने के बारे में सोचने से मुझे कभी भी हल्की-फुल्की चिंता का एहसास नहीं हुआ।

उन्होंने साफ़-साफ़ मेरा नाम बताया. और ईमेल मेरे ईमेल पते पर भेजा गया था, किसी और के नहीं, और यह सीसी: या बीसीसी: नहीं है। लहजा बहुत व्यक्तिगत और स्पष्ट है. शायद यह किसी तरह की गलती है?

अंततः, जिज्ञासा मुझ पर हावी हो गई और मैं उनके द्वारा बताए गए डेटा सेंटर में बोर्ग कंसोल को देखने गया।

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

इस कहानी के कई उल्लेखनीय पहलू हैं। सबसे पहले, बिगटेबल का काम Google के पैमाने पर इतना महत्वहीन था कि केवल दो साल बाद ही किसी ने अतिरिक्त भंडारण पर ध्यान दिया, और केवल इसलिए कि बाइनरी का संस्करण पुराना हो गया था। तुलना के लिए, मैंने एक बार उपयोग करने पर विचार किया था Google क्लाउड पर बिगटेबल मेरे ऑनलाइन गेम के लिए. उस समय, इस सेवा की लागत लगभग $16 प्रति वर्ष थी। खाली जीसीपी पर बिगटेबल. मैं यह नहीं कह रहा हूं कि वे आपके साथ धोखाधड़ी कर रहे हैं, लेकिन मेरी निजी राय में, खाली डेटाबेस के लिए यह बहुत सारा पैसा है।

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

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

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

प्रिय Google क्लाउड उपयोगकर्ता,

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

हम यह सुनिश्चित करने के लिए प्रतिबद्ध हैं कि इस परिवर्तन का Google क्लाउड प्लेटफ़ॉर्म के सभी उपयोगकर्ताओं पर न्यूनतम प्रभाव पड़े।

हमेशा के लिए अच्छे दोस्त,
गूगल क्लाउड प्लेटफार्म

लेकिन मैंने ऐसे पत्र लगभग कभी नहीं पढ़े, क्योंकि वे वास्तव में क्या कहते हैं:

प्रिय प्राप्तकर्ता,

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

हम यह सुनिश्चित करने के लिए प्रयास जारी रखते हैं कि आपके सभी विकास एक वर्ष के भीतर अनुपयोगी हो जाएं।

कृपया भाड़ में जाओ
गूगल क्लाउड प्लेटफार्म

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

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

मैं Google के बाहर अन्य बड़ी परियोजनाओं से कुछ यादृच्छिक उदाहरण दूंगा, लेकिन मुझे आशा है कि आप इस पैटर्न को हर जगह देखेंगे। यह इस प्रकार है: बैकवर्ड अनुकूलता सिस्टम को दशकों तक जीवित और अद्यतन रखती है.

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

पहला सिस्टम जो मैं चुनूंगा वह सबसे पुराना है: GNU Emacs, जो कि विंडोज नोटपैड, OS कर्नेल और इंटरनेशनल स्पेस स्टेशन के बीच एक हाइब्रिड है। इसे समझाना थोड़ा कठिन है, लेकिन संक्षेप में, Emacs आपको अधिक उत्पादक बनाने के लिए प्रोग्रामिंग के लिए 1976 में (हाँ, लगभग आधी सदी पहले) बनाया गया एक प्लेटफ़ॉर्म है, लेकिन एक टेक्स्ट एडिटर के रूप में प्रच्छन्न है।

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

मैं अभी भी उस सॉफ़्टवेयर का उपयोग करता हूं जो मैंने 1995 में Emacs के लिए लिखा था। और मुझे यकीन है कि कोई व्यक्ति 80 के दशक के मध्य में Emacs के लिए लिखे गए मॉड्यूल का उपयोग कर रहा है, यदि पहले नहीं। उन्हें समय-समय पर थोड़े बदलाव की आवश्यकता हो सकती है, लेकिन यह वास्तव में काफी दुर्लभ है। मैं Emacs के लिए लिखी गई किसी भी चीज़ के बारे में नहीं जानता (और मैंने बहुत कुछ लिखा है) जिसके लिए पुनः आर्किटेक्चर की आवश्यकता पड़ी हो।

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

लेकिन Emacs दुनिया में एक अलग कार्यशील परिभाषा प्रतीत होती है। यदि आप चाहें तो एक अलग अंतर्निहित दर्शन।

Emacs की दुनिया में (और कई अन्य क्षेत्रों में, जिन्हें हम नीचे कवर करेंगे), बहिष्कृत एपीआई स्थिति का मूल रूप से मतलब है: "आपको वास्तव में इस दृष्टिकोण का उपयोग नहीं करना चाहिए, क्योंकि जब यह काम करता है, तो यह विभिन्न कमियों से ग्रस्त है जो हम करेंगे यहाँ सूची. लेकिन आख़िरकार, यह आपकी पसंद है।"

Google की दुनिया में, अप्रचलित होने का अर्थ है, "हम आपके प्रति अपनी प्रतिबद्धता का उल्लंघन कर रहे हैं।" यह सच है। इसका मूलतः यही मतलब है। इसका मतलब है कि वे तुम्हें मजबूर करेंगे नियमित उन पर विश्वास करने की सज़ा के तौर पर कुछ काम करें, शायद बहुत सारा काम करें रंगीन विज्ञापन: हमारे पास सबसे अच्छा सॉफ्टवेयर है। सबसे तेज! आप निर्देशों के अनुसार सब कुछ करते हैं, अपना एप्लिकेशन या सेवा लॉन्च करते हैं, और फिर, एक या दो साल के बाद यह टूट जाता है।

यह एक पुरानी कार बेचने जैसा है जो 1500 किमी के बाद निश्चित रूप से खराब हो जाएगी।

ये "अप्रचलन" की दो पूरी तरह से अलग-अलग दार्शनिक परिभाषाएँ हैं। Google की गंध की परिभाषा नियोजित मूल्यह्रास. मैं इस पर विश्वास नहीं करता वास्तव में Apple के समान अर्थ में नियोजित अप्रचलन। लेकिन Google निश्चित रूप से आपके कार्यक्रमों को गोल-मोल तरीके से तोड़ने की योजना बना रहा है। मैं यह जानता हूं क्योंकि मैंने वहां 12 वर्षों से अधिक समय तक एक सॉफ्टवेयर इंजीनियर के रूप में काम किया है। उनके पास अस्पष्ट आंतरिक दिशानिर्देश हैं कि बैकवर्ड संगतता का कितना पालन किया जाना चाहिए, लेकिन यह अंततः प्रत्येक व्यक्तिगत टीम या सेवा पर निर्भर है। कोई उद्यम या इंजीनियरिंग-स्तर की सिफारिशें नहीं हैं, और अप्रचलन चक्रों के संदर्भ में सबसे साहसी सिफारिश यह है कि "ग्राहकों को उनके पूरे सिस्टम को तोड़ने से पहले अपग्रेड करने के लिए 6-12 महीने देने का प्रयास करें।"

समस्या उनकी सोच से कहीं अधिक बड़ी है और यह आने वाले वर्षों तक बनी रहेगी क्योंकि ग्राहक सेवा उनके डीएनए में नहीं है। इस पर और अधिक जानकारी नीचे दी गई है।

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

दरअसल, मुझे एंड्रॉइड का संक्षेप में उल्लेख करना चाहिए क्योंकि आप शायद इसके बारे में सोच रहे हैं।

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

पिछले लेख में, मैंने चर्चा की थी कि एंड्रॉइड के कुछ शुरुआती डिज़ाइन निर्णय कितने बुरे थे। हेक, जब मैंने वह लेख लिखा था तो वे "तत्काल ऐप्स" नामक बकवास ला रहे थे जो अब (आश्चर्यजनक!) हैं पुराना है, और यदि आप इतने मूर्ख थे कि Google की बात सुनकर अपनी सामग्री को इन त्वरित ऐप्स पर ले गए तो मुझे सहानुभूति है।

लेकिन यहां एक अंतर है, एक महत्वपूर्ण अंतर, जो यह है कि एंड्रॉइड लोग वास्तव में समझते हैं कि प्लेटफ़ॉर्म कितने महत्वपूर्ण हैं, वे पुराने एंड्रॉइड ऐप्स को चालू रखने की पूरी कोशिश करते हैं। असल में, बैकवर्ड संगतता बनाए रखने के उनके प्रयास इतने चरम हैं कि यहां तक ​​कि कुछ साल पहले एंड्रॉइड डिवीजन में अपने संक्षिप्त कार्यकाल के दौरान, मैंने खुद को कुछ सबसे पुराने उपकरणों और एपीआई के लिए समर्थन छोड़ने के लिए मनाने की कोशिश की थी (मैं गलत था) , जैसा कि अतीत और वर्तमान में कई अन्य चीजों में था। क्षमा करें एंड्रॉइड दोस्तों! अब जब मैं इंडोनेशिया गया हूं, तो मुझे समझ में आया कि हमें उनकी आवश्यकता क्यों है)।

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

इसके लिए, मैं एंड्रॉइड को प्रतिष्ठित "यू आर नॉट गूगल" पुरस्कार प्रदान करता हूं। वे वास्तव में Google नहीं बनना चाहते, जो टिकाऊ प्लेटफ़ॉर्म बनाना नहीं जानता, बल्कि Android बनना चाहता है वह जानता है कि, इसे कैसे करना है। और इसलिए Google एक मामले में बहुत स्मार्ट हो रहा है: लोगों को Android पर अपने तरीके से काम करने की अनुमति देना।

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

लेकिन एक अंतर है। पिछड़ी अनुकूलता की बड़ी कीमत चुकानी पड़ती है। एंड्रॉइड इन लागतों का बोझ खुद वहन करता है, जबकि Google इस बात पर ज़ोर देता है कि यह बोझ वहन किया जाए आप हैं, भुगतान करने वाला ग्राहक।

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

यहां Google की मुख्य समस्या उनकी इंजीनियरिंग स्वच्छता पर उनका गर्व है। उन्हें यह पसंद नहीं है जब एक ही काम को करने के कई अलग-अलग तरीके हों, पुराने, कम वांछनीय तरीके नए, आकर्षक तरीकों के बगल में हों। यह सिस्टम में नए लोगों के लिए सीखने की अवस्था को बढ़ाता है, यह विरासत एपीआई को बनाए रखने का बोझ बढ़ाता है, यह नई सुविधाओं की गति को धीमा कर देता है, और मुख्य पाप यह है कि यह सुंदर नहीं है। Google - टिम बर्टन की ऐलिस इन वंडरलैंड की लेडी एस्कॉट की तरह:

लेडी एस्कॉट:
- ऐलिस, क्या तुम्हें पता है कि मुझे सबसे ज़्यादा डर किस चीज़ से लगता है?
- अभिजात वर्ग का पतन?
- मुझे डर था कि मेरे पास होगा बदसूरत पोते.

सुंदर और व्यावहारिक के बीच के तालमेल को समझने के लिए, आइए तीसरे सफल प्लेटफ़ॉर्म (Emacs और Android के बाद) पर एक नज़र डालें और देखें कि यह कैसे काम करता है: Java ही।

जावा में बहुत सारे पुराने एपीआई हैं। जावा प्रोग्रामर्स के बीच डिप्रेशन बहुत लोकप्रिय है, यहां तक ​​कि अधिकांश प्रोग्रामिंग भाषाओं की तुलना में यह अधिक लोकप्रिय है। स्वयं जावा, मुख्य भाषा और पुस्तकालय लगातार एपीआई का बहिष्कार कर रहे हैं।

हज़ारों उदाहरणों में से केवल एक को लें, समापन धागे अप्रचलित माना जाता है. दिसंबर 1.2 में जावा 1998 के रिलीज़ होने के बाद से इसे बंद कर दिया गया है। इसे अस्वीकृत हुए 22 साल हो गए हैं।

लेकिन उत्पादन में मेरा वास्तविक कोड अभी भी धागों को खत्म कर रहा है हर दिन. क्या आप सचमुच सोचते हैं कि यह अच्छा है? बिल्कुल! मेरा मतलब है, निश्चित रूप से, अगर मुझे आज कोड को फिर से लिखना होता, तो मैं इसे अलग तरीके से लागू करता। लेकिन मेरे गेम का कोड, जिसने पिछले दो दशकों में सैकड़ों हजारों लोगों को खुश किया है, बहुत लंबे समय तक लटके हुए धागों को बंद करने के लिए एक फ़ंक्शन के साथ लिखा गया है, और मैं इसे कभी बदलना नहीं पड़ा. मैं अपने सिस्टम को किसी से भी बेहतर जानता हूं, मेरे पास उत्पादन में इसके साथ काम करने का वस्तुतः 25 वर्षों का अनुभव है, और मैं निश्चित रूप से कह सकता हूं: मेरे मामले में, इन विशिष्ट कार्यकर्ता थ्रेड को बंद करना पूरी तरह से है हानिरहित. इस कोड को फिर से लिखना समय और प्रयास के लायक नहीं है, और लैरी एलिसन (शायद) को धन्यवाद कि ओरेकल ने मुझे इसे फिर से लिखने के लिए मजबूर नहीं किया।

ओरेकल शायद प्लेटफ़ॉर्म को भी समझता है। कौन जानता है।

साक्ष्य संपूर्ण जावा एपीआई में पाए जा सकते हैं, जो घाटी में ग्लेशियर की रेखाओं की तरह अप्रचलन की लहरों से भरे हुए हैं। आप जावा स्विंग लाइब्रेरी में पांच या छह अलग-अलग कीबोर्ड नेविगेशन मैनेजर (कीबोर्डफोकसमैनेजर) आसानी से पा सकते हैं। ऐसा जावा एपीआई ढूंढना वास्तव में कठिन है जो अप्रचलित न हो। लेकिन वे अभी भी काम करते हैं! मुझे लगता है कि जावा टीम वास्तव में केवल तभी एपीआई को हटाएगी जब इंटरफ़ेस एक स्पष्ट सुरक्षा समस्या उत्पन्न करता है।

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

आइए काल्पनिक रूप से मान लें कि Apple ने मूर्खतापूर्वक गुइडो वैन रोसुम से संकेत लिया और घोषणा की कि स्विफ्ट 6.0, स्विफ्ट 5.0 के साथ असंगत है, ठीक उसी तरह जैसे Python 3, Python 2 के साथ असंगत है।

मैंने शायद यह कहानी लगभग दस साल पहले सुनाई थी, लेकिन लगभग पंद्रह साल पहले मैं गुइडो के साथ ओ'रेली के फू कैंप में गया था, पॉल ग्राहम और कुछ बड़े शॉट्स के साथ एक तंबू में बैठा था। हम प्रचंड गर्मी में लैरी पेज के अपने निजी हेलीकॉप्टर में उड़ान भरने के इंतजार में बैठे रहे, जबकि गुइडो ने "पायथन 3000" पर ड्रोन किया, जिसका नाम उन्होंने उन वर्षों की संख्या के आधार पर रखा, जो हर किसी को वहां स्थानांतरित होने में लगेंगे। हम उनसे पूछते रहे कि वह अनुकूलता क्यों तोड़ रहे हैं, और उन्होंने उत्तर दिया: "यूनिकोड।" और हमने पूछा, यदि हमें अपना कोड फिर से लिखना पड़ा, तो हमें और क्या लाभ दिखाई देंगे? और उसने उत्तर दिया "यौउउउउउउउउउउउउउउउउउउउउउउउउउउउउदे।"

यदि आप Google क्लाउड प्लेटफ़ॉर्म SDK ("gcloud") इंस्टॉल करते हैं, तो आपको निम्नलिखित सूचना प्राप्त होगी:

प्रिय प्राप्तकर्ता,

हम आपको याद दिलाना चाहेंगे कि Python 2 के लिए समर्थन बंद कर दिया गया है, इसलिए भाड़ में जाओ

… और इसी तरह। जीवन का चक्र।

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

इस पश्चगामी असंगति के कारण गो (या रूबी, या किसी अन्य विकल्प) में कितने पायथन कार्यक्रमों को फिर से लिखा गया है? हालाँकि, Python के अलावा किसी अन्य चीज़ में कितना नया सॉफ़्टवेयर लिखा गया है हो सकता है पायथन में लिखा है, अगर गुइडो ने पूरे गांव को नहीं जला दिया होता? यह कहना कठिन है, लेकिन पायथन को स्पष्ट रूप से नुकसान हुआ है। यह बहुत बड़ी गड़बड़ी है और हर कोई हारता है।

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

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

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

ग्रोक ने Googlers को उनके संपूर्ण कोडबेस (शाब्दिक रूप से संपूर्ण Google) में स्वचालित रिफैक्टरिंग करने के लिए एक शक्तिशाली ढांचा प्रदान किया। सिस्टम न केवल आपकी अपस्ट्रीम निर्भरता (जिस पर आप निर्भर हैं) की गणना करता है, बल्कि इसकी भी गणना करता है अवरोही (जो आप पर निर्भर है) इसलिए जब आप एपीआई बदलते हैं तो आप जानते हैं कि आप किसका उल्लंघन कर रहे हैं! इस तरह, जब आप परिवर्तन करते हैं, तो आप सत्यापित कर सकते हैं कि आपके एपीआई के प्रत्येक उपभोक्ता ने नए संस्करण में अपडेट किया है, और वास्तव में, अक्सर उनके द्वारा लिखे गए रोज़ी टूल के साथ, आप प्रक्रिया को पूरी तरह से स्वचालित कर सकते हैं।

यह Google के कोडबेस को आंतरिक रूप से लगभग अलौकिक रूप से साफ करने की अनुमति देता है, क्योंकि उनके पास ये रोबोटिक नौकर हैं जो घर के चारों ओर घूमते हैं और स्वचालित रूप से सब कुछ साफ कर देते हैं यदि उन्होंने SomDespicableLongFunctionName का नाम बदलकर SomDespicableLongMethodName कर दिया है क्योंकि किसी ने फैसला किया कि यह एक बदसूरत पोता था और उसे सुलाने की जरूरत थी।

और स्पष्ट रूप से, यह Google के लिए बहुत अच्छा काम करता है... आंतरिक रूप से। मेरा मतलब है, हाँ, Google में गो समुदाय की निरंतर रिफैक्टरिंग की आदत के कारण Google में जावा समुदाय के साथ अच्छी हंसी है। यदि आप किसी चीज़ को N बार पुनः आरंभ करते हैं, तो इसका मतलब है कि आपने न केवल इसे N-1 बार खराब किया है, बल्कि थोड़ी देर के बाद यह बिल्कुल स्पष्ट हो जाता है कि आपने संभवतः इसे Nवें प्रयास में भी खराब कर दिया है। लेकिन, कुल मिलाकर, वे इस सब झंझट से ऊपर रहते हैं और कोड को "साफ़" रखते हैं।

समस्या तब शुरू होती है जब वे अपने क्लाउड क्लाइंट और अन्य एपीआई के उपयोगकर्ताओं पर यह रवैया थोपने की कोशिश करते हैं।

मैंने आपको Emacs, Android और Java से थोड़ा परिचित कराया है; आइए नवीनतम सफल दीर्घकालिक प्लेटफ़ॉर्म पर नज़र डालें: वेब ही। क्या आप कल्पना कर सकते हैं कि 1995 से जब हमने फ्लैशिंग टैग का उपयोग किया था तब से HTTP कितने पुनरावृत्तियों से गुजरा है? और वेब पेजों पर "निर्माणाधीन" आइकन।

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

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

लेकिन रुकिए, आप कहते हैं। क्या हम सेब की तुलना संतरे से नहीं कर रहे हैं - Emacs/JDK/Android/Chrome जैसी एकल मशीन पर स्टैंडअलोन सॉफ़्टवेयर सिस्टम बनाम मल्टी-सर्वर सिस्टम और क्लाउड सेवाओं जैसे API की तुलना नहीं कर रहे हैं?

ठीक है, मैंने कल इस बारे में ट्वीट किया था, लेकिन "बेकार/नियम" के सिद्धांत पर लैरी वॉल (प्रोग्रामिंग भाषा पर्ल के निर्माता - लगभग प्रति) की शैली में मैंने शब्द को देखा पदावनत Google और Amazon डेवलपर साइटों पर। और यद्यपि AWS के पास है के सैकड़ों GCP की तुलना में कई गुना अधिक सेवा पेशकश, Google के डेवलपर दस्तावेज़ में लगभग सात गुना अधिक बार अवनति का उल्लेख है।

यदि Google पर कोई भी इसे पढ़ रहा है, तो वे शायद डोनाल्ड ट्रम्प-शैली के चार्ट निकालने के लिए तैयार हैं जो दिखाते हैं कि वे वास्तव में सब कुछ सही कर रहे हैं, और मुझे "बहिष्कृत शब्द के उल्लेखों की संख्या बनाम" जैसी अनुचित तुलना नहीं करनी चाहिए। सेवाओं की संख्या" "

लेकिन इतने वर्षों के बाद भी, Google क्लाउड अभी भी नंबर 3 सेवा है (मैंने नंबर 2 बनने के असफल प्रयास के बारे में कभी कोई लेख नहीं लिखा), लेकिन अगर अंदरूनी सूत्रों पर विश्वास किया जाए, तो कुछ चिंताएं हैं कि वे जल्द ही नीचे आ सकते हैं नंबर 4.

मेरे पास अपनी थीसिस को "साबित" करने के लिए कोई ठोस तर्क नहीं है। मेरे पास केवल वे रंगीन उदाहरण हैं जो मैंने एक डेवलपर के रूप में 30 वर्षों में जमा किए हैं। मैं पहले ही इस समस्या की गहन दार्शनिक प्रकृति का उल्लेख कर चुका हूँ; कुछ मायनों में डेवलपर समुदायों में इसका राजनीतिकरण किया जाता है। कुछ लोग ऐसा मानते हैं रचनाकारों प्लेटफ़ॉर्म को अनुकूलता का ध्यान रखना चाहिए, जबकि अन्य सोचते हैं कि यह एक चिंता का विषय है उपयोगकर्ताओं (डेवलपर्स स्वयं)। दो में से एक। दरअसल, क्या यह एक राजनीतिक मुद्दा नहीं है जब हम तय करते हैं कि आम समस्याओं की लागत किसे वहन करनी चाहिए?

तो ये है राजनीति. और संभवतः मेरे भाषण पर नाराज़गी भरी प्रतिक्रियाएँ होंगी।

जैसा उपयोगकर्ता Google क्लाउड प्लेटफ़ॉर्म, और दो वर्षों तक AWS उपयोगकर्ता के रूप में (ग्रैब के लिए काम करते हुए), मैं कह सकता हूँ कि जब प्राथमिकताओं की बात आती है तो Amazon और Google के दर्शन के बीच बहुत बड़ा अंतर है। मैं AWS पर सक्रिय रूप से विकास नहीं करता, इसलिए मुझे अच्छी तरह से नहीं पता कि वे कितनी बार पुराने API को हटाते हैं। लेकिन संदेह है कि ऐसा Google जितनी बार नहीं होता है। और मैं वास्तव में मानता हूं कि जीसीपी में निरंतर विवाद और हताशा का यह स्रोत मंच के विकास को रोकने वाले सबसे बड़े कारकों में से एक है।

मुझे पता है कि मैंने जीसीपी सिस्टम के विशिष्ट उदाहरणों का नाम नहीं दिया है जो अब समर्थित नहीं हैं। मैं कह सकता हूं कि नेटवर्क (सबसे पुराने से वीपीसी तक) से लेकर स्टोरेज (क्लाउड एसक्यूएल v1-v2), फायरबेस (अब एक पूरी तरह से अलग एपीआई के साथ फायरस्टोर), ऐप इंजन (चलो अभी शुरू नहीं हुआ है) तक मैंने लगभग हर चीज का उपयोग किया है। , क्लाउड एंडपॉइंट क्लाउड एंडपॉइंट और तक... मुझे नहीं पता - बिल्कुल यह सब आपको अधिकतम 2-3 वर्षों के बाद कोड को फिर से लिखने के लिए मजबूर किया गया, और उन्होंने कभी भी आपके लिए माइग्रेशन को स्वचालित नहीं किया, और अक्सर वहां कोई प्रलेखित प्रवासन पथ नहीं था. मानो ऐसा ही होना चाहिए था.

और हर बार जब मैं AWS को देखता हूं, तो मैं खुद से पूछता हूं कि आखिर मैं अभी भी GCP पर क्यों हूं। उन्हें स्पष्ट रूप से ग्राहकों की आवश्यकता नहीं है। उन्हें जरूरत है खरीददारों. क्या आप अंतर समझते हैं? मुझे समझाने दो।

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

उदाहरण के लिए, एक कथित "वन-क्लिक" परिनियोजन समाधान लें। Percona. मैं गूगल क्लाउड एसक्यूएल की गड़बड़ियों से तंग आ चुका था, इसलिए मैंने एक विकल्प के रूप में अपना खुद का पेरकोना क्लस्टर बनाने पर विचार करना शुरू कर दिया। और इस बार ऐसा लग रहा था कि Google ने अच्छा काम किया है, वे एक बटन के क्लिक से मेरा कुछ समय और प्रयास बचाएंगे!

बहुत बढ़िया, चलो चलते हैं। आइए लिंक का अनुसरण करें और इस बटन पर क्लिक करें। सभी डिफ़ॉल्ट सेटिंग्स से सहमत होने और अपने Google क्लाउड प्रोजेक्ट में क्लस्टर को तैनात करने के लिए "हां" चुनें। हाहा, यह काम नहीं करता. इनमें से कोई भी बकवास काम नहीं करता. उपकरण का परीक्षण कभी नहीं किया गया था और यह पहले मिनट से ही सड़ना शुरू हो गया था, और मुझे आश्चर्य नहीं होगा यदि आधे से अधिक "समाधान" एक-क्लिक परिनियोजन हैं (अब हम समझते हैं कि उद्धरण क्यों) सामान्य में काम नहीं करता है। यह बिल्कुल निराशाजनक अंधकार है, जहां प्रवेश न करना ही बेहतर है।

लेकिन गूगल सही है आग्रह आप उनका उपयोग करें. वे तुम्हें चाहते हैं मैं खरीदा. उनके लिए यह एक लेन-देन है. उन्हें कुछ नहीं चाहिए समर्थन करने के लिए. यह Google के DNA का हिस्सा नहीं है. हां, इंजीनियर एक-दूसरे का समर्थन करते हैं, जैसा कि बिगटेबल के साथ मेरी कहानी से प्रमाणित है। लेकिन आम लोगों के लिए उत्पादों और सेवाओं में वे सदैव में क्रूर थे किसी भी सेवा को बंद करना, जो लाखों उपयोगकर्ताओं के होने पर भी लाभप्रदता के मानक को पूरा नहीं करता है।

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

समर्थन संस्कृति की यह कमी, "इसे और अधिक सुंदर बनाने के लिए इसे तोड़ दें" मानसिकता के साथ मिलकर, डेवलपर्स को अलग-थलग कर देती है।

और यदि आप एक दीर्घकालिक मंच बनाना चाहते हैं तो यह अच्छी बात नहीं है।

गूगल, जागो, लानत है। अभी 2020 है. आप अभी भी हार रहे हैं. अब समय आ गया है कि आप खुद को आईने में देखें और जवाब दें कि क्या आप वाकई क्लाउड बिजनेस में बने रहना चाहते हैं।

रहना है तो फिर सब कुछ तोड़ना बंद करो. दोस्तों, आप अमीर हैं. हम डेवलपर्स नहीं करते। इसलिए जब बात आती है कि अनुकूलता का बोझ कौन उठाएगा, तो आपको इसे अपने ऊपर लेने की जरूरत है। हमारे लिए नहीं।

क्योंकि कम से कम तीन और सचमुच अच्छे बादल हैं। वे इशारा करते हैं.

और अब मैं अपने सभी टूटे हुए सिस्टम को ठीक करने के लिए आगे बढ़ूंगा। एह।

अगली बार तक!

इस लेख पर कुछ चर्चाओं को पढ़ने के बाद पीएस अपडेट (वैसे चर्चाएं बहुत अच्छी हैं)। फायरबेस समर्थन बंद नहीं किया गया है और ऐसी कोई योजना नहीं है जिसके बारे में मुझे जानकारी हो। हालाँकि, उनके पास एक ख़राब स्ट्रीमिंग बग है जिसके कारण जावा क्लाइंट ऐप इंजन में रुक जाता है। उनके एक इंजीनियर ने इस समस्या को हल करने में मेरी मदद की, जब मैं Google में काम करता था, लेकिन उन्होंने वास्तव में बग को कभी ठीक नहीं किया, इसलिए मेरे पास हर दिन जीएई ऐप को पुनरारंभ करने का एक बेकार समाधान है। और चार साल से ऐसा ही है! अब उनके पास फायरस्टोर है। इसमें माइग्रेट करने में बहुत काम लगेगा क्योंकि यह एक पूरी तरह से अलग प्रणाली है और फायरबेस बग को कभी भी ठीक नहीं किया जाएगा। क्या निष्कर्ष निकाला जा सकता है? आपको मदद मिल सकती है अगर आप किसी कंपनी में काम करते हैं. शायद मैं जीएई पर फायरबेस का उपयोग करने वाला एकमात्र व्यक्ति हूं क्योंकि मैं 100% मूल ऐप में 100 से कम कुंजी लॉग करता हूं और यह एक ज्ञात बग के कारण हर दो दिन में काम करना बंद कर देता है। मैं इसे अपने जोखिम पर उपयोग करने के अलावा और क्या कह सकता हूं। मैं रेडिस पर स्विच कर रहा हूं।

मैंने कुछ अनुभवी AWS उपयोगकर्ताओं को यह कहते हुए भी देखा है कि AWS आमतौर पर किसी भी सेवा का समर्थन करना बंद नहीं करता है, और SimpleDB एक बेहतरीन उदाहरण है। मेरी यह धारणा कि AWS में Google जैसी समर्थन बीमारी नहीं है, उचित प्रतीत होती है।

इसके अतिरिक्त, मैंने देखा कि 20 दिन पहले Google ऐप इंजन टीम ने एक महत्वपूर्ण गो लाइब्रेरी की होस्टिंग को तोड़ दिया था, जिससे मुख्य गो डेवलपर्स में से एक जीएई एप्लिकेशन बंद हो गया था। यह सचमुच बेवकूफी थी.

अंततः, मैंने सुना है कि गूगलर्स पहले से ही इस मुद्दे पर चर्चा कर रहे हैं और आम तौर पर मुझसे सहमत हैं (आप लोगों से प्यार है!)। लेकिन उन्हें लगता है कि समस्या हल नहीं हो सकती क्योंकि Google की संस्कृति में कभी भी सही प्रोत्साहन संरचना नहीं थी। मैंने सोचा कि ग्रैब में काम करने के दौरान AWS इंजीनियरों के साथ काम करने के अपने अद्भुत अनुभव पर चर्चा करने के लिए कुछ समय निकालना अच्छा होगा। मुझे आशा है कि भविष्य में किसी दिन!

और हाँ, 2005 में बिल्डिंग 43 में विशाल बुफे पर उनके पास विभिन्न प्रकार के शार्क मांस थे, और मेरा पसंदीदा हैमरहेड शार्क मांस था। हालाँकि, 2006 तक लैरी और सर्गेई ने सभी अस्वास्थ्यकर स्नैक्स से छुटकारा पा लिया। तो 2007 में बिगटेबल कहानी के दौरान वास्तव में कोई शार्क नहीं थी और मैंने आपको धोखा दिया।

जब मैंने चार साल पहले क्लाउड बिगटेबल को देखा (दे या ले), तो लागत यही थी। ऐसा लगता है कि अब इसमें कुछ कमी आई है, लेकिन एक खाली डेटा वेयरहाउस के लिए यह अभी भी बहुत बड़ी बात है, खासकर जब से मेरी पहली कहानी दिखाती है कि एक खाली बड़ी टेबल उनके पैमाने पर कितनी महत्वहीन है।

Apple समुदाय को ठेस पहुँचाने और Microsoft आदि के बारे में कुछ भी अच्छा न कहने के लिए क्षमा करें। आप बिल्कुल ठीक हैं, मैं वास्तव में इस लेख द्वारा उत्पन्न सभी चर्चाओं की सराहना करता हूँ! लेकिन कभी-कभी आपको चर्चा शुरू करने के लिए थोड़ी हलचल मचाने की ज़रूरत होती है, क्या आप जानते हैं?

पढ़ने के लिए धन्यवाद।

अद्यतन 2, 19.08.2020/XNUMX/XNUMX। पट्टी एपीआई को सही ढंग से अपडेट करता है!

अद्यतन 3, 31.08.2020/2/2। क्लाउड मार्केटप्लेस पर एक Google इंजीनियर ने मुझसे संपर्क किया, जो मेरा पुराना मित्र निकला। वह यह पता लगाना चाहता था कि CXNUMXD काम क्यों नहीं कर रहा था, और अंततः हमें पता चला कि ऐसा इसलिए था क्योंकि मैंने अपना नेटवर्क वर्षों पहले बनाया था, और CXNUMXD पुराने नेटवर्क पर काम नहीं कर रहा था क्योंकि उनके टेम्पलेट्स में सबनेट पैरामीटर गायब था। मुझे लगता है कि संभावित GCP उपयोगकर्ताओं के लिए यह सुनिश्चित करना सबसे अच्छा है कि वे Google में पर्याप्त इंजीनियरों को जानते हैं...

स्रोत: www.habr.com