प्रिय Google क्लाउड, मागे सुसंगत नसणे हे तुम्हाला मारत आहे.

डॅम गुगल, मला पुन्हा ब्लॉग करायचा नव्हता. मला खूप काही करायचे आहे. ब्लॉगिंगला वेळ, ऊर्जा आणि सर्जनशीलता लागते, ज्याचा मी चांगला उपयोग करू शकतो: माझी पुस्तके, संगीत, माझा खेळ वगैरे. पण तुम्ही मला इतके चिडवले आहे की मला हे लिहावे लागेल.

चला तर मग हे संपवूया.

मी जेव्हा पहिल्यांदा Google वर काम करायला सुरुवात केली तेव्हापासून मी एका छोट्या पण बोधप्रद कथेने सुरुवात करू. मला माहित आहे की मी अलीकडे Google बद्दल बर्‍याच वाईट गोष्टी बोलत आहे, परंतु जेव्हा माझी स्वतःची कंपनी नियमितपणे अक्षम व्यावसायिक निर्णय घेते तेव्हा ते मला अस्वस्थ करते. त्याच वेळी, आपण त्याचे कारण दिले पाहिजे: Google ची अंतर्गत पायाभूत सुविधा खरोखरच विलक्षण आहे, हे सांगणे सुरक्षित आहे की आज काही चांगले नाही. Google चे संस्थापक माझ्यापेक्षा खूप चांगले अभियंते होते आणि ही कथा केवळ त्या वस्तुस्थितीची पुष्टी करते.

प्रथम, थोडी पार्श्वभूमी: Google कडे डेटा स्टोरेज तंत्रज्ञान आहे बिगटेबल. ही एक उल्लेखनीय तांत्रिक उपलब्धी होती, पहिली (पहिली नसल्यास) “अनंत स्केलेबल” की-व्हॅल्यू स्टोअर (K/V): मूलत: NoSQL ची सुरुवात. आजकाल बिगटेबल अजूनही गर्दीच्या K/V स्टोरेज स्पेसमध्ये चांगले काम करत आहे, परंतु त्या वेळी (2005) ते आश्चर्यकारकपणे छान होते.

Bigtable बद्दल एक मजेदार गोष्ट अशी आहे की त्यांच्याकडे अंतर्गत नियंत्रण प्लेन ऑब्जेक्ट्स (अंमलबजावणीचा भाग म्हणून) टॅब्लेट सर्व्हर म्हणतात, मोठ्या निर्देशांकांसह, आणि काही क्षणी ते सिस्टम स्केलिंग करताना अडथळे बनले. बिगटेबल अभियंते स्केलेबिलिटी कशी अंमलात आणायची याबद्दल गोंधळात पडले होते आणि अचानक लक्षात आले की ते इतर बिगटेबल स्टोरेजसह टॅब्लेट सर्व्हर बदलू शकतात. तर Bigtable हा Bigtable अंमलबजावणीचा भाग आहे. या साठवणुकीच्या सुविधा सर्व स्तरांवर आहेत.

आणखी एक मनोरंजक तपशील म्हणजे काही काळासाठी बिगटेबल Google मध्ये लोकप्रिय आणि सर्वव्यापी बनले, प्रत्येक संघाचे स्वतःचे भांडार होते. त्यामुळे शुक्रवारच्या एका सभेत, लॅरी पेजने सहजतेने विचारले: “आमच्याकडे एकापेक्षा जास्त बिगटेबल का आहेत? फक्त एकच का नाही?" सिद्धांतानुसार, Google च्या सर्व स्टोरेज गरजांसाठी एक स्टोरेज पुरेसे असावे. अर्थात, ते व्यावहारिक विकासाच्या कारणास्तव फक्त एकाकडे गेले नाहीत (जसे की संभाव्य अपयशाचे परिणाम), परंतु सिद्धांत मनोरंजक होता. संपूर्ण विश्वासाठी एक भांडार (तसे, अॅमेझॉनने त्यांच्या सेबलसह हे केले आहे की नाही हे कोणाला माहित आहे का?)

असो, इथे माझी कथा आहे.

त्यावेळी, मी गुगलमध्ये फक्त दोन वर्षांपासून काम करत होतो आणि एके दिवशी मला बिगटेबल अभियांत्रिकी कार्यसंघाकडून एक ईमेल प्राप्त झाला जो असे काहीतरी होता:

प्रिय स्टीव्ह,

बिगटेबल टीमकडून नमस्कार. आम्ही तुम्हाला कळवू इच्छितो की [डेटा सेंटरचे नाव] येथे तुम्ही खूप जुनी बिगटेबल बायनरी वापरत आहात. ही आवृत्ती यापुढे समर्थित नाही आणि आम्ही तुम्हाला नवीनतम आवृत्तीवर श्रेणीसुधारित करण्यात मदत करू इच्छितो.

कृपया मला कळवा की तुम्ही या समस्येवर एकत्र काम करण्यासाठी काही वेळ शेड्यूल करू शकता.

सर्व शुभेच्छा,
बिगटेबल टीम

Google वर तुम्हाला बरेच मेल येतात, म्हणून पहिल्या दृष्टीक्षेपात मी असे काहीतरी वाचले:

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

काही संघाकडून नमस्कार. आम्हाला तो ब्ला ब्ला ब्ला ब्ला ब्ला संवाद साधायचा आहे. ब्ला ब्ला ब्ला ब्ला ब्ला ब्ला, आणि ब्ला ब्ला ब्ला लगेच.

कृपया ब्ला ब्ला ब्ला साठी तुमचा काही मौल्यवान वेळ शेड्यूल करू शकता का ते आम्हाला कळवा.

सर्व शुभेच्छा,
काही प्रकारची आज्ञा

मी ते लगेच हटवले, पण माझ्या जाणीवेच्या टोकावर मला एक वेदनादायक, त्रासदायक भावना जाणवली खरोखर नाही औपचारिक पत्रासारखे दिसते स्पष्टपणे, की प्राप्तकर्त्याची चूक झाली कारण मी Bigtable वापरला नाही.

पण ते विचित्र होते.

मी उरलेला दिवस आळीपाळीने कामाचा आणि मायक्रो-किचनमध्ये कोणत्या प्रकारचे शार्कचे मांस वापरायचे याचा विचार करण्यात घालवला, ज्यापैकी किमान तीन बिस्किटांच्या चांगल्या उद्देशाने फेकून माझ्या सीटवरून आपटण्याइतके जवळ होते, परंतु लिहिण्याच्या विचाराने मला कधीच वाढत्या चिंतेने सोडले नाही.

