प्रिय गुगल क्लाउड, ब्याकवर्ड मिल्दो नहुनुले तपाईलाई मारिरहेको छ।

धिक्कार छ गुगल, म फेरि ब्लग गर्न चाहन्न। मैले गर्न धेरै छ। ब्लगिङले समय, ऊर्जा र रचनात्मकता लिन्छ, जुन मैले राम्रोसँग प्रयोग गर्न सक्छु: मेरा पुस्तकहरू, संगीत, मेरो खेल र यस्तै। तर तपाईले मलाई यति धेरै रिसाउनु भयो कि मैले यो लेख्नु पर्छ।

त्यसोभए यसलाई समाप्त गरौं।

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

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

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

अर्को चाखलाग्दो विवरण यो हो कि केहि समयको लागि Bigtable गुगल भित्र लोकप्रिय र सर्वव्यापी भयो, प्रत्येक टोलीको आफ्नै भण्डार भएको। त्यसोभए शुक्रबारको एक बैठकमा, ल्यारी पेजले अनौपचारिक रूपमा सोधे: "हामीसँग किन एक भन्दा बढी बिगटेबल छ? किन एक मात्र होइन?" सिद्धान्तमा, Google को सबै भण्डारण आवश्यकताहरूको लागि एउटा भण्डारण पर्याप्त हुनुपर्छ। निस्सन्देह, तिनीहरू व्यावहारिक विकास कारणहरू (जस्तै सम्भावित असफलताको नतिजाहरू) को लागि मात्र एकमा गएनन्, तर सिद्धान्त रोचक थियो। सम्पूर्ण ब्रह्माण्डको लागि एउटा भण्डार (खैर, के कसैलाई थाहा छ कि अमेजनले तिनीहरूको सेबलसँग यो गर्यो?)

जे होस्, यहाँ मेरो कथा छ।

त्यतिखेर, म गुगलमा दुई वर्षभन्दा बढी समयदेखि काम गरिरहेको थिएँ, र एक दिन मैले Bigtable इन्जिनियरिङ् टोलीबाट एउटा इमेल प्राप्त गरें जुन यस प्रकारको थियो:

प्रिय स्टीव,

बिगटेबल टोलीबाट नमस्कार। हामी तपाईंलाई सूचित गर्न चाहन्छौं कि [डेटा केन्द्र नाम] मा तपाईंले धेरै, धेरै पुरानो Bigtable बाइनरी प्रयोग गर्दै हुनुहुन्छ। यो संस्करण अब समर्थित छैन र हामी तपाईंलाई नवीनतम संस्करणमा स्तरवृद्धि गर्न मद्दत गर्न चाहन्छौं।

कृपया मलाई थाहा दिनुहोस् यदि तपाईं यस मुद्दामा सँगै काम गर्न केही समय तालिका बनाउन सक्नुहुन्छ।

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

गुगलमा तपाईले धेरै मेलहरू पाउनु हुन्छ, त्यसैले पहिलो नजरमा मैले यस्तो केहि पढें:

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

केही टोलीबाट नमस्कार। हामी त्यो ब्ला ब्ला ब्ला ब्ला ब्ला संवाद गर्न चाहन्छौं। ब्ला ब्ला ब्ला ब्ला ब्ला ब्ला, र ब्ला ब्ला ब्ला तुरुन्तै।

कृपया हामीलाई थाहा दिनुहोस् यदि तपाईंले आफ्नो बहुमूल्य समय ब्ला ब्ला ब्लाको लागि समय तालिका बनाउन सक्नुहुन्छ।

शुभकामना,
कुनै प्रकारको आदेश

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

तर यो अनौठो थियो।

मैले बाँकी दिन वैकल्पिक रूपमा कामको बारेमा र माइक्रो-किचनमा कस्तो प्रकारको शार्कको मासु प्रयोग गर्ने बारे सोच्दै बिताएँ, जसमध्ये कम्तिमा तीनवटा बिस्कुटको राम्रो उद्देश्यले फ्याँकेर मेरो सिटबाट प्रहार गर्न पर्याप्त थिए, तर लेख्ने सोचले मलाई हल्का चिन्ताको बढ्दो भावनाको साथ कहिल्यै छोडेन।

उनीहरुले स्पष्ट रुपमा मेरो नाम भने । र इमेल मेरो इमेल ठेगानामा पठाइएको थियो, अरू कसैको होइन, र यो cc: वा bcc: होइन। स्वर धेरै व्यक्तिगत र स्पष्ट छ। सायद यो कुनै प्रकारको गल्ती हो?

अन्तमा, जिज्ञासा मबाट राम्रो भयो र म उनीहरूले उल्लेख गरेको डाटा सेन्टरमा बोर्ग कन्सोल हेर्न गएँ।

