Sialan Google, aku tidak mau ngeblog lagi. Banyak sekali yang harus aku lakukan. Blogging membutuhkan waktu, tenaga dan kreativitas, yang dapat saya manfaatkan dengan baik: buku-buku saya, , permainan saya dan sebagainya. Tapi kamu sudah cukup membuatku kesal sehingga aku harus menulis ini.
Jadi mari kita selesaikan ini.
Izinkan saya memulai dengan cerita singkat namun instruktif sejak saya pertama kali bekerja di Google. Saya tahu saya telah mengatakan banyak hal buruk tentang Google akhir-akhir ini, namun saya merasa kesal ketika perusahaan saya sendiri sering kali membuat keputusan bisnis yang tidak kompeten. Pada saat yang sama, kita harus memberikan haknya: infrastruktur internal Google sungguh luar biasa, dapat dikatakan bahwa tidak ada yang lebih baik saat ini. Para pendiri Google adalah insinyur yang jauh lebih baik daripada saya, dan cerita ini hanya menegaskan fakta tersebut.
Pertama, sedikit latar belakang: Google memiliki teknologi penyimpanan data yang disebut . Ini adalah pencapaian teknis yang luar biasa, salah satu penyimpanan nilai kunci (K/V) yang “dapat diskalakan tanpa batas” pertama (jika bukan yang pertama): yang pada dasarnya merupakan awal dari NoSQL. Saat ini Bigtable masih bekerja dengan baik di ruang penyimpanan K/V yang agak ramai, namun pada saat itu (2005) sangat keren.
Satu hal yang lucu tentang Bigtable adalah mereka memiliki objek bidang kendali internal (sebagai bagian dari implementasi) yang disebut server tablet, dengan indeks besar, dan pada titik tertentu menjadi hambatan saat menskalakan sistem. Insinyur Bigtable bingung bagaimana menerapkan skalabilitas, dan tiba-tiba menyadari bahwa mereka dapat mengganti server tablet dengan penyimpanan Bigtable lainnya. Jadi Bigtable adalah bagian dari implementasi Bigtable. Fasilitas penyimpanan ini ada di semua tingkatan.
Detail menarik lainnya adalah untuk sementara waktu Bigtable menjadi populer dan ada di mana-mana di Google, dengan masing-masing tim memiliki repositori sendiri. Jadi pada salah satu pertemuan hari Jumat, Larry Page dengan santai bertanya sambil lalu: “Mengapa kita memiliki lebih dari satu Bigtable? Kenapa tidak satu saja?” Secara teori, satu penyimpanan seharusnya cukup untuk semua kebutuhan penyimpanan Google. Tentu saja, mereka tidak pernah membahas satu hal saja karena alasan pengembangan praktis (seperti konsekuensi dari potensi kegagalan), namun teorinya menarik. Satu gudang untuk seluruh Alam Semesta (Ngomong-ngomong, adakah yang tahu kalau Amazon melakukan ini dengan Sable-nya?)
Bagaimanapun, inilah ceritaku.
Saat itu, saya baru bekerja di Google selama lebih dari dua tahun, dan suatu hari saya menerima email dari tim teknik Bigtable yang isinya seperti ini:
Steve sayang,
Halo dari tim Bigtable. Kami ingin memberi tahu Anda bahwa di [nama pusat data] Anda menggunakan biner Bigtable yang sangat lama. Versi ini tidak lagi didukung dan kami ingin membantu Anda meningkatkan ke versi terbaru.
Harap beri tahu saya jika Anda dapat menjadwalkan waktu untuk bekerja sama dalam masalah ini.
Semua yang terbaik,
Tim Meja Besar
Di Google Anda mendapatkan banyak email, jadi sekilas saya membaca sesuatu seperti ini:
Penerima yang terhormat,
Halo dari beberapa tim. Kami ingin mengkomunikasikan itu bla bla bla bla bla. Bla bla bla bla bla bla, dan bla bla bla segera.
Harap beri tahu kami jika Anda dapat menjadwalkan waktu berharga Anda untuk bla bla bla.
Semua yang terbaik,
Semacam perintah
Aku hampir langsung menghapusnya, tapi di ujung kesadaranku, aku merasakan perasaan yang menyakitkan dan mengganggu tidak juga terlihat seperti surat resmi jelas, bahwa penerimanya salah karena saya tidak menggunakan Bigtable.
Tapi itu aneh.
Aku menghabiskan sisa hari itu bergantian memikirkan tentang pekerjaan dan jenis daging hiu apa yang akan dicoba di dapur mikro, yang setidaknya tiga di antaranya cukup dekat untuk dilempar dari tempat dudukku dengan lemparan biskuit yang tepat sasaran, tapi Pikiran untuk menulis tidak pernah membuatku merasa sedikit cemas.
Mereka dengan jelas menyebut namaku. Dan email tersebut dikirim ke alamat email saya, bukan ke alamat email orang lain, dan bukan cc: atau bcc:. Nadanya sangat pribadi dan jelas. Mungkin ini semacam kesalahan?
Akhirnya, rasa ingin tahu menguasai diri saya dan saya pergi untuk melihat konsol Borg di pusat data yang mereka sebutkan.
Dan tentu saja, saya mengelola penyimpanan BigTable. Maafkan aku, apa? Saya melihat isinya, dan wow! Itu dari inkubator Codelab yang saya ikuti selama minggu pertama saya di Google pada bulan Juni 2005. Codelab memaksa Anda menjalankan Bigtable untuk menulis beberapa nilai di sana, dan sepertinya saya tidak pernah menutup penyimpanan setelah itu. Itu masih berfungsi meskipun lebih dari dua tahun telah berlalu.
Ada beberapa aspek penting dalam cerita ini. Pertama, pekerjaan Bigtable sangat kecil pada skala Google sehingga hanya dua tahun kemudian seseorang menyadari adanya penyimpanan tambahan, dan hanya karena versi binernya sudah ketinggalan zaman. Sebagai perbandingan, saya pernah mempertimbangkan untuk menggunakan untuk permainan daringku. Pada saat itu, biaya layanan ini sekitar $16 per tahun. kosong Meja besar di GCP. Aku tidak bilang mereka menipumu, tapi menurut pendapat pribadiku, itu adalah jumlah uang yang banyak untuk database yang kosong.
Aspek penting lainnya adalah penyimpanan masih bekerja setelah dua tahun. Apa? Pusat data datang dan pergi; mereka mengalami pemadaman, mereka menjalani pemeliharaan terjadwal, mereka berubah setiap saat. Perangkat keras diperbarui, sakelar ditukar, semuanya terus ditingkatkan. Bagaimana mereka bisa menjaga program saya tetap berjalan selama dua tahun dengan semua perubahan ini? Hal ini mungkin tampak seperti pencapaian biasa pada tahun 2020, namun pada tahun 2005-2007 pencapaian ini cukup mengesankan.
Dan aspek yang paling menakjubkan adalah tim teknik luar di negara bagian lain mendekati saya, pemilik Bigtable yang kecil dan hampir kosong, yang telah lalu lintas nol selama dua tahun terakhir - dan menawarkan bantuan untuk memperbaruinya.
Saya berterima kasih kepada mereka, menghapus penyimpanannya, dan hidup berjalan seperti biasa. Namun tiga belas tahun kemudian, saya masih memikirkan surat itu. Karena terkadang saya menerima email serupa dari Google Cloud. Mereka terlihat seperti ini:
Pengguna Google Cloud yang terhormat,
Sebagai pengingat, kami akan menghentikan layanan [layanan penting yang Anda gunakan] mulai Agustus 2020, setelah itu Anda tidak akan dapat meningkatkan instans Anda. Kami menyarankan untuk meningkatkan ke versi terbaru, yang masih dalam pengujian beta, tidak memiliki dokumentasi, tidak ada jalur migrasi, dan sudah ketinggalan zaman dengan bantuan kami.
Kami berkomitmen untuk memastikan bahwa perubahan ini memiliki dampak minimal terhadap semua pengguna platform Google Cloud.
Sahabat Selamanya,
Google Cloud Platform
Tapi saya hampir tidak pernah membaca surat seperti itu, karena sebenarnya isinya adalah:
Penerima yang terhormat,
Pergi ke neraka. Persetan denganmu, persetan denganmu, persetan denganmu. Hentikan semua yang Anda lakukan karena itu tidak masalah. Yang penting adalah waktu kita. Kita membuang-buang waktu dan uang untuk mempertahankan omong kosong kita dan kita sudah bosan sehingga kita tidak akan mendukungnya lagi. Jadi hentikan rencanamu dan mulailah menggali dokumentasi jelek kami, meminta potongan di forum, dan ngomong-ngomong, konten baru kami benar-benar berbeda dari konten lama, karena kami mengacaukan desain ini dengan sangat buruk, heh, tapi itu milikmu masalah, bukan masalah kita.
Kami terus melakukan upaya untuk memastikan bahwa semua pengembangan Anda menjadi tidak dapat digunakan dalam waktu satu tahun.
Tolong pergilah
Google Cloud Platform
Dan faktanya saya menerima surat seperti itu sebulan sekali. Hal ini terjadi begitu sering dan terus-menerus sehingga tidak bisa dihindari didorong menjauh saya dari GCP ke kamp anti-cloud. Saya tidak lagi setuju untuk bergantung pada pengembangan milik mereka, karena pada kenyataannya lebih mudah bagi pengembang untuk memelihara sistem sumber terbuka pada mesin virtual daripada mencoba mengikuti kebijakan Google untuk menutup produk "ketinggalan jaman".
Sebelum saya kembali ke Google Cloud karena saya bahkan dekat Belum selesai mengkritik mereka, mari kita lihat kinerja perusahaan di beberapa bidang lainnya. Insinyur Google bangga dengan disiplin rekayasa perangkat lunak mereka, dan inilah yang sebenarnya menimbulkan masalah. Kesombongan adalah jebakan bagi mereka yang tidak waspada, dan hal ini menyebabkan banyak karyawan Google berpikir bahwa keputusan mereka selalu benar dan bahwa menjadi benar (menurut definisi yang tidak jelas) lebih penting daripada kepedulian terhadap pelanggan.
Saya akan memberikan beberapa contoh acak dari proyek besar lainnya di luar Google, tapi saya harap Anda melihat pola ini di mana-mana. Ini adalah sebagai berikut: kompatibilitas ke belakang membuat sistem tetap hidup dan mutakhir selama beberapa dekade.
Kompatibilitas ke belakang adalah tujuan desain dari semua sistem sukses yang dirancang terbuka penggunaannya, yaitu diimplementasikan dengan kode sumber terbuka dan/atau standar terbuka. Saya merasa seperti saya mengatakan sesuatu yang terlalu jelas sehingga semua orang merasa tidak nyaman, tetapi tidak. Ini persoalan politik, jadi perlu ada contoh.
Sistem pertama yang saya pilih adalah yang tertua: GNU Emacs, yang merupakan gabungan antara Windows Notepad, kernel OS, dan Stasiun Luar Angkasa Internasional. Agak sulit untuk dijelaskan, tapi singkatnya, Emacs adalah platform yang dibuat pada tahun 1976 (ya, hampir setengah abad yang lalu) untuk pemrograman agar Anda lebih produktif, namun menyamar sebagai editor teks.
Saya menggunakan Emacs setiap hari. Ya, saya juga menggunakan IntelliJ setiap hari, IntelliJ telah berkembang menjadi platform perkakas yang kuat. Namun menulis ekstensi untuk IntelliJ adalah tugas yang jauh lebih ambisius dan kompleks dibandingkan menulis ekstensi untuk Emacs. Dan yang lebih penting, semua yang ditulis untuk Emacs dipertahankan selamanya.
Saya masih menggunakan perangkat lunak yang saya tulis untuk Emacs pada tahun 1995. Dan saya yakin seseorang menggunakan modul yang ditulis untuk Emacs pada pertengahan tahun 80an, jika tidak lebih awal. Mereka mungkin memerlukan sedikit penyesuaian dari waktu ke waktu, tetapi ini sangat jarang terjadi. Saya tidak tahu apa pun yang pernah saya tulis untuk Emacs (dan saya sudah banyak menulis) yang memerlukan arsitektur ulang.
Emacs memiliki fungsi yang disebut make-obsolete untuk entitas yang sudah usang. Terminologi Emacs untuk konsep dasar komputer (seperti apa itu "jendela") sering kali berbeda dari konvensi industri karena Emacs telah memperkenalkannya sejak lama. Ini adalah bahaya umum bagi mereka yang mendahului zamannya: semua persyaratan Anda salah. Namun Emacs memang memiliki konsep deprecation, yang dalam jargonnya disebut keusangan.
Namun di dunia Emacs sepertinya ada definisi kerja yang berbeda. Filosofi mendasar yang berbeda, jika Anda mau.
Di dunia Emacs (dan di banyak area lainnya, yang akan kita bahas di bawah), status API yang tidak digunakan lagi pada dasarnya berarti: "Anda sebaiknya tidak menggunakan pendekatan ini, karena meskipun berhasil, pendekatan ini memiliki berbagai kekurangan yang akan kami gunakan. daftar di sini. Namun pada akhirnya, itu adalah pilihanmu."
Di dunia Google, menjadi usang berarti, "Kami melanggar komitmen kami kepada Anda." Ini benar. Inilah arti dasarnya. Artinya mereka akan memaksa Anda secara teratur melakukan beberapa pekerjaan, mungkin banyak pekerjaan, sebagai hukuman karena mempercayainya : Kami memiliki perangkat lunak terbaik. Tercepat! Anda melakukan segalanya sesuai dengan instruksi, meluncurkan aplikasi atau layanan Anda, dan kemudian gagal, setelah satu atau dua tahun rusak.
Ibarat menjual mobil bekas yang pasti mogok setelah menempuh jarak 1500 km.
Ini adalah dua definisi filosofis yang sangat berbeda tentang “keusangan”. Definisi Google tentang bau . Saya tidak percaya ini sebenarnya keusangan yang direncanakan dalam arti yang sama seperti Apple. Namun Google pasti berencana untuk menghancurkan program Anda secara tidak langsung. Saya mengetahui hal ini karena saya bekerja di sana sebagai insinyur perangkat lunak selama lebih dari 12 tahun. Mereka memiliki pedoman internal yang tidak jelas mengenai seberapa banyak kompatibilitas ke belakang harus diikuti, namun pada akhirnya tergantung pada masing-masing tim atau layanan. Tidak ada rekomendasi tingkat perusahaan atau teknik, dan rekomendasi paling berani dalam hal siklus keusangan adalah “mencoba memberi pelanggan waktu 6-12 bulan untuk melakukan upgrade sebelum merusak seluruh sistem mereka.”
Masalahnya jauh lebih besar daripada yang mereka kira, dan masalah ini akan terus berlanjut selama bertahun-tahun yang akan datang karena layanan pelanggan tidak ada dalam DNA mereka. Lebih lanjut tentang ini di bawah.
Pada titik ini saya akan membuat pernyataan yang berani bahwa Emacs sangat sukses dan merata kebanyakan karena mereka menganggap serius kompatibilitas ke belakang. Sebenarnya ini adalah tesis artikel kami. Sistem terbuka yang sukses dan berumur panjang berutang keberhasilannya kepada komunitas mikro yang telah hidup di sekitarnya selama beberapa dekade ekstensi/plugin. Inilah ekosistemnya. Saya telah membicarakan tentang sifat platform dan betapa pentingnya platform tersebut, dan bagaimana Google sepanjang sejarah perusahaannya tidak pernah memahami apa yang diperlukan untuk menciptakan platform terbuka yang sukses di luar Android atau Chrome.
Sebenarnya, saya harus menyebutkan Android secara singkat karena Anda mungkin sedang memikirkannya.
Pertama, Android bukan Google. Mereka hampir tidak memiliki kesamaan satu sama lain. Android adalah perusahaan yang dibeli oleh Google pada bulan Juli 2005, perusahaan tersebut diizinkan untuk beroperasi kurang lebih secara mandiri dan pada kenyataannya sebagian besar tetap tidak tersentuh pada tahun-tahun berikutnya. Android adalah tumpukan teknologi terkenal dan organisasi yang sama-sama terkenal kejamnya. Seperti yang dikatakan oleh salah satu Googler, “Anda tidak bisa masuk ke Android begitu saja.”
Pada artikel sebelumnya, saya membahas betapa buruknya beberapa keputusan desain awal Android. Heck, ketika saya menulis artikel itu mereka meluncurkan omong kosong yang disebut "aplikasi instan" yang sekarang (kejutan!) , dan saya bersimpati jika Anda cukup bodoh untuk mendengarkan Google dan memindahkan konten Anda ke aplikasi instan ini.
Namun ada perbedaan disini, perbedaan yang signifikan, yaitu masyarakat Android sangat memahami betapa pentingnya platform, mereka berusaha semaksimal mungkin untuk menjaga aplikasi Android lama tetap berfungsi. Faktanya, upaya mereka untuk mempertahankan kompatibilitas ke belakang sangat ekstrem sehingga bahkan saya, selama tugas singkat saya di divisi Android beberapa tahun yang lalu, mendapati diri saya mencoba meyakinkan mereka untuk menghentikan dukungan untuk beberapa perangkat dan API tertua (saya salah , seperti yang terjadi di banyak hal dulu dan sekarang. Maaf teman-teman Android! Sekarang saya sudah ke Indonesia, saya mengerti mengapa kita membutuhkannya).
Orang-orang Android mendorong kompatibilitas mundur ke tingkat ekstrem yang hampir tak terbayangkan, sehingga menumpuk sejumlah besar utang teknis lama dalam sistem dan rantai alat mereka. Ya Tuhan, Anda akan melihat beberapa hal gila yang harus mereka lakukan dalam sistem build mereka, semuanya atas nama kompatibilitas.
Untuk ini, saya memberi Android penghargaan "Anda Bukan Google" yang didambakan. Mereka sebenarnya tidak ingin menjadi Google yang tidak tahu cara membuat platform yang tahan lama, melainkan Android tahu, Bagaimana cara melakukannya. Jadi Google sangat cerdas dalam satu hal: memungkinkan orang melakukan berbagai hal dengan cara mereka sendiri di Android.
Namun, aplikasi instan untuk Android adalah ide yang sangat bodoh. Dan tahukah Anda alasannya? Karena mereka menuntut menulis ulang dan mendesain ulang aplikasi Anda! Seolah-olah orang akan menulis ulang dua juta aplikasi. Saya kira Aplikasi Instan adalah ide beberapa Googler.
Tapi ada perbedaan. Kompatibilitas ke belakang membutuhkan biaya yang tinggi. Android sendiri yang menanggung beban biaya ini, sementara Google bersikeras bahwa beban tersebut harus ditanggung вы, klien yang membayar.
Anda dapat melihat komitmen Android terhadap kompatibilitas mundur di API-nya. Ketika Anda memiliki empat atau lima subsistem berbeda yang melakukan hal yang sama, ini merupakan tanda pasti bahwa ada komitmen terhadap kompatibilitas ke belakang sebagai intinya. Yang mana dalam dunia platform identik dengan komitmen terhadap pelanggan dan pasar Anda.
Masalah utama Google di sini adalah kebanggaan mereka terhadap kebersihan tekniknya. Mereka tidak suka bila ada banyak cara berbeda untuk melakukan hal yang sama, dan cara-cara lama yang kurang diminati disandingkan dengan cara-cara baru yang lebih menarik. Hal ini meningkatkan kurva pembelajaran bagi mereka yang baru mengenal sistem ini, meningkatkan beban pemeliharaan API lama, memperlambat kecepatan fitur baru, dan dosa terbesarnya adalah hal ini tidak bagus. Google - seperti Lady Ascot dari Alice in Wonderland karya Tim Burton:
Nyonya Ascot:
- Alice, tahukah kamu apa yang paling aku takuti?
- Kemunduran aristokrasi?
- Aku takut aku akan melakukannya cucu jelek.
Untuk memahami perbedaan antara cantik dan praktis, mari kita lihat platform ketiga yang sukses (setelah Emacs dan Android) dan lihat cara kerjanya: Java itu sendiri.
Java memiliki banyak API yang ketinggalan jaman. Penghentian sangat populer di kalangan programmer Java, bahkan lebih populer daripada kebanyakan bahasa pemrograman. Java sendiri, bahasa inti, dan perpustakaan terus-menerus menghentikan penggunaan API.
Untuk mengambil satu saja dari ribuan contoh, dianggap usang. Sudah tidak digunakan lagi sejak rilis Java 1.2 pada bulan Desember 1998. Sudah 22 tahun sejak ini tidak digunakan lagi.
Tetapi kode saya yang sebenarnya dalam produksi masih mematikan thread setiap hari. Apakah menurut Anda itu bagus? Sangat! Maksud saya, tentu saja, jika saya menulis ulang kodenya hari ini, saya akan menerapkannya secara berbeda. Namun kode untuk permainan saya, yang telah membuat ratusan ribu orang bahagia selama dua dekade terakhir, ditulis dengan fungsi untuk menutup thread yang terlalu lama menggantung, dan saya tidak pernah harus mengubahnya. Saya mengetahui sistem saya lebih baik daripada siapa pun, saya memiliki 25 tahun pengalaman bekerja dengannya dalam produksi, dan saya dapat mengatakan dengan pasti: dalam kasus saya, menutup thread pekerja tertentu ini sepenuhnya tidak berbahaya. Tidak sepadan dengan waktu dan tenaga untuk menulis ulang kode ini, dan terima kasih kepada Larry Ellison (mungkin) karena Oracle tidak memaksa saya untuk menulis ulang.
Oracle mungkin juga memahami platform. Siapa tahu.
Bukti dapat ditemukan di seluruh inti Java API, yang penuh dengan gelombang keusangan, seperti garis gletser di ngarai. Anda dapat dengan mudah menemukan lima atau enam pengelola navigasi keyboard yang berbeda (KeyboardFocusManager) di perpustakaan Java Swing. Sebenarnya sulit untuk menemukan Java API yang tidak digunakan lagi. Tapi mereka masih bekerja! Saya pikir tim Java hanya akan benar-benar menghapus API jika antarmukanya menimbulkan masalah keamanan yang mencolok.
Begini masalahnya, teman-teman: Kami para pengembang perangkat lunak sangat sibuk, dan di setiap bidang perangkat lunak kami dihadapkan pada alternatif yang bersaing. Pada waktu tertentu, pemrogram dalam bahasa X mempertimbangkan bahasa Y sebagai kemungkinan penggantinya. Oh, kamu tidak percaya padaku? Apakah Anda ingin menyebutnya Swift? Misalnya, semua orang bermigrasi ke Swift dan tidak ada yang meninggalkannya, bukan? Wow, betapa sedikitnya yang Anda ketahui. Perusahaan menghitung biaya tim pengembangan seluler ganda (iOS dan Android) - dan mereka mulai menyadari bahwa sistem pengembangan lintas platform dengan nama lucu seperti Flutter dan React Native benar-benar berfungsi dan dapat digunakan untuk mengurangi ukuran tim mereka. tim mobile dua kali atau, sebaliknya, menjadikan mereka dua kali lebih produktif. Ada uang nyata yang dipertaruhkan. Ya, memang ada kompromi, tapi di sisi lain, ada uang.
Mari kita asumsikan secara hipotetis bahwa Apple dengan bodohnya mengambil petunjuk dari Guido van Rossum dan menyatakan bahwa Swift 6.0 tidak kompatibel dengan Swift 5.0, seperti halnya Python 3 tidak kompatibel dengan Python 2.
Saya mungkin menceritakan kisah ini sekitar sepuluh tahun yang lalu, tetapi sekitar lima belas tahun yang lalu saya pergi ke Kamp Foo O'Reilly bersama Guido, duduk di tenda bersama Paul Graham dan sekelompok orang hebat. Kami duduk di tengah panas terik menunggu Larry Page terbang dengan helikopter pribadinya sementara Guido mengoceh tentang “Python 3000,” yang dia beri nama berdasarkan jumlah tahun yang diperlukan bagi setiap orang untuk bermigrasi ke sana. Kami terus bertanya mengapa dia melanggar kompatibilitas, dan dia menjawab: “Unicode.” Dan kami bertanya, jika kami harus menulis ulang kode kami, manfaat apa lagi yang akan kami lihat? Dan dia menjawab “Yoooooooooooooouuuuuuuuniiiiiiiicoooooooode.”
Jika Anda memasang Google Cloud Platform SDK (“gcloud”), Anda akan menerima pemberitahuan berikut:
Penerima yang terhormat,
Kami ingin mengingatkan Anda bahwa dukungan untuk Python 2 sudah tidak digunakan lagi, jadi persetan
… dan seterusnya. Lingkaran kehidupan.
Tapi intinya setiap pengembang punya pilihan. Dan jika Anda memaksa mereka untuk menulis ulang kode cukup sering, mereka mungkin akan memikirkannya lain pilihan. Mereka bukanlah sandera Anda, tidak peduli seberapa besar Anda menginginkannya. Mereka adalah tamu Anda. Python masih merupakan bahasa pemrograman yang sangat populer, tapi sialnya, Python 3(000) menciptakan kekacauan dalam dirinya sendiri, dalam komunitasnya dan di antara para pengguna komunitasnya sehingga konsekuensinya belum terselesaikan selama lima belas tahun.
Berapa banyak program Python yang telah ditulis ulang di Go (atau Ruby, atau alternatif lain) karena ketidakcocokan ke belakang ini? Berapa banyak perangkat lunak baru yang telah ditulis selain Python bisa jadi ditulis dengan Python, jika Guido tidak membakar seluruh desa? Sulit untuk mengatakannya, tetapi Python jelas menderita. Ini kekacauan besar dan semua orang kalah.
Jadi katakanlah Apple mengambil petunjuk dari Guido dan merusak kompatibilitas. Menurutmu apa yang akan terjadi nanti? Mungkin 80-90% pengembang akan menulis ulang perangkat lunak mereka jika memungkinkan. Dengan kata lain, 10-20% basis pengguna secara otomatis beralih ke bahasa pesaing, seperti Flutter.
Lakukan ini berkali-kali dan Anda akan kehilangan separuh basis pengguna Anda. Sama seperti dalam olahraga, dalam dunia pemrograman, performa terkini juga penting. semua. Siapapun yang kehilangan separuh penggunanya dalam lima tahun akan dianggap sebagai Big Fat Loser. Anda harus trendi di dunia platform. Namun di sinilah tidak mendukung versi lama akan merusak Anda seiring waktu. Karena setiap kali Anda menyingkirkan beberapa pengembang, Anda (a) kehilangan mereka selamanya karena mereka marah kepada Anda karena melanggar kontrak, dan (b) memberikan mereka kepada pesaing Anda.
Ironisnya, saya juga membantu Google menjadi primadona yang mengabaikan kompatibilitas ke belakang ketika saya membuat Grok, sistem analisis dan pemahaman kode sumber yang memudahkan otomatisasi dan instrumen kode itu sendiri - mirip dengan IDE, tetapi di sini layanan cloud menyimpan representasi terwujud dari miliaran baris kode sumber Google di gudang data yang besar.
Grok memberi Googler kerangka kerja yang kuat untuk melakukan pemfaktoran ulang otomatis di seluruh basis kode mereka (secara harfiah di seluruh Google). Sistem tidak hanya menghitung ketergantungan upstream Anda (yang menjadi sandaran Anda), tetapi juga menurun (terserah Anda) jadi saat Anda mengubah API, Anda tahu semua orang yang Anda langgar! Dengan cara ini, saat Anda membuat perubahan, Anda dapat memverifikasi bahwa setiap konsumen API Anda telah memperbarui ke versi baru, dan pada kenyataannya, sering kali dengan alat Rosie yang mereka tulis, Anda dapat mengotomatiskan prosesnya sepenuhnya.
Hal ini memungkinkan basis kode Google menjadi hampir bersih secara internal, karena mereka memiliki pelayan robot yang berlarian di sekitar rumah dan secara otomatis membersihkan semuanya jika mereka mengganti nama SomeDespicablyLongFunctionName menjadi SomeDespicablyLongMethodName karena seseorang memutuskan bahwa itu adalah cucu yang jelek dan kebutuhannya untuk ditidurkan.
Dan sejujurnya, ini bekerja cukup baik untuk Google... secara internal. Maksud saya, ya, komunitas Go di Google tertawa terbahak-bahak dengan komunitas Java di Google karena kebiasaan mereka melakukan refactoring terus menerus. Jika Anda memulai ulang sesuatu sebanyak N kali, itu berarti Anda tidak hanya mengacaukannya sebanyak N-1 kali, namun setelah beberapa saat menjadi cukup jelas bahwa Anda mungkin juga mengacaukannya pada percobaan ke-N. Namun, pada umumnya, mereka tetap mengatasi semua keributan ini dan menjaga kode tetap “bersih”.
Masalahnya dimulai ketika mereka mencoba menerapkan sikap ini pada klien cloud dan pengguna API lain.
Saya telah memperkenalkan Anda sedikit pada Emacs, Android dan Java; mari kita lihat platform terbaru yang sukses dan berumur panjang: Web itu sendiri. Bisakah Anda bayangkan berapa banyak iterasi yang dilakukan HTTP sejak tahun 1995 ketika kami menggunakan tag flashing? dan ikon "Sedang Dibangun" di halaman web.
Tapi itu masih berhasil! Dan halaman ini masih berfungsi! Ya kawan, browser adalah juara dunia dalam kompatibilitas mundur. Chrome adalah contoh lain dari platform Google langka yang memiliki fungsi yang tepat, dan seperti yang sudah Anda duga, Chrome secara efektif beroperasi sebagai perusahaan sandbox yang terpisah dari Google lainnya.
Saya juga ingin berterima kasih kepada teman-teman kami di pengembang sistem operasi: Windows, Linux, BUKAN APPLE FUCK YOU APPLE, FreeBSD, dll., karena telah melakukan pekerjaan kompatibilitas mundur yang luar biasa pada platform mereka yang sukses (Apple mendapatkan nilai terbaik C dengan The kelemahannya adalah mereka selalu merusak segalanya tanpa alasan yang jelas, namun entah bagaimana komunitas menyiasatinya dengan setiap rilis, dan container OS X masih belum sepenuhnya usang...).
Tapi tunggu, katamu. Bukankah kita membandingkan apel dengan jeruk - sistem perangkat lunak mandiri pada satu mesin seperti Emacs/JDK/Android/Chrome versus sistem multi-server dan API seperti layanan cloud?
Baiklah, saya men-tweet tentang ini kemarin, tetapi dengan gaya Larry Wall (pencipta bahasa pemrograman Perl - kira-kira per.) dengan prinsip "sucks/rules" saya mencari kata tersebut usang di situs pengembang Google dan Amazon. Dan meskipun AWS punya ratusan penawaran layanan kali lebih banyak dibandingkan GCP, dokumentasi developer Google menyebutkan penghentian layanan sekitar tujuh kali lebih sering.
Jika ada orang di Google yang membaca ini, mereka mungkin siap untuk mengeluarkan grafik gaya Donald Trump yang menunjukkan bahwa mereka benar-benar melakukan segalanya dengan benar, dan bahwa saya tidak boleh membuat perbandingan yang tidak adil seperti "jumlah penyebutan kata tidak digunakan lagi versus jumlah layanan" "
Namun setelah bertahun-tahun, Google Cloud masih menjadi layanan No. 3 (saya tidak pernah menulis artikel tentang upaya yang gagal untuk menjadi No. 2), namun jika orang dalam dapat mempercayainya, ada beberapa kekhawatiran bahwa layanan tersebut akan segera turun ke layanan No. Nomor 4.
Saya tidak mempunyai argumen yang meyakinkan untuk "membuktikan" tesis saya. Yang saya miliki hanyalah contoh-contoh penuh warna yang saya kumpulkan selama 30 tahun sebagai pengembang. Saya telah menyebutkan sifat filosofis yang mendalam dari masalah ini; dalam beberapa hal hal ini dipolitisasi dalam komunitas pengembang. Beberapa orang percaya itu pencipta platform harus memperhatikan kompatibilitas, sementara yang lain menganggap hal ini mengkhawatirkan pengguna (pengembang itu sendiri). Satu dari dua. Memang benar, bukankah menjadi isu politik ketika kita memutuskan siapa yang harus menanggung dampak dari permasalahan bersama?
Jadi inilah politik. Dan mungkin akan ada tanggapan marah terhadap pidato saya.
Как pemakai Google Cloud Platform, dan sebagai pengguna AWS selama dua tahun (saat bekerja untuk Grab), saya dapat mengatakan bahwa ada perbedaan besar antara filosofi Amazon dan Google dalam hal prioritas. Saya tidak aktif mengembangkan di AWS, jadi saya tidak tahu betul seberapa sering mereka menghapus API lama. Namun ada kecurigaan bahwa hal ini tidak terjadi sesering di Google. Dan saya sangat yakin bahwa sumber kontroversi dan frustrasi yang terus-menerus terjadi di GCP adalah salah satu faktor terbesar yang menghambat pengembangan platform ini.
Saya tahu bahwa saya tidak menyebutkan contoh spesifik sistem GCP yang tidak lagi didukung. Saya dapat mengatakan bahwa hampir semua yang saya gunakan, mulai dari jaringan (dari yang terlama hingga VPC) hingga penyimpanan (Cloud SQL v1-v2), Firebase (sekarang Firestore dengan API yang sama sekali berbeda), App Engine (jangan memulainya) , titik akhir cloud Cloud Endpoint dan hingga... Saya tidak tahu - benar-benar semua ini memaksa Anda untuk menulis ulang kode setelah maksimal 2-3 tahun, dan mereka tidak pernah mengotomatiskan migrasi untuk Anda, dan sering kali . Seolah-olah memang seharusnya demikian.
Dan setiap kali saya melihat AWS, saya bertanya pada diri sendiri mengapa saya masih menggunakan GCP. Mereka jelas tidak membutuhkan klien. Mereka butuh pembeli. Apakah Anda memahami perbedaannya? Biar saya jelaskan.
Google Cloud punya , di mana orang-orang mengusulkan solusi perangkat lunak mereka, dan untuk menghindari efek restoran kosong, mereka perlu mengisinya dengan beberapa proposal, jadi mereka mengontrak sebuah perusahaan bernama Bitnami untuk membuat sekumpulan solusi yang diterapkan dengan “satu klik”, atau seharusnya Saya sendiri yang menulisnya sebagai “solusi”, karena ini tidak menyelesaikan apa pun. Mereka hanya ada sebagai kotak centang, sebagai pengisi pemasaran, dan Google tidak pernah peduli apakah alat tersebut benar-benar berfungsi. Saya mengenal manajer produk yang pernah memegang kendali, dan saya dapat meyakinkan Anda bahwa orang-orang ini tidak peduli.
Ambil contoh, solusi penerapan “sekali klik”. . Saya muak dengan kejahatan Google Cloud SQL, jadi saya mulai mencari cara untuk membangun cluster Percona saya sendiri sebagai alternatif. Dan kali ini Google sepertinya telah melakukan pekerjaannya dengan baik, mereka akan menghemat waktu dan tenaga saya hanya dengan mengklik sebuah tombol!
Baiklah, ayo pergi. Mari ikuti tautannya dan klik tombol ini. Pilih “Ya” untuk menyetujui semua pengaturan default dan menerapkan cluster di proyek cloud Google Anda. Haha, itu tidak berhasil. Semua omong kosong ini tidak berhasil. Alat ini tidak pernah diuji dan mulai membusuk sejak menit pertama, dan tidak mengherankan saya jika lebih dari separuh "solusi" adalah penerapan sekali klik (sekarang kami mengerti mengapa ada tanda kutip) secara umum tidak bekerja. Ini benar-benar kegelapan tanpa harapan, yang lebih baik tidak dimasuki.
Tapi Google benar dorongan Anda untuk menggunakannya. Mereka ingin Anda melakukannya membeli. Bagi mereka itu adalah transaksi. Mereka tidak menginginkan apa pun mendukung. Itu bukan bagian dari DNA Google. Ya, para insinyur saling mendukung, sebagaimana dibuktikan oleh cerita saya dengan Bigtable. Namun dalam produk dan layanan untuk masyarakat biasa, mereka selalu kejam , yang tidak memenuhi standar profitabilitas meskipun memiliki jutaan pengguna.
Dan hal ini menghadirkan tantangan nyata bagi GCP karena inilah DNA di balik semua penawaran cloud. Mereka tidak berusaha mendukung apa pun; Sudah diketahui bahwa mereka menolak untuk menghosting (sebagai layanan terkelola) perangkat lunak pihak ketiga mana pun sampai, hingga AWS melakukan hal yang sama dan membangun bisnis yang sukses di sekitarnya, dan ketika pelanggan benar-benar meminta hal yang sama. Namun, diperlukan upaya agar Google mendukung sesuatu.
Kurangnya budaya dukungan, ditambah dengan mentalitas “mari kita hancurkan agar lebih indah”, mengasingkan pengembang.
Dan itu bukan hal yang baik jika Anda ingin membangun platform yang berumur panjang.
Google, bangun, sialan. Sekarang tahun 2020. Anda masih kalah. Saatnya untuk melihat ke cermin dan menjawab apakah Anda benar-benar ingin bertahan di bisnis cloud.
Jika kamu ingin tinggal maka berhenti merusak segalanya. Teman-teman, kamu kaya. Kami pengembang tidak. Jadi ketika menyangkut siapa yang akan memikul beban kecocokan, Anda harus menanggungnya sendiri. Bukan untuk kami.
Karena setidaknya ada tiga awan lagi yang sangat bagus. Mereka memberi isyarat.
Dan sekarang saya akan melanjutkan untuk memperbaiki semua sistem saya yang rusak. Eh.
Sampai Lain waktu!
PS Update setelah membaca beberapa pembahasan di artikel ini (diskusinya bagus btw). Dukungan Firebase belum dihentikan dan tidak ada rencana yang saya ketahui. Namun, mereka memiliki bug streaming buruk yang menyebabkan klien Java terhenti di App Engine. Salah satu teknisi mereka membantu saya memecahkan masalah ini, ketika saya bekerja di Google, tetapi mereka tidak pernah benar-benar memperbaiki bug tersebut, jadi saya memiliki solusi buruk karena harus memulai ulang aplikasi GAE setiap hari. Dan itu sudah terjadi selama empat tahun! Mereka sekarang memiliki Firestore. Dibutuhkan banyak usaha untuk bermigrasi ke sana karena ini adalah sistem yang sama sekali berbeda dan bug Firebase tidak akan pernah diperbaiki. Kesimpulan apa yang bisa diambil? Anda bisa mendapatkan bantuan jika Anda bekerja di sebuah perusahaan. Saya mungkin satu-satunya yang menggunakan Firebase di GAE karena saya mencatat kurang dari 100 kunci di aplikasi yang 100% asli dan aplikasi tersebut berhenti berfungsi setiap beberapa hari karena bug yang diketahui. Apa yang bisa saya katakan selain menggunakannya dengan risiko Anda sendiri. Saya beralih ke Redis.
Saya juga melihat beberapa pengguna AWS yang lebih berpengalaman mengatakan bahwa AWS biasanya tidak pernah berhenti mendukung layanan apa pun, dan SimpleDB adalah contoh yang bagus. Asumsi saya bahwa AWS tidak memiliki penyakit dukungan akhir yang sama seperti Google tampaknya dapat dibenarkan.
Selain itu, saya perhatikan bahwa 20 hari yang lalu tim Google App Engine merusak hosting perpustakaan Go yang penting, mematikan aplikasi GAE dari salah satu pengembang inti Go. Itu sangat bodoh.
Terakhir, saya mendengar para Googler telah mendiskusikan masalah ini dan secara umum setuju dengan saya (saya sayang kalian!). Namun mereka tampaknya menganggap masalah ini tidak dapat diselesaikan karena budaya Google tidak pernah memiliki struktur insentif yang tepat. Saya pikir ada baiknya meluangkan waktu untuk mendiskusikan pengalaman luar biasa yang saya alami saat bekerja dengan teknisi AWS saat bekerja di Grab. Suatu hari nanti di masa depan, saya harap!
Dan ya, pada tahun 2005 mereka memiliki berbagai jenis daging hiu di prasmanan raksasa di gedung 43, dan favorit saya adalah daging hiu martil. Namun, pada tahun 2006, Larry dan Sergei menyingkirkan semua camilan tidak sehat. Jadi saat cerita Bigtable tahun 2007 memang tidak ada hiu dan saya menipu Anda.
Saat saya melihat cloud Bigtable empat tahun lalu (memberi atau menerima), di sinilah letak biayanya. Tampaknya sudah turun sedikit sekarang, tapi itu masih terlalu banyak untuk gudang data yang kosong, terutama karena cerita pertama saya menunjukkan betapa tidak pentingnya sebuah tabel besar yang kosong dalam skalanya.
Maaf telah menyinggung komunitas Apple dan tidak mengatakan hal baik tentang Microsoft, dll. Anda baik-baik saja, saya sangat menghargai semua diskusi yang dihasilkan artikel ini! Namun terkadang Anda perlu membuat sedikit keributan untuk memulai diskusi, Anda tahu?
Terima kasih sudah membaca.
Pembaruan 2, 19.08.2020/XNUMX/XNUMX. Garis !
Pembaruan 3, 31.08.2020/2/2. Saya dihubungi oleh seorang insinyur Google di Cloud Marketplace yang ternyata adalah teman lama saya. Dia ingin mencari tahu mengapa CXNUMXD tidak berfungsi, dan kami akhirnya mengetahui bahwa itu karena saya telah membangun jaringan saya bertahun-tahun yang lalu, dan CXNUMXD tidak berfungsi pada jaringan lama karena parameter subnet tidak ada di templatnya. Menurut saya, yang terbaik bagi calon pengguna GCP adalah memastikan bahwa mereka mengenal cukup banyak teknisi di Google...
Sumber: www.habr.com