त्यांनी माझे नाव स्पष्ट सांगितले. आणि ईमेल माझ्या ईमेल पत्त्यावर पाठविला गेला होता, इतर कोणाचा नाही आणि तो cc: किंवा bcc: नाही. टोन अतिशय वैयक्तिक आणि स्पष्ट आहे. कदाचित ही काही चूक आहे?

शेवटी, माझी उत्सुकता वाढली आणि मी त्यांनी नमूद केलेल्या डेटा सेंटरमधील बोर्ग कन्सोल पाहण्यासाठी गेलो.

आणि अर्थातच, माझ्याकडे व्यवस्थापनाखाली BigTable स्टोरेज होते. मला माफ करा, काय? मी त्यातील सामग्री पाहिली, आणि व्वा! ते कोडलॅब इनक्यूबेटरचे होते ज्यामध्ये मी जून 2005 मध्ये Google वर माझ्या पहिल्या आठवड्यात बसलो होतो. कोडलॅबने तुम्हाला तेथे काही मूल्ये लिहिण्यासाठी बिगटेबल चालविण्यास भाग पाडले आणि त्यानंतर मी कधीही स्टोरेज बंद केले नाही. दोन वर्षांहून अधिक काळ लोटूनही ते काम करत होते.

या कथेचे अनेक उल्लेखनीय पैलू आहेत. प्रथम, बिगटेबलचे कार्य Google च्या स्केलवर इतके नगण्य होते की केवळ दोन वर्षांनंतर कोणालाही अतिरिक्त संचयन लक्षात आले नाही आणि केवळ बायनरीची आवृत्ती जुनी असल्याने. तुलनेसाठी, मी एकदा वापरण्याचा विचार केला Google Cloud वर Bigtable माझ्या ऑनलाइन गेमसाठी. त्या वेळी, या सेवेची किंमत प्रति वर्ष अंदाजे $16 होती. रिक्त GCP वर बिगटेबल. मी असे म्हणत नाही की ते तुमची फसवणूक करत आहेत, परंतु माझ्या वैयक्तिक मते, रिकाम्या डेटाबेससाठी हे खूप पैसे आहेत.

आणखी एक लक्षात घेण्याजोगा पैलू म्हणजे स्टोरेज दोन वर्षानंतरही काम करत आहे. WTF? डेटा सेंटर येतात आणि जातात; त्यांना आउटेजचा अनुभव येतो, त्यांची नियोजित देखभाल केली जाते, ते सर्व वेळ बदलतात. हार्डवेअर अद्ययावत केले आहे, स्विचेस स्वॅप केले आहेत, सर्वकाही सतत सुधारले जात आहे. हे सर्व बदल करून माझा कार्यक्रम दोन वर्षे चालू कसा ठेवता आला? 2020 मध्ये ही एक माफक कामगिरी वाटू शकते, परंतु 2005-2007 मध्ये ती खूपच प्रभावी होती.

आणि सर्वात आश्चर्यकारक बाब म्हणजे इतर काही राज्यातील बाहेरील अभियांत्रिकी संघ माझ्याकडे येतो, बिगटेबलच्या काही लहान, जवळजवळ रिक्त उदाहरणाचा मालक, ज्याने शून्य रहदारी गेल्या दोन वर्षांपासून - आणि ते अपडेट करण्यासाठी मदत करत आहेत.

मी त्यांचे आभार मानले, स्टोरेज डिलीट केले आणि आयुष्य नेहमीप्रमाणे चालू झाले. पण तेरा वर्षांनंतरही मी त्या पत्राचा विचार करतो. कारण कधीकधी मला Google Cloud वरून असेच ईमेल प्राप्त होतात. ते यासारखे दिसतात:

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

स्मरणपत्र म्हणून, आम्ही ऑगस्ट 2020 पासून [तुम्ही वापरत असलेली अत्यावश्यक सेवा] सेवा बंद करत आहोत, त्यानंतर तुम्ही तुमची उदाहरणे अपग्रेड करू शकणार नाही. आम्ही नवीनतम आवृत्तीवर श्रेणीसुधारित करण्याची शिफारस करतो, जी बीटा चाचणीमध्ये आहे, कोणतेही दस्तऐवजीकरण नाही, स्थलांतरण मार्ग नाही आणि आमच्या दयाळू मदतीमुळे ती पूर्वीपासून जुनी आहे.

या बदलाचा Google क्लाउड प्लॅटफॉर्मच्या सर्व वापरकर्त्यांवर किमान प्रभाव पडेल याची खात्री करण्यासाठी आम्ही वचनबद्ध आहोत.

कायमचे सर्वोत्तम मित्र,
Google क्लाउड प्लॅटफॉर्म

परंतु मी अशी अक्षरे जवळजवळ कधीच वाचली नाहीत, कारण ते प्रत्यक्षात काय म्हणतात:

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

नरकात जा. फक यू, फक यू, फक यू. तुम्ही जे काही करता ते सोडून द्या कारण काही फरक पडत नाही. आमच्या वेळेला महत्त्व आहे. आम्ही आमची बकवास राखण्यात वेळ आणि पैसा वाया घालवतो आणि आम्ही ते कंटाळलो आहोत म्हणून आम्ही यापुढे समर्थन करणार नाही. तेव्हा तुमची बिनधास्त योजना सोडा आणि आमच्या क्षुल्लक दस्तऐवजात खोदणे सुरू करा, फोरमवर भंगारासाठी भीक मागत रहा, आणि तसे, आमची नवीन गोष्ट जुन्या गोष्टींपेक्षा पूर्णपणे वेगळी आहे, कारण आम्ही हे डिझाइन खूपच खराब केले आहे, अहो, पण ते तुमचे आहे. समस्या, आमची नाही.

तुमच्या सर्व घडामोडी एका वर्षात निरुपयोगी व्हाव्यात यासाठी आम्ही प्रयत्न करत आहोत.

कृपया बंद संभोग
Google क्लाउड प्लॅटफॉर्म

आणि वस्तुस्थिती अशी आहे की मला अशी पत्रे महिन्यातून एकदा मिळतात. हे इतके वारंवार आणि इतके सतत घडते की ते अपरिहार्यपणे दूर ढकलले मी GCP कडून क्लाउड विरोधी शिबिरात. मी यापुढे त्यांच्या मालकीच्या घडामोडींवर अवलंबून राहण्यास सहमत नाही, कारण खरेतर डेव्हॉप्सना "कालबाह्य" उत्पादने बंद करण्याच्या धोरणासह Google सोबत राहण्याचा प्रयत्न करण्यापेक्षा अगदी व्हर्च्युअल मशीनवर ओपन सोर्स सिस्टम राखणे सोपे आहे.