र अवश्य पनि, मसँग व्यवस्थापन अन्तर्गत BigTable भण्डारण थियो। मलाई माफ गर्नुहोस्, के? मैले यसको सामग्री हेरे, र वाह! जुन 2005 मा Google मा मेरो पहिलो हप्तामा म बसेको कोडल्याब इन्क्यूबेटरबाट आएको थियो। Codelab ले तपाईंलाई त्यहाँ केही मानहरू लेख्न Bigtable चलाउन बाध्य तुल्यायो, र मैले स्पष्ट रूपमा त्यस पछि भण्डारण कहिल्यै बन्द गरेन। दुई वर्षभन्दा बढी समय बितिसक्दा पनि काम भइरहेको थियो ।

यस कथामा धेरै उल्लेखनीय पक्षहरू छन्। पहिलो, Bigtable को काम गुगलको मापनमा यति नगण्य थियो कि केवल दुई वर्ष पछि कसैले अतिरिक्त भण्डारण याद गरे, र केवल किनभने बाइनरीको संस्करण पुरानो थियो। तुलनाको लागि, मैले एक पटक प्रयोग गर्ने विचार गरें Google Cloud मा Bigtable मेरो अनलाइन खेल को लागी। त्यतिखेर, यो सेवा प्रति वर्ष लगभग $16 लागत थियो। खाली GCP मा बिगटेबल। मैले भनेको होइन कि तिनीहरूले तपाईंलाई घोटाला गर्दैछन्, तर मेरो व्यक्तिगत विचारमा, त्यो खाली डाटाबेसको लागि धेरै पैसा हो।

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

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

मैले तिनीहरूलाई धन्यवाद दिएँ, भण्डारण हटाएँ, र जीवन सामान्य रूपमा चल्यो। तर तेह्र वर्ष पछि, म अझै पनि त्यो पत्रको बारेमा सोच्दछु। किनभने कहिलेकाहीँ म Google Cloud बाट समान इमेलहरू प्राप्त गर्छु। तिनीहरू यस्तो देखिन्छन्:

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

रिमाइन्डरको रूपमा, हामीले अगस्ट २०२० देखि [तपाईंले प्रयोग गर्ने अत्यावश्यक सेवा] सेवा बन्द गर्दैछौं, त्यसपछि तपाईंले आफ्नो उदाहरणहरू अपग्रेड गर्न सक्षम हुनुहुने छैन। हामी नवीनतम संस्करणमा स्तरवृद्धि गर्न सिफारिस गर्छौं, जुन बीटा परीक्षणमा छ, कुनै कागजात छैन, कुनै माइग्रेसन मार्ग छैन र हाम्रो दयालु मद्दतले पहिले नै पुरानो छ।

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

सधैंभरि राम्रो मित्र,
गुगल क्लाउड प्लेटफर्म

तर मैले त्यस्ता अक्षरहरू कहिल्यै पढ्दिन, किनभने तिनीहरूले वास्तवमा के भन्छन्:

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

नर्कमा जानुहोस्। तिमीलाई बकवास, तिमीलाई बकवास, तिमीलाई बकवास। तपाईंले गर्नुहुने सबै कुरा छोड्नुहोस् किनभने यसले फरक पार्दैन। महत्त्वपूर्ण कुरा हाम्रो समय हो। हामी हाम्रो बकवास कायम राख्न समय र पैसा बर्बाद गर्छौं र हामी यसबाट थकित छौं त्यसैले हामी यसलाई समर्थन गर्दैनौं। त्यसोभए तपाइँको कमबख्त योजनाहरू छोड्नुहोस् र फोरमहरूमा स्क्र्यापहरूको लागि भिख माग्दै हाम्रो डरलाग्दो कागजातहरू खोल्न सुरु गर्नुहोस्, र वैसे, हाम्रो नयाँ बकवास पुरानो बकवास भन्दा पूर्ण रूपमा फरक छ, किनकि हामीले यो डिजाइन धेरै नराम्रो गर्यौं, हे, तर त्यो तपाइँको हो। समस्या, हाम्रो होइन।

हामी तपाईका सबै विकासहरू एक वर्ष भित्र प्रयोग गर्न नसकिने सुनिश्चित गर्न प्रयास जारी राख्छौं।

कृपया चुदाई बन्द गर्नुहोस्
गुगल क्लाउड प्लेटफर्म

र तथ्य यो हो कि म महिनामा एक पटक त्यस्ता पत्रहरू प्राप्त गर्दछु। यो धेरै पटक र यति निरन्तर हुन्छ कि तिनीहरू अनिवार्य रूपमा टाढा धकेलियो म GCP बाट क्लाउड विरोधी शिविरमा। म अब तिनीहरूको स्वामित्व विकासहरूमा निर्भर रहन सहमत छैन, किनकि वास्तवमा डेभपहरूका लागि "पुरानो" उत्पादनहरू बन्द गर्ने नीतिको साथ गुगलसँग रहन प्रयास गर्नु भन्दा खुला भर्चुअल मेसिनमा खुला स्रोत प्रणाली कायम राख्न सजिलो छ।

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

