Alamak Google, saya tidak mahu berblog lagi. Banyak yang perlu saya lakukan. Memblog memerlukan masa, tenaga dan kreativiti, yang boleh saya gunakan dengan baik: buku saya, , permainan saya dan sebagainya. Tetapi anda telah cukup marahkan saya sehingga saya perlu menulis ini.
Jadi mari kita selesaikan perkara ini.
Izinkan saya mulakan dengan cerita ringkas tetapi penuh pengajaran sejak saya mula bekerja di Google. Saya tahu saya telah mengatakan banyak perkara buruk tentang Google sejak kebelakangan ini, tetapi saya kecewa apabila syarikat saya sendiri kerap membuat keputusan perniagaan yang tidak cekap. Pada masa yang sama, kita mesti memberikannya: Infrastruktur dalaman Google benar-benar luar biasa, adalah selamat untuk mengatakan bahawa tidak ada yang lebih baik hari ini. Pengasas Google adalah jurutera yang lebih baik daripada saya, dan cerita ini hanya mengesahkan fakta itu.
Pertama, sedikit latar belakang: Google mempunyai teknologi penyimpanan data yang dipanggil . Ia merupakan pencapaian teknikal yang luar biasa, salah satu daripada stor nilai kunci (K/V) yang pertama (jika bukan yang pertama) "boleh skala tak terhingga": pada asasnya permulaan NoSQL. Hari ini Bigtable masih berfungsi dengan baik di ruang simpanan K/V yang agak sesak, tetapi pada masa itu (2005) ia sangat hebat.
Satu perkara yang lucu tentang Bigtable ialah mereka mempunyai objek satah kawalan dalaman (sebagai sebahagian daripada pelaksanaan) yang dipanggil pelayan tablet, dengan indeks yang besar, dan pada satu ketika ia menjadi halangan apabila menskalakan sistem. Jurutera Bigtable bingung tentang cara melaksanakan kebolehskalaan, dan tiba-tiba menyedari bahawa mereka boleh menggantikan pelayan tablet dengan storan Bigtable yang lain. Jadi Bigtable adalah sebahagian daripada pelaksanaan Bigtable. Kemudahan penyimpanan ini ada di semua peringkat.
Satu lagi perincian yang menarik ialah untuk seketika Bigtable menjadi popular dan di mana-mana dalam Google, dengan setiap pasukan mempunyai repositori sendiri. Jadi pada salah satu mesyuarat Jumaat, Larry Page dengan santai bertanya sambil berlalu: βMengapa kita mempunyai lebih daripada satu Bigtable? Kenapa tidak satu sahaja?β Secara teorinya, satu storan sepatutnya mencukupi untuk semua keperluan storan Google. Sudah tentu, mereka tidak pernah pergi ke satu sahaja atas sebab pembangunan praktikal (seperti akibat kegagalan yang berpotensi), tetapi teori itu menarik. Satu repositori untuk seluruh Alam Semesta (By the way, adakah sesiapa tahu jika Amazon melakukan ini dengan Sable mereka?)
Apa pun, ini cerita saya.
Pada masa itu, saya telah bekerja di Google selama lebih dua tahun dan pada suatu hari saya menerima e-mel daripada pasukan kejuruteraan Bigtable yang berbunyi seperti ini:
Steve yang dihormati,
Helo dari pasukan Bigtable. Kami ingin memaklumkan kepada anda bahawa di [nama pusat data] anda menggunakan binari Bigtable yang sangat lama. Versi ini tidak lagi disokong dan kami ingin membantu anda meningkatkan kepada versi terkini.
Sila beritahu saya jika anda boleh menjadualkan sedikit masa untuk bekerjasama dalam isu ini.
Semua yang terbaik,
Pasukan Meja Besar
Di Google anda mendapat banyak mel, jadi pada pandangan pertama saya membaca sesuatu seperti ini:
Penerima yang dihormati,
Salam dari beberapa pasukan. Kami mahu berkomunikasi bahawa bla bla bla bla bla. Bla bla bla bla bla bla, dan bla bla bla serta-merta.
Sila maklumkan kepada kami jika anda boleh menjadualkan beberapa masa berharga anda untuk bla bla bla.
Semua yang terbaik,
Beberapa jenis arahan
Saya hampir memadamkannya serta-merta, tetapi di tepi kesedaran saya, saya merasakan perasaan yang menyakitkan dan mengganggu bahawa ia sebenarnya tidak nampak macam surat rasmi jelas, bahawa penerima telah tersilap kerana saya tidak menggunakan Bigtable.
Tetapi ia adalah pelik.
Saya menghabiskan sepanjang hari itu secara bergilir-gilir memikirkan tentang kerja dan jenis daging ikan jerung yang perlu dicuba di dapur mikro, yang sekurang-kurangnya tiga daripadanya cukup dekat untuk memukul dari tempat duduk saya dengan lontaran biskut yang bertujuan baik, tetapi terfikir untuk menulis tidak pernah meninggalkan saya dengan perasaan yang semakin meningkat kebimbangan ringan.
Mereka menyebut nama saya dengan jelas. Dan e-mel itu telah dihantar ke alamat e-mel saya, bukan orang lain, dan ia bukan cc: atau bcc:. Nadanya sangat peribadi dan jelas. Mungkin ini adalah sejenis kesilapan?
Akhirnya, rasa ingin tahu menguasai saya dan saya pergi melihat konsol Borg di pusat data yang mereka sebutkan.
Dan sudah tentu, saya mempunyai storan BigTable di bawah pengurusan. Minta maaf, apa? Saya melihat kandungannya, dan wow! Ia adalah daripada inkubator Codelab yang saya gunakan semasa minggu pertama saya di Google pada Jun 2005. Codelab memaksa anda menjalankan Bigtable untuk menulis beberapa nilai di sana, dan saya nampaknya tidak pernah menutup storan selepas itu. Ia masih berfungsi walaupun lebih daripada dua tahun telah berlalu.
Terdapat beberapa aspek yang perlu diberi perhatian untuk cerita ini. Pertama, kerja Bigtable adalah sangat tidak penting pada skala Google sehingga hanya dua tahun kemudian sesiapa sahaja menyedari storan tambahan, dan hanya kerana versi binari itu sudah lapuk. Sebagai perbandingan, saya pernah mempertimbangkan untuk menggunakan untuk permainan dalam talian saya. Pada masa itu, kos perkhidmatan ini kira-kira $16 setahun. kosong Bigtable pada GCP. Saya tidak mengatakan mereka menipu anda, tetapi pada pendapat peribadi saya, itu adalah banyak wang untuk pangkalan data sialan kosong.
Satu lagi aspek yang perlu diberi perhatian ialah penyimpanan masih bekerja selepas dua tahun. WTF? Pusat data datang dan pergi; mereka mengalami gangguan, mereka menjalani penyelenggaraan berjadual, mereka berubah sepanjang masa. Perkakasan dikemas kini, suis ditukar, semuanya sentiasa diperbaiki. Bagaimanakah mereka dapat mengekalkan program saya selama dua tahun dengan semua perubahan ini? Ini mungkin kelihatan seperti pencapaian sederhana pada tahun 2020, tetapi pada tahun 2005-2007 ia agak mengagumkan.
Dan aspek yang paling menarik ialah pasukan kejuruteraan luar di beberapa negeri lain mendekati saya, pemilik contoh kecil Bigtable yang hampir kosong, yang telah trafik sifar selama dua tahun yang lalu - dan menawarkan bantuan untuk mengemas kininya.
Saya berterima kasih kepada mereka, memadamkan storan, dan kehidupan berjalan seperti biasa. Tetapi tiga belas tahun kemudian, saya masih memikirkan surat itu. Kerana kadangkala saya menerima e-mel yang serupa daripada Google Cloud. Mereka kelihatan seperti ini:
Pengguna Awan Google yang dihormati,
Sebagai peringatan, kami akan menghentikan perkhidmatan [perkhidmatan penting yang anda gunakan] mulai Ogos 2020, selepas itu anda tidak akan dapat meningkatkan kejadian anda. Kami mengesyorkan anda menaik taraf kepada versi terkini, yang dalam ujian beta, tidak mempunyai dokumentasi, tiada laluan migrasi dan sebelum ini sudah lapuk dengan bantuan baik kami.
Kami komited untuk memastikan bahawa perubahan ini mempunyai kesan yang minimum kepada semua pengguna platform Google Cloud.
Kawan baik selamanya,
Platform Awan Google
Tetapi saya hampir tidak pernah membaca surat sedemikian, kerana apa yang sebenarnya mereka katakan ialah:
Penerima yang dihormati,
Pergi ke neraka. Jahat awak, jahanam awak, jahanam awak. Tinggalkan semua yang anda lakukan kerana ia tidak penting. Yang penting masa kita. Kami membuang masa dan wang untuk mengekalkan omong kosong kami dan kami bosan dengannya jadi kami tidak akan menyokongnya lagi. Oleh itu, berhenti dari rancangan jahat anda dan mulalah menggali dokumentasi buruk kami, meminta sisa-sisa di forum, dan omong-omong, omong kosong kami yang baru benar-benar berbeza daripada omong kosong lama, kerana kami mengacaukan reka bentuk ini dengan sangat teruk, heh, tetapi itulah anda masalah, bukan kita.
Kami terus berusaha untuk memastikan semua pembangunan anda tidak dapat digunakan dalam tempoh satu tahun.
Tolong bercinta
Platform Awan Google
Dan hakikatnya saya menerima surat sedemikian kira-kira sebulan sekali. Ini berlaku begitu kerap dan berterusan sehingga tidak dapat dielakkan ditolak jauh saya dari GCP ke kem anti-awan. Saya tidak lagi bersetuju untuk bergantung pada perkembangan proprietari mereka, kerana sebenarnya lebih mudah bagi devops untuk mengekalkan sistem sumber terbuka pada mesin maya kosong daripada cuba mengikuti Google dengan dasar menutup produk "lapuk".
Sebelum saya kembali ke Google Cloud kerana saya tak dekat pun belum selesai mengkritik mereka, mari kita lihat prestasi syarikat dalam beberapa bidang lain. Jurutera Google berbangga dengan disiplin kejuruteraan perisian mereka, dan inilah yang sebenarnya menyebabkan masalah. Kebanggaan adalah perangkap bagi mereka yang tidak berhati-hati, dan ia telah menyebabkan ramai pekerja Google berfikir bahawa keputusan mereka sentiasa betul dan bahawa menjadi betul (mengikut beberapa definisi kabur yang tidak jelas) adalah lebih penting daripada mengambil berat tentang pelanggan.
Saya akan memberikan beberapa contoh rawak daripada projek besar lain di luar Google, tetapi saya harap anda melihat corak ini di mana-mana sahaja. Ia adalah seperti berikut: keserasian ke belakang memastikan sistem hidup dan terkini selama beberapa dekad.
Keserasian ke belakang ialah matlamat reka bentuk semua sistem yang berjaya direka bentuk terbuka penggunaan, iaitu, dilaksanakan dengan kod sumber terbuka dan/atau piawaian terbuka. Saya rasa seperti saya mengatakan sesuatu yang terlalu jelas sehingga semua orang berasa tidak selesa, tetapi tidak. Ini adalah isu politik, jadi contoh diperlukan.
Sistem pertama yang akan saya pilih ialah yang tertua: GNU Emacs, yang merupakan sejenis hibrid antara Windows Notepad, kernel OS dan Stesen Angkasa Antarabangsa. Agak sukar untuk dijelaskan, tetapi secara ringkasnya, Emacs ialah platform yang dicipta pada tahun 1976 (ya, hampir setengah abad yang lalu) untuk pengaturcaraan menjadikan anda lebih produktif, tetapi menyamar sebagai editor teks.
Saya menggunakan Emacs setiap hari. Ya, saya juga menggunakan IntelliJ setiap hari, ia telah berkembang menjadi platform perkakas yang berkuasa dengan cara tersendiri. Tetapi menulis sambungan untuk IntelliJ adalah tugas yang jauh lebih bercita-cita tinggi dan kompleks daripada menulis sambungan untuk Emacs. Dan yang lebih penting, semua yang ditulis untuk Emacs dipelihara selamanya.
Saya masih menggunakan perisian yang saya tulis untuk Emacs pada tahun 1995. Dan saya pasti seseorang menggunakan modul yang ditulis untuk Emacs pada pertengahan 80-an, jika tidak lebih awal. Mereka mungkin memerlukan sedikit tweak dari semasa ke semasa, tetapi ini benar-benar jarang berlaku. Saya tidak tahu apa-apa yang pernah saya tulis untuk Emacs (dan saya telah menulis banyak) yang memerlukan seni bina semula.
Emacs mempunyai fungsi yang dipanggil make-obsolete untuk entiti usang. Terminologi Emacs untuk konsep komputer asas (seperti apa itu "tetingkap") selalunya berbeza daripada konvensyen industri kerana Emacs telah memperkenalkannya sejak lama dahulu. Ini adalah bahaya biasa bagi mereka yang mendahului masa mereka: semua syarat anda tidak betul. Tetapi Emacs mempunyai konsep penamatan, yang dalam jargon mereka dipanggil Usang.
Tetapi dalam dunia Emacs nampaknya terdapat definisi kerja yang berbeza. Falsafah asas yang berbeza, jika anda mahu.
Dalam dunia Emacs (dan banyak kawasan lain yang akan kami bincangkan di bawah), status API yang tidak digunakan pada asasnya bermaksud: "Anda tidak sepatutnya menggunakan pendekatan ini kerana, semasa ia berfungsi, ia mengalami pelbagai kekurangan yang akan kami senaraikan di sini. Tetapi pada penghujung hari, itu adalah pilihan anda."
Di dunia Google, menjadi usang bermakna, "Kami melanggar komitmen kami kepada anda." Ini adalah benar. Inilah maksud asasnya. Ini bermakna mereka akan memaksa anda kerap melakukan beberapa kerja, mungkin banyak kerja, sebagai hukuman kerana mempercayai mereka : Kami mempunyai perisian terbaik. Yang terpantas! Anda melakukan segala-galanya mengikut arahan, melancarkan aplikasi atau perkhidmatan anda, dan kemudian bam, selepas satu atau dua tahun ia rosak.
Ibarat menjual kereta terpakai yang pasti rosak selepas 1500 km.
Ini adalah dua definisi falsafah yang sama sekali berbeza tentang "keusangan." Definisi bau Google . Saya tidak percaya ini sebenarnya keusangan yang dirancang dalam erti kata yang sama seperti Apple. Tetapi Google pasti merancang untuk memecahkan program anda, dengan cara yang bulat. Saya tahu ini kerana saya bekerja di sana sebagai jurutera perisian selama lebih 12 tahun. Mereka mempunyai garis panduan dalaman yang samar-samar tentang berapa banyak keserasian ke belakang yang perlu diikuti, tetapi akhirnya terpulang kepada setiap pasukan atau perkhidmatan individu. Tiada pengesyoran peringkat perusahaan atau kejuruteraan, dan pengesyoran paling berani dari segi kitaran usang ialah "cuba beri pelanggan 6-12 bulan untuk menaik taraf sebelum memecahkan keseluruhan sistem mereka."
Masalahnya jauh lebih besar daripada yang mereka fikirkan, dan ia akan berterusan selama bertahun-tahun akan datang kerana penjagaan pelanggan tiada dalam DNA mereka. Lebih lanjut mengenai perkara ini di bawah.
Pada ketika ini saya akan membuat kenyataan yang berani bahawa Emacs berjaya pada tahap yang besar dan sekata kebanyakannya kerana mereka memandang serius keserasian ke belakang. Sebenarnya, ini adalah tesis artikel kami. Sistem terbuka yang berjaya dan bertahan lama berhutang kejayaan mereka kepada komuniti mikro yang telah hidup di sekeliling mereka selama beberapa dekad sambungan/pemalam. Ini adalah ekosistem. Saya telah pun bercakap tentang sifat platform dan betapa pentingnya platform tersebut, dan bagaimana Google tidak pernah sepanjang sejarah korporatnya memahami perkara yang perlu dilakukan untuk mencipta platform terbuka yang berjaya di luar Android atau Chrome.
Sebenarnya, saya harus menyebut Android secara ringkas kerana anda mungkin memikirkannya.
Pertama, Android bukan Google. Mereka hampir tiada persamaan antara satu sama lain. Android ialah sebuah syarikat yang telah dibeli oleh Google pada Julai 2005, syarikat itu dibenarkan untuk beroperasi lebih kurang secara autonomi dan sebenarnya sebahagian besarnya tidak disentuh pada tahun-tahun berikutnya. Android ialah timbunan teknologi terkenal dan organisasi berduri yang sama terkenal. Seperti yang dikatakan oleh seorang Googler, "Anda tidak boleh log masuk ke Android sahaja."
Dalam artikel sebelumnya, saya membincangkan betapa buruknya beberapa keputusan reka bentuk awal Android. Heck, apabila saya menulis artikel itu mereka melancarkan omong kosong yang dipanggil "aplikasi segera" yang kini (mengejutkan!) , dan saya bersimpati jika anda cukup bodoh untuk mendengar Google dan mengalihkan kandungan anda ke apl segera ini.
Tetapi terdapat perbezaan di sini, perbezaan yang ketara, iaitu orang Android benar-benar memahami betapa pentingnya platform, mereka cuba sedaya upaya untuk memastikan apl Android lama berfungsi. Malah, usaha mereka untuk mengekalkan keserasian ke belakang adalah sangat melampau sehinggakan saya, semasa saya berkhidmat ringkas di bahagian Android beberapa tahun lalu, mendapati diri saya cuba meyakinkan mereka untuk menggugurkan sokongan untuk beberapa peranti dan API tertua (saya silap , seperti dalam banyak perkara lain dahulu dan sekarang. Maaf kawan-kawan Android! Sekarang saya sudah ke Indonesia, saya faham mengapa kita memerlukannya).
Orang Android menolak keserasian ke belakang kepada keterlaluan yang hampir tidak dapat dibayangkan, mengumpul sejumlah besar hutang teknikal warisan dalam sistem dan rantai alat mereka. Ya Tuhanku, anda sepatutnya melihat beberapa perkara gila yang perlu mereka lakukan dalam sistem binaan mereka, semuanya atas nama keserasian.
Untuk ini, saya menganugerahkan Android anugerah "You're Not Google" yang diidamkan. Mereka benar-benar tidak mahu menjadi Google, yang tidak tahu cara mencipta platform tahan lama, tetapi Android tahu, bagaimana hendak melakukannya. Oleh itu, Google sangat bijak dalam satu aspek: membenarkan orang ramai melakukan perkara dengan cara mereka sendiri pada Android.
Walau bagaimanapun, aplikasi segera untuk Android adalah idea yang agak bodoh. Dan adakah anda tahu mengapa? Kerana mereka menuntut tulis semula dan reka bentuk semula aplikasi anda! Seolah-olah orang hanya akan menulis semula dua juta aplikasi. Saya rasa Apl Segera adalah idea Googler.
Tetapi ada perbezaan. Keserasian ke belakang datang pada kos yang tinggi. Android sendiri menanggung beban kos ini, manakala Google menegaskan bahawa beban itu ditanggung Π²Ρ, pelanggan yang membayar.
Anda boleh melihat komitmen Android terhadap keserasian ke belakang dalam APInya. Apabila anda mempunyai empat atau lima subsistem yang berbeza melakukan perkara yang sama secara literal, ini adalah petanda pasti bahawa terdapat komitmen terhadap keserasian ke belakang pada terasnya. Yang dalam dunia platform adalah sinonim dengan komitmen kepada pelanggan anda dan pasaran anda.
Masalah utama Google di sini ialah kebanggaan mereka dalam kebersihan kejuruteraan mereka. Mereka tidak suka apabila terdapat banyak cara berbeza untuk melakukan perkara yang sama, dengan cara lama yang kurang diingini duduk bersebelahan dengan cara baharu yang lebih menarik. Ia meningkatkan keluk pembelajaran bagi mereka yang baharu kepada sistem, ia meningkatkan beban mengekalkan API warisan, ia memperlahankan kelajuan ciri baharu, dan dosa utamanya ialah ia tidak cantik. Google - seperti Lady Ascot dari Alice in Wonderland karya Tim Burton:
Lady Ascot:
- Alice, adakah anda tahu apa yang paling saya takuti?
- Kemerosotan golongan bangsawan?
- Saya takut bahawa saya akan mempunyai cucu hodoh.
Untuk memahami pertukaran antara cantik dan praktikal, mari kita lihat pada platform ketiga yang berjaya (selepas Emacs dan Android) dan lihat cara ia berfungsi: Java itu sendiri.
Java mempunyai banyak API yang sudah lapuk. Penamatan sangat popular di kalangan pengaturcara Java, malah lebih popular daripada kebanyakan bahasa pengaturcaraan. Java sendiri, bahasa teras dan perpustakaan sentiasa menafikan API.
Untuk mengambil hanya satu daripada beribu-ribu contoh, dianggap usang. Ia telah ditamatkan sejak dikeluarkan Java 1.2 pada Disember 1998. Sudah 22 tahun sejak ini ditamatkan.
Tetapi kod sebenar saya dalam pengeluaran masih membunuh benang setiap hari. Adakah anda benar-benar fikir itu bagus? Sudah tentu! Maksud saya, sudah tentu, jika saya menulis semula kod hari ini, saya akan melaksanakannya secara berbeza. Tetapi kod untuk permainan saya, yang telah menggembirakan ratusan ribu orang sejak dua dekad yang lalu, ditulis dengan fungsi untuk menutup benang yang tergantung terlalu lama, dan saya tidak pernah perlu mengubahnya. Saya tahu sistem saya lebih baik daripada sesiapa sahaja, saya mempunyai pengalaman selama 25 tahun bekerja dengannya dalam pengeluaran, dan saya boleh mengatakan dengan pasti: dalam kes saya, menutup rangkaian pekerja khusus ini sepenuhnya tidak bernilai. Ia tidak berbaloi dengan masa dan usaha untuk menulis semula kod ini, dan terima kasih kepada Larry Ellison (mungkin) bahawa Oracle tidak memaksa saya untuk menulis semula kod ini.
Oracle mungkin juga memahami platform. Siapa tahu.
Bukti boleh didapati di seluruh API Java teras, yang penuh dengan gelombang keusangan, seperti garisan glasier di ngarai. Anda boleh mencari lima atau enam pengurus navigasi papan kekunci yang berbeza (KeyboardFocusManager) dengan mudah dalam perpustakaan Java Swing. Sebenarnya sukar untuk mencari API Java yang tidak ditamatkan. Tetapi mereka masih bekerja! Saya rasa pasukan Java hanya akan benar-benar mengalih keluar API jika antara muka menimbulkan isu keselamatan yang ketara.
Inilah perkaranya, kawan-kawan: Kami pembangun perisian semuanya sangat sibuk, dan dalam setiap bidang perisian kami berhadapan dengan alternatif yang bersaing. Pada bila-bila masa, pengaturcara dalam bahasa X sedang mempertimbangkan bahasa Y sebagai pengganti yang mungkin. Oh, awak tidak percaya saya? Adakah anda mahu memanggilnya Swift? Seperti, semua orang berhijrah ke Swift dan tiada siapa yang meninggalkannya, bukan? Wow, betapa sedikit yang anda tahu. Syarikat sedang mengira kos pasukan pembangunan dwi mudah alih (iOS dan Android) - dan mereka mula menyedari bahawa sistem pembangunan merentas platform dengan nama lucu seperti Flutter dan React Native sebenarnya berfungsi dan boleh digunakan untuk mengurangkan saiz mereka. pasukan mudah alih dua kali atau, sebaliknya, menjadikan mereka dua kali lebih produktif. Terdapat wang sebenar yang dipertaruhkan. Ya, ada kompromi, tetapi, sebaliknya, wang.
Mari kita anggap secara hipotesis bahawa Apple secara bodoh mengambil isyarat daripada Guido van Rossum dan mengisytiharkan bahawa Swift 6.0 tidak serasi ke belakang dengan Swift 5.0, sama seperti Python 3 tidak serasi dengan Python 2.
Saya mungkin menceritakan kisah ini kira-kira sepuluh tahun yang lalu, tetapi kira-kira lima belas tahun yang lalu saya pergi ke O'Reilly's Foo Camp bersama Guido, duduk dalam khemah bersama Paul Graham dan sekumpulan gambar besar. Kami duduk dalam panas terik menunggu Larry Page untuk terbang keluar dengan helikopter peribadinya manakala Guido berdengung tentang "Python 3000," yang dia namakan selepas bilangan tahun yang diperlukan untuk semua orang berhijrah ke sana. Kami terus bertanya kepadanya mengapa dia melanggar keserasian, dan dia menjawab: "Unicode." Dan kami bertanya, jika kami perlu menulis semula kod kami, apakah faedah lain yang akan kami lihat? Dan dia menjawab "Yoooooooooooouuuuuuuuniiiiiiiiiiioooooooode."
Jika anda memasang Google Cloud Platform SDK (βgcloudβ), anda akan menerima pemberitahuan berikut:
Penerima yang dihormati,
Kami ingin mengingatkan anda bahawa sokongan untuk Python 2 telah ditamatkan, jadi persetankan anda
β¦ dan sebagainya. Bulatan kehidupan.
Tetapi maksudnya ialah setiap pemaju mempunyai pilihan. Dan jika anda memaksa mereka menulis semula kod dengan kerap, mereka mungkin memikirkannya lain pilihan. Mereka bukan tebusan anda, tidak kira betapa anda mahukan mereka. Mereka adalah tetamu anda. Python masih merupakan bahasa pengaturcaraan yang sangat popular, tetapi sial, Python 3(000) mencipta kekacauan itu sendiri, dalam komunitinya dan dalam kalangan pengguna komunitinya sehingga akibatnya tidak dapat diselesaikan selama lima belas tahun.
Berapa banyak program Python telah ditulis semula dalam Go (atau Ruby, atau beberapa alternatif lain) kerana ketidakserasian ke belakang ini? Berapa banyak perisian baharu telah ditulis dalam sesuatu selain Python, walaupun ia boleh jadi ditulis dalam Python, jika Guido tidak membakar seluruh kampung? Sukar untuk dikatakan, tetapi Python jelas menderita. Ia adalah kekacauan besar dan semua orang kalah.
Jadi, katakan Apple mengambil petunjuk daripada Guido dan memecahkan keserasian. Apa yang anda fikir akan berlaku seterusnya? Mungkin 80-90% pembangun akan menulis semula perisian mereka jika boleh. Dalam erti kata lain, 10-20% daripada pangkalan pengguna secara automatik pergi ke beberapa bahasa yang bersaing, seperti Flutter.
Lakukan ini beberapa kali dan anda akan kehilangan separuh pangkalan pengguna anda. Sama seperti dalam sukan, dalam dunia pengaturcaraan, bentuk semasa juga penting. semuanya. Sesiapa yang kehilangan separuh pengguna mereka dalam tempoh lima tahun akan dianggap sebagai Penghilang Lemak Besar. Anda mesti bergaya dalam dunia platform. Tetapi di sinilah tidak menyokong versi lama akan merosakkan anda dari semasa ke semasa. Kerana setiap kali anda menyingkirkan beberapa pembangun, anda (a) kehilangan mereka selama-lamanya kerana mereka marah kepada anda kerana melanggar kontrak, dan (b) memberikannya kepada pesaing anda.
Ironinya, saya turut membantu Google menjadi primadona yang mengabaikan keserasian ke belakang apabila saya mencipta Grok, sistem analisis dan pemahaman kod sumber yang memudahkan untuk mengautomasikan dan memperalatkan kod itu sendiri - serupa dengan IDE, tetapi di sini perkhidmatan awan disimpan. merealisasikan perwakilan semua berbilion baris kod sumber Google dalam gudang data yang besar.
Grok menyediakan Googler dengan rangka kerja yang berkuasa untuk melaksanakan pemfaktoran semula automatik merentas keseluruhan pangkalan kod mereka (secara harfiah di seluruh Google). Sistem mengira bukan sahaja kebergantungan huluan anda (yang anda bergantung), tetapi juga menurun (terpulang kepada anda) jadi apabila anda menukar API, anda tahu semua orang yang anda langgar! Dengan cara ini, apabila anda membuat perubahan, anda boleh mengesahkan bahawa setiap pengguna API anda telah mengemas kini kepada versi baharu, dan sebenarnya, selalunya dengan alat Rosie yang mereka tulis, anda boleh mengautomasikan sepenuhnya proses tersebut.
Ini membolehkan pangkalan kod Google secara dalaman hampir bersih secara ghaib, kerana mereka mempunyai pelayan robotik ini berkeliaran di sekitar rumah dan membersihkan semuanya secara automatik jika mereka menamakan semula SomeDespicablyLongFunctionName kepada SomeDespicablyLongMethodName kerana seseorang memutuskan bahawa ia adalah cucu yang hodoh dan dia perlu ditidurkan.
Dan terus terang, ia berfungsi dengan baik untuk Google... secara dalaman. Maksud saya, ya, komuniti Go di Google memang bergelak ketawa dengan komuniti Java di Google kerana tabiat mereka memfaktorkan semula secara berterusan. Jika anda memulakan semula sesuatu N kali, ini bermakna anda bukan sahaja mengacaukannya N-1 kali, tetapi selepas beberapa ketika ia menjadi agak jelas bahawa anda mungkin mengacaukannya pada percubaan Nth juga. Tetapi, pada umumnya, mereka tetap mengatasi semua kekecohan ini dan mengekalkan kod "bersih".
Masalahnya bermula apabila mereka cuba mengenakan sikap ini pada pelanggan awan mereka dan pengguna API lain.
Saya telah memperkenalkan anda sedikit kepada Emacs, Android dan Java; mari kita lihat platform terbaharu yang berjaya bertahan lama: Web itu sendiri. Bolehkah anda bayangkan berapa banyak lelaran yang telah dilalui oleh HTTP sejak 1995 apabila kami menggunakan teg berkelip? dan ikon "Dalam Pembinaan" pada halaman web.
Tetapi ia masih berfungsi! Dan halaman ini masih berfungsi! Ya, kawan-kawan, pelayar adalah juara dunia dalam keserasian ke belakang. Chrome ialah satu lagi contoh platform Google yang jarang berlaku yang telah dikacau dengan betul, dan seperti yang anda duga, Chrome berkesan beroperasi sebagai syarikat kotak pasir yang berasingan daripada Google yang lain.
Saya juga ingin mengucapkan terima kasih kepada rakan-rakan kami dalam pembangun sistem pengendalian: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, dll., kerana melakukan kerja yang hebat dalam keserasian ke belakang pada platform mereka yang berjaya (Apple mendapat C terbaik dengan The Kelemahannya ialah mereka memecahkan segala-galanya sepanjang masa tanpa sebab yang kukuh, tetapi entah bagaimana komuniti mengatasinya dengan setiap keluaran, dan bekas OS X masih belum usang sepenuhnya... lagi).
Tetapi tunggu, anda berkata. Bukankah kita membandingkan epal dengan oren - sistem perisian kendiri pada satu mesin seperti Emacs/JDK/Android/Chrome berbanding sistem berbilang pelayan dan API seperti perkhidmatan awan?
Baiklah, saya tweet tentang perkara ini semalam, tetapi dalam gaya Larry Wall (pencipta bahasa pengaturcaraan Perl - lebih kurang per.) pada prinsip "menghisap/peraturan" saya mencari perkataan itu deprecated di tapak pembangun Google dan Amazon. Dan walaupun AWS mempunyai beratus-ratus kali lebih banyak tawaran perkhidmatan daripada GCP, dokumentasi pembangun Google menyebut penamatan kira-kira tujuh kali lebih kerap.
Jika sesiapa di Google membaca ini, mereka mungkin bersedia untuk mengeluarkan carta gaya Donald Trump yang menunjukkan bahawa mereka sebenarnya melakukan segala-galanya dengan betul, dan bahawa saya tidak sepatutnya membuat perbandingan yang tidak adil seperti "bilangan sebutan perkataan yang tidak digunakan berbanding bilangan perkhidmatan" "
Tetapi selepas bertahun-tahun ini, Google Cloud masih menjadi perkhidmatan No. 3 (saya tidak pernah menulis artikel tentang percubaan gagal untuk menjadi No. 2), tetapi jika orang dalam boleh dipercayai, terdapat beberapa kebimbangan bahawa mereka mungkin tidak lama lagi. No 4.
Saya tidak mempunyai sebarang hujah yang menarik untuk "membuktikan" tesis saya. Apa yang saya ada hanyalah contoh berwarna-warni yang telah saya kumpulkan selama 30 tahun sebagai pemaju. Saya telah menyebut tentang sifat falsafah yang mendalam tentang masalah ini; dalam beberapa cara ia dipolitikkan dalam komuniti pemaju. Ada yang percaya itu pencipta platform harus mengambil berat tentang keserasian, manakala yang lain berpendapat bahawa ini adalah kebimbangan pengguna (pemaju sendiri). Satu daripada dua. Sememangnya, bukankah menjadi isu politik apabila kita memutuskan siapa yang harus menanggung kos masalah biasa?
Jadi ini adalah politik. Dan mungkin akan ada respon marah terhadap ucapan saya.
bagaimana pengguna Platform Awan Google, dan sebagai pengguna AWS selama dua tahun (semasa bekerja untuk Grab), saya boleh mengatakan bahawa terdapat perbezaan besar antara falsafah Amazon dan Google apabila ia berkaitan dengan keutamaan. Saya tidak membangunkan AWS secara aktif, jadi saya tidak tahu berapa kerap mereka mengalih keluar API lama. Tetapi terdapat syak wasangka bahawa ini tidak berlaku hampir sekerap di Google. Dan saya benar-benar percaya bahawa sumber kontroversi dan kekecewaan berterusan dalam GCP ini adalah salah satu faktor terbesar yang menghalang pembangunan platform.
Saya tahu bahawa saya tidak menamakan contoh khusus sistem GCP yang tidak lagi disokong. Saya boleh mengatakan bahawa hampir semua yang saya gunakan, daripada rangkaian (daripada yang paling lama kepada VPC) kepada storan (Cloud SQL v1-v2), Firebase (kini Firestore dengan API yang sama sekali berbeza), App Engine (jangan kita mulakan) , titik akhir awan Titik Akhir Awan dan sehingga... Saya tidak tahu - benar-benar semua ini memaksa anda untuk menulis semula kod selepas maksimum 2-3 tahun, dan mereka tidak pernah mengautomasikan penghijrahan untuk anda, dan selalunya . Seolah-olah ia sepatutnya begitu.
Dan setiap kali saya melihat AWS, saya bertanya kepada diri sendiri mengapa saya masih menggunakan GCP. Mereka jelas tidak memerlukan pelanggan. Mereka perlu ΠΏΠΎΠΊΡΠΏΠ°ΡΠ΅Π»ΠΈ. Adakah anda faham perbezaannya? Biar saya jelaskan.
Google Cloud mempunyai , di mana orang ramai mencadangkan penyelesaian perisian mereka, dan untuk mengelakkan kesan restoran kosong, mereka perlu mengisinya dengan beberapa cadangan, jadi mereka membuat kontrak dengan syarikat bernama Bitnami untuk mencipta sekumpulan penyelesaian yang digunakan dengan "satu klik", atau sepatutnya Saya menulis sendiri "penyelesaian," kerana ini tidak menyelesaikan masalah. Ia hanya wujud sebagai kotak pilihan, sebagai pengisi pemasaran, dan Google tidak pernah peduli sama ada mana-mana alat itu benar-benar berfungsi. Saya mengenali pengurus produk yang pernah berada di tempat duduk pemandu, dan saya boleh memberi jaminan kepada anda bahawa orang ini tidak peduli.
Ambil, sebagai contoh, penyelesaian penggunaan "satu klik" yang sepatutnya. . Saya sudah muak dengan penipuan Google Cloud SQL, jadi saya mula melihat untuk membina kelompok Percona saya sendiri sebagai alternatif. Dan kali ini Google nampaknya telah melakukan kerja yang baik, mereka akan menjimatkan masa dan usaha saya dengan satu klik butang!
Baiklah, mari kita pergi. Jom ikuti pautan dan klik butang ini. Pilih "Ya" untuk bersetuju menerima semua tetapan lalai dan menggunakan kluster dalam projek awan Google anda. Haha, ia tidak berfungsi. Tiada satu pun omong kosong ini berfungsi. Alat ini tidak pernah diuji dan ia mula reput dari minit pertama, dan ia tidak akan mengejutkan saya jika lebih daripada separuh daripada "penyelesaian" adalah penggunaan satu klik (kini kita faham mengapa petikan itu) secara umum tidak berfungsi. Ini adalah kegelapan yang tidak ada harapan, di mana lebih baik tidak masuk.
Tetapi Google betul nafsu anda untuk menggunakannya. Mereka mahu anda dibeli. Bagi mereka ia adalah satu transaksi. Mereka tidak mahu apa-apa sokongan. Ia bukan sebahagian daripada DNA Google. Ya, jurutera menyokong satu sama lain, seperti yang dibuktikan oleh cerita saya dengan Bigtable. Tetapi dalam produk dan perkhidmatan untuk orang biasa mereka sentiasa telah kejam masuk , yang tidak memenuhi syarat untuk keuntungan walaupun ia mempunyai berjuta-juta pengguna.
Dan ini memberikan cabaran sebenar untuk GCP kerana ini adalah DNA di sebalik semua tawaran awan. Mereka tidak cuba menyokong apa-apa; Umum mengetahui bahawa mereka enggan mengehoskan (sebagai perkhidmatan terurus) mana-mana perisian pihak ketiga sehingga, sehingga AWS melakukan perkara yang sama dan membina perniagaan yang berjaya di sekelilingnya, dan apabila pelanggan benar-benar menuntut perkara yang sama. Walau bagaimanapun, ia memerlukan sedikit usaha untuk mendapatkan Google menyokong sesuatu.
Kekurangan budaya sokongan ini, ditambah pula dengan mentaliti "mari kita patahkan untuk menjadikannya lebih cantik", mengasingkan pembangun.
Dan itu bukan perkara yang baik jika anda ingin membina platform yang tahan lama.
Google, bangun, sial. Sekarang dah 2020. Anda masih kalah. Sudah tiba masanya untuk melihat cermin dengan teliti dan menjawab sama ada anda benar-benar mahu kekal dalam perniagaan awan.
Jika anda mahu tinggal kemudian berhenti memecahkan segala-galanya. Lelaki, anda kaya. Kami pemaju tidak. Jadi apabila bercakap tentang siapa yang akan memikul beban keserasian, anda perlu memikulnya sendiri. Bukan untuk kita.
Kerana terdapat sekurang-kurangnya tiga awan yang sangat bagus. Mereka memberi isyarat.
Dan sekarang saya akan meneruskan untuk membaiki semua sistem saya yang rosak. Eh.
Sehingga kali seterusnya!
Kemas Kini PS selepas membaca beberapa perbincangan mengenai artikel ini (perbincangan adalah hebat, btw). Sokongan Firebase belum dihentikan dan tiada rancangan yang saya ketahui. Walau bagaimanapun, mereka mempunyai pepijat penstriman jahat yang menyebabkan pelanggan Java terhenti dalam App Engine. Salah seorang jurutera mereka membantu saya menyelesaikan masalah ini, semasa saya bekerja di Google, tetapi mereka tidak pernah betul-betul membetulkan pepijat itu, jadi saya mempunyai penyelesaian yang buruk untuk memulakan semula apl GAE setiap hari. Dan begitulah selama empat tahun! Mereka kini mempunyai Firestore. Ia akan mengambil banyak kerja untuk berhijrah kepadanya kerana ia adalah sistem yang sama sekali berbeza dan pepijat Firebase tidak akan dibetulkan. Apakah kesimpulan yang boleh dibuat? Anda boleh mendapatkan bantuan jika anda bekerja di syarikat. Saya mungkin satu-satunya yang menggunakan Firebase pada GAE kerana saya log kurang daripada 100 kunci dalam apl asli 100% dan ia berhenti berfungsi setiap beberapa hari disebabkan pepijat yang diketahui. Apa yang boleh saya katakan selain menggunakannya atas risiko anda sendiri. Saya beralih kepada Redis.
Saya juga telah melihat beberapa pengguna AWS yang lebih berpengalaman mengatakan bahawa AWS biasanya tidak pernah berhenti menyokong sebarang perkhidmatan, dan SimpleDB ialah contoh yang bagus. Andaian saya bahawa AWS tidak mempunyai penghujung penyakit sokongan yang sama seperti Google nampaknya wajar.
Selain itu, saya mendapati bahawa 20 hari yang lalu pasukan Google App Engine telah memecahkan pengehosan pustaka Go yang kritikal, menutup aplikasi GAE daripada salah satu pembangun teras Go. Ia benar-benar bodoh.
Akhirnya, saya telah mendengar Googler telah membincangkan isu ini dan secara amnya bersetuju dengan saya (sayang anda semua!). Tetapi mereka nampaknya berpendapat masalah itu tidak dapat diselesaikan kerana budaya Google tidak pernah mempunyai struktur insentif yang betul. Saya fikir adalah baik untuk mengambil sedikit masa untuk membincangkan pengalaman yang sangat menakjubkan yang saya alami bekerja dengan jurutera AWS semasa bekerja di Grab. Suatu hari nanti, saya harap!
Dan ya, pada tahun 2005 mereka mempunyai pelbagai jenis daging jerung di bufet gergasi di bangunan 43, dan kegemaran saya ialah daging jerung kepala tukul. Walau bagaimanapun, menjelang 2006, Larry dan Sergei menyingkirkan semua makanan ringan yang tidak sihat. Jadi semasa cerita Bigtable pada tahun 2007 memang tiada jerung dan saya menipu awak.
Apabila saya melihat awan Bigtable empat tahun lalu (beri atau terima), di sinilah kosnya. Nampaknya ia telah menurun sedikit sekarang, tetapi itu masih sangat besar untuk gudang data kosong, terutamanya kerana cerita pertama saya menunjukkan betapa tidak pentingnya meja besar kosong pada skala mereka.
Maaf kerana menyinggung perasaan komuniti Apple dan tidak berkata apa-apa yang baik tentang Microsoft dan lain-lain. Anda tidak apa-apa, saya sangat menghargai semua perbincangan yang telah dijana oleh artikel ini! Tetapi kadang-kadang anda perlu membuat gelombang sedikit untuk memulakan perbincangan, anda tahu?
Terima kasih untuk membaca.
Kemas kini 2, 19.08.2020/XNUMX/XNUMX. belang !
Kemas kini 3, 31.08.2020/2/2. Saya telah dihubungi oleh jurutera Google di Cloud Marketplace yang ternyata rakan lama saya. Dia ingin mengetahui sebab CXNUMXD tidak berfungsi, dan akhirnya kami mendapati bahawa ia adalah kerana saya telah membina rangkaian saya bertahun-tahun yang lalu, dan CXNUMXD tidak berfungsi pada rangkaian warisan kerana parameter subnet tiada dalam templatnya. Saya rasa yang terbaik untuk bakal pengguna GCP memastikan mereka mempunyai cukup pengetahuan jurutera di Google...
Sumber: www.habr.com