मी Google Cloud वर परत जाण्यापूर्वी कारण मी जवळपास हि नाही त्यांच्यावर टीका केली नाही, तर इतर काही क्षेत्रात कंपनीची कामगिरी पाहू. Google अभियंते त्यांच्या सॉफ्टवेअर अभियांत्रिकी विषयावर अभिमान बाळगतात आणि यामुळेच समस्या उद्भवतात. अभिमान हा अविचारी लोकांसाठी एक सापळा आहे आणि यामुळे अनेक Google कर्मचार्‍यांना असे वाटू लागले आहे की त्यांचे निर्णय नेहमीच योग्य असतात आणि ते बरोबर असणे (काही अस्पष्ट अस्पष्ट व्याख्येनुसार) ग्राहकांची काळजी घेण्यापेक्षा अधिक महत्त्वाचे आहे.

मी Google च्या बाहेर इतर मोठ्या प्रकल्पांमधून काही यादृच्छिक उदाहरणे देईन, परंतु मला आशा आहे की तुम्हाला हा नमुना सर्वत्र दिसेल. ते खालीलप्रमाणे आहे. मागासलेली सुसंगतता अनेक दशके प्रणाली जिवंत आणि अद्ययावत ठेवते.

मागास सुसंगतता हे सर्व यशस्वी प्रणालींसाठी डिझाइन केलेले लक्ष्य आहे उघडा वापरा, म्हणजेच ओपन सोर्स कोड आणि/किंवा खुल्या मानकांसह लागू करा. मला असे वाटते की मी काहीतरी अगदी स्पष्टपणे बोलत आहे की प्रत्येकजण अगदी अस्वस्थ आहे, पण नाही. हा राजकीय मुद्दा आहे, त्यामुळे उदाहरणांची गरज आहे.

मी निवडत असलेली पहिली प्रणाली सर्वात जुनी आहे: GNU Emacs, जी Windows Notepad, OS कर्नल आणि इंटरनॅशनल स्पेस स्टेशन मधील संकरीत आहे. हे समजावून सांगणे थोडे कठीण आहे, परंतु थोडक्यात, Emacs हे 1976 मध्ये (होय, जवळजवळ अर्ध्या शतकापूर्वी) प्रोग्रामिंगसाठी तयार केलेले एक व्यासपीठ आहे जे तुम्हाला अधिक उत्पादनक्षम बनवते, परंतु मजकूर संपादक म्हणून मुखवटा घालते.

मी दररोज Emacs वापरतो. होय, मी दररोज IntelliJ देखील वापरतो, ते स्वतःच्या अधिकारात एक शक्तिशाली टूलिंग प्लॅटफॉर्म बनले आहे. परंतु IntelliJ साठी विस्तार लिहिणे हे Emacs साठी विस्तार लिहिण्यापेक्षा अधिक महत्वाकांक्षी आणि गुंतागुंतीचे काम आहे. आणि महत्त्वाचे म्हणजे Emacs साठी लिहिलेली प्रत्येक गोष्ट जतन केलेली आहे कायमचे.

मी 1995 मध्ये Emacs साठी लिहिलेले सॉफ्टवेअर अजूनही वापरतो. आणि मला खात्री आहे की कोणीतरी 80 च्या दशकाच्या मध्यात Emacs साठी लिहिलेले मॉड्यूल वापरत असेल, जर आधी नसेल. त्यांना वेळोवेळी थोडासा चिमटा काढण्याची आवश्यकता असू शकते, परंतु हे खरोखर दुर्मिळ आहे. मी कधीही Emacs साठी लिहिलेले काहीही मला माहित नाही (आणि मी बरेच काही लिहिले आहे) ज्यासाठी पुन्हा आर्किटेक्चर आवश्यक आहे.

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

पण Emacs जगात कामाची वेगळी व्याख्या दिसते. एक वेगळे अंतर्निहित तत्वज्ञान, जर तुम्ही कराल.

Emacs च्या जगात (आणि इतर बर्‍याच क्षेत्रांमध्ये, ज्यांचा आम्ही खाली कव्हर करू) एपीआय स्थितीचा मुळात अर्थ असा होतो: "तुम्ही खरोखर हा दृष्टीकोन वापरू नये, कारण ते कार्य करत असताना, त्यास विविध कमतरतांचा सामना करावा लागतो. येथे यादी. पण दिवसाच्या शेवटी, ही तुमची निवड आहे."

Google च्या जगात, अप्रचलित असण्याचा अर्थ, "आम्ही तुमच्याशी असलेल्या आमच्या वचनबद्धतेचे उल्लंघन करत आहोत." हे खरं आहे. याचा मूलत: अर्थ असा आहे. याचा अर्थ ते तुम्हाला जबरदस्ती करतील नियमितपणे त्यांच्यावर विश्वास ठेवल्याबद्दल शिक्षा म्हणून काही काम करा, कदाचित बरेच काम करा रंगीत जाहिरात: आमच्याकडे सर्वोत्तम सॉफ्टवेअर आहे. सर्वात गतिमान! आपण सूचनांनुसार सर्वकाही करा, आपला अनुप्रयोग किंवा सेवा लाँच करा आणि नंतर एक किंवा दोन वर्षांनी ते खंडित होईल.

हे एक वापरलेली कार विकण्यासारखे आहे जी निश्चितपणे 1500 किमी नंतर खंडित होईल.

या दोन पूर्णपणे भिन्न तात्विक व्याख्या आहेत "अप्रचलितपणा." Google ची वासाची व्याख्या नियोजित अप्रचलितता. माझा यावर विश्वास बसत नाही खरं तर ऍपल सारख्याच अर्थाने नियोजित अप्रचलितता. पण गुगल निश्चितपणे तुमचे कार्यक्रम खंडित करण्याचा विचार करत आहे. मला हे माहित आहे कारण मी तेथे 12 वर्षांहून अधिक काळ सॉफ्टवेअर अभियंता म्हणून काम केले आहे. त्यांच्याकडे अस्पष्ट अंतर्गत मार्गदर्शक तत्त्वे आहेत की किती बॅकवर्ड कंपॅटिबिलिटी पाळली पाहिजे, परंतु हे शेवटी प्रत्येक वैयक्तिक टीम किंवा सेवेवर अवलंबून आहे. कोणतीही एंटरप्राइझ किंवा अभियांत्रिकी-स्तरीय शिफारसी नाहीत आणि अप्रचलित चक्रांच्या दृष्टीने सर्वात धाडसी शिफारस म्हणजे "ग्राहकांना त्यांची संपूर्ण प्रणाली खंडित करण्यापूर्वी अपग्रेड करण्यासाठी 6-12 महिने देण्याचा प्रयत्न करा."

समस्या त्यांच्या विचारापेक्षा खूप मोठी आहे आणि ती पुढील अनेक वर्षे टिकून राहील कारण ग्राहक सेवा त्यांच्या डीएनएमध्ये नाही. खाली यावर अधिक.