म Google बाहिरका अन्य ठूला परियोजनाहरूबाट केही अनियमित उदाहरणहरू दिनेछु, तर मलाई आशा छ कि तपाईंले यो ढाँचा जताततै देख्नुहुन्छ। यो निम्नानुसार छ: पछाडि अनुकूलताले प्रणालीहरूलाई दशकौंसम्म जीवित र अप-टु-डेट राख्छ.

पछाडि अनुकूलता सबै सफल प्रणालीहरूको डिजाइन लक्ष्य हो खोल्नुहोस् प्रयोग गर्नुहोस्, त्यो हो, खुला स्रोत कोड र/वा खुला मापदण्डहरूसँग लागू। मलाई लाग्छ कि मैले केहि धेरै स्पष्ट भनेको छु कि सबैलाई पनि असहज छ, तर होइन। यो राजनीतिक मुद्दा हो, त्यसैले उदाहरण चाहिन्छ।

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

म हरेक दिन Emacs प्रयोग गर्छु। हो, म पनि हरेक दिन IntelliJ प्रयोग गर्छु, यो आफ्नै अधिकारमा शक्तिशाली टूलिङ प्लेटफर्ममा बढेको छ। तर IntelliJ को लागी विस्तार लेख्नु Emacs को लागी विस्तार लेख्नु भन्दा धेरै महत्वाकांक्षी र जटिल कार्य हो। र अझ महत्त्वपूर्ण कुरा, Emacs का लागि लेखिएका सबै कुरा सुरक्षित छन् सधैंभरि.

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

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

तर Emacs संसारमा फरक काम गर्ने परिभाषा जस्तो देखिन्छ। एक फरक अन्तर्निहित दर्शन, यदि तपाईं गर्नुहुन्छ।

Emacs को संसारमा (र धेरै अन्य क्षेत्रहरूमा, जसलाई हामी तल कभर गर्नेछौं), deprecated API स्थितिको मूलतया अर्थ: "तपाईंले वास्तवमै यो दृष्टिकोण प्रयोग गर्नु हुँदैन, किनकि यसले काम गर्दा, यसले विभिन्न कमजोरीहरूबाट ग्रस्त हुन्छ जुन हामी गर्नेछौं। यहाँ सूची। तर दिनको अन्त्यमा, यो तपाइँको छनौट हो।"

गुगलको संसारमा, अप्रचलित हुनुको अर्थ हो, "हामी तपाईंप्रतिको हाम्रो प्रतिबद्धताको उल्लङ्घनमा छौं।" यो सत्य हो। यसको मूल अर्थ यही हो। यसको मतलब तिनीहरूले तपाईंलाई जबरजस्ती गर्नेछन् नियमित रूपमा केही काम गर्नुहोस्, सायद धेरै काम, तिनीहरूमा विश्वासको सजायको रूपमा रंगीन विज्ञापन: हामीसँग उत्कृष्ट सफ्टवेयर छ। सबैभन्दा छिटो! तपाइँ निर्देशन अनुसार सबै गर्नुहुन्छ, तपाइँको अनुप्रयोग वा सेवा सुरु गर्नुहोस्, र त्यसपछि ब्याम, एक वा दुई वर्ष पछि यो ब्रेक हुन्छ।

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

यी दुई पूर्णतया भिन्न दार्शनिक परिभाषाहरू "अप्रचलितता" को हुन्। गुगलको गन्धको परिभाषा योजनाबद्ध अप्रचलितता। मलाई यो विश्वास लाग्दैन वास्तवमा एप्पलको रूपमा समान अर्थमा योजनाबद्ध अप्रचलितता। तर गुगलले पक्कै पनि तपाइँका कार्यक्रमहरू तोड्ने योजना बनाइरहेको छ, राउन्डअबाउट तरिकामा। मलाई यो थाहा छ किनभने मैले त्यहाँ 12 वर्ष भन्दा बढी सफ्टवेयर इन्जिनियरको रूपमा काम गरें। तिनीहरूसँग अस्पष्ट आन्तरिक दिशानिर्देशहरू छन् कि कति पछाडि अनुकूलता पछ्याउनु पर्छ, तर यो अन्ततः प्रत्येक व्यक्तिगत टोली वा सेवामा निर्भर हुन्छ। त्यहाँ कुनै उद्यम वा ईन्जिनियरिङ्-स्तर सिफारिसहरू छैनन्, र अप्रचलित चक्रको सन्दर्भमा सबैभन्दा साहसी सिफारिस भनेको "ग्राहकहरूलाई उनीहरूको सम्पूर्ण प्रणाली तोड्नु अघि अपग्रेड गर्न 6-12 महिना दिन प्रयास गर्नुहोस्।"

समस्या उनीहरूले सोचेभन्दा धेरै ठूलो छ, र यो आउने वर्षसम्म जारी रहनेछ किनभने ग्राहक हेरचाह तिनीहरूको डीएनएमा छैन। तल यस बारे थप।

