Jadi mari kita selesaikan ini.
Saya akan mulai dengan cerita kecil namun instruktif sejak saya pertama kali bekerja di Google. Saya tahu saya telah mengatakan banyak hal buruk tentang Google akhir-akhir ini, tetapi saya merasa kesal ketika perusahaan asal saya secara teratur membuat keputusan bisnis yang tidak kompeten. Meskipun demikian, kami harus memberikan penghormatan: infrastruktur internal Google benar-benar luar biasa, dan kami dapat dengan aman mengatakan bahwa tidak ada yang lebih baik saat ini. Pendiri Google adalah insinyur yang jauh lebih baik daripada yang pernah saya lakukan, dan cerita ini hanya menegaskan fakta ini.
Pertama, sedikit latar belakang: Google memiliki teknologi penyimpanan yang disebut Bigtable . Itu adalah pencapaian teknis yang luar biasa, salah satu dari penyimpanan nilai kunci (K / V) yang pertama (jika bukan yang pertama) "skalabel tak terbatas": pada dasarnya awal dari NoSQL. Bigtable masih terasa nyaman di ruang penyimpanan K / V yang agak ramai akhir-akhir ini, tetapi pada saat itu (2005) sangat keren.
Satu hal lucu tentang Bigtable adalah mereka memiliki objek bidang kontrol internal (sebagai bagian dari implementasi) yang disebut server tablet, dengan indeks besar, dan pada titik tertentu mereka menjadi hambatan saat menskalakan sistem. Insinyur Bigtable memeras otak mereka tentang cara 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 Bigtable menjadi populer dan ada di mana-mana di dalam Google, dan setiap 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? Mengapa tidak hanya satu? Secara teori, satu penyimpanan seharusnya cukup untuk semua kebutuhan penyimpanan Google. Tentu saja, mereka tidak pernah melompat ke hanya satu karena alasan pengembangan praktis (seperti konsekuensi dari potensi kegagalan), tetapi teorinya menarik. Satu gudang untuk seluruh alam semesta ( omong - omong, apakah ada yang tahu jika Amazon melakukan ini dengan Sable-nya? )
Bagaimanapun, inilah cerita saya.
Saat itu, saya bekerja di Google selama lebih dari dua tahun, dan suatu hari saya menerima email dari tim teknik Bigtable seperti ini:
Dear Steve,
Salam dari tim Bigtable. Kami ingin memberi tahu Anda bahwa Anda menggunakan biner Bigtable yang sangat, sangat tua di pusat data [nama pusat data]. Versi ini tidak lagi didukung dan kami ingin membantu Anda meningkatkan ke versi terbaru.
Beri tahu saya jika Anda dapat menjadwalkan waktu untuk bekerja sama mengenai masalah ini.
Semua yang terbaik,
Tim Bigtable
Anda mendapatkan banyak email di Google, jadi sekilas saya membaca sesuatu seperti ini:
,
- . , ----. -----, -- .
, , --.
,
-
Saya hampir langsung menghapusnya, tetapi di ujung kesadaran saya, saya merasakan perasaan yang menyakitkan dan sakit karena ini tidak terlihat seperti surat resmi, meskipun jelas bahwa penerimanya salah karena saya tidak menggunakan Bigtable.
Tapi itu aneh.
Sisa hari itu saya bergantian memikirkan pekerjaan dan jenis daging hiu apa yang harus dicoba di dapur mikro, yang setidaknya tiga di antaranya cukup dekat untuk didapat dari tempat saya dengan kue bolu yang ditujukan dengan baik, tetapi pemikiran untuk menulis tidak membuat saya tumbuh perasaan. sedikit kecemasan.
Mereka dengan jelas memanggil namaku. Dan email tersebut dikirim ke alamat email saya, bukan orang lain, dan bukan cc: atau bcc:. Nadanya sangat pribadi dan jelas. Mungkin ini semacam kesalahan?
Akhirnya, rasa ingin tahu menguasai saya dan saya pergi untuk melihat konsol Borg di pusat data yang mereka sebutkan.
Dan tentu saja, saya memiliki penyimpanan BigTable di bawah kendali saya. Maaf, apa? Saya melihat isinya, dan - wow! Itu dari inkubator Codelab, tempat saya duduk minggu pertama saya di Google pada bulan Juni 2005. Codelab memaksa Anda untuk memulai Bigtable sehingga Anda menulis beberapa nilai di sana, dan saya mungkin tidak pernah menutup repositori setelah itu. Ini masih berhasil, meskipun lebih dari dua tahun telah berlalu.
Ada beberapa aspek penting dari cerita ini. Pertama, pekerjaan Bigtable sangat tidak signifikan dalam skala Google sehingga hanya dua tahun kemudian seseorang memperhatikan penyimpanan ekstra, dan bahkan hanya karena versi biner sudah ketinggalan zaman. Sebagai perbandingan, saya pernah mempertimbangkan untuk menggunakanBigtable di Google Cloud untuk game online saya. Saat itu, biaya layanan ini sekitar $ 16.000 per tahun untuk Bigtable kosong di GCP. Saya tidak mengatakan mereka menipu Anda, tetapi menurut pendapat pribadi saya, ini banyak uang untuk database sialan kosong.
Aspek penting lainnya adalah penyimpanan masih berfungsi setelah dua tahun... WTF? Pusat data datang dan pergi; mereka mengalami gangguan, mereka menjalani pemeliharaan terjadwal, mereka berubah sepanjang waktu. Perangkat keras diperbarui, sakelar ditukar, semuanya terus ditingkatkan. Bagaimana mereka bisa mempertahankan program saya berjalan selama dua tahun dengan semua perubahan ini? Ini mungkin tampak seperti pencapaian sederhana di tahun 2020, tetapi cukup mengesankan di tahun 2005-2007.
Dan aspek yang paling menakjubkan adalah bahwa tim teknik luar di beberapa negara bagian lain menghubungi saya, pemilik beberapa instance kecil Bigtable yang hampir kosong, yang tidak memiliki lalu lintas selama dua tahun terakhir - dan menawarkan bantuan untuk memperbaruinya. ...
Saya berterima kasih kepada mereka, melepaskan lemari besi, dan hidup berjalan seperti biasa. Tapi tiga belas tahun kemudian, saya masih memikirkan surat ini. Karena terkadang saya mendapatkan email seperti ini dari Google Cloud. Mereka terlihat seperti ini:
Pengguna Google Cloud yang Terhormat, Kami
mengingatkan Anda bahwa kami menghentikan layanan [layanan penting yang Anda gunakan] mulai Agustus 2020, setelah itu Anda tidak akan dapat mengupdate instance Anda. Kami menyarankan Anda meningkatkan ke versi terbaru, yang dalam pengujian beta, tidak memiliki dokumentasi, tidak ada jalur migrasi, dan sudah usang sebelumnya dengan bantuan kami.
Kami berkomitmen untuk meminimalkan dampak perubahan ini pada semua pengguna platform Google Cloud.
Sahabat Selamanya,
Google Cloud Platform
Tetapi saya hampir tidak membaca surat-surat seperti itu, karena sebenarnya mereka mengatakan yang berikut:
Penerima yang terhormat,
Persetan. Persetan, persetan, persetan. Buang semua yang Anda lakukan karena itu tidak masalah. Yang penting adalah waktu kita. Kami menghabiskan waktu dan uang untuk menyokong kotoran kami dan kami bosan, jadi kami tidak akan mendukungnya lagi. Jadi lepaskan rencana sialan Anda dan mulailah menggali dokumentasi kami yang buruk, meminta memo di forum, dan omong-omong, omong kosong baru kami benar-benar berbeda dari omong kosong lama karena kami mengacaukan desain ini cukup parah, heh, tapi itu masalah Anda, bukan kami.
Kami masih bekerja keras untuk memastikan bahwa semua desain Anda tidak dapat digunakan dalam waktu satu tahun.
Silakan,
Google Cloud Platform
Dan faktanya, saya menerima surat seperti itu sebulan sekali. Hal ini terjadi begitu sering dan terus-menerus sehingga mereka secara tak terelakkan mendorong saya menjauh dari GCP dan masuk ke cloud camp lawan. Saya tidak lagi setuju untuk bergantung pada perkembangan kepemilikan mereka, karena pada kenyataannya lebih mudah bagi pengembang untuk mempertahankan sistem open source pada mesin virtual telanjang daripada mencoba mengikuti kebijakan Google untuk menutup produk "usang".
Sebelum kembali ke Google Cloud karena saya sudah dekatBelum 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 menyebabkan masalah. Kebanggaan adalah jebakan bagi yang tidak waspada; hal itu telah membuat banyak karyawan Google berpikir bahwa keputusan mereka selalu benar dan bahwa menjadi benar (menurut definisi yang kabur dan tidak jelas) lebih penting daripada layanan pelanggan.
Berikut beberapa contoh sewenang-wenang dari proyek besar lainnya di luar Google, tetapi saya harap Anda melihat pola ini di mana-mana. Ini adalah sebagai berikut: kompatibilitas mundur membuat sistem tetap hidup dan mutakhir selama beberapa dekade .
Kompatibilitas ke belakang adalah tujuan desain dari semua sistem yang berhasil dirancangpenggunaan terbuka , yaitu diimplementasikan dengan open source dan / atau standar terbuka. Saya merasa seperti saya mengatakan sesuatu yang terlalu jelas sehingga semua orang bahkan tidak nyaman, tapi tidak. Ini adalah masalah politik, jadi dibutuhkan contoh.
Sistem pertama yang saya pilih adalah yang tertua: GNU Emacs, yang merupakan hibrida antara Windows Notepad, kernel OS, dan Stasiun Luar Angkasa Internasional. Agak sulit untuk dijelaskan, tetapi secara singkat, Emacs adalah platform yang dibuat pada tahun 1976 (ya, hampir setengah abad yang lalu) untuk pemrograman untuk meningkatkan produktivitas Anda, tetapi menyamar sebagai editor teks.
Saya menggunakan Emacs setiap hari. Ya, saya juga menggunakan IntelliJ setiap hari, ini telah menjadi platform perkakas yang hebat. Tetapi menulis ekstensi untuk IntelliJ jauh lebih ambisius dan sulit daripada menulis ekstensi untuk Emacs. Dan yang lebih penting, apapun yang ditulis untuk Emacs akan bertahan selamanya .
Saya masih menggunakan perangkat lunak yang saya tulis untuk Emacs pada tahun 1995. Dan saya yakin seseorang menggunakan modul yang ditulis untuk Emacs di pertengahan 80-an, jika tidak sebelumnya. Mereka mungkin memerlukan sedikit penyesuaian dari waktu ke waktu, tetapi ini sangat jarang. Saya tidak tahu apa pun yang pernah saya tulis untuk Emacs (dan saya telah banyak menulis) yang harus merancang ulang arsitekturnya.
Emacs memiliki fungsi yang disebut make-obsolete untuk entitas lama. 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 tipikal bagi mereka yang lebih dulu: semua istilah Anda salah. Namun Emacs memang memiliki konsep obsolescence, yang dalam jargonnya disebut obsolescence .
Tetapi di dunia Emacs tampaknya ada definisi kerja yang berbeda. Filosofi mendasar lainnya, jika Anda mau.
Di dunia Emacs (dan di banyak area lain yang akan kami bahas di bawah), status deprecation API pada dasarnya berarti, “Anda sebaiknya tidak menggunakan pendekatan ini, karena meskipun berhasil, pendekatan ini mengalami berbagai kelemahan yang akan kami sebutkan di sini. Tapi pada akhirnya, itu pilihanmu. "
Di dunia Google, status produk lama berarti "Kami melanggar kewajiban kami kepada Anda". Sungguh. Inilah arti dasarnya. Ini berarti bahwa mereka akan memaksa Anda untuk melakukan beberapa pekerjaan secara teratur , mungkin banyak pekerjaan, sebagai hukuman karena percaya pada iklan mereka yang penuh warna : kami memiliki perangkat lunak terbaik. Tercepat! Anda melakukan semuanya sesuai dengan instruksi, meluncurkan aplikasi atau layanan Anda, dan kemudian bam, setelah satu atau dua tahun rusak.
Ini seperti menjual mobil bekas yang pasti akan mogok dalam jarak 1500 km.
Ini adalah dua definisi filosofis yang sama sekali berbeda tentang "keusangan". Definisi Google berbau seperti keusangan yang direncanakan . Saya tidak percaya itu sebenarnyakeusangan direncanakan dalam arti yang sama seperti Apple. Tapi Google pasti berencana untuk merusak program Anda secara tidak langsung. Saya tahu ini karena saya bekerja di sana sebagai insinyur perangkat lunak selama lebih dari 12 tahun. Mereka memiliki pedoman internal yang tidak jelas tentang seberapa banyak kompatibilitas ke belakang seharusnya, tetapi 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 "cobalah memberi pelanggan 6-12 bulan untuk meningkatkan sebelum merusak seluruh sistem."
Masalahnya jauh lebih serius daripada yang mereka pikirkan, dan akan bertahan selama bertahun-tahun yang akan datang karena layanan pelanggan tidak ada dalam DNA mereka. Lebih lanjut tentang ini di bawah.
Untuk saat ini, saya akan membuat pernyataan berani bahwa Emacs berhasil sebagian besar, dan bahkan sebagian besar , karena mereka menganggap kompatibilitas ke belakang dengan sangat serius. Sebenarnya, ini adalah tesis artikel kami. Sistem open source berumur panjang yang sukses berhutang keberhasilannya pada komunitas mikro yang telah hidup di sekitar ekstensi / plugin selama beberapa dekade . Inilah ekosistemnya. Saya telah berbicara tentang esensi platform dan betapa pentingnya platform tersebut, dan bagaimana Google, sepanjang sejarah perusahaannya, tidak pernah memahami apa yang menyebabkan terciptanya platform terbuka yang sukses, selain dari Android atau Chrome.
Sebenarnya, saya harus menyebutkan Android secara singkat, karena Anda mungkin sudah memikirkannya.
Pertama, Android bukanlah Google... Mereka hampir tidak ada hubungannya satu sama lain. Android adalah perusahaan yang dibeli oleh Google pada Juli 2005, perusahaan ini diizinkan untuk berjalan lebih atau kurang secara otonom dan faktanya sebagian besar tetap utuh selama bertahun-tahun. Android adalah tumpukan teknologi yang terkenal dan organisasi berduri yang sama terkenalnya. Seperti yang dikatakan oleh seorang googler, "Anda tidak bisa hanya menggunakan Android."
Di posting sebelumnya, saya telah membahas seberapa buruk beberapa desain awal Android. Heck, ketika saya menulis artikel itu, mereka menyebarkan sesuatu yang disebut "Aplikasi Instan" yang sekarang (kejutan!) Usangdan bersimpati jika Anda cukup bodoh untuk mendengarkan Google dan menghadirkan konten Anda ke aplikasi instan ini.
Tetapi ada perbedaan, perbedaan yang signifikan, yaitu orang-orang Android benar-benar memahami betapa pentingnya platform, mereka mencoba yang terbaik untuk menjaga aplikasi Android lama tetap berfungsi. Faktanya, upaya mereka untuk mempertahankan kompatibilitas ke belakang begitu ekstrim sehingga bahkan saya, selama tugas singkat saya di divisi Android beberapa tahun yang lalu, menemukan diri saya mencoba meyakinkan mereka untuk melepaskan dukungan untuk beberapa perangkat dan API tertua (saya salah, seperti banyak hal lain dulu dan sekarang. Maaf Android guys! Sekarang saya pernah ke Indonesia, saya mengerti mengapa kami membutuhkannya).
Orang-orang Android mempertahankan kompatibilitas ke belakang hingga ke ekstrem yang hampir tak terbayangkan, menumpuk sejumlah besar hutang teknologi usang dalam sistem dan toolchain mereka. Ya Tuhan, Anda seharusnya melihat beberapa hal gila yang harus mereka lakukan dalam sistem build mereka, semuanya atas nama kompatibilitas.
Untuk ini, saya memberi Android penghargaan You Are Not Google yang didambakan. Mereka benar-benar tidak ingin menjadi Google, yang tidak tahu bagaimana membangun platform yang tahan lama, tapi Android tahu bagaimana melakukannya. Jadi Google sangat bijaksana dalam satu hal: memungkinkan orang di Android melakukan berbagai hal dengan cara mereka sendiri.
Namun, aplikasi Android instan adalah ide yang cukup bodoh. Apa kamu tahu kenapa? Karena mereka menuntuttulis ulang dan desain ulang aplikasi Anda ! Seolah-olah orang akan mengambil dan menulis ulang dua juta aplikasi. Saya rasa aplikasi instan adalah ide dari beberapa googler.
Tapi ada perbedaan disini. Kompatibilitas ke belakang mahal. Android sendiri yang menanggung beban biaya ini, sementara Google menegaskan bahwa Anda , pelanggan yang membayar, menanggung beban tersebut .
Anda dapat melihat komitmen Android untuk kompatibilitas mundur di API-nya. Ketika Anda memiliki empat atau lima subsistem yang berbeda untuk melakukan hal yang sama secara harfiah, itu adalah tanda pasti bahwa komitmen untuk kompatibilitas ke belakang ada di intinya. Yang dalam dunia platform identik dengan komitmen kepada pelanggan dan pasar Anda.
Masalah utama Google di sini adalah kebanggaan mereka terhadap kebersihan teknik mereka. Mereka tidak suka jika ada banyak cara berbeda untuk melakukan hal yang sama, dengan cara yang lebih lama dan kurang disukai duduk di samping cara yang lebih baru dan lebih aneh. Ini meningkatkan kurva pembelajaran bagi pendatang baru di sistem, meningkatkan beban pemeliharaan API lama, memperlambat kecepatan fitur baru, dan dosa utama buruk. Google - seperti Lady Ascot dari "Alice in Wonderland" oleh Tim Burton:
Lady Ascot:
- Alice, Anda tahu apa yang paling saya takuti?
- Penurunan aristokrasi?
- Saya takut akan memiliki cucu yang jelek .
Untuk memahami pertukaran antara cantik dan praktis, mari kita lihat platform ketiga yang berhasil (setelah Emacs dan Android) dan lihat cara kerjanya: Java itu sendiri.
Java memiliki banyak sekali API lama. Penghentian sangat populer di kalangan programmer Java, bahkan lebih populer daripada kebanyakan bahasa pemrograman. Di Java sendiri, bahasa dan pustaka utama, penghentian API terus-menerus terjadi.
Jika Anda hanya mengambil satu dari ribuan contoh, menutup streaming sudah tidak digunakan lagi. Sudah tidak digunakan lagi sejak Java 1.2 dirilis pada Desember 1998. Sudah 22 tahun sejak ini tidak digunakan lagi.
Tetapi kode produksi saya yang sebenarnya masih membunuh utas setiap hari... Apakah itu bagus Benar! Maksud saya, tentu saja, jika saya menulis ulang kode hari ini, saya akan menerapkannya secara berbeda. Tetapi kode untuk permainan saya, yang telah membuat ratusan ribu orang bahagia selama dua dekade terakhir, ditulis dengan fungsi untuk menutup utas yang menggantung terlalu lama, dan saya tidak pernah harus mengubahnya . Saya tahu sistem saya lebih baik daripada siapa pun, saya benar-benar memiliki pengalaman 25 tahun bekerja dengannya dalam produksi, dan saya dapat mengatakan dengan pasti: dalam kasus saya, menutup aliran kerja tertentu ini sama sekali tidak berbahaya . Anda tidak perlu membuang waktu dan tenaga untuk menulis ulang kode ini, dan puji Larry Ellison (mungkin) bahwa Oracle tidak memaksa saya untuk menulis ulang.
Mungkin Oracle juga memahami platform. Siapa tahu.
Bukti dapat ditemukan untuk semua API Java inti yang penuh dengan gelombang usang, seperti garis gletser di ngarai. Anda dapat dengan mudah menemukan lima atau enam manajer navigasi keyboard yang berbeda (KeyboardFocusManager) di pustaka Java Swing. Sebenarnya sulit untuk menemukan API Java yang tidak usang. Tapi mereka tetap bekerja! Saya pikir tim Java hanya akan benar-benar menghapus API jika antarmukanya menyebabkan masalah keamanan yang parah.
Begini masalahnya: kami para pengembang perangkat lunak sangat sibuk dan di setiap bidang perangkat lunak kami dihadapkan pada alternatif yang bersaing. Pada waktu tertentu, programmer X melihat Y sebagai kemungkinan pengganti. Oh, apa kau tidak percaya padaku? Ingin dipanggil Swift? Seperti, semua orang bermigrasi ke Swift dan tidak ada yang menyerah, bukan? Wow, betapa sedikit yang kamu tahu. Perusahaan menghitung biaya tim pengembangan seluler ganda (iOS dan Android) - dan mereka mulai menyadari bahwa sistem pengembangan lintas platform yang diberi nama lucu ini seperti Flutter dan React Native berfungsi dan dapat mengurangi ukuran tim seluler mereka. dua kali atau, sebaliknya, membuatnya dua kali lebih produktif. Uang nyata dipertaruhkan. Ya, ada kompromi, tetapi di sisi lain, de-e-money.
Misalkan, secara hipotesis, Apple dengan bodohnya mengambil contoh Guido van Rossum dan mengumumkan bahwa Swift 6.0 tidak kompatibel dengan Swift 5.0, seperti Python 3 tidak kompatibel dengan Python 2.
Saya mungkin menceritakan kisah ini sepuluh tahun lalu, tetapi lima belas tahun yang lalu saya pergi ke Perkemahan Foo O'Reilly dengan Guido, duduk di tenda bersama Paul Graham dan sekelompok gundukan besar. Kami duduk di terik yang terik dan menunggu Larry Page lepas landas dengan helikopter pribadinya, sementara Guido bergumam monoton tentang Python 3000, yang dia namai setelah berapa tahun yang dibutuhkan semua orang untuk bermigrasi ke sana. Kami bertanya kepadanya sepanjang waktu mengapa itu merusak 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 “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Jika Anda menginstal Google Cloud Platform SDK ("gcloud"), Anda akan menerima pemberitahuan berikut:
Penerima yang terhormat,
Kami ingin mengingatkan Anda bahwa dukungan Python 2 sudah usang, jadi Anda
… Dll. Lingkaran kehidupan.
Tapi intinya, setiap pengembang punya pilihan. Dan jika Anda membuat mereka cukup sering menulis ulang kode, maka mereka mungkin memikirkan opsi lain . Mereka bukan sandera Anda, tidak peduli seberapa besar Anda menginginkan mereka. Mereka adalah tamumu. Python masih merupakan bahasa pemrograman yang sangat populer, tetapi sebenarnya, Python 3 (000) telah membuat kekacauan sendiri, di komunitasnya, dan di antara pengguna komunitasnya sehingga konsekuensinya belum diselesaikan 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 dalam sesuatu selain Python, meskipun mungkin saja sudahditulis dengan Python, jika Guido tidak membakar seluruh desa? Sulit untuk mengatakannya, tetapi Python jelas menderita. Ini adalah kekacauan besar, dan semua orang kalah.
Jadi katakanlah Apple mengikuti contoh Guido dan merusak kompatibilitas. Menurutmu apa yang akan terjadi nanti? Yah, mungkin 80-90% pengembang akan menulis ulang perangkat lunak mereka jika mereka bisa. Dengan kata lain, 10-20% basis pengguna secara otomatis beralih ke beberapa bahasa yang bersaing seperti Flutter.
Lakukan ini beberapa kali dan Anda akan kehilangan setengah dari basis pengguna Anda. Seperti dalam olahraga, dalam dunia pemrograman, bentuk kekinian juga berarti segalanya.... Siapapun yang kehilangan setengah dari penggunanya dalam lima tahun akan dianggap sebagai Big Fat Loser. Anda harus menjadi trending di dunia platform. Tetapi di sinilah mengabaikan dukungan untuk versi yang lebih lama akan membunuh Anda seiring waktu. Karena setiap kali Anda menyingkirkan sebagian dari pengembang, Anda (a) kehilangan mereka selamanya, karena mereka marah kepada Anda karena melanggar kontrak, dan (b) memberikannya kepada pesaing Anda.
Ironisnya, saya juga membantu mengubah Google menjadi primadona yang kompatibel dengan versi sebelumnya ketika saya membuat Grok, sistem pemahaman dan analisis kode sumber yang memfasilitasi otomatisasi dan perkakas berbasis kode - mirip dengan IDE, tetapi di sini toko layanan cloud terwujud representasi dari miliaran baris kode sumber Google di gudang data yang besar.
Grok memberi Googler kerangka kerja yang kuat untuk pemfaktoran ulang otomatis di seluruh basis kode (secara harfiah di seluruh Google). Sistem menghitung tidak hanya dependensi upstream (yang Anda andalkan), tetapi juga dependensi downstream (yang bergantung pada Anda), jadi saat Anda mengubah API, Anda tahu semua orang yang Anda hancurkan! Dengan cara ini, saat Anda membuat perubahan, Anda dapat memeriksa bahwa setiap konsumen API Anda diperbarui ke versi baru, dan pada kenyataannya, seringkali dengan alat Rosie yang mereka tulis, Anda dapat sepenuhnya mengotomatiskan prosesnya.
Hal ini memungkinkan basis kode Google menjadi "bersih" secara internal hampir supernatural, karena mereka memiliki pelayan robot yang berlarian di sekitar rumah dan secara otomatis membersihkan semuanya jika mereka mengganti nama SomeDespicablyLongFunctionName menjadi SomeDespicablyLongMethodName, karena seseorang mengira itu adalah cucunya yang jelek, dan perlu ditidurkan.
Dan sejujurnya, ini bekerja cukup baik untuk Google ... secara internal. Maksud saya, ya, komunitas Go di Google menertawakan komunitas Java di Google karena kebiasaan mereka yang terus-menerus melakukan refactoring. Memulai ulang sesuatu N kali berarti Anda tidak hanya mengacaukannya N-1 kali, tetapi setelah beberapa saat menjadi cukup jelas bahwa Anda mungkin mengacaukannya pada percobaan ke-N. Tapi, pada umumnya, mereka tetap berada di atas keributan ini dan menjaga kode "bersih".
Masalahnya dimulai ketika mereka mencoba memaksakan sikap ini pada klien cloud mereka dan pengguna API lain.
Saya memperkenalkan Anda sedikit ke Emacs, Android, dan Java; Mari kita lihat platform berumur panjang terbaru yang sukses: Web itu sendiri. Anda dapat membayangkan berapa banyak iterasi yang telah dilalui HTTP sejak 1995, ketika kami menggunakan tag <blink> berkedip dan ikon "Sedang Dibuat" di halaman web.
Tapi masih berhasil! Dan halaman ini masih berfungsi! Ya teman-teman, browser adalah juara kompatibilitas mundur dunia. Chrome adalah contoh lain dari platform Google langka yang kepalanya terpasang dengan benar, dan, Anda dapat menebaknya, Chrome secara efektif bertindak sebagai perusahaan terisolasi yang terpisah dari Google lainnya.
Saya juga ingin berterima kasih kepada teman-teman kita di antara pengembang sistem operasi: Windows, Linux, BUKAN APPLE IKUTI ANDA APPLE, FreeBSD dan seterusnya, karena telah melakukan begitu banyak pekerjaan kompatibilitas mundur pada platform mereka yang sukses (Apple paling banyak mendapatkan tiga kali lipat minus, karena mereka terus-menerus merusak semuanya tanpa alasan yang baik, tetapi entah bagaimana komunitas menangani ini di setiap rilis, dan sejauh ini wadah OS X tidak sepenuhnya ketinggalan zaman ... belum).
Tapi tunggu, katamu. Bukankah kita membandingkan apel dengan jeruk - sistem perangkat lunak mandiri pada satu mesin seperti Emacs / JDK / Android / Chrome, dengan sistem multi-server dan API seperti layanan cloud?
Yah, saya men-tweet tentang itu kemarin, tetapi dalam gaya Larry Wall of suck / rule, saya mencari kata yang tidak berlaku lagi di situs pengembang Google dan Amazon. Meskipun AWS memiliki ratusan kali lebih banyak penawaran layanan daripada GCP, dokumentasi pengembang Google menyebutkan penghentian sekitar tujuh kali lebih sering.
Jika seseorang dari Google membaca ini, maka mereka mungkin siap untuk mengeluarkan diagram yang menunjukkan gaya Donald Trump bahwa sebenarnya mereka melakukan segalanya dengan benar, dan bahwa saya tidak boleh membuat perbandingan yang tidak adil, seperti "jumlah penyebutan kata yang tidak digunakan lagi bergantung pada jumlah layanan ".
Namun setelah bertahun-tahun, Google Cloud masih # 3 (saya tidak pernah menulis artikel tentang upaya yang gagal untuk menjadi # 2), tetapi jika Anda mempercayai orang dalam, ada beberapa kekhawatiran bahwa mereka mungkin akan segera turun ke # 4.
Saya tidak ada gunanya argumen untuk "membuktikan" tesis Anda. Semua yang saya miliki adalah contoh penuh warna yang telah saya kumpulkan selama 30 tahun sebagai pengembang. Saya telah menyebutkan sifat filosofis yang mendalam dari masalah ini; dalam arti, ini dipolitisasi dalam komunitas pengembang. Beberapa orang berpikir bahwa pembuat platform harus memperhatikan kompatibilitas, sementara yang lain percaya bahwa ini adalah perhatian pengguna.(pengembang itu sendiri). Satu dari dua. Memang, bukankah itu masalah politik ketika kita memutuskan siapa yang harus menanggung biaya masalah bersama?
Jadi ini politik. Dan pasti akan ada tanggapan marah atas pidato saya.
Sebagai pengguna platform cloud Google, serta pengguna AWS selama dua tahun (di Grab), saya dapat mengatakan bahwa ada perbedaan besar antara filosofi Amazon dan Google dalam hal prioritas. Saya tidak secara 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 benar-benar yakin bahwa sumber kontroversi dan frustrasi yang terus-menerus di GCP ini adalah salah satu kendala terbesar dalam pengembangan platform.
Saya tahu saya belum menyebutkan contoh spesifik dari sistem GCP yang tidak lagi didukung. Saya dapat mengatakan bahwa hampir semua yang telah saya gunakan, dari jaringan (dari yang terlama hingga VPC) hingga penyimpanan (Cloud SQL v1-v2), Firebase (sekarang Firestore dengan API yang sama sekali berbeda), App Engine (mari kita bahkan tidak memulai), titik akhir cloud dan sebelumnya ... Saya tidak tahu - benar - benar semua penulisan ulang paksa kode ini dalam waktu maksimal 2-3 tahun, dan mereka tidak pernah mengotomatiskan migrasi untuk Anda, dan seringkali tidak ada jalur migrasi yang terdokumentasi sama sekali . Seolah seharusnya begitu.
Dan setiap kali saya melihat AWS, saya bertanya pada diri sendiri mengapa saya masih duduk di GCP. Mereka jelas tidak membutuhkan klien. Mereka menginginkan pembeli . Apakah Anda memahami perbedaannya? Biar saya jelaskan.
Google Cloud memiliki Marketplace tempat orang menawarkan solusi perangkat lunak mereka, dan untuk menghindari pengaruh restoran kosong, mereka harus mengisinya dengan beberapa saran, jadi mereka mengontrak Bitnami untuk membuat sekumpulan solusi yang diterapkan "dengan satu klik", atau Saya harus menulis "solusi" sendiri, karena ini tidak menyelesaikan apa pun. Mereka hanya ada sebagai bendera, sebagai pengisi pemasaran, dan Google tidak pernah peduli jika ada alat yang benar-benar berfungsi. Saya tahu manajer produk yang telah mendorong, dan saya dapat meyakinkan Anda bahwa orang-orang ini tidak peduli.
Ambil, misalnya, solusi penerapan "sekali klik" Percona... Saya sangat bosan dengan kejenakaan Google Cloud SQL, jadi saya mulai mempertimbangkan untuk membuat cluster Percona saya sendiri sebagai alternatif. Dan kali ini Google tampaknya melakukan pekerjaan dengan baik, mereka akan menghemat waktu dan tenaga saya dengan mengklik sebuah tombol!
Baiklah, bagus, ayo pergi. Mari ikuti tautan dan tekan tombol ini. Pilih "Ya" untuk menyetujui semua default dan menerapkan cluster di proyek cloud Google Anda. Haha, tidak berhasil. Tak satu pun dari omong kosong ini berhasil. Alat ini belum pernah diuji dan mulai membusuk dari menit pertama, dan itu tidak akan mengejutkan saya jika lebih dari setengah dari “solusi” untuk satu-klik penyebaran (sekarang kita mengerti mengapa tanda kutip) melakukan tidak bekerja sama sekali. Ini benar-benar kegelapan tanpa harapan, di mana lebih baik tidak masuk.
Namun Google secara eksplisit mendorong Anda untuk menggunakannya. Mereka ingin Anda membelinya . Bagi mereka, ini adalah transaksi. Mereka tidak ingin mendukung apapun . Itu bukan bagian dari DNA Google. Ya, para insinyur saling mendukung, sebagaimana dibuktikan oleh cerita saya dengan Bigtable. Namun dalam produk dan layanan untuk orang biasa, mereka selalu kejam dalam menutup layanan apa pun yang tidak memenuhi standar profitabilitas, bahkan jika layanan tersebut memiliki jutaan pengguna.
Dan itu menghadirkan tantangan nyata bagi GCP karena DNA ini ada di balik semua penawaran cloud. Mereka tidak berusaha mendukung apa pun; telah diketahui dengan baik bahwa mereka menolak untuk menghosting (sebagai layanan terkelola) perangkat lunak pihak ketiga mana punselama AWS tidak melakukan hal yang sama dan tidak akan membangun bisnis yang sukses di sekitar, dan ketika pelanggan membutuhkan hal yang sama. Namun, perlu upaya agar Google mendukung sesuatu.
Kurangnya budaya dukungan ini, ditambah dengan prinsip "mari kita hancurkan untuk membuatnya indah", membuat developer terasing dari mereka.
Dan itu tidak baik jika Anda ingin membangun platform yang tahan lama.
Google bangun, sialan. Ini tahun 2020. Anda masih kalah. Saatnya untuk melihat lebih dekat ke cermin dan menjawab jika Anda benar-benar ingin bertahan di bisnis cloud.
Jika Anda ingin tinggal maka berhentilah merusak segalanya... Kalian kaya. Kami pengembang tidak. Jadi ketika menyangkut siapa yang akan menanggung beban kompatibilitas, Anda perlu memikulnya sendiri. Bukan untuk kami.
Karena setidaknya ada tiga awan lagi yang sangat bagus. Mereka memanggil mereka.
Dan sekarang saya akan terus memperbaiki semua sistem saya yang rusak. Eh.
Sampai Lain waktu!
Pembaruan PS setelah membaca beberapa diskusi di artikel ini (pembahasannya bagus sekali). Firebase belum dihentikan dan tidak ada paket yang saya ketahui. Namun, mereka memiliki kesalahan pengaliran yang parah yang menyebabkan klien Java berhenti di App Engine. Salah satu teknisi mereka membantu saya mengatasi masalah ini saat saya bekerja di Google, , , GAE. ! Firestore. , , , Firebase . ? , . , , Firebase GAE, 100 100% , - . , . Redis.
, AWS , AWS , SimpleDB — . , AWS , Google, , .
, , 20 Google App Engine Go, GAE Go. , .
, , ( , !). , , Google . , , AWS, Grab. - , !
, 2005 43, . 2006 . Bigtable 2007 .
Bigtable (-), . , , , , , .
, Apple Microsoft . . , , ! , , ?
.
2, 19.08.2020. Stripe API!
Pembaruan 3, 31/08/2020. Saya dihubungi oleh teknisi Google di Cloud Marketplace yang ternyata adalah teman lama saya. Dia ingin mencari tahu mengapa C2D tidak berfungsi, dan pada akhirnya kami menemukan: alasannya adalah saya membuat jaringan saya beberapa tahun yang lalu, dan C2D tidak berfungsi di jaringan lama karena parameter subnet yang hilang di template mereka. Menurut saya, calon pengguna GCP sebaiknya memastikan mereka memiliki teknisi yang cukup familiar di Google ...