या टप्प्यावर मी एक धाडसी विधान करणार आहे की Emacs मोठ्या प्रमाणात आणि अगदी यशस्वी आहे प्रामुख्याने कारण ते पार्श्वगामी सुसंगतता गांभीर्याने घेतात. वास्तविक, हा आमच्या लेखाचा प्रबंध आहे. यशस्वी, दीर्घायुषी खुल्या प्रणाली त्यांच्या यशाचे ऋणी आहेत त्यांच्या आजूबाजूला अनेक दशकांपासून राहत असलेल्या सूक्ष्म समुदायांना विस्तार/प्लगइन. ही परिसंस्था आहे. मी आधीच प्लॅटफॉर्मचे स्वरूप आणि ते किती महत्त्वाचे आहेत याबद्दल बोललो आहे आणि Google ला त्याच्या संपूर्ण कॉर्पोरेट इतिहासात Android किंवा Chrome च्या बाहेर यशस्वी मुक्त प्लॅटफॉर्म तयार करण्यामध्ये काय होते हे कसे समजले नाही.

वास्तविक, मी Android चा थोडक्यात उल्लेख केला पाहिजे कारण तुम्ही कदाचित त्याबद्दल विचार करत आहात.

सर्वप्रथम, Android Google नाही. त्यांच्यात एकमेकांशी जवळजवळ काहीही साम्य नाही. अँड्रॉइड ही एक कंपनी आहे जी Google ने जुलै 2005 मध्ये खरेदी केली होती, कंपनीला कमी-अधिक प्रमाणात स्वायत्तपणे ऑपरेट करण्याची परवानगी देण्यात आली होती आणि खरं तर मधल्या काही वर्षांत ती मोठ्या प्रमाणात अस्पर्शित राहिली आहे. Android ही एक कुख्यात टेक स्टॅक आणि तितकीच कुख्यात काटेरी संस्था आहे. एका Googler ने म्हटल्याप्रमाणे, "तुम्ही फक्त Android मध्ये लॉग इन करू शकत नाही."

मागील लेखात, मी Android चे सुरुवातीचे काही डिझाईन निर्णय किती वाईट होते यावर चर्चा केली. हेक, जेव्हा मी तो लेख लिहिला तेव्हा ते "इन्स्टंट अॅप्स" नावाचे बकवास आणत होते जे आता आहेत (आश्चर्य!) कालबाह्य, आणि तुम्ही Google ऐकण्यासाठी पुरेसे मूर्ख असाल आणि तुमची सामग्री या झटपट अॅप्समध्ये हलवली असेल तर मला सहानुभूती आहे.

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

अँड्रॉइड लोक सुसंगततेला जवळजवळ अकल्पनीय टोकाकडे ढकलतात, त्यांच्या सिस्टम आणि टूलचेनमध्ये मोठ्या प्रमाणात तांत्रिक कर्जे जमा करतात. अरे देवा, तुम्ही त्यांच्या बिल्ड सिस्टममध्ये केलेल्या काही वेड्या गोष्टी पहाव्यात, त्या सर्व सुसंगततेच्या नावाखाली.

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

तथापि, Android साठी झटपट अॅप्स ही एक अतिशय मूर्ख कल्पना होती. आणि का माहित आहे? कारण त्यांनी मागणी केली तुमचा अर्ज पुन्हा लिहा आणि पुन्हा डिझाइन करा! जणू काही लोक फक्त दोन दशलक्ष अर्ज पुन्हा लिहितात. माझा अंदाज आहे की झटपट अॅप्स ही काही Googler ची कल्पना होती.

पण फरक आहे. मागास सुसंगतता उच्च किंमतीवर येते. अँड्रॉइड स्वतः या खर्चाचा भार उचलते, तर गुगलने हा भार उचलावा असा आग्रह धरला आहे вы, पेमेंट क्लायंट.

तुम्ही त्याच्या API मध्ये बॅकवर्ड कंपॅटिबिलिटीसाठी Android ची वचनबद्धता पाहू शकता. जेव्हा तुमच्याकडे चार किंवा पाच भिन्न उपप्रणाली अक्षरशः समान गोष्टी करत असतात, तेव्हा हे एक निश्चित चिन्ह आहे की मूळ बाजूने अनुकूलतेसाठी वचनबद्धता आहे. जे प्लॅटफॉर्मच्या जगात तुमच्या ग्राहकांना आणि तुमच्या मार्केटशी बांधिलकीचे समानार्थी आहे.

येथे Google ची मुख्य समस्या त्यांच्या अभियांत्रिकी स्वच्छतेचा अभिमान आहे. जुन्या, कमी इष्ट मार्गांसह नवीन, कल्पक मार्गांच्या शेजारी बसून एकच गोष्ट करण्याचे वेगवेगळे मार्ग असताना त्यांना ते आवडत नाही. हे सिस्टीममध्ये नवीन असलेल्यांसाठी शिकण्याची वक्र वाढवते, ते लेगेसी API राखण्याचे ओझे वाढवते, ते नवीन वैशिष्ट्यांचा वेग कमी करते आणि मुख्य पाप म्हणजे ते सुंदर नाही. Google - टिम बर्टनच्या अॅलिस इन वंडरलँडमधील लेडी एस्कॉट प्रमाणे:

लेडी एस्कॉट:
- अॅलिस, मला सर्वात जास्त कशाची भीती वाटते हे तुला माहिती आहे का?
- अभिजात वर्गाचा ऱ्हास?
- मला भीती होती की माझ्याकडे असेल कुरुप नातवंडे.

सुंदर आणि व्यावहारिक यांच्यातील ट्रेडऑफ समजून घेण्यासाठी, तिसरे यशस्वी प्लॅटफॉर्म (Emacs आणि Android नंतर) पाहू आणि ते कसे कार्य करते ते पाहू: Java स्वतः.

Java मध्ये बरेच जुने API आहेत. जावा प्रोग्रामरमध्ये अवमूल्यन खूप लोकप्रिय आहे, बहुतेक प्रोग्रामिंग भाषांपेक्षाही अधिक लोकप्रिय आहे. जावा स्वतः, मूळ भाषा आणि लायब्ररी सतत APIs नापसंत करत आहेत.

हजारो उदाहरणांपैकी फक्त एकच उदाहरण घ्यायचे, धागे बंद करणे अप्रचलित मानले जाते. डिसेंबर 1.2 मध्ये Java 1998 रिलीज झाल्यापासून ते नापसंत केले गेले आहे. या नाकारल्याला 22 वर्षे झाली आहेत.

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

ओरॅकल कदाचित प्लॅटफॉर्म देखील समजते. कोणास ठाऊक.