यस बिन्दुमा म एक बोल्ड कथन गर्न जाँदैछु कि Emacs धेरै हदसम्म सफल छ साधारणतया किनभने तिनीहरू पछाडि अनुकूलतालाई गम्भीर रूपमा लिन्छन्। वास्तवमा, यो हाम्रो लेखको थीसिस हो। सफल, लामो समयसम्म चल्ने खुल्ला प्रणालीहरूले आफ्नो सफलताको श्रेय दश वर्षदेखि तिनीहरूको वरिपरि बसेका सूक्ष्म समुदायहरूलाई दिन्छन्। विस्तारहरू/प्लगइनहरू। यो इकोसिस्टम हो। मैले पहिले नै प्लेटफर्महरूको प्रकृति र तिनीहरू कत्तिको महत्त्वपूर्ण छन् भन्ने बारे कुरा गरिसकेको छु, र कसरी गुगलले आफ्नो सम्पूर्ण कर्पोरेट इतिहासमा एन्ड्रोइड वा क्रोम बाहिर सफल खुला प्लेटफर्म सिर्जना गर्दा के हुन्छ भनेर बुझेको छैन।

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

सबै भन्दा पहिले, एन्ड्रोइड गुगल होइन। तिनीहरू एकअर्कासँग लगभग केहि समान छैन। एन्ड्रोइड एक कम्पनी हो जुन गुगल द्वारा जुलाई 2005 मा खरिद गरिएको थियो, कम्पनीलाई कम वा कम स्वायत्त रूपमा सञ्चालन गर्न अनुमति दिइएको थियो र वास्तवमा मध्यवर्ती वर्षहरूमा धेरै हदसम्म अछुतो रह्यो। एन्ड्रोइड एक कुख्यात टेक स्ट्याक र समान रूपमा कुख्यात काँटेदार संगठन हो। जसरी एक Googler ले भन्यो, "तपाईले एन्ड्रोइडमा मात्र लग इन गर्न सक्नुहुन्न।"

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

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

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

यसका लागि म एन्ड्रोइडलाई प्रतिष्ठित "You're Not Google" अवार्ड प्रदान गर्छु। तिनीहरू वास्तवमै Google बन्न चाहँदैनन्, जसले टिकाऊ प्लेटफर्महरू कसरी बनाउने भनेर थाहा छैन, तर एन्ड्रोइड थाहा छ, कसरी गर्ने। र त्यसैले गुगल एक हिसाबले धेरै स्मार्ट भएको छ: मानिसहरूलाई एन्ड्रोइडमा आफ्नै तरिकाले काम गर्न अनुमति दिँदै।

यद्यपि, एन्ड्रोइडका लागि तत्काल एपहरू एकदमै मूर्ख विचार थिए। र के तपाईलाई थाहा छ किन? किनभने उनीहरुले माग गरेका थिए तपाइँको आवेदन पुन: लेख्नुहोस् र पुन: डिजाइन गर्नुहोस्! यो जस्तो छ कि मानिसहरूले केवल दुई लाख आवेदनहरू पुन: लेख्नेछन्। म अनुमान गर्दैछु कि तत्काल एप्स केहि Googler को विचार थियो।

तर फरक छ। पछाडि अनुकूलता उच्च लागतमा आउँछ। एन्ड्रोइड आफैंले यी लागतहरूको बोझ वहन गर्दछ, जबकि गुगलले भार वहन गर्न जोड दिन्छ। вы, भुक्तानी ग्राहक।

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

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

लेडी एस्कट:
- एलिस, के तपाईंलाई थाहा छ म केसँग धेरै डराउँछु?
- कुलीन वर्गको पतन ?
- मलाई डर थियो कि मसँग हुनेछ कुरूप नातिनातिनाहरू.

सुन्दर र व्यावहारिक बीचको ट्रेडअफ बुझ्नको लागि, तेस्रो सफल प्लेटफर्म (Emacs र एन्ड्रोइड पछि) हेरौं र यसले कसरी काम गर्छ हेर्नुहोस्: जाभा आफैं।

Java सँग धेरै पुराना API हरू छन्। Deprecation Java प्रोग्रामरहरू बीच धेरै लोकप्रिय छ, धेरै प्रोग्रामिङ भाषाहरूमा भन्दा पनि लोकप्रिय। जाभा आफैं, मूल भाषा, र पुस्तकालयहरू निरन्तर API लाई अस्वीकार गर्दै छन्।

हजारौं उदाहरणहरू मध्ये एउटा मात्र लिनुहोस्, बन्द थ्रेडहरू अप्रचलित मानिन्छ। यो डिसेम्बर 1.2 मा Java 1998 को रिलीज पछि हटाइएको छ। यो खारेज भएको २२ वर्ष भइसक्यो।

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

ओरेकलले प्लेटफर्महरू पनि बुझ्दछ। कसलाई थाँहा छ।

