Sialan Google, aku ora pengin blog maneh. Aku duwe akeh sing kudu ditindakake. Blogging mbutuhake wektu, energi lan kreatifitas, sing bisa digunakake kanthi apik: bukuku, , game sandi lan ing. Nanging sampeyan wis cukup nesu aku nganti aku kudu nulis iki.
Dadi ayo padha rampung iki.
Ayo kula miwiti karo crita cekak nanging instruktif saka nalika pisanan miwiti makarya ing Google. Aku ngerti aku wis ngomong akeh perkara sing ora apik babagan Google akhir-akhir iki, nanging aku ngganggu nalika perusahaanku dhewe ajeg nggawe keputusan bisnis sing ora kompeten. Ing wektu sing padha, kita kudu menehi amarga: infrastruktur internal Google pancen luar biasa, ora ana sing luwih apik saiki. Pendhiri Google minangka insinyur sing luwih apik tinimbang aku, lan crita iki mung negesake kasunyatan kasebut.
Kaping pisanan, latar mburi cilik: Google duwe teknologi panyimpenan data sing diarani . Iki minangka prestasi teknis sing luar biasa, salah sawijining toko kunci (K / V) sing pertama (yen ora sing pertama) "ora bisa diukur" (K / V): sejatine wiwitan NoSQL. Dina iki, Bigtable isih apik ing papan panyimpenan K / V sing rada rame, nanging ing wektu kasebut (2005) pancen apik banget.
Siji bab lucu Bigtable iku padha duwe obyek pesawat kontrol internal (minangka bagéan saka implementasine) disebut server tablet, karo indeks gedhe, lan ing sawetara titik padha dadi bottleneck nalika njongko sistem. engineers Bigtable padha puzzling carane ngleksanakake kaukur, lan dumadakan temen maujud sing padha bisa ngganti server tablet karo panyimpenan Bigtable liyane. Dadi Bigtable minangka bagean saka implementasi Bigtable. Fasilitas panyimpenan iki ana ing kabeh tingkat.
Rincian liyane sing menarik yaiku sawetara wektu Bigtable dadi populer lan ana ing ngendi wae ing Google, kanthi saben tim duwe gudang dhewe. Dadi ing salah sawijining rapat Jumuah, Larry Page kanthi santai takon: "Napa kita duwe luwih saka siji Bigtable? Kok ora mung siji?” Ing teori, siji panyimpenan kudu cukup kanggo kabeh kabutuhan panyimpenan Google. Mesthine, dheweke ora tau pindhah menyang mung siji kanggo alasan pangembangan praktis (kaya akibat saka kegagalan potensial), nanging teori kasebut menarik. Siji gudang kanggo kabeh Semesta (Ngomong-ngomong, ana sing ngerti yen Amazon nindakake iki karo Sable?)
Oalah, iki critaku.
Ing wektu iku, aku wis kerja ing Google mung luwih saka rong taun, lan ing sawijining dina aku nampa email saka tim teknik Bigtable sing kaya mangkene:
Dear Steve,
Hello saka tim Bigtable. Kita pengin ngandhani yen ing [jeneng pusat data] sampeyan nggunakake binar Bigtable sing lawas banget. Versi iki ora didhukung maneh lan kita pengin mbantu sampeyan nganyarke menyang versi paling anyar.
Mangga kabari kula yen sampeyan bisa gawe jadwal sawetara wektu kanggo bisa bebarengan ing masalah iki.
Kabeh sing paling apik,
Tim Bigtable
Ing Google sampeyan entuk akeh email, mula aku maca kaya mangkene:
Dear panampa,
Hello saka sawetara tim. Kita pengin komunikasi sing blah blah blah blah blah. Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla.
Mangga kabari yen sampeyan bisa gawe jadwal wektu larang regane kanggo bla bla bla.
Kabeh sing paling apik,
Sawetara jinis printah
Aku meh mbusak iku langsung, nanging ing pojok eling, aku krasa krasa lara, nagging yen iku. ora cukup katon kaya layang resmi temenan, yen panampa salah amarga aku ora nggunakake Bigtable.
Nanging aneh.
Aku ngentekake dina liyane gantian mikir babagan kerja lan jinis daging hiu apa sing kudu dicoba ing pawon mikro, sing paling ora ana telu sing cukup cedhak saka kursiku kanthi mbuwang biskuit sing apik, nanging mikir nulis ora nate ninggalake aku kanthi rasa kuwatir sing entheng.
Padha cetha nyebut jenengku. Lan email kasebut dikirim menyang alamat emailku, dudu wong liya, lan dudu cc: utawa bcc:. Nada kasebut banget pribadi lan jelas. Mungkin iki sawetara jenis kesalahan?
Akhire, penasaran dadi luwih apik saka kula lan aku lunga kanggo dipikir ing console Borg ing pusat data padha kasebut.
Lan mesthi, aku duwe panyimpenan BigTable ing manajemen. Nuwun sewu, apa? Aku ndeleng isine, lan wow! Iku saka inkubator Codelab sing aku lenggah ing minggu pisanan ing Google ing wulan Juni 2005. Codelab meksa sampeyan mbukak Bigtable kanggo nulis sawetara nilai ing kana, lan aku ora nate nutup panyimpenan sawise iku. Iku isih bisa digunakake sanajan luwih saka rong taun wis liwati.
Ana sawetara aspek penting kanggo crita iki. Kaping pisanan, karya Bigtable ora pati penting ing skala Google sing mung rong taun sawisé ana sing weruh panyimpenan ekstra, lan mung amarga versi binar wis ketinggalan jaman. Kanggo mbandhingake, aku tau nganggep nggunakake kanggo game online sandi. Ing wektu, layanan iki biaya kira-kira $16 saben taun. kosong Bigtable ing GCP. Aku ora ngandika padha scamming sampeyan, nanging ing mratelakake panemume pribadi, sing akèh dhuwit kanggo database kurang ajar kosong.
Aspek liyane sing penting yaiku panyimpenan isih kerja sawise rong taun. WTF? Pusat data teka lan lunga; padha ngalami outages, padha ngalami pangopènan dijadwal, padha ngganti kabeh wektu. Hardware dianyari, ngalih diganti, kabeh wis saya apik. Kepiye carane bisa njaga programku sajrone rong taun kanthi owah-owahan kasebut? Iki bisa uga katon kaya prestasi sing sithik ing 2020, nanging ing 2005-2007 cukup nyengsemaken.
Lan aspek sing paling apik yaiku tim teknik njaba ing sawetara negara liyane nyedhaki aku, sing duwe sawetara conto cilik sing meh kosong saka Bigtable, sing duwe nul lalu lintas suwene rong taun kepungkur - lan nawakake bantuan kanggo nganyari.
Aku matur nuwun, mbusak panyimpenan, lan urip kaya biasane. Nanging telulas taun mengko, aku isih mikir babagan surat kasebut. Amarga kadhangkala aku nampa email sing padha saka Google Cloud. Padha katon kaya iki:
Panganggo Google Cloud sing dihormati,
Minangka pangeling, kita bakal mandhegake layanan [layanan penting sing sampeyan gunakake] wiwit Agustus 2020, sawise sampeyan ora bisa nganyarke instan. Disaranake nganyarke menyang versi paling anyar, sing ana ing uji coba beta, ora duwe dokumentasi, ora ana jalur migrasi lan wis lawas sadurunge kanthi bantuan apik.
Kita setya kanggo mesthekake yen owah-owahan iki duwe pengaruh minimal marang kabeh pangguna platform Google Cloud.
Kanca-kanca sing paling apik ing salawas-lawase,
Google Cloud Platform
Nanging aku meh ora nate maca layang kaya ngono, amarga apa sing diomongake yaiku:
Dear panampa,
Menyang neraka. Jancok kowe, jancok kowe, jancok kowe. Selehake kabeh sing sampeyan lakoni amarga ora penting. Sing penting yaiku wektu kita. Kita mbuwang wektu lan dhuwit kanggo njaga omong kosong lan kesel dadi ora ndhukung maneh. Dadi metu saka rencana kurang ajar sampeyan lan wiwiti ngeduk dokumentasi sing ora apik, njaluk potongan-potongan ing forum, lan omong-omong, telek anyar kita beda banget karo telek lawas, amarga kita ngrusak desain iki kanthi apik, heh, nanging iki sampeyan masalah, ora kita.
Kita terus ngupayakake supaya kabeh pangembangan sampeyan ora bisa digunakake sajrone setaun.
Mangga jancok
Google Cloud Platform
Lan nyatane aku nampa layang kaya ngono saben wulan. Iki kedadeyan asring lan terus-terusan nganti ora bisa ditindakake disurung adoh kula saka GCP menyang camp anti-awan. Aku ora setuju maneh kanggo gumantung ing pangembangan kepemilikan, amarga nyatane luwih gampang kanggo devops kanggo njaga sistem open source ing mesin virtual gundhul saka nyoba kanggo tetep karo Google karo kawicaksanan nutup produk "outdated".
Sadurunge aku bali menyang Google Cloud amarga aku malah cedhak durung rampung ngritik wong-wong mau, ayo kang katon ing kinerja perusahaan ing sawetara wilayah liyane. Insinyur Google bangga karo disiplin teknik piranti lunak, lan iki sing nyebabake masalah. Bangga minangka jebakan kanggo wong sing ora waspada, lan wis nyebabake akeh karyawan Google mikir yen keputusane mesthi bener lan sing bener (kanthi sawetara definisi kabur sing ora jelas) luwih penting tinimbang peduli karo pelanggan.
Aku bakal menehi sawetara conto acak saka proyek gedhe liyane ing njaba Google, nanging muga-muga sampeyan bisa ndeleng pola iki ing endi wae. Kaya ing ngisor iki: kompatibilitas mundur tetep sistem urip lan up-to-date kanggo dekade.
Kompatibilitas mundur minangka tujuan desain kabeh sistem sukses sing dirancang kanggo mbukak nggunakake, yaiku, dileksanakake kanthi kode sumber terbuka lan / utawa standar mbukak. Aku rumangsa kaya ngomong sing jelas banget yen saben wong malah ora kepenak, nanging ora. Iki masalah politik, mula perlu conto.
Sistem pisanan sing bakal dakpilih yaiku sing paling tuwa: GNU Emacs, sing minangka hibrida antarane Windows Notepad, kernel OS, lan Stasiun Luar Angkasa Internasional. Iku rada angel kanggo nerangake, nanging kanthi ringkes, Emacs minangka platform sing digawe ing 1976 (ya, meh setengah abad kepungkur) kanggo program supaya sampeyan luwih produktif, nanging nyamar dadi editor teks.
Aku nggunakake Emacs saben dina. Ya, aku uga nggunakake IntelliJ saben dina, wis berkembang dadi platform perkakas sing kuat dhewe. Nanging nulis ekstensi kanggo IntelliJ minangka tugas sing luwih ambisius lan rumit tinimbang nulis ekstensi kanggo Emacs. Lan sing luwih penting, kabeh sing ditulis kanggo Emacs disimpen selawase.
Aku isih nggunakake piranti lunak sing daktulis kanggo Emacs ing taun 1995. Lan Aku manawa wong nggunakake modul ditulis kanggo Emacs ing agêng-80s, yen ora sadurungé. Padha mbutuhake tweaking sethitik saka wektu kanggo wektu, nanging iki pancene arang banget. Aku ora ngerti apa-apa sing wis daktulis kanggo Emacs (lan aku wis nulis akeh) sing mbutuhake arsitektur maneh.
Emacs nduweni fungsi sing disebut make-obsolete kanggo entitas sing wis usang. Terminologi Emacs kanggo konsep komputer dhasar (kayata apa "jendhela") asring beda karo konvensi industri amarga Emacs ngenalake dheweke ing wektu sing suwe. Iki minangka bebaya khas kanggo wong-wong sing ndhisiki wektu: kabeh syarat sampeyan ora bener. Nanging Emacs duwe konsep deprecation, sing diarani jargon lungse.
Nanging ing jagad Emacs katon ana definisi kerja sing beda. A filosofi ndasari beda, yen sampeyan pengin.
Ing jagad Emacs (lan ing pirang-pirang wilayah liyane, sing bakal kita bahas ing ngisor iki), status API sing ora ana gunane tegese: "Sampeyan pancene ora kudu nggunakake pendekatan iki, amarga nalika kerjane, ngalami macem-macem kekurangan sing bakal kita lakoni. dhaptar kene. Nanging ing pungkasan dina, iku pilihan sampeyan."
Ing jagad Google, dadi lungse tegese, "Kita nglanggar komitmen kita marang sampeyan." Iki bener. Iki tegese tegese. Iki tegese dheweke bakal meksa sampeyan ajeg nindakake sawetara karya, mbok menawa akeh karya, minangka paukuman kanggo pracaya marang wong-wong mau : Kita duwe piranti lunak sing paling apik. Paling cepet! Sampeyan nindakake kabeh miturut pandhuane, bukak aplikasi utawa layanan, banjur bam, sawise setahun utawa rong taun rusak.
Kayane dodolan montor bekas sing mesthi mogok 1500 km.
Iki minangka rong definisi filosofis sing beda banget babagan "obsolescence." Definisi mambu Google . Aku ora percaya iki nyatane ngrancang obsolescence ing pangertèn sing padha Apple. Nanging Google mesthi ngrancang ngrusak program sampeyan, kanthi cara bunder. Aku ngerti iki amarga aku kerja ing kana minangka insinyur piranti lunak luwih saka 12 taun. Dheweke duwe pedoman internal sing ora jelas babagan kompatibilitas mundur sing kudu ditindakake, nanging pungkasane gumantung ing saben tim utawa layanan. Ora ana rekomendasi tingkat perusahaan utawa teknik, lan rekomendasi sing paling wani babagan siklus obsolescence yaiku "nyoba menehi pelanggan 6-12 wulan kanggo nganyarke sadurunge ngrusak kabeh sistem."
Masalah kasebut luwih gedhe tinimbang sing dikira, lan bakal terus nganti pirang-pirang taun amarga perawatan pelanggan ora ana ing DNA. Liyane babagan iki ing ngisor iki.
Ing jalur iki aku bakal nggawe statement kandel sing Emacs sukses kanggo ombone gedhe lan malah utamane amarga padha nganggep kompatibilitas mundur kanthi serius. Bener, iki tesis artikel kita. Sistem terbuka sing sukses lan tahan suwe amarga sukses amarga komunitas mikro sing wis urip ing saubengé nganti pirang-pirang dekade. ekstensi / plugin. Iki ekosistem. Aku wis ngomong babagan sifat platform lan sepira pentinge, lan kepiye Google ing kabeh sejarah perusahaan ora ngerti apa sing nggawe platform mbukak sing sukses ing njaba Android utawa Chrome.
Bener, aku kudu sebutno Android sedhela amarga sampeyan bisa uga mikir babagan iki.
Kaping pisanan, Android dudu Google. Dheweke meh ora ana sing padha karo saben liyane. Android minangka perusahaan sing dituku dening Google ing Juli 2005, perusahaan iki diijini kanggo operate luwih utawa kurang otonom lan nyatane tetep ora kena pengaruh ing taun-taun sabanjure. Android minangka tumpukan teknologi sing kondhang lan organisasi prickly sing kondhang. Minangka salah siji Googler ngandika, "Sampeyan ora bisa mung mlebu menyang Android."
Ing artikel sadurunge, Aku rembugan carane ala sawetara pancasan desain awal Android. Heck, nalika aku nulis artikel kasebut, dheweke ngluncurake omong kosong sing diarani "aplikasi instan" sing saiki (kaget!) , lan aku simpati yen sampeyan cukup bodho ngrungokake Google lan mindhah konten sampeyan menyang aplikasi cepet iki.
Nanging ana prabédan ing kene, prabédan sing signifikan, yaiku wong-wong Android ngerti sejatine platform sing penting, dheweke ngupayakake supaya aplikasi Android lawas bisa digunakake. Nyatane, upaya kanggo njaga kompatibilitas mundur banget banget, sanajan aku, sajrone wektu singkat ing divisi Android sawetara taun kepungkur, nemokake aku nyoba ngyakinake dheweke kanggo nyelehake dhukungan kanggo sawetara piranti lan API sing paling tuwa (aku salah. , kaya ing pirang-pirang perkara sing kepungkur lan saiki. Nuwun sewu cah Android! Saiki aku wis tekan Indonesia, aku ngerti kenapa kita butuh).
Wong Android nyurung kompatibilitas nganti meh ora bisa dibayangake, numpuk utang teknis warisan sing akeh banget ing sistem lan toolchains. Duh Gusti, sampeyan kudu ndeleng sawetara perkara edan sing kudu ditindakake ing sistem mbangun, kabeh kanthi jeneng kompatibilitas.
Kanggo iki, aku menehi penghargaan "You're Not Google" kanggo Android. Dheweke pancen ora pengin dadi Google, sing ora ngerti carane nggawe platform tahan lama, nanging Android ngerti, piye carane. Dadi Google dadi pinter banget ing siji bab: ngidini wong nindakake samubarang kanthi cara dhewe ing Android.
Nanging, aplikasi cepet kanggo Android minangka ide sing bodho. Lan sampeyan ngerti kenapa? Amarga padha nuntut nulis maneh lan ngrancang maneh aplikasi sampeyan! Kaya-kaya wong mung bakal nulis ulang rong yuta aplikasi. Aku ngira Aplikasi Instan minangka ide Googler.
Nanging ana bedane. Kompatibilitas mundur teka kanthi biaya dhuwur. Android dhewe nanggung beban biaya kasebut, nalika Google ngeyel yen beban kasebut kudu ditanggung sampeyan, mbayar klien.
Sampeyan bisa ndeleng komitmen Android kanggo kompatibilitas mundur ing API. Yen sampeyan duwe papat utawa lima subsistem sing beda-beda sing nindakake perkara sing padha, iku tandha manawa ana komitmen kanggo kompatibilitas mundur ing inti. Kang ing donya platform sinonim karo prasetya kanggo pelanggan lan pasar.
Masalah utama Google ing kene yaiku bangga karo kebersihan teknik. Dheweke ora seneng yen ana macem-macem cara kanggo nindakake perkara sing padha, kanthi cara sing lawas lan ora dikarepake lungguh ing jejere cara anyar sing luwih apik. Iku mundhak kurva learning kanggo sing anyar kanggo sistem, iku mundhak beban njaga API warisan, iku slows mudhun kacepetan fitur-fitur anyar, lan dosa cardinal iku ora cantik. Google - kaya Lady Ascot saka Alice in Wonderland karya Tim Burton:
Lady Ascot:
- Alice, sampeyan ngerti apa sing paling aku wedi?
- Mudhun saka aristokrasi?
- Aku wedi yen aku bakal duwe putu elek.
Kanggo ngerti tradeoff antarane ayu lan praktis, ayo kang njupuk dipikir ing platform sukses katelu (sawise Emacs lan Android) lan ndeleng cara kerjane: Jawa dhewe.
Jawa nduweni akeh API sing wis lawas. Deprecation misuwur banget ing antarane programer Java, malah luwih populer tinimbang ing pirang-pirang basa pemrograman. Jawa dhewe, basa inti, lan perpustakaan-perpustakaan sing terus-terusan nolak API.
Kanggo njupuk mung siji saka ewu conto, dianggep lungse. Wis ora digunakake wiwit release Java 1.2 ing Desember 1998. Wis 22 taun wiwit iki ora digunakake.
Nanging kode asliku ing produksi isih mateni benang saben dina. Apa sampeyan mikir sing apik? Pancen! Maksudku, mesthi, yen aku nulis ulang kode dina iki, aku bakal ngetrapake kanthi beda. Nanging kode kanggo game sandi, sing wis nggawe atusan ewu wong seneng liwat rong puluh taun kepungkur, ditulis karo fungsi kanggo nutup Utas sing macet dawa banget, lan aku tau kudu ngganti. Aku ngerti sistemku luwih apik tinimbang sapa wae, aku duwe pengalaman 25 taun ing produksi, lan aku bisa ujar manawa: ing kasusku, nutup benang pekerja khusus iki rampung. ora mbebayani. Iku ora worth wektu lan gaweyan kanggo nulis ulang kode iki, lan matur nuwun Larry Ellison (mbokmenawa) sing Oracle ora meksa aku kanggo nulis maneh.
Oracle uga ngerti platform. Sapa ngerti.
Bukti bisa ditemokaké ing saindhenging inti Jawa API, kang riddled karo ombak saka obsolescence, kaya garis gletser ing canyon. Sampeyan bisa kanthi gampang nemokake lima utawa enem manajer navigasi keyboard (KeyboardFocusManager) ing perpustakaan Java Swing. Pancen angel golek API Java sing ora ditinggalake. Nanging padha isih bisa! Aku tim Jawa mung bakal mbusak API yen antarmuka nuduhke masalah keamanan glaring.
Mangkene perkarane, wong-wong: Kita para pangembang piranti lunak sibuk banget, lan ing saben area piranti lunak kita ngadhepi alternatif sing saingan. Ing wektu tartamtu, programer ing basa X nganggep basa Y minangka pengganti sing bisa ditindakake. Oh, sampeyan ora pracaya marang aku? Apa sampeyan pengin nelpon Swift? Kaya, kabeh wong migrasi menyang Swift lan ora ana sing ninggalke, ta? Wah, kurang ngerti. Perusahaan ngetung biaya tim pangembangan seluler dual (iOS lan Android) - lan dheweke wiwit ngerti manawa sistem pangembangan lintas platform kanthi jeneng lucu kaya Flutter lan React Native bener-bener bisa digunakake lan bisa digunakake kanggo nyuda ukurane. tim seluler kaping pindho utawa, Kosok baline, nggawe wong kaping pindho minangka produktif. Ana dhuwit nyata ing taruhan. Ya, ana kompromi, nanging, ing sisih liya, dhuwit.
Ayo hypothetically nganggep yen Apple bodho njupuk isyarat saka Guido van Rossum lan nyatakake yen Swift 6.0 mundur ora kompatibel karo Swift 5.0, kaya Python 3 ora kompatibel karo Python 2.
Aku mbokmenawa crita iki bab sepuluh taun kepungkur, nanging bab limalas taun kepungkur aku lunga menyang O'Reilly kang Foo Camp karo Guido, lungguh ing tarub karo Paul Graham lan Bunch saka nembak amba. We lungguh ing panas sweltering nunggu Larry Page mabur metu ing helikopter pribadine nalika Guido droned ing bab "Python 3000", kang dijenengi sawise nomer taun iku bakal njupuk kanggo saben wong migrasi ana. Kita terus takon kenapa dheweke nglanggar kompatibilitas, lan dheweke mangsuli: "Unicode." Lan kita takon, yen kita kudu nulis ulang kode kita, apa keuntungan liyane sing bakal kita deleng? Lan dheweke mangsuli "Yooooooooooooooooooooooooooooooooode."
Yen sampeyan nginstal Google Cloud Platform SDK ("gcloud"), sampeyan bakal nampa kabar ing ngisor iki:
Dear panampa,
Kita pengin ngelingake sampeyan manawa dhukungan kanggo Python 2 wis ora digunakake, mula jancok sampeyan
… lan liya-liyane. Lingkaran urip.
Nanging titik kasebut saben pangembang duwe pilihan. Lan yen sampeyan meksa wong-wong mau kanggo nulis ulang kode asring cukup, padha bisa mikir bab liyane pilihan. Dheweke dudu sandera sampeyan, ora ketompo carane sampeyan pengin dadi. Padha tamu sampeyan. Python isih dadi basa pamrograman sing populer, nanging, Python 3(000) nggawe kekacoan dhewe, ing komunitas lan ing antarane pangguna komunitas sing akibate durung diresiki sajrone limalas taun.
Pira program Python sing wis ditulis maneh ing Go (utawa Ruby utawa sawetara alternatif liyane) amarga incompatibility mundur iki? Pinten lunak anyar wis ditulis ing soko liyane saka Python, sanajan iku bisa dadi ditulis ing Python, yen Guido wis ora ngobong kabeh desa? Iku hard kanggo ngomong, nanging Python wis cetha nandhang sangsara. Kekacoan gedhe lan kabeh wong kalah.
Dadi ayo ngomong Apple njupuk isyarat saka Guido lan ngilangi kompatibilitas. Apa sampeyan mikir sing bakal kelakon sabanjure? Ya, mungkin 80-90% pangembang bakal nulis ulang piranti lunak yen bisa. Ing tembung liyane, 10-20% saka basis pangguna kanthi otomatis menyang sawetara basa saingan, kayata Flutter.
Tindakake kaping pirang-pirang lan sampeyan bakal kelangan setengah basis pangguna. Kaya ing olahraga, ing jagad pemrograman, wujud saiki uga penting. сё. Sapa wae sing kelangan setengah pangguna sajrone limang taun bakal dianggep minangka Big Fat Loser. Sampeyan kudu dadi trendi ing jagad platform. Nanging ing kene ora ndhukung versi lawas bakal ngrusak sampeyan liwat wektu. Amarga saben-saben sampeyan nyingkirake sawetara pangembang, sampeyan (a) bakal ilang ing salawas-lawase amarga dheweke nesu marang sampeyan amarga nglanggar kontrak, lan (b) menehi menyang pesaing sampeyan.
Ironis, aku uga mbantu Google dadi primadona sing ora nglirwakake kompatibilitas mundur nalika nggawe Grok, sistem analisis kode sumber lan pangerten sing gampang ngotomatisasi lan instrumen kode kasebut dhewe - padha karo IDE, nanging ing kene nyimpen layanan awan. wujud perwakilan kabeh milyaran baris kode sumber Google ing gudang data gedhe.
Grok nyedhiyakake Googlers karo kerangka kuat kanggo nindakake refactorings otomatis ing kabeh basis kode (secara harfiah ing Google). Sistem ngetung ora mung dependensi hulu sampeyan (sing sampeyan gumantung), nanging uga mudun (sing terserah sampeyan) dadi nalika sampeyan ngganti API, sampeyan ngerti kabeh wong sing dilanggar! Kanthi cara iki, nalika sampeyan nggawe pangowahan, sampeyan bisa verifikasi manawa saben konsumen API sampeyan wis nganyari versi anyar, lan ing kasunyatan, asring nganggo alat Rosie sing ditulis, sampeyan bisa ngotomatisasi proses kasebut.
Iki ngidini basis kode Google dadi resik sacara internal meh supernaturally, amarga dheweke duwe abdi robot sing mlaku-mlaku ing omah lan kanthi otomatis ngresiki kabeh yen jenenge SomeDespicablyLongFunctionName dadi SomeDespicablyLongMethodName amarga ana sing mutusake yen dheweke putu sing ala lan kudu turu.
Lan sakbenere, kerjane apik banget kanggo Google ... sacara internal. Maksudku, ya, komunitas Go ing Google pancen ngguyu karo komunitas Jawa ing Google amarga kebiasaane refactoring terus-terusan. Yen sampeyan miwiti maneh soko N kaping, tegese sampeyan ora mung ngaco munggah N-1 kaping, nanging sawise nalika iku dadi cantik cetha sing mbokmenawa ngaco munggah ing Nth nyoba uga. Nanging, umume, dheweke tetep ing ndhuwur kabeh repot lan tetep kode "resik".
Masalah kasebut diwiwiti nalika nyoba ngetrapake sikap kasebut marang klien awan lan pangguna API liyane.
Aku wis ngenalaken sampeyan sethitik kanggo Emacs, Android lan Jawa; ayo deleng platform paling anyar sing sukses: Web dhewe. Apa sampeyan bisa mbayangno pirang-pirang iterasi sing wis ditindakake HTTP wiwit taun 1995 nalika nggunakake tag sing sumunar? lan lambang "Ing Konstruksi" ing kaca web.
Nanging isih bisa digunakake! Lan kaca-kaca iki isih bisa digunakake! Ya, wong lanang, browser minangka juara donya ing kompatibilitas mundur. Chrome minangka conto liyane saka platform Google sing langka sing wis dicopot kanthi bener, lan kaya sing sampeyan duga, Chrome kanthi efektif beroperasi minangka perusahaan kothak wedhi sing kapisah saka Google liyane.
Aku uga pengin matur nuwun marang kanca-kanca ing pangembang sistem operasi: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, lan sapiturute, amarga nindakake kompatibilitas mundur ing platform sing sukses (Apple entuk C paling apik karo The downside iku padha break kabeh kabeh wektu tanpa alesan apik, nanging piye wae masyarakat nemu watara karo saben release, lan kontaner OS X isih ora rampung lungse ... durung).
Nanging ngenteni, sampeyan ngomong. Apa kita ora mbandhingake apel karo jeruk - sistem piranti lunak mandiri ing mesin siji kaya Emacs/JDK/Android/Chrome versus sistem multi-server lan API kaya layanan awan?
Ya, aku tweeted babagan iki wingi, nanging ing gaya Larry Wall (pencipta basa pemrograman Perl - kira-kira saben.) Ing prinsip "nyedot / aturan" aku nggoleki tembung kasebut. deprecated ing situs pangembang Google lan Amazon. Lan sanajan AWS wis ratusan kaping luwih kurban layanan saka GCP, dokumentasi pangembang Google nyebataken deprecation bab kaping pitu luwih asring.
Yen ana wong ing Google sing maca iki, mesthine dheweke wis siyap narik grafik gaya Donald Trump sing nuduhake yen dheweke nindakake kabeh kanthi bener, lan aku ora kudu mbandhingake sing ora adil kaya "jumlah sebutan saka tembung sing ditinggalake mungsuh. nomer layanan ""
Nanging sawise pirang-pirang taun iki, Google Cloud isih dadi layanan nomer 3 (aku ora tau nulis artikel babagan upaya gagal dadi nomer 2), nanging yen wong njero kudu dipercaya, ana sawetara keprihatinan sing bisa ditindakake kanthi cepet. No. 4.
Aku ora duwe argumen sing kuat kanggo "mbuktèkaké" skripsiku. Kabeh sing dakkarepake yaiku conto warna-warni sing wis dakkumpulake sajrone 30 taun minangka pangembang. Aku wis kasebut sifat rumiyin filosofis saka masalah iki; ing sawetara cara dipolitisasi ing komunitas pangembang. Sawetara pracaya iku pangripta platform kudu Care babagan kompatibilitas, nalika liyane mikir sing iki badhan kedhaftar (pangembang dhewe). Siji saka loro. Pancen, apa ora masalah politik nalika kita mutusake sapa sing kudu nanggung biaya masalah umum?
Dadi iki politik. Lan mbokmenawa bakal ana respon nesu marang pidatoku.
Carane pangguna Google Cloud Platform, lan minangka pangguna AWS suwene rong taun (nalika kerja ing Grab), aku bisa ujar manawa ana bedane antarane filosofi Amazon lan Google nalika nerangake prioritas. Aku ora aktif berkembang ing AWS, dadi aku ora ngerti banget sepira kerepe mbusak API lawas. Nanging ana anggepan manawa iki ora kedadeyan kaya ing Google. Lan aku yakin manawa sumber kontroversi lan frustasi sing terus-terusan ing GCP iki minangka salah sawijining faktor paling gedhe sing nahan pangembangan platform kasebut.
Aku ngerti yen aku ora nyebutake conto tartamtu saka sistem GCP sing ora didhukung maneh. Aku bisa ngomong sing meh kabeh aku wis digunakake, saka jaringan (saka sing paling tuwa kanggo VPC) kanggo panyimpenan (Cloud SQL v1-v2), Firebase (saiki Firestore karo API temen beda), App Engine (ayo ora malah miwiti) , awan endpoint Cloud Endpoint lan nganti... Aku ora ngerti - pancen kabeh iki meksa sampeyan nulis ulang kode kasebut sawise maksimal 2-3 taun, lan dheweke ora tau ngotomatisasi migrasi kanggo sampeyan, lan asring . Kaya-kaya kudune.
Lan saben-saben aku ndeleng AWS, aku takon dhewe kenapa aku isih ana ing GCP. Dheweke jelas ora butuh klien. Dheweke butuh panuku. Apa sampeyan ngerti bedane? Ayo kula nerangake.
Google Cloud wis , ing ngendi wong ngusulake solusi piranti lunak, lan kanggo ngindhari efek restoran sing kosong, dheweke kudu ngisi sawetara proposal, mula dheweke dikontrak karo perusahaan sing diarani Bitnami kanggo nggawe pirang-pirang solusi sing disebarake kanthi "siji klik", utawa kudu Aku nulis dhewe "solusi," amarga iki ora ngatasi masalah. Dheweke mung ana minangka kothak centhang, minangka pangisi marketing, lan Google ora nate peduli manawa ana alat sing bener. Aku ngerti manajer produk sing wis ana ing kursi pembalap, lan aku bisa njamin yen wong-wong iki ora peduli.
Contone, contone, solusi penyebaran "siji-klik". . Aku lara mati amarga Google Cloud SQL shenanigans, mula aku wiwit ndeleng mbangun kluster Percona dhewe minangka alternatif. Lan wektu iki Google ketoke wis rampung proyek apik, padha bakal ngirit sawetara wektu lan gaweyan karo klik tombol!
Wah apik, ayo. Ayo tindakake link lan klik tombol iki. Pilih "Ya" kanggo setuju karo kabeh setelan gawan lan masang kluster ing proyek awan Google sampeyan. Haha, ora bisa. Ora ana omong kosong iki. Alat kasebut ora nate dites lan wiwit bosok wiwit menit pisanan, lan ora bakal kaget yen luwih saka setengah saka "solusi" minangka panyebaran siji-klik (saiki kita ngerti kenapa kuotasi kasebut) ing umum ora bisa. Iki pancen pepeteng tanpa pangarep-arep, ing ngendi luwih becik ora mlebu.
Nanging Google bener nyengkuyung sampeyan nggunakake mau. Dheweke pengin sampeyan tuku. Kanggo wong iku transaksi. Dheweke ora pengin apa-apa dhukungan. Iku dudu bagéan saka DNA Google. Ya, insinyur ndhukung saben liyane, minangka bukti saka critaku karo Bigtable. Nanging ing produk lan layanan kanggo wong biasa padha tansah padha kejem ing , sing ora ketemu bar kanggo untung sanajan wis mayuta-yuta pangguna.
Lan iki menehi tantangan nyata kanggo GCP amarga iki DNA konco kabeh kurban maya. Dheweke ora nyoba ndhukung apa-apa; Dikenal manawa dheweke ora gelem dadi tuan rumah (minangka layanan sing dikelola) piranti lunak pihak katelu nganti, nganti AWS nindakake perkara sing padha lan mbangun bisnis sing sukses ing saubengé, lan nalika pelanggan bener-bener nuntut sing padha. Nanging, butuh sawetara usaha kanggo njaluk Google ndhukung soko.
Kurang budaya dhukungan iki, ditambah karo mentalitas "ayo dibubarake supaya luwih apik", nggawe para pangembang asing.
Lan iku dudu perkara sing apik yen sampeyan pengin nggawe platform sing umure dawa.
Google, tangi, sialan. Saiki wis 2020. Sampeyan isih kalah. Iku wektu kanggo njupuk dipikir hard ing pangilon lan njawab apa sampeyan pancene pengin tetep ing bisnis maya.
Yen sampeyan pengin tetep banjur mungkasi rusak kabeh. Wong lanang, kowe sugih. Kita pangembang ora. Dadi nalika nerangake sapa sing bakal nanggung beban kompatibilitas, sampeyan kudu njupuk dhewe. Ora kanggo kita.
Amarga paling ora ana telung awan sing apik banget. Dheweke ngundang.
Lan saiki aku bakal nerusake kanggo ndandani kabeh sistem rusak. Eh.
Nganti wektu sabanjure!
Pembaruan PS sawise maca sawetara diskusi ing artikel iki (diskusi kasebut apik banget, btw). Dhukungan Firebase durung mandheg lan ora ana rencana sing dakkarepake. Nanging, dheweke duwe bug streaming sing nyebabake klien Java mandheg ing App Engine. Salah sawijining insinyur mbantu aku ngatasi masalah iki, nalika aku kerja ing Google, nanging dheweke ora nate ndandani bug kasebut, mula aku duwe solusi sing ora becik kanggo miwiti maneh aplikasi GAE saben dina. Lan wis patang taun! Dheweke saiki duwe Firestore. Butuh akeh gaweyan kanggo migrasi amarga iku sistem sing beda banget lan bug Firebase ora bakal diatasi. Apa kesimpulan sing bisa ditarik? Sampeyan bisa njaluk bantuan yen sampeyan kerja ing perusahaan. Aku mung siji-sijine sing nggunakake Firebase ing GAE amarga aku mlebu kurang saka 100 tombol ing aplikasi asli 100% lan ora bisa digunakake saben dina amarga ana bug sing dikenal. Apa aku bisa ngomong liyane saka nggunakake ing dhewe resiko. Aku ngalih menyang Redis.
Aku uga ndeleng sawetara pangguna AWS sing luwih berpengalaman ujar manawa AWS biasane ora mandheg ndhukung layanan apa wae, lan SimpleDB minangka conto sing apik. Asumsiku yen AWS ora duwe penyakit dhukungan sing padha karo Google kayane bisa dibenerake.
Kajaba iku, aku weruh yen 20 dina kepungkur tim Google App Engine nyuwil hosting perpustakaan Go kritis, mateni aplikasi GAE saka salah sawijining pangembang inti Go. Bodho tenan.
Pungkasan, aku wis krungu Googler wis ngrembug masalah iki lan umume setuju karo aku (tresno kowe!). Nanging dheweke mikir yen masalah kasebut ora bisa diatasi amarga budaya Google ora duwe struktur insentif sing bener. Aku panginten iku bakal apik kanggo njupuk sawetara wektu kanggo ngrembug pengalaman pancen apik tenan aku wis nggarap engineers AWS nalika makarya ing Grab. Ing sawijining dina ing mangsa ngarep, aku ngarep-arep!
Lan ya, ing taun 2005 dheweke duwe macem-macem jinis daging hiu ing prasmanan raksasa ing gedung 43, lan sing paling disenengi yaiku daging hiu martil. Nanging, ing taun 2006, Larry lan Sergei nyingkirake kabeh cemilan sing ora sehat. Dadi sajrone crita Bigtable ing taun 2007 pancen ora ana hiu lan aku ngapusi sampeyan.
Nalika aku ndeleng awan Bigtable patang taun kepungkur (menehi utawa njupuk), iki ngendi biaya. Kayane saiki wis mudhun, nanging isih akeh banget kanggo gudang data kosong, utamane amarga crita pertamaku nuduhake kepiye meja gedhe sing ora ana gandhengane.
Nuwun sewu kanggo nyinggung masyarakat Apple lan ora ngandika apik bab Microsoft etc.. Sampeyan kabeh tengen, Aku appreciate kabeh diskusi artikel iki wis kui! Nanging kadhangkala sampeyan kudu nggawe ombak sethithik kanggo miwiti diskusi, ngerti?
Matur nuwun kanggo maca.
Dianyari 2, 19.08.2020/XNUMX/XNUMX. belang !
Dianyari 3, 31.08.2020/2/2. Aku dikontak dening insinyur Google ing Cloud Marketplace sing dadi kanca lawasku. Dheweke pengin ngerti sebabe CXNUMXD ora bisa digunakake, lan pungkasane ngerti amarga aku wis nggawe jaringanku pirang-pirang taun kepungkur, lan CXNUMXD ora bisa digunakake ing jaringan warisan amarga parameter subnet ilang ing template kasebut. Aku mikir sing paling apik kanggo pangguna GCP potensial kanggo mesthekake yen dheweke ngerti cukup insinyur ing Google...
Source: www.habr.com