पुरावे संपूर्ण Java API मध्ये आढळू शकतात, जे कॅन्यनमधील हिमनदीच्या ओळींप्रमाणे अप्रचलिततेच्या लाटांनी भरलेले आहेत. जावा स्विंग लायब्ररीमध्ये तुम्हाला पाच किंवा सहा वेगवेगळे कीबोर्ड नेव्हिगेशन व्यवस्थापक (KeyboardFocusManager) सहज मिळू शकतात. बहिष्कृत नसलेले Java API शोधणे खरोखर कठीण आहे. पण तरीही ते काम करतात! मला वाटते की जर इंटरफेसमध्ये सुरक्षिततेची गंभीर समस्या असेल तरच Java कार्यसंघ खरोखरच API काढून टाकेल.

ही गोष्ट आहे, लोक: आम्ही सॉफ्टवेअर डेव्हलपर सर्व खूप व्यस्त आहोत आणि सॉफ्टवेअरच्या प्रत्येक क्षेत्रात आम्हाला प्रतिस्पर्धी पर्यायांचा सामना करावा लागतो. कोणत्याही वेळी, भाषा X मधील प्रोग्रामर भाषा Y ला संभाव्य बदली म्हणून विचारात घेतात. अरे, तुझा माझ्यावर विश्वास नाही? तुम्हाला स्विफ्ट म्हणायचे आहे का? जसे की, प्रत्येकजण स्विफ्टकडे स्थलांतर करत आहे आणि कोणीही ते सोडत नाही, बरोबर? व्वा, तुम्हाला किती कमी माहिती आहे. कंपन्या ड्युअल मोबाइल डेव्हलपमेंट टीम्स (iOS आणि Android) ची किंमत मोजत आहेत - आणि त्यांना हे समजू लागले आहे की फ्लटर आणि रिऍक्ट नेटिव्ह सारख्या मजेदार नावांसह क्रॉस-प्लॅटफॉर्म डेव्हलपमेंट सिस्टम प्रत्यक्षात काम करतात आणि त्यांचा आकार कमी करण्यासाठी वापरला जाऊ शकतो. मोबाईल टीम्स दोनदा किंवा त्याउलट, त्यांना दुप्पट उत्पादक बनवतात. खरे पैसे पणाला लागले आहेत. होय, तडजोडी आहेत, परंतु, दुसरीकडे, पैसा.

चला काल्पनिकपणे असे गृहीत धरू की Apple ने मूर्खपणाने Guido van Rossum कडून एक संकेत घेतला आणि घोषित केले की स्विफ्ट 6.0 हे स्विफ्ट 5.0 शी विसंगत आहे, जसे पायथन 3 पायथन 2 शी विसंगत आहे.

मी कदाचित ही कथा सुमारे दहा वर्षांपूर्वी सांगितली होती, परंतु सुमारे पंधरा वर्षांपूर्वी मी गुइडोसह ओ'रेलीच्या फू कॅम्पमध्ये गेलो होतो, पॉल ग्रॅहम आणि मोठ्या शॉट्सच्या गुच्छांसह तंबूत बसलो होतो. आम्ही लॅरी पेज त्याच्या वैयक्तिक हेलिकॉप्टरमधून बाहेर पडण्याची वाट पाहत उष्णतेमध्ये बसलो होतो, तर गुइडोने सुमारे “पायथन 3000” वर ड्रोन केले, ज्याचे नाव त्याने प्रत्येकाला तेथे स्थलांतरित होण्यास किती वर्षे लागतील यावरून ठेवले. आम्ही त्याला विचारत राहिलो की तो सुसंगतता का तोडत आहे आणि त्याने उत्तर दिले: “युनिकोड.” आणि आम्ही विचारले, जर आम्हाला आमचा कोड पुन्हा लिहावा लागला तर आम्हाला आणखी कोणते फायदे दिसतील? आणि त्याने उत्तर दिले "Yoooooooooooooouuuuuuniiiiiiiiiiiiiiiiiiiiiii"

तुम्ही Google Cloud Platform SDK (“gcloud”) इंस्टॉल केल्यास, तुम्हाला पुढील सूचना प्राप्त होतील:

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

आम्‍ही तुम्‍हाला आठवण करून देऊ इच्छितो की पायथन 2 साठी समर्थन नापसंत केले गेले आहे, त्यामुळे तुमचा

… आणि असेच. जीवनचक्र.

पण मुद्दा असा आहे की प्रत्येक विकसकाला एक पर्याय असतो. आणि जर तुम्ही त्यांना कोड पुन्हा लिहिण्यास भाग पाडले तर ते कदाचित विचार करू शकतात इतर पर्याय ते तुमचे ओलिस नाहीत, तुमची त्यांना कितीही इच्छा असली तरीही. ते तुमचे पाहुणे आहेत. Python ही अजूनही एक अतिशय लोकप्रिय प्रोग्रामिंग भाषा आहे, परंतु धिक्कार असो, Python 3(000) ने स्वतःमध्ये, त्याच्या समुदायांमध्ये आणि त्याच्या समुदायांच्या वापरकर्त्यांमध्ये असा गोंधळ निर्माण केला की त्याचे परिणाम पंधरा वर्षांपासून साफ ​​झाले नाहीत.

गो (किंवा रुबी, किंवा इतर काही पर्यायी) मध्ये किती पायथन प्रोग्राम्स या मागच्या बाजूच्या विसंगतीमुळे पुन्हा लिहिले गेले आहेत? Python व्यतिरिक्त इतर कशातही किती नवीन सॉफ्टवेअर लिहिले गेले आहे, जरी ते असू शकते Python मध्ये लिहिले आहे, जर Guido ने संपूर्ण गाव जाळले नसते? हे सांगणे कठीण आहे, परंतु पायथनला स्पष्टपणे त्रास झाला आहे. हा एक मोठा गोंधळ आहे आणि प्रत्येकजण हरतो.

तर असे म्हणूया की Apple ने Guido कडून एक संकेत घेतला आणि सुसंगतता तोडली. पुढे काय होईल असे वाटते? ठीक आहे, कदाचित 80-90% विकासक शक्य असल्यास त्यांचे सॉफ्टवेअर पुन्हा लिहतील. दुसऱ्या शब्दांत, 10-20% वापरकर्ता आधार आपोआप काही स्पर्धक भाषेत जातो, जसे की फ्लटर.