कोर जाभा एपीआईहरूमा प्रमाणहरू फेला पार्न सकिन्छ, जुन घाटीमा ग्लेशियरको रेखाहरू जस्तै अप्रचलितताका छालहरूले भरिएका छन्। तपाईंले जाभा स्विङ लाइब्रेरीमा पाँच वा छवटा फरक किबोर्ड नेभिगेसन प्रबन्धकहरू (KeyboardFocusManager) सजिलै फेला पार्न सक्नुहुन्छ। यो वास्तवमा जाभा API फेला पार्न गाह्रो छ जुन बहिष्कार गरिएको छैन। तर तिनीहरू अझै काम गर्छन्! मलाई लाग्छ कि जाभा टोलीले साँच्चै एपीआई हटाउनेछ यदि इन्टरफेसले स्पष्ट सुरक्षा मुद्दा खडा गर्छ।

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

काल्पनिक रूपमा अनुमान गरौं कि एप्पलले मूर्खतापूर्वक Guido van Rossum बाट क्यु लिएको छ र घोषणा गर्‍यो कि स्विफ्ट 6.0 स्विफ्ट 5.0 सँग पछाडि असंगत छ, जस्तै पाइथन 3 पाइथन 2 सँग असंगत छ।

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

यदि तपाईंले Google क्लाउड प्लेटफर्म SDK ("gcloud") स्थापना गर्नुभयो भने, तपाईंले निम्न सूचना प्राप्त गर्नुहुनेछ:

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

हामी तपाईलाई सम्झाउन चाहन्छौं कि पाइथन २ को लागि समर्थन हटाइएको छ, त्यसैले तपाईलाई बकवास गर्नुहोस्

… र यस्तै। जीवनको चक्र।

तर बिन्दु यो हो कि प्रत्येक विकासकर्ताको छनौट छ। र यदि तपाईंले तिनीहरूलाई कोड पुन: लेख्नको लागि पर्याप्त मात्रामा जबरजस्ती गर्नुहुन्छ भने, तिनीहरूले सोच्न सक्छन् अन्य विकल्पहरू। तिनीहरू तपाईंका बन्धकहरू होइनन्, तपाईंले उनीहरूलाई जतिसुकै बनाउन चाहनुहुन्छ। तिनीहरू तपाईंका पाहुना हुन्। पाइथन अझै पनि एक धेरै लोकप्रिय प्रोग्रामिङ भाषा हो, तर धिक्कार छ, पाइथन 3(000) ले आफैंमा, यसको समुदायमा र यसको समुदायका प्रयोगकर्ताहरू बीचमा यस्तो गडबडी सिर्जना गर्‍यो कि परिणामहरू पन्ध्र वर्षसम्म स्पष्ट हुन सकेको छैन।

गो (वा रुबी, वा केहि अन्य वैकल्पिक) मा कति पाइथन प्रोग्रामहरू यो पछाडिको असंगतताको कारणले पुन: लेखिएको छ? पाइथन बाहेक अरु केहिमा कति नयाँ सफ्टवेयर लेखिएको छ, यद्यपि यो हुन सक्छ पाइथनमा लेखिएको छ, यदि गुइडोले पुरै गाउँ न जलाएको भए ? यो भन्न गाह्रो छ, तर पाइथनले स्पष्ट रूपमा पीडित भएको छ। यो एक ठूलो गडबड हो र सबैले हार्छन्।

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

यो धेरै पटक गर्नुहोस् र तपाईंले आफ्नो आधा प्रयोगकर्ता आधार गुमाउनुहुनेछ। खेलकुदमा जस्तै, प्रोग्रामिङको संसारमा, वर्तमान फारम पनि महत्त्वपूर्ण छ। सबै कुरा। पाँच वर्षमा आफ्नो आधा प्रयोगकर्ता गुमाउने जो कोहीले ठूलो फ्याट लूजर मानिनेछ। तपाईं प्लेटफर्मको संसारमा चल्ती हुनुपर्छ। तर यो हो जहाँ पुरानो संस्करणहरूलाई समर्थन नगर्दा तपाईंलाई समयसँगै बर्बाद हुनेछ। किनकि हरेक पटक तपाईंले केही विकासकर्ताहरूबाट छुटकारा पाउनुहुँदा, तपाईंले (a) तिनीहरूलाई सदाको लागि गुमाउनुहुन्छ किनभने तिनीहरू तपाईंसँग सम्झौता तोडेकोमा रिसाउँछन्, र (b) तिनीहरूलाई तपाईंका प्रतिस्पर्धीहरूलाई दिनुहोस्।

विडम्बनाको रूपमा, मैले Google लाई यस्तो प्राइमा डोना बन्न मद्दत गरेको छु जसले पछाडि अनुकूलतालाई बेवास्ता गर्दछ जब मैले Grok सिर्जना गरें, एक स्रोत कोड विश्लेषण र समझ प्रणाली जसले कोड आफैंलाई स्वचालित र उपकरण बनाउन सजिलो बनाउँदछ - IDE जस्तै, तर यहाँ क्लाउड सेवा स्टोरहरू ठूलो डाटा गोदाममा गुगल स्रोत कोडका सबै अरबौं लाइनहरूको वास्तविक प्रतिनिधित्व।