हे अनेक वेळा करा आणि तुम्ही तुमचा अर्धा वापरकर्ता आधार गमावाल. खेळाप्रमाणेच, प्रोग्रामिंगच्या जगात, वर्तमान स्वरूप देखील महत्त्वाचे आहे. सर्वकाही. जो कोणी पाच वर्षात त्यांचे अर्धे वापरकर्ते गमावेल तो बिग फॅट लूझर समजला जाईल. आपण प्लॅटफॉर्मच्या जगात ट्रेंडी असणे आवश्यक आहे. परंतु येथेच जुन्या आवृत्त्यांचे समर्थन न केल्याने कालांतराने तुमचा नाश होईल. कारण प्रत्येक वेळी तुम्ही काही विकसकांपासून सुटका करून घेता, तुम्ही (अ) त्यांना कायमचे गमावता कारण ते करार मोडल्याबद्दल तुमच्यावर रागावतात आणि (ब) त्यांना तुमच्या प्रतिस्पर्ध्यांना देतात.

गंमत म्हणजे, मी Google ला असा प्राइमा डोना बनण्यास मदत केली जी मी Grok तयार केली तेव्हा मागच्या बाजूच्या सुसंगततेकडे दुर्लक्ष करते, एक स्त्रोत कोड विश्लेषण आणि समजून घेण्याची प्रणाली जी कोड स्वतःच स्वयंचलित आणि इन्स्ट्रुमेंट करणे सोपे करते - IDE प्रमाणेच, परंतु येथे क्लाउड सेवा स्टोअर करते. मोठ्या डेटा वेअरहाऊसमध्ये Google स्त्रोत कोडच्या सर्व अब्जावधी ओळींचे वास्तविक प्रतिनिधित्व.

Grok ने Googlers ला त्यांच्या संपूर्ण कोडबेसवर (अक्षरशः संपूर्ण Google) स्वयंचलित रिफॅक्टरिंग करण्यासाठी एक शक्तिशाली फ्रेमवर्क प्रदान केले. प्रणाली केवळ तुमच्या अपस्ट्रीम अवलंबित्वांची (ज्यावर तुम्ही अवलंबून आहात) गणना करते उतरत्या (जे तुमच्यावर अवलंबून आहे) म्हणून जेव्हा तुम्ही API बदलता तेव्हा तुम्ही तोडत आहात हे तुम्हाला माहीत असते! अशा प्रकारे, जेव्हा तुम्ही बदल करता, तेव्हा तुम्ही सत्यापित करू शकता की तुमच्या API च्या प्रत्येक ग्राहकाने नवीन आवृत्ती अद्यतनित केली आहे आणि प्रत्यक्षात, अनेकदा त्यांनी लिहिलेल्या रोझी टूलसह, तुम्ही प्रक्रिया पूर्णपणे स्वयंचलित करू शकता.

हे Google च्या कोडबेसला अंतर्गत जवळजवळ अलौकिकरित्या स्वच्छ ठेवण्यास अनुमती देते, कारण त्यांच्याकडे हे रोबोटिक सेवक घराभोवती फिरत असतात आणि त्यांनी SomeDespicablyLongFunctionName असे नाव बदलून SomeDespicablyLongMethodName केले असल्यास ते सर्व काही आपोआप साफ करतात कारण कोणीतरी ठरवले की ते एक कुरूप नातवंड आहे आणि त्याला झोपण्याची गरज आहे.

आणि खरे सांगायचे तर, ते Google साठी खूप चांगले काम करते... अंतर्गतरित्या. म्हणजे, होय, Google वरील Go समुदायाला सतत रिफॅक्टरिंग करण्याच्या त्यांच्या सवयीमुळे Google वर जावा समुदायासोबत चांगलेच हसू येते. तुम्ही काही N वेळा रीस्टार्ट केल्यास, याचा अर्थ तुम्ही ते फक्त N-1 वेळा खराब केले नाही, परंतु थोड्या वेळाने हे अगदी स्पष्ट होते की तुम्ही Nth प्रयत्नात देखील ते खराब केले आहे. परंतु, मोठ्या प्रमाणावर, ते या सर्व गोंधळाच्या वर राहतात आणि कोड "स्वच्छ" ठेवतात.

जेव्हा ते त्यांच्या क्लाउड क्लायंटवर आणि इतर API च्या वापरकर्त्यांवर ही वृत्ती लादण्याचा प्रयत्न करतात तेव्हा समस्या सुरू होते.

मी तुम्हाला Emacs, Android आणि Java ची थोडीशी ओळख करून दिली आहे; चला नवीनतम यशस्वी दीर्घायुषी प्लॅटफॉर्म पाहू: वेब स्वतः. जेव्हा आम्ही फ्लॅशिंग टॅग वापरतो तेव्हा 1995 पासून HTTP किती पुनरावृत्ती झाली आहे याची तुम्ही कल्पना करू शकता? आणि वेब पृष्ठांवर "अंडर कन्स्ट्रक्शन" चिन्ह.

पण तरीही ते कार्य करते! आणि ही पृष्ठे अजूनही कार्यरत आहेत! होय, मित्रांनो, ब्राउझर हे मागासलेल्या अनुकूलतेमध्ये जागतिक विजेते आहेत. क्रोम हे दुर्मिळ Google प्लॅटफॉर्मचे आणखी एक उदाहरण आहे ज्याचे डोके योग्यरित्या स्क्रू केले गेले आहे आणि तुम्ही अंदाज केला असेल, क्रोम प्रभावीपणे उर्वरित Google पेक्षा वेगळी सँडबॉक्स कंपनी म्हणून कार्य करते.

मला ऑपरेटिंग सिस्टम डेव्हलपरमधील आमच्या मित्रांचे देखील आभार मानायचे आहेत: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, इ., त्यांच्या यशस्वी प्लॅटफॉर्मवर बॅकवर्ड कंपॅटिबिलिटीचे इतके उत्तम काम केल्याबद्दल (Apple ला सर्वोत्तम C मिळवून देते. नकारात्मक बाजू अशी आहे की ते कोणत्याही चांगल्या कारणाशिवाय सर्व काही वेळोवेळी खंडित करतात, परंतु प्रत्येक रिलीझसह कसा तरी समुदाय त्याच्याभोवती येतो आणि OS X कंटेनर अजूनही पूर्णपणे अप्रचलित नाहीत... अद्याप).

पण थांबा, तुम्ही म्हणाल. आम्ही सफरचंदांची संत्र्यांशी तुलना करत नाही का - एकाच मशीनवर इमॅक्स/जेडीके/अँड्रॉइड/क्रोम विरुद्ध मल्टी-सर्व्हर सिस्टम आणि क्लाउड सर्व्हिसेस सारख्या एपीआय सारख्या स्वतंत्र सॉफ्टवेअर सिस्टम?