Grok ले Googlers लाई तिनीहरूको सम्पूर्ण कोडबेस (शाब्दिक रूपमा Google भर) मा स्वचालित रिफ्याक्टरिङहरू प्रदर्शन गर्नको लागि एक शक्तिशाली फ्रेमवर्क प्रदान गर्यो। प्रणालीले तपाइँको अपस्ट्रीम निर्भरता (जसमा तपाइँ निर्भर हुनुहुन्छ) मात्र होइन, तर पनि गणना गर्दछ अवरोही (जुन तपाईं मा निर्भर छ) त्यसैले जब तपाईं API हरू परिवर्तन गर्नुहुन्छ तपाईंले तोड्दै हुनुहुन्छ सबैलाई थाहा छ! यस तरिकाले, जब तपाइँ परिवर्तनहरू गर्नुहुन्छ, तपाइँ प्रमाणित गर्न सक्नुहुन्छ कि तपाइँको API को प्रत्येक उपभोक्ताले नयाँ संस्करणमा अद्यावधिक गरेको छ, र वास्तवमा, प्रायः तिनीहरूले लेखेका रोजी उपकरणको साथ, तपाइँ प्रक्रियालाई पूर्ण रूपमा स्वचालित गर्न सक्नुहुन्छ।

यसले Google को कोडबेसलाई आन्तरिक रूपमा लगभग अलौकिक रूपमा सफा गर्न अनुमति दिन्छ, किनकि तिनीहरूसँग यी रोबोट सेवकहरू घरको वरिपरि घुमिरहेका छन् र यदि तिनीहरूले SomeDespicablyLongFunctionName लाई SomeDespicablyLongMethodName नाम दिएमा सबै कुरा स्वचालित रूपमा सफा गर्छ किनभने कसैले यो कुरूप नातिनातिना हो भनेर निर्णय गर्यो र उसलाई सुत्न आवश्यक छ।

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

समस्या सुरु हुन्छ जब तिनीहरूले आफ्नो क्लाउड क्लाइन्टहरू र अन्य API को प्रयोगकर्ताहरूमा यो मनोवृत्ति लागू गर्न प्रयास गर्छन्।

मैले तपाईलाई Emacs, एन्ड्रोइड र जाभामा थोरै परिचय दिएको छु; नवीनतम सफल दीर्घायु प्लेटफर्म हेरौं: वेब आफैं। हामीले फ्ल्यासिङ ट्यागहरू प्रयोग गर्दा 1995 देखि HTTP कतिवटा पुनरावृत्तिहरू गएको छ भनेर के तपाईं कल्पना गर्न सक्नुहुन्छ? र वेब पृष्ठहरूमा "निर्माणाधीन" आइकनहरू।

तर यो अझै काम गर्दछ! र यी पृष्ठहरू अझै काम गर्दै छन्! हो, साथीहरू, ब्राउजरहरू पछाडि अनुकूलतामा विश्व च्याम्पियनहरू हुन्। क्रोम दुर्लभ गुगल प्लेटफर्मको अर्को उदाहरण हो जसको टाउको सही तरिकाले स्क्रू गरिएको छ, र तपाईंले अनुमान गर्नुभए जस्तै, क्रोमले प्रभावकारी रूपमा Google को बाँकी भागबाट अलग स्यान्डबक्स गरिएको कम्पनीको रूपमा सञ्चालन गर्दछ।

म अपरेटिङ सिस्टम विकासकर्ताहरूमा हाम्रा साथीहरूलाई पनि धन्यवाद दिन चाहन्छु: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, इत्यादि, तिनीहरूको सफल प्लेटफर्महरूमा पछाडि अनुकूलताको यस्तो उत्कृष्ट काम गरेकोमा (एप्पलले उत्कृष्ट रूपमा C प्राप्त गर्दछ। नकारात्मक पक्ष यो हो कि तिनीहरू कुनै राम्रो कारण बिना सबै समय तोड्छन्, तर कुनै न कुनै रूपमा समुदायले हरेक रिलीजको साथ यसको वरिपरि पाउँछ, र OS X कन्टेनरहरू अझै पनि पूर्ण रूपमा अप्रचलित छैनन्... अझै)।

तर पर्खनुहोस्, तपाईं भन्नुहुन्छ। के हामी स्याउलाई सुन्तलासँग तुलना गर्दैनौं - एकल मेसिनमा स्ट्यान्डअलोन सफ्टवेयर प्रणालीहरू जस्तै Emacs/JDK/Android/Chrome बनाम बहु-सर्भर प्रणालीहरू र क्लाउड सेवाहरू जस्ता API हरू?

ठिक छ, मैले हिजो यसको बारेमा ट्वीट गरें, तर ल्यारी वालको शैलीमा (प्रोग्रामिङ भाषा पर्ल - लगभग प्रति।) को सिद्धान्तमा मैले शब्द हेरेँ। विकृत Google र Amazon विकासकर्ता साइटहरूमा। र यद्यपि AWS छ सैकड GCP भन्दा गुणा बढी सेवा प्रस्तावहरू, गुगलको विकासकर्ता कागजातले लगभग सात गुणा बढी ह्रासको उल्लेख गर्दछ।