बरं, मी याबद्दल कालच ट्विट केलं होतं, पण लॅरी वॉलच्या शैलीत (प्रोग्रामिंग भाषेचा निर्माता पर्ल - अंदाजे प्रति.) "उत्साही/नियम" या तत्त्वावर मी हा शब्द पाहिला. नापसंत Google आणि Amazon डेव्हलपर साइटवर. आणि AWS आहे तरी शेकडो GCP पेक्षा पटींनी जास्त सेवा ऑफर, Google च्या विकसक दस्तऐवजीकरणात सातपट अधिक वेळा अवमूल्यनाचा उल्लेख आहे.

जर Google वर कोणीही हे वाचत असेल, तर ते कदाचित डोनाल्ड ट्रम्प-शैलीतील तक्ते काढण्यासाठी तयार असतील जे ते प्रत्यक्षात सर्वकाही बरोबर करत आहेत हे दर्शविते आणि मी "बहिष्कृत शब्दाच्या उल्लेखांची संख्या विरुद्ध" अशी अयोग्य तुलना करू नये. सेवांची संख्या" "

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

माझा प्रबंध "सिद्ध" करण्यासाठी माझ्याकडे कोणतेही आकर्षक युक्तिवाद नाहीत. मी विकसक म्हणून 30 वर्षांपासून जमा केलेली रंगीत उदाहरणे माझ्याकडे आहेत. या समस्येचे सखोल तात्विक स्वरूप मी आधीच नमूद केले आहे; काही मार्गांनी विकासक समुदायांमध्ये त्याचे राजकारण केले जाते. असे काहीजण मानतात निर्माते प्लॅटफॉर्मने सुसंगततेची काळजी घेतली पाहिजे, तर इतरांना वाटते की ही चिंतेची बाब आहे वापरकर्ते (स्वतः विकासक). दोन पैकी एक. खरंच, सामान्य समस्यांचा खर्च कोणी उचलायचा हे आपण ठरवतो तेव्हा हा राजकीय मुद्दा नाही का?

त्यामुळे हे राजकारण आहे. आणि कदाचित माझ्या भाषणावर संतप्त प्रतिक्रिया येतील.

कसे वापरकर्ता Google क्लाउड प्लॅटफॉर्म, आणि AWS वापरकर्ता म्हणून दोन वर्षे (ग्रॅबसाठी काम करत असताना), मी असे म्हणू शकतो की ऍमेझॉन आणि Google च्या तत्त्वज्ञानामध्ये खूप फरक आहे जेव्हा तो प्राधान्यक्रमांवर येतो. मी AWS वर सक्रियपणे विकसित होत नाही, म्हणून ते जुने API किती वेळा काढतात हे मला चांगले माहित नाही. पण गुगलवर जेवढ्या वेळा घडते तेवढेच घडत नाही असा संशय आहे. आणि माझा खरोखर विश्वास आहे की GCP मधील सतत विवाद आणि निराशेचा हा स्त्रोत प्लॅटफॉर्मच्या विकासास रोखणारा सर्वात मोठा घटक आहे.

मला माहित आहे की मी यापुढे समर्थित नसलेल्या GCP सिस्टीमच्या विशिष्ट उदाहरणांची नावे दिली नाहीत. मी असे म्हणू शकतो की नेटवर्क (सर्वात जुने ते व्हीपीसी) पासून स्टोरेज (क्लाउड SQL v1-v2), फायरबेस (आता पूर्णपणे वेगळ्या API सह फायरस्टोर), अॅप इंजिन (चला तर सुरुवात करू नका) जवळजवळ प्रत्येक गोष्ट मी वापरली आहे. , क्लाउड एंडपॉइंट क्लाउड एंडपॉइंट आणि पर्यंत... मला माहित नाही - पूर्णपणे हे सर्व तुम्हाला जास्तीत जास्त २-३ वर्षांनी कोड पुन्हा लिहिण्यास भाग पाडले, आणि त्यांनी तुमच्यासाठी स्थलांतर स्वयंचलित केले नाही, आणि अनेकदा कोणताही दस्तऐवजीकरण केलेला स्थलांतर मार्ग नव्हता. जणू असेच व्हायला हवे होते.

आणि प्रत्येक वेळी जेव्हा मी AWS कडे पाहतो तेव्हा मी स्वतःला विचारतो की मी अजूनही GCP वर का आहे. त्यांना स्पष्टपणे ग्राहकांची गरज नाही. त्यांना गरज आहे खरेदीदार. तुम्हाला फरक समजला का? मला समजावून सांगा.

Google क्लाउड आहे बाजारात, जेथे लोक त्यांचे सॉफ्टवेअर सोल्यूशन्स प्रस्तावित करतात आणि रेस्टॉरंटचा रिकामा परिणाम टाळण्यासाठी, त्यांना काही प्रस्तावांसह ते भरणे आवश्यक होते, म्हणून त्यांनी "एका क्लिकने" उपयोजित केलेल्या समाधानांचा समूह तयार करण्यासाठी बिटनामी नावाच्या कंपनीशी करार केला. मी ते स्वतः लिहितो “उपाय”, कारण हे काही वाईट सोडवत नाहीत. ते फक्त चेकबॉक्सेस म्हणून अस्तित्वात आहेत, मार्केटिंग फिलर म्हणून, आणि कोणतीही साधने प्रत्यक्षात काम करतात की नाही याची Google ने कधीही काळजी घेतली नाही. मी उत्पादन व्यवस्थापकांना ओळखतो जे ड्रायव्हरच्या सीटवर आहेत आणि मी तुम्हाला खात्री देतो की या लोकांना काळजी नाही.

उदाहरणार्थ, एक "एक-क्लिक" उपयोजन उपाय घ्या. पर्कोना. मी गुगल क्लाउड एसक्यूएल शेनानिगन्समुळे आजारी पडलो होतो, म्हणून मी एक पर्याय म्हणून माझे स्वतःचे पर्कोना क्लस्टर बनवण्याचा विचार करू लागलो. आणि यावेळी गुगलने चांगले काम केले आहे असे वाटले, ते एका बटणाच्या क्लिकने माझा थोडा वेळ आणि श्रम वाचवणार होते!

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

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

आणि हे GCP साठी एक खरे आव्हान प्रस्तुत करते कारण सर्व क्लाउड ऑफरिंगच्या मागे हा DNA आहे. ते कशाचेही समर्थन करण्याचा प्रयत्न करत नाहीत; हे सर्वज्ञात आहे की ते कोणतेही तृतीय पक्ष सॉफ्टवेअर होस्ट करण्यास (व्यवस्थापित सेवा म्हणून) नकार देतात पर्यंत, जोपर्यंत AWS तेच करत नाही आणि त्याभोवती एक यशस्वी व्यवसाय तयार करत नाही आणि जेव्हा ग्राहक अक्षरशः तशी मागणी करत नाही. तथापि, Google ला काहीतरी समर्थन मिळण्यासाठी काही प्रयत्न करावे लागतात.