यदि गुगलमा कसैले यो पढिरहेको छ भने, तिनीहरू सम्भवतः डोनाल्ड ट्रम्प-शैली चार्टहरू बाहिर निकाल्न तयार छन् जुन उनीहरूले वास्तवमा सबै कुरा ठीक गर्दैछन् भनेर देखाउँछन्, र मैले "बन्द शब्दको उल्लेखको संख्या बनाम" जस्ता अनुचित तुलनाहरू गर्नु हुँदैन। सेवाहरूको संख्या ""

तर यी सबै वर्षहरू पछि, गुगल क्लाउड अझै पनि नम्बर 3 सेवा हो (मैले नम्बर 2 बन्ने असफल प्रयासको बारेमा कहिल्यै लेख लेखेको छैन), तर यदि भित्रीहरूलाई विश्वास गर्ने हो भने, त्यहाँ केही चिन्ताहरू छन् जुन तिनीहरू छिट्टै झर्ने छन्। नम्बर ४।

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

त्यसैले यो राजनीति हो। र सायद मेरो भाषणमा क्रोधित प्रतिक्रियाहरू हुनेछन्।

कसरी प्रयोगकर्ता गुगल क्लाउड प्लेटफर्म, र दुई वर्षको लागि AWS प्रयोगकर्ताको रूपमा (ग्राबका लागि काम गर्दा), म भन्न सक्छु कि अमेजन र गुगलको दर्शनहरू बीच ठूलो भिन्नता छ जब यो प्राथमिकताहरूमा आउँछ। म सक्रिय रूपमा AWS मा विकास गर्दैन, त्यसैले मलाई राम्ररी थाहा छैन कि उनीहरूले पुराना API हरू कति पटक हटाउँछन्। तर गुगलमा जत्तिकै प्रायः यस्तो हुँदैन भन्ने आशंका छ। र म साँच्चै विश्वास गर्छु कि GCP मा निरन्तर विवाद र निराशाको यो स्रोत प्लेटफर्मको विकासलाई रोक्ने सबैभन्दा ठूलो कारक हो।

मलाई थाहा छ कि मैले अब समर्थन नगर्ने GCP प्रणालीहरूको विशेष उदाहरणहरूको नाम राखेको छैन। म भन्न सक्छु कि नेटवर्कहरू (सबैभन्दा पुरानो देखि VPC सम्म) भण्डारण (क्लाउड SQL v1-v2), फायरबेस (अहिले पूर्ण रूपमा फरक API संग फायरस्टोर), एप इन्जिन (सुरु नगरौं) सम्म मैले प्रयोग गरेको लगभग सबै कुराहरू भन्न सक्छु। , क्लाउड एन्डपोइन्ट क्लाउड एन्डपोइन्ट र माथि... मलाई थाहा छैन - बिल्कुल यो सबै तपाईलाई अधिकतम २-३ वर्ष पछि कोड पुन: लेख्न बाध्य तुल्यायो, र तिनीहरूले तपाईको लागि माइग्रेसन स्वचालित गरेनन्, र प्रायः त्यहाँ कुनै पनि दस्तावेज माइग्रेसन मार्ग थिएन। हुनै पर्ने हो कि जस्तो ।

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

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

उदाहरणका लागि, एक अनुमानित "एक-क्लिक" परिनियोजन समाधान लिनुहोस्। पर्कोना। म Google क्लाउड SQL shenanigans को मृत्यु को लागी बिरामी थिए, त्यसैले मैले एक विकल्प को रूप मा मेरो आफ्नै Percona क्लस्टर निर्माण गर्न थाले। र यस पटक गुगलले राम्रो काम गरेको जस्तो देखिन्थ्यो, तिनीहरूले मलाई एक बटन क्लिक गरेर केही समय र प्रयास बचत गर्न लागेका थिए!

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

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

र यो GCP को लागी एक वास्तविक चुनौती प्रस्तुत गर्दछ किनभने यो सबै क्लाउड प्रस्तावहरु पछि DNA हो। तिनीहरू कुनै पनि कुरालाई समर्थन गर्न खोजिरहेका छैनन्; यो राम्रोसँग थाहा छ कि तिनीहरूले कुनै पनि तेस्रो पक्ष सफ्टवेयर होस्ट गर्न अस्वीकार गर्छन् (व्यवस्थित सेवाको रूपमा) सम्म, जब सम्म AWS ले त्यसै गर्छ र यसको वरिपरि एक सफल व्यवसाय निर्माण गर्दैन, र जब ग्राहकहरूले शाब्दिक रूपमा उही माग गर्छन्। जे होस्, गुगललाई केहि समर्थन गर्नको लागि केहि प्रयास चाहिन्छ।

समर्थन संस्कृतिको यो अभाव, "यसलाई अझ सुन्दर बनाउन यसलाई तोडौं" मानसिकताले विकासकर्ताहरूलाई टाढा बनाउँछ।

र यो राम्रो कुरा होइन यदि तपाईं लामो समयसम्म चल्ने प्लेटफर्म निर्माण गर्न चाहनुहुन्छ भने।

गुगल, उठ, धिक्कार छ। अहिले २०२० हो। तपाईं अझै पनि हार्दै हुनुहुन्छ। यो ऐनामा कडा नजर लिने र तपाईं साँच्चै क्लाउड व्यवसायमा रहन चाहनुहुन्छ कि भनेर जवाफ दिने समय हो।

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

किनभने त्यहाँ कम्तीमा पनि तीनवटा साँच्चै राम्रा बादलहरू छन्। तिनीहरूले इशारा गर्छन्।

र अब म मेरो सबै बिग्रिएको प्रणाली ठीक गर्न अगाडि बढ्नेछु। एह।

अर्को पटक सम्म!

यस लेखमा भएका केही छलफलहरू पढेपछि PS अपडेट गर्नुहोस् (चर्चाहरू उत्कृष्ट छन्, btw)। Firebase समर्थन बन्द गरिएको छैन र त्यहाँ कुनै योजनाहरू छैनन् जुन मलाई थाहा छ। यद्यपि, तिनीहरूसँग एउटा खराब स्ट्रिमिङ बग छ जसले जाभा क्लाइन्टलाई एप इन्जिनमा रोक्छ। तिनीहरूका एक इन्जिनियरले मलाई यो समस्या समाधान गर्न मद्दत गरे, जब मैले Google मा काम गरें, तर तिनीहरूले वास्तवमा बगलाई कहिल्यै फिक्स गरेनन्, त्यसैले मसँग हरेक दिन GAE एप पुन: सुरु गर्नु पर्ने एउटा खराब समाधान छ। र यसरी यो चार वर्ष भयो! तिनीहरूसँग अहिले फायरस्टोर छ। यसलाई माइग्रेट गर्न धेरै काम लाग्नेछ किनकि यो पूर्ण रूपमा फरक प्रणाली हो र फायरबेस बग कहिल्यै फिक्स हुनेछैन। के निष्कर्ष निकाल्न सकिन्छ? तपाईं मद्दत प्राप्त गर्न सक्नुहुन्छ यदि तपाइँ एक कम्पनी मा काम गर्नुहुन्छ। GAE मा Firebase प्रयोग गर्ने म मात्र एक हुँ किनभने मैले १००% नेटिभ एपमा १०० भन्दा कम कुञ्जीहरू लग गर्छु र यसले ज्ञात बगका कारण प्रत्येक दुई दिनमा काम गर्न बन्द गर्छ। म यसलाई आफ्नो जोखिममा प्रयोग बाहेक अरू के भन्न सक्छु। म Redis मा स्विच गर्दै छु।

मैले केहि थप अनुभवी AWS प्रयोगकर्ताहरू पनि देखेको छु कि AWS सामान्यतया कुनै पनि सेवाहरूलाई समर्थन गर्न बन्द गर्दैन, र SimpleDB एक उत्कृष्ट उदाहरण हो। मेरो अनुमानहरू कि AWS सँग समर्थन रोगको उस्तै अन्त्य छैन जस्तो Google ले उचित देखिन्छ।

थप रूपमा, मैले 20 दिन अघि गुगल एप इन्जिन टोलीले एउटा महत्वपूर्ण Go विकासकर्ताहरूको GAE अनुप्रयोग बन्द गर्दै, एउटा महत्वपूर्ण Go पुस्तकालयको होस्टिङ तोडेको याद गरें। यो साँच्चै मूर्ख थियो।

अन्तमा, मैले Googlers लाई पहिले नै यस मुद्दामा छलफल गरिरहेको र सामान्यतया मसँग सहमत भएको सुनेको छु (लभ युज!)। तर तिनीहरूले समस्या समाधान गर्न नसकिने जस्तो देखिन्छ किनभने गुगलको संस्कृतिमा सही प्रोत्साहन संरचना कहिल्यै थिएन। Grab मा काम गर्दा AWS ईन्जिनियरहरु संग काम गरेको बिल्कुल अचम्मको अनुभव को बारे मा छलफल गर्न को लागी केहि समय लिन राम्रो हुनेछ भन्ने मैले सोचें। भविष्यमा कुनै दिन, मलाई आशा छ!

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

जब मैले चार वर्ष पहिले क्लाउड बिगटेबल हेरेँ (दिनुहोस् वा लिनुहोस्), लागत यहीँ थियो। यो अब अलि घटेको जस्तो देखिन्छ, तर खाली डाटा गोदामको लागि त्यो अझै डरलाग्दो कुरा हो, विशेष गरी जब मेरो पहिलो कथाले खाली ठूलो टेबल तिनीहरूको मापनमा कति अप्रासंगिक छ भनेर देखाउँदछ।

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

पढ्नु भएकोमा धन्यवाद।

अपडेट 2, 19.08.2020/XNUMX/XNUMX। पट्टी API लाई सही रूपमा अद्यावधिक गर्दछ!

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

स्रोत: www.habr.com