समर्थन संस्कृतीचा अभाव, "चला तो अधिक सुंदर बनवण्यासाठी तो मोडूया" या मानसिकतेसह, विकासकांना दूर करते.

आणि जर तुम्हाला दीर्घकालीन व्यासपीठ तयार करायचे असेल तर ती चांगली गोष्ट नाही.

गुगल, जागे व्हा, धिक्कार असो. आता २०२० आहे. तू अजूनही हरत आहेस. आरशात कठोरपणे पाहण्याची आणि तुम्हाला खरोखर क्लाउड व्यवसायात राहायचे आहे की नाही याचे उत्तर देण्याची ही वेळ आहे.

राहायचे असेल तर मग सर्वकाही तोडणे थांबवा. मित्रांनो, तुम्ही श्रीमंत आहात. आम्ही विकासक नाही. तेव्हा सुसंगततेचा भार कोणाच्या खांद्यावर घ्यायचा हा प्रश्न येतो, तेव्हा तो तुम्हाला स्वतःवर घ्यावा लागेल. आमच्यासाठी नाही.

कारण आणखी किमान तीन खरोखर चांगले ढग आहेत. ते खुणावतात.

आणि आता मी माझ्या सर्व तुटलेल्या प्रणाली दुरुस्त करण्यासाठी पुढे जाईन. एह.

पुढच्या वेळे पर्यंत!

या लेखावरील काही चर्चा वाचल्यानंतर पुनश्च अपडेट (चर्चा छान आहेत, btw). फायरबेस समर्थन बंद केले गेले नाही आणि मला माहिती आहे अशा कोणत्याही योजना नाहीत. तथापि, त्यांच्याकडे एक खराब स्ट्रीमिंग बग आहे ज्यामुळे Java क्लायंट अॅप इंजिनमध्ये थांबतो. त्यांच्या एका अभियंत्याने मला ही समस्या सोडविण्यास मदत केली, जेव्हा मी Google वर काम केले, परंतु त्यांनी प्रत्यक्षात बग कधीच दुरुस्त केला नाही, म्हणून माझ्याकडे दररोज GAE अॅप रीस्टार्ट करायचा आहे. आणि असेच चार वर्षे झाली! त्यांच्याकडे आता फायरस्टोअर आहे. त्यात स्थलांतरित होण्यासाठी खूप काम करावे लागेल कारण ती पूर्णपणे वेगळी प्रणाली आहे आणि फायरबेस बग कधीही निश्चित केला जाणार नाही. कोणता निष्कर्ष काढला जाऊ शकतो? तुम्हाला मदत मिळू शकते जर तुम्ही कंपनीत काम करता. GAE वर फायरबेस वापरणारा मी कदाचित एकमेव आहे कारण मी 100% नेटिव्ह अॅपमध्ये 100 पेक्षा कमी की लॉग करतो आणि ज्ञात बगमुळे ते दर दोन दिवसांनी काम करणे थांबवते. तुमच्या स्वत:च्या जबाबदारीवर वापरण्याशिवाय मी काय बोलू शकतो. मी Redis वर स्विच करत आहे.

मी काही अधिक अनुभवी AWS वापरकर्ते देखील पाहिले आहेत की AWS सहसा कोणत्याही सेवांना समर्थन देणे थांबवत नाही आणि SimpleDB हे एक उत्तम उदाहरण आहे. Google प्रमाणे AWS ला समर्थन रोगाचा समान अंत नाही हे माझे गृहितक न्याय्य असल्याचे दिसते.

याव्यतिरिक्त, माझ्या लक्षात आले की 20 दिवसांपूर्वी Google App Engine टीमने एका गंभीर Go लायब्ररीचे होस्टिंग तोडले, मुख्य Go विकासकांपैकी एक GAE ऍप्लिकेशन बंद केले. ते खरोखर मूर्ख होते.

शेवटी, मी Googlers आधीच या समस्येवर चर्चा करताना आणि सर्वसाधारणपणे माझ्याशी सहमत असल्याचे ऐकले आहे (लव्ह युज!). परंतु त्यांना असे वाटते की ही समस्या सोडवता येणार नाही कारण Google च्या संस्कृतीत कधीही योग्य प्रोत्साहन संरचना नव्हती. मला वाटले की ग्रॅबमध्ये काम करत असताना मला AWS अभियंत्यांसह काम करताना आलेल्या आश्चर्यकारक अनुभवावर चर्चा करण्यासाठी थोडा वेळ काढणे चांगले होईल. भविष्यात कधीतरी, मला आशा आहे!

आणि हो, 2005 मध्ये त्यांनी बिल्डिंग 43 मधील राक्षस बुफेवर विविध प्रकारचे शार्क मांस घेतले होते आणि माझे आवडते हॅमरहेड शार्क मांस होते. तथापि, 2006 पर्यंत, लॅरी आणि सर्गेईने सर्व अस्वास्थ्यकर स्नॅक्सपासून मुक्त केले. म्हणून 2007 मध्ये बिगटेबल कथेदरम्यान खरोखर शार्क नव्हते आणि मी तुम्हाला फसवले.

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

ऍपल समुदायाला दुखावल्याबद्दल क्षमस्व आणि मायक्रोसॉफ्ट इत्यादीबद्दल काहीही चांगले न बोलल्याबद्दल क्षमस्व. तुम्ही ठीक आहात, मी या लेखाद्वारे तयार केलेल्या सर्व चर्चेची खरोखर प्रशंसा करतो! परंतु कधीकधी चर्चा सुरू करण्यासाठी तुम्हाला थोडेसे लहरीपणाची आवश्यकता असते, तुम्हाला माहिती आहे?

वाचल्याबद्दल धन्यवाद.

अपडेट 2, 19.08.2020/XNUMX/XNUMX. पट्टी API योग्यरित्या अद्यतनित करते!

अपडेट 3, 31.08.2020/2/2. माझ्याशी क्लाउड मार्केटप्लेसमधील एका Google अभियंत्याने संपर्क साधला जो माझा जुना मित्र होता. त्याला CXNUMXD का काम करत नाही हे शोधून काढायचे होते आणि शेवटी आम्हाला कळले की मी माझे नेटवर्क काही वर्षांपूर्वी तयार केले होते आणि CXNUMXD लेगेसी नेटवर्कवर काम करत नव्हते कारण त्यांच्या टेम्प्लेटमध्ये सबनेट पॅरामीटर गहाळ होता. मला वाटते की संभाव्य GCP वापरकर्त्यांसाठी ते Google वर पुरेसे अभियंते ओळखतात याची खात्री करणे सर्वोत्तम आहे...

स्त्रोत: www.habr.com