Damn Google, ayoko nang mag-blog ulit. Marami akong gagawin. Ang pagba-blog ay nangangailangan ng oras, lakas at pagkamalikhain, na maaari kong gamitin: ang aking mga libro, , aking laro at iba pa. Pero sapat na ang inis mo sa akin kaya kailangan kong isulat ito.
Kaya't tapusin na natin ito.
Hayaan akong magsimula sa isang maikli ngunit nakapagtuturo na kuwento mula noong una akong nagsimulang magtrabaho sa Google. Alam kong marami akong sinasabing masasamang bagay tungkol sa Google kamakailan, ngunit nakakainis ako kapag ang sarili kong kumpanya ay regular na gumagawa ng mga walang kakayahan na desisyon sa negosyo. Kasabay nito, dapat nating ibigay ang nararapat: Ang panloob na imprastraktura ng Google ay talagang pambihira, ligtas na sabihin na walang mas mahusay ngayon. Ang mga tagapagtatag ng Google ay mas mahuhusay na inhinyero kaysa sa akin, at ang kuwentong ito ay nagpapatunay lamang sa katotohanang iyon.
Una, isang maliit na background: Ang Google ay may teknolohiya sa pag-iimbak ng data na tinatawag . Ito ay isang kahanga-hangang teknikal na tagumpay, isa sa una (kung hindi man ang una) "walang katapusan na nasusukat" na key-value store (K/V): mahalagang simula ng NoSQL. Sa mga araw na ito, maganda pa rin ang takbo ng Bigtable sa medyo masikip na espasyo ng imbakan ng K/V, ngunit noong panahong iyon (2005) ito ay kahanga-hangang cool.
Ang isang nakakatawang bagay tungkol sa Bigtable ay mayroon silang mga internal control plane object (bilang bahagi ng pagpapatupad) na tinatawag na mga tablet server, na may malalaking index, at sa ilang sandali ay naging bottleneck sila kapag sinusuri ang system. Ang mga inhinyero ng Bigtable ay naguguluhan kung paano ipatupad ang scalability, at biglang napagtanto na maaari nilang palitan ang mga server ng tablet ng iba pang storage ng Bigtable. Kaya bahagi ang Bigtable ng pagpapatupad ng Bigtable. Ang mga pasilidad ng imbakan na ito ay naroroon sa lahat ng antas.
Ang isa pang kawili-wiling detalye ay ang Bigtable ay naging tanyag at nasa lahat ng dako sa loob ng Google sa loob ng ilang sandali, na ang bawat koponan ay may sariling repositoryo. Kaya sa isa sa mga pagpupulong sa Biyernes, kaswal na nagtanong si Larry Page: "Bakit mayroon tayong higit sa isang Bigtable? Bakit hindi na lang isa?" Sa teorya, dapat sapat ang isang storage para sa lahat ng pangangailangan ng storage ng Google. Siyempre, hindi sila pumunta sa isa lamang para sa mga praktikal na dahilan ng pag-unlad (tulad ng mga kahihinatnan ng isang potensyal na pagkabigo), ngunit ang teorya ay kawili-wili. Isang imbakan para sa buong Uniberso (By the way, may nakakaalam ba kung ginawa ito ng Amazon sa kanilang Sable?)
Anyway, eto ang kwento ko.
Noong panahong iyon, mahigit dalawang taon lang akong nagtatrabaho sa Google, at isang araw nakatanggap ako ng email mula sa Bigtable engineering team na naging ganito:
Dear Steve,
Hello mula sa Bigtable team. Nais naming ipaalam sa iyo na sa [pangalan ng data center] gumagamit ka ng napakalumang Bigtable binary. Hindi na sinusuportahan ang bersyong ito at gusto naming tulungan kang mag-upgrade sa pinakabagong bersyon.
Mangyaring ipaalam sa akin kung maaari kang mag-iskedyul ng ilang oras upang magtulungan sa isyung ito.
Lahat ng pinakamahusay,
Bigtable Team
Sa Google nakakakuha ka ng maraming mail, kaya sa unang tingin ay may nabasa akong ganito:
Minamahal na Tatanggap,
Hello mula sa ilang team. Gusto naming makipag-usap na blah blah blah blah blah. Blah blah blah blah blah blah, at blah blah blah agad.
Mangyaring ipaalam sa amin kung maaari mong iiskedyul ang ilan sa iyong mahalagang oras para sa blah blah blah.
Lahat ng pinakamahusay,
Isang uri ng utos
Muntik ko nang tanggalin ito kaagad, ngunit sa dulo ng aking kamalayan ay nakaramdam ako ng masakit, nakakapanghinayang pakiramdam na iyon. hindi talaga parang pormal na sulat malinaw naman, na nagkamali ang tatanggap dahil hindi ako gumamit ng Bigtable.
Ngunit ito ay kakaiba.
Ginugol ko ang natitirang bahagi ng araw sa salit-salit na pag-iisip tungkol sa trabaho at kung anong uri ng karne ng pating ang susubukan sa micro-kitchen, kung saan ang hindi bababa sa tatlo ay malapit na upang tamaan mula sa aking upuan ng isang mahusay na layunin na paghagis ng isang biskwit, ngunit ang Ang pag-iisip na magsulat ay hindi nag-iwan sa akin ng lumalagong pakiramdam ng banayad na pagkabalisa.
Malinaw nilang sinabi ang pangalan ko. At ang email ay ipinadala sa aking email address, hindi sa ibang tao, at hindi ito cc: o bcc:. Napakapersonal at malinaw ang tono. Marahil ito ay isang uri ng pagkakamali?
Sa wakas, nadagdagan ako ng kuryusidad at tumingin ako sa Borg console sa data center na binanggit nila.
At siyempre, mayroon akong BigTable storage sa ilalim ng pamamahala. Sorry, ano? Tiningnan ko ang laman nito, and wow! Ito ay mula sa Codelab incubator kung saan ako nakaupo noong unang linggo ko sa Google noong Hunyo 2005. Pinilit ka ng Codelab na patakbuhin ang Bigtable upang magsulat ng ilang mga halaga doon, at tila hindi ko na isinara ang imbakan pagkatapos noon. Gumagana pa rin ito kahit mahigit dalawang taon na ang lumipas.
Mayroong ilang mga kapansin-pansin na aspeto sa kuwentong ito. Una, ang gawain ng Bigtable ay napakaliit sa sukat ng Google na makalipas lamang ang dalawang taon ay napansin ng sinuman ang labis na storage, at dahil lamang sa luma na ang bersyon ng binary. Para sa paghahambing, minsan naisip kong gamitin para sa online game ko. Sa panahong iyon, ang serbisyong ito ay nagkakahalaga ng humigit-kumulang $16 bawat taon. walang laman Bigtable sa GCP. Hindi ko sinasabing niloloko ka nila, ngunit sa aking personal na opinyon, iyon ay maraming pera para sa isang walang laman na database ng fucking.
Ang isa pang kapansin-pansin na aspeto ay ang imbakan nagtatrabaho pa rin pagkatapos ng dalawang taon. WTF? Dumating at umalis ang mga data center; nakakaranas sila ng outages, sumasailalim sila sa scheduled maintenance, nagbabago sila sa lahat ng oras. Ang hardware ay na-update, ang mga switch ay pinapalitan, ang lahat ay patuloy na pinapabuti. Paano nila nagawang panatilihing tumatakbo ang aking programa sa loob ng dalawang taon sa lahat ng mga pagbabagong ito? Ito ay maaaring mukhang isang maliit na tagumpay sa 2020, ngunit noong 2005-2007 ito ay lubos na kahanga-hanga.
At ang pinakakahanga-hangang aspeto ay ang isang labas ng engineering team sa ibang estado ay lumapit sa akin, ang may-ari ng ilang maliit, halos walang laman na instance ng Bigtable, na may walang trapiko sa nakalipas na dalawang taon - at nag-aalok ng tulong upang i-update ito.
Nagpasalamat ako sa kanila, tinanggal ang imbakan, at nagpatuloy ang buhay gaya ng dati. Ngunit makalipas ang labintatlong taon, iniisip ko pa rin ang liham na iyon. Dahil minsan nakakatanggap ako ng mga katulad na email mula sa Google Cloud. Ganito ang hitsura nila:
Minamahal na Gumagamit ng Google Cloud,
Bilang paalala, ihihinto namin ang serbisyong [mahahalagang serbisyo na ginagamit mo] simula Agosto 2020, pagkatapos nito ay hindi mo na maa-upgrade ang iyong mga instance. Inirerekomenda namin ang pag-upgrade sa pinakabagong bersyon, na nasa beta testing, walang dokumentasyon, walang migration path at nauna nang luma sa aming tulong.
Nakatuon kami sa pagtiyak na ang pagbabagong ito ay may kaunting epekto sa lahat ng user ng Google Cloud platform.
Matalik na kaibigan magpakailanman,
Google Cloud Platform
Ngunit halos hindi ko nabasa ang gayong mga liham, dahil ang talagang sinasabi nila ay:
Minamahal na Tatanggap,
Pumunta sa impiyerno. Fuck you, fuck you, fuck you. I-drop ang lahat ng iyong ginagawa dahil ito ay hindi mahalaga. Ang mahalaga ay ang ating oras. We waste time and money maintaining our crap and we are tired of it so we don't support it anymore. Kaya itigil mo na ang iyong mga plano at simulan ang paghuhukay sa aming mga bastos na dokumentasyon, paghingi ng mga scrap sa mga forum, at sa pamamagitan ng paraan, ang aming bagong tae ay ganap na naiiba mula sa lumang tae, dahil nasira namin ang disenyo na ito medyo masama, heh, ngunit iyon ang iyong problema, hindi sa atin.
Patuloy kaming nagsusumikap upang matiyak na ang lahat ng iyong mga pag-unlad ay hindi magagamit sa loob ng isang taon.
Please fuck off
Google Cloud Platform
At ang katotohanan ay nakakatanggap ako ng gayong mga liham halos isang beses sa isang buwan. Nangyayari ito nang napakadalas at patuloy na hindi maiiwasan itinulak palayo mula sa GCP hanggang sa anti-cloud camp. Hindi na ako sumasang-ayon na umasa sa kanilang pagmamay-ari na mga pag-unlad, dahil sa katunayan ay mas madali para sa mga devop na magpanatili ng isang open source system sa isang hubad na virtual machine kaysa sa subukang makipagsabayan sa Google sa patakaran nito sa pagsasara ng "luma na" na mga produkto.
Bago ako bumalik sa Google Cloud dahil ako hindi man lang malapit hindi pa tapos na punahin sila, tingnan natin ang performance ng kumpanya sa ibang lugar. Ipinagmamalaki ng mga inhinyero ng Google ang kanilang sarili sa kanilang disiplina sa software engineering, at ito ang aktwal na nagdudulot ng mga problema. Ang pagmamataas ay isang bitag para sa mga hindi nag-iingat, at nagdulot ito ng maraming empleyado ng Google na isipin na ang kanilang mga desisyon ay palaging tama at ang pagiging tama (sa ilang malabo na malabong kahulugan) ay mas mahalaga kaysa sa pagmamalasakit sa mga customer.
Magbibigay ako ng ilang random na halimbawa mula sa iba pang malalaking proyekto sa labas ng Google, ngunit sana ay makita mo ang pattern na ito sa lahat ng dako. Ito ay ang mga sumusunod: Ang backward compatibility ay nagpapanatili sa mga system na buhay at napapanahon sa loob ng mga dekada.
Ang backward compatibility ay ang layunin ng disenyo ng lahat ng matagumpay na system na idinisenyo para sa bukas gamitin, ibig sabihin, ipinatupad gamit ang open source code at/o open standards. Pakiramdam ko ay may sinasabi akong masyadong halata na ang lahat ay hindi komportable, ngunit hindi. Ito ay isyung pampulitika, kaya kailangan ng mga halimbawa.
Ang unang sistema na pipiliin ko ay ang pinakamatanda: GNU Emacs, na isang uri ng hybrid sa pagitan ng Windows Notepad, ang OS kernel, at ang International Space Station. Medyo mahirap ipaliwanag, ngunit sa madaling sabi, ang Emacs ay isang platform na nilikha noong 1976 (oo, halos kalahating siglo na ang nakalipas) para sa programming upang gawing mas produktibo ka, ngunit nagpapanggap bilang isang text editor.
Gumagamit ako ng Emacs araw-araw. Oo, gumagamit din ako ng IntelliJ araw-araw, ito ay lumago sa isang malakas na tooling platform sa sarili nitong karapatan. Ngunit ang pagsulat ng mga extension para sa IntelliJ ay isang mas ambisyoso at kumplikadong gawain kaysa sa pagsulat ng mga extension para sa Emacs. At higit sa lahat, lahat ng nakasulat para sa Emacs ay napanatili magpakailanman.
Ginagamit ko pa rin ang software na isinulat ko para sa Emacs noong 1995. At sigurado akong may gumagamit ng mga module na isinulat para sa Emacs noong kalagitnaan ng 80s, kung hindi mas maaga. Maaaring mangailangan sila ng kaunting pag-aayos paminsan-minsan, ngunit ito ay talagang bihira. Wala akong alam na anumang naisulat ko para sa Emacs (at marami na akong naisulat) na nangangailangan ng muling arkitektura.
Ang Emacs ay may function na tinatawag na make-obsolete para sa mga hindi na ginagamit na entity. Ang terminolohiya ng Emacs para sa mga pangunahing konsepto ng computer (tulad ng kung ano ang isang "window") ay kadalasang naiiba sa mga kombensiyon sa industriya dahil ipinakilala sila ng Emacs matagal na ang nakalipas. Isa itong tipikal na panganib para sa mga nauuna sa kanilang oras: lahat ng iyong mga tuntunin ay mali. Ngunit ang Emacs ay may konsepto ng deprecation, na sa kanilang jargon ay tinatawag pagkalayo.
Ngunit sa mundo ng Emacs ay tila may ibang kahulugan sa pagtatrabaho. Isang ibang pinagbabatayan na pilosopiya, kung gugustuhin mo.
Sa mundo ng Emacs (at sa maraming iba pang mga lugar, na tatalakayin namin sa ibaba), ang hindi na ginagamit na katayuan ng API ay karaniwang nangangahulugang: "Talagang hindi mo dapat gamitin ang diskarteng ito, dahil habang gumagana ito, dumaranas ito ng iba't ibang mga pagkukulang na gagawin natin. listahan dito. Pero at the end of the day, ikaw ang pumili."
Sa mundo ng Google, ang ibig sabihin ng pagiging laos ay, "Kami ay lumalabag sa aming pangako sa iyo." Ito ay totoo. Ito ang mahalagang kahulugan nito. Ibig sabihin pipilitin ka nila regular gumawa ng ilang trabaho, marahil ng maraming trabaho, bilang parusa sa paniniwala sa kanila : Mayroon kaming pinakamahusay na software. Ang pinakamabilis! Ginagawa mo ang lahat ayon sa mga tagubilin, ilunsad ang iyong aplikasyon o serbisyo, at pagkatapos ay bam, pagkatapos ng isang taon o dalawa ay masira ito.
Parang pagbebenta ng used car na siguradong masisira after 1500 km.
Ito ay dalawang ganap na magkaibang pilosopikal na kahulugan ng "pagkaluma." Ang kahulugan ng amoy ng Google . Hindi ako naniniwala dito sa katunayan nakaplanong pagkaluma sa parehong kahulugan ng Apple. Ngunit talagang pinaplano ng Google na sirain ang iyong mga programa, sa paikot-ikot na paraan. Alam ko ito dahil nagtrabaho ako doon bilang isang software engineer sa loob ng mahigit 12 taon. Mayroon silang hindi malinaw na panloob na mga alituntunin sa kung gaano karaming backward compatibility ang dapat sundin, ngunit sa huli ay nakasalalay sa bawat indibidwal na koponan o serbisyo. Walang mga rekomendasyon sa antas ng enterprise o engineering, at ang pinakamatapang na rekomendasyon sa mga tuntunin ng mga obsolescence cycle ay "subukang bigyan ang mga customer ng 6-12 buwan upang mag-upgrade bago sirain ang kanilang buong system."
Ang problema ay mas malaki kaysa sa kanilang iniisip, at ito ay magpapatuloy sa mga darating na taon dahil ang pangangalaga sa customer ay wala sa kanilang DNA. Higit pa tungkol dito sa ibaba.
Sa puntong ito gagawa ako ng isang matapang na pahayag na ang Emacs ay matagumpay sa isang malaking lawak at kahit na pangunahin dahil sineseryoso nila ang backwards compatibility. Sa totoo lang, ito ang thesis ng aming artikulo. Ang matagumpay, matagal nang bukas na mga sistema ay may utang sa kanilang tagumpay sa mga microcommunity na nabuhay sa kanilang paligid sa loob ng mga dekada mga extension/plugin. Ito ang ecosystem. Napag-usapan ko na ang tungkol sa likas na katangian ng mga platform at kung gaano kahalaga ang mga ito, at kung paano hindi kailanman naunawaan ng Google sa buong kasaysayan ng kumpanya nito kung ano ang pumapasok sa paglikha ng isang matagumpay na bukas na platform sa labas ng Android o Chrome.
Sa totoo lang, dapat kong banggitin ang Android nang maikli dahil malamang na iniisip mo ito.
Una, ang Ang Android ay hindi Google. Halos wala silang pagkakatulad sa isa't isa. Ang Android ay isang kumpanya na binili ng Google noong Hulyo 2005, ang kumpanya ay pinahintulutan na gumana nang higit pa o hindi gaanong nagsasarili at sa katunayan ay nanatiling hindi nagalaw sa mga nagdaang taon. Ang Android ay isang kilalang-kilalang tech stack at isang pantay na kilalang matinik na organisasyon. Tulad ng sinabi ng isang Googler, "Hindi ka maaaring mag-log in sa Android."
Sa isang nakaraang artikulo, tinalakay ko kung gaano kalala ang ilan sa mga naunang desisyon sa disenyo ng Android. Ano ba, noong isinulat ko ang artikulong iyon ay naglalabas sila ng crap na tinatawag na "instant apps" na ngayon ay (sorpresa!) , at nakikiramay ako kung naging tanga ka para makinig sa Google at ilipat ang iyong content sa mga instant na app na ito.
Ngunit may pagkakaiba dito, isang makabuluhang pagkakaiba, na talagang nauunawaan ng mga taong Android kung gaano kahalaga ang mga platform, sinusubukan nila ang kanilang makakaya upang panatilihing gumagana ang mga lumang Android app. Sa katunayan, ang kanilang mga pagsisikap na mapanatili ang backward compatibility ay napakatindi na kahit ako, sa aking maikling stint sa Android division ilang taon na ang nakakaraan, natagpuan ang aking sarili na sinusubukang kumbinsihin silang ihinto ang suporta para sa ilan sa mga pinakalumang device at API (ako ay mali , gaya ng sa maraming iba pang bagay noon at kasalukuyan. Paumanhin, mga ka-Android! Ngayong nakapunta na ako sa Indonesia, naiintindihan ko na kung bakit natin kailangan ang mga ito).
Itinutulak ng mga taong Android ang pagiging tugma sa halos hindi maisip na mga sukdulan, na nagtatambak ng napakalaking halaga ng legacy na teknikal na utang sa kanilang mga system at toolchain. Oh diyos ko, dapat mong makita ang ilan sa mga nakatutuwang bagay na kailangan nilang gawin sa kanilang build system, lahat sa ngalan ng compatibility.
Para dito, iginawad ko sa Android ang inaasam-asam na award na "You're Not Google." Talagang ayaw nilang maging Google, na hindi alam kung paano gumawa ng mga matibay na platform, ngunit Android alam, kung paano ito gawin. At kaya napakatalino ng Google sa isang aspeto: pinapayagan ang mga tao na gawin ang mga bagay sa sarili nilang paraan sa Android.
Gayunpaman, ang mga instant na app para sa Android ay isang medyo hangal na ideya. At alam mo kung bakit? Dahil nagdemand sila muling isulat at muling idisenyo ang iyong aplikasyon! Parang susulat na lang ulit ng dalawang milyong application ang mga tao. Sa palagay ko, ang Instant Apps ay ilang ideya ng Googler.
Ngunit may pagkakaiba. Malaki ang halaga ng backward compatibility. Ang Android mismo ang nagdadala ng pasanin ng mga gastos na ito, habang iginigiit ng Google na pasanin ang pasanin sa iyo, nagbabayad na kliyente.
Makikita mo ang pangako ng Android sa pabalik na compatibility sa mga API nito. Kapag mayroon kang apat o limang magkakaibang subsystem na literal na gumagawa ng parehong bagay, ito ay isang tiyak na senyales na mayroong isang pangako sa pabalik na pagkakatugma sa ubod. Na sa mundo ng mga platform ay kasingkahulugan ng pangako sa iyong mga customer at sa iyong market.
Ang pangunahing problema ng Google dito ay ang kanilang pagmamalaki sa kanilang engineering hygiene. Hindi nila gusto kapag mayroong maraming iba't ibang paraan upang gawin ang parehong bagay, na ang mga luma, hindi gaanong kanais-nais na mga paraan ay nakaupo sa tabi ng bago, mas mahilig sa mga paraan. Pinapataas nito ang kurba ng pagkatuto para sa mga bago sa system, pinatataas nito ang pasanin sa pagpapanatili ng mga legacy na API, pinapabagal nito ang bilis ng mga bagong feature, at ang pangunahing kasalanan ay hindi ito maganda. Google - tulad ng Lady Ascot mula sa Alice in Wonderland ni Tim Burton:
Lady Ascot:
- Alice, alam mo ba kung ano ang pinakakinatatakutan ko?
- Ang pagtanggi ng aristokrasya?
- Natakot ako na magkakaroon ako mga pangit na apo.
Upang maunawaan ang tradeoff sa pagitan ng maganda at praktikal, tingnan natin ang ikatlong matagumpay na platform (pagkatapos ng Emacs at Android) at tingnan kung paano ito gumagana: ang Java mismo.
Ang Java ay may maraming hindi napapanahong mga API. Napakasikat ng paghinto sa paggamit sa mga programmer ng Java, mas sikat pa kaysa sa karamihan ng mga programming language. Ang Java mismo, ang pangunahing wika, at ang mga aklatan ay patuloy na hindi ginagamit ang mga API.
Upang kumuha lamang ng isa sa libu-libong mga halimbawa, itinuturing na lipas na. Ito ay hindi na ginagamit mula noong inilabas ang Java 1.2 noong Disyembre 1998. 22 taon na ang nakalipas mula nang hindi ito ginagamit.
Ngunit ang aking aktwal na code sa produksyon ay pumapatay pa rin ng mga thread araw-araw. Sa tingin mo ba talaga maganda iyan? Ganap! Ibig kong sabihin, siyempre, kung isusulat kong muli ang code ngayon, iba ang ipapatupad ko. Ngunit ang code para sa aking laro, na nagpasaya sa daan-daang libong tao sa nakalipas na dalawang dekada, ay nakasulat na may function upang isara ang mga thread na masyadong mahaba, at ako hindi na kailangang baguhin ito. Alam ko ang aking sistema nang mas mahusay kaysa sa sinuman, mayroon akong literal na 25 taong karanasan sa paggawa nito sa produksyon, at masasabi kong sigurado: sa aking kaso, ang pagsasara ng mga partikular na thread ng manggagawa ay ganap na hindi nakakapinsala. Hindi katumbas ng oras at pagsisikap na muling isulat ang code na ito, at salamat kay Larry Ellison (marahil) na hindi ako pinilit ng Oracle na isulat ito muli.
Marahil ay naiintindihan din ng Oracle ang mga platform. Sino ang nakakaalam.
Matatagpuan ang katibayan sa kabuuan ng mga pangunahing Java API, na puno ng mga alon ng pagkaluma, tulad ng mga linya ng glacier sa isang canyon. Madali kang makakahanap ng lima o anim na magkakaibang keyboard navigation manager (KeyboardFocusManager) sa library ng Java Swing. Mahirap talagang makahanap ng Java API na hindi na ginagamit. Ngunit gumagana pa rin sila! Sa tingin ko, ang Java team ay talagang mag-aalis lamang ng isang API kung ang interface ay nagdudulot ng matingkad na isyu sa seguridad.
Narito ang bagay, mga kababayan: Kaming mga developer ng software ay abala lahat, at sa bawat lugar ng software ay nahaharap kami sa mga nakikipagkumpitensyang alternatibo. Sa anumang oras, ang mga programmer sa wikang X ay isinasaalang-alang ang wikang Y bilang isang posibleng kapalit. Oh, hindi ka naniniwala sa akin? Gusto mo bang tawagan itong Swift? Tulad ng, lahat ay nag-migrate sa Swift at walang umaabanduna dito, tama ba? Wow, ang liit ng alam mo. Binibilang ng mga kumpanya ang mga gastos ng dalawahang mobile development team (iOS at Android) - at nagsisimula na silang matanto na ang mga cross-platform na development system na may mga nakakatawang pangalan tulad ng Flutter at React Native ay talagang gumagana at magagamit upang bawasan ang laki ng kanilang mga mobile team nang dalawang beses o, sa kabaligtaran, ginagawa silang dalawang beses bilang produktibo. May totoong pera ang nakataya. Oo, may mga kompromiso, ngunit, sa kabilang banda, pera.
Ipagpalagay natin na ang Apple ay may katangahang kumuha ng cue mula kay Guido van Rossum at ipinahayag na ang Swift 6.0 ay pabalik na hindi tugma sa Swift 5.0, tulad ng Python 3 ay hindi tugma sa Python 2.
Marahil ay kinuwento ko ang kuwentong ito mga sampung taon na ang nakalilipas, ngunit mga labinlimang taon na ang nakalilipas nagpunta ako sa O'Reilly's Foo Camp kasama si Guido, naupo sa isang tolda kasama si Paul Graham at isang grupo ng mga malalaking shot. Nakaupo kami sa napakainit na init habang naghihintay na lumipad si Larry Page sakay ng kanyang personal na helicopter habang si Guido ay naka-drone sa tungkol sa "Python 3000," na pinangalanan niya pagkatapos ng bilang ng mga taon na aabutin para sa lahat upang lumipat doon. Paulit-ulit namin siyang tinatanong kung bakit niya sinisira ang compatibility, at sumagot siya: βUnicode.β At tinanong namin, kung kailangan naming muling isulat ang aming code, ano ang iba pang mga benepisyo ang makikita namin? At sumagot siya ng "Yoooooooooooooooouuuuuuuuniiiiiiioooooooode."
Kung i-install mo ang Google Cloud Platform SDK (βgcloudβ), matatanggap mo ang sumusunod na notification:
Minamahal na Tatanggap,
Nais naming ipaalala sa iyo na ang suporta para sa Python 2 ay hindi na ginagamit, kaya fuck ka
β¦ at iba pa. Bilog ng buhay.
Ngunit ang punto ay ang bawat developer ay may pagpipilian. At kung pipilitin mo silang muling isulat ang code nang madalas, maaari nilang isipin iba mga pagpipilian. Hindi mo sila mga hostage, kahit gaano mo sila gusto. Sila ang iyong mga bisita. Ang Python ay isa pa ring napakasikat na programming language, ngunit mapahamak, ang Python 3(000) ay lumikha ng ganoong gulo sa sarili nito, sa mga komunidad nito at sa mga gumagamit ng mga komunidad nito na ang mga kahihinatnan ay hindi naalis sa loob ng labinlimang taon.
Gaano karaming mga programa ng Python ang muling isinulat sa Go (o Ruby, o iba pang alternatibo) dahil sa hindi pagkakatugma na ito? Gaano karaming bagong software ang naisulat sa isang bagay maliban sa Python, bagama't ito maaaring maging nakasulat sa Python, kung hindi sinunog ni Guido ang buong nayon? Mahirap sabihin, ngunit malinaw na nagdusa si Python. Ito ay isang malaking gulo at lahat ay natalo.
Kaya't sabihin nating kumukuha ang Apple ng cue mula sa Guido at sinira ang compatibility. Ano sa tingin mo ang susunod na mangyayari? Well, marahil 80-90% ng mga developer ay muling isusulat ang kanilang software kung maaari. Sa madaling salita, 10-20% ng user base ang awtomatikong napupunta sa ilang nakikipagkumpitensyang wika, gaya ng Flutter.
Gawin ito nang maraming beses at mawawala sa iyo ang kalahati ng iyong user base. Tulad ng sa sports, sa mundo ng programming, mahalaga din ang kasalukuyang anyo. Π²ΡΡ. Ang sinumang mawalan ng kalahati ng kanilang mga user sa loob ng limang taon ay ituturing na Big Fat Loser. Dapat ay uso ka sa mundo ng mga platform. Ngunit dito ka masisira sa paglipas ng panahon ang hindi pagsuporta sa mga mas lumang bersyon. Dahil sa tuwing aalisin mo ang ilang developer, (a) mawawala sila nang tuluyan dahil galit sila sa iyong paglabag sa kontrata, at (b) ibigay sila sa iyong mga kakumpitensya.
Kabalintunaan, tinulungan ko rin ang Google na maging isang prima donna na hindi pinapansin ang backward compatibility noong ginawa ko ang Grok, isang source code analysis at understanding system na nagpapadali sa pag-automate at instrumento sa mismong code - katulad ng isang IDE, ngunit narito ang cloud service store. nagkatawang mga representasyon ng lahat ng bilyun-bilyong linya ng source code ng Google sa isang malaking warehouse ng data.
Nagbigay ang Grok sa mga Googler ng isang makapangyarihang framework para sa pagsasagawa ng mga automated na refactoring sa kanilang buong codebase (literal sa buong Google). Kinakalkula ng system hindi lamang ang iyong upstream dependencies (kung saan ka umaasa), kundi pati na rin sa ilog (na ikaw ang bahala) kaya kapag nagpalit ka ng mga API, alam mo lahat na sinisiraan mo! Sa ganitong paraan, kapag gumawa ka ng mga pagbabago, maaari mong i-verify na ang bawat consumer ng iyong API ay nag-update sa bagong bersyon, at sa katotohanan, kadalasan gamit ang Rosie tool na kanilang isinulat, maaari mong ganap na i-automate ang proseso.
Binibigyang-daan nito ang codebase ng Google na maging halos supernatural na malinis, dahil mayroon silang mga robotic na tagapaglingkod na umaaligid sa bahay at awtomatikong nililinis ang lahat kung pinalitan nila ang SomeDespicablyLongFunctionName ng SomeDespicablyLongMethodName dahil may nagpasya na ito ay isang pangit na apo at kailangan niyang patulugin.
At sa totoo lang, ito ay gumagana nang maayos para sa Google... sa loob. Ibig kong sabihin, oo, ang komunidad ng Go sa Google ay natatawa sa komunidad ng Java sa Google dahil sa kanilang ugali ng patuloy na refactoring. Kung nag-restart ka ng isang bagay nang N beses, nangangahulugan iyon na hindi mo lang ito na-screwed up N-1 beses, ngunit pagkatapos ng ilang sandali ay nagiging medyo malinaw na malamang na screwed mo ito sa Nth pagsubok pati na rin. Ngunit, sa pangkalahatan, nananatili silang higit sa lahat ng kaguluhang ito at pinananatiling "malinis" ang code.
Nagsisimula ang problema kapag sinubukan nilang ipataw ang saloobing ito sa kanilang mga cloud client at user ng iba pang mga API.
Ipinakilala ko sa iyo ng kaunti ang Emacs, Android at Java; tingnan natin ang pinakabagong matagumpay na pangmatagalang platform: ang Web mismo. Naiisip mo ba kung gaano karaming mga pag-ulit ang pinagdaanan ng HTTP mula noong 1995 nang gumamit kami ng mga flashing na tag? at mga icon na "Under Construction" sa mga web page.
Ngunit gumagana pa rin ito! At gumagana pa rin ang mga page na ito! Oo, guys, ang mga browser ang world champion sa backward compatibility. Ang Chrome ay isa pang halimbawa ng pambihirang platform ng Google na tama ang mga ulo nito, at tulad ng nahulaan mo, epektibong gumagana ang Chrome bilang isang sandboxed na kumpanya na hiwalay sa iba pang bahagi ng Google.
Nais ko ring pasalamatan ang aming mga kaibigan sa mga developer ng operating system: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, atbp., sa paggawa ng napakagandang trabaho ng backwards compatibility sa kanilang matagumpay na mga platform (Ang Apple ay nakakakuha ng C sa pinakamahusay sa The Ang downside ay ang lahat ng bagay ay sinisira nila sa lahat ng oras nang walang magandang dahilan, ngunit kahit papaano ay napapalibutan ito ng komunidad sa bawat paglabas, at ang mga lalagyan ng OS X ay hindi pa rin ganap na lipas... pa).
Pero teka, sabi mo. Hindi ba't inihahambing natin ang mga mansanas sa mga dalandan - mga standalone na software system sa isang makina tulad ng Emacs/JDK/Android/Chrome kumpara sa mga multi-server system at mga API tulad ng mga serbisyo sa cloud?
Well, nag-tweet ako tungkol dito kahapon, ngunit sa istilo ni Larry Wall (tagalikha ng programming language na Perl - approx. per.) sa prinsipyo ng "sucks/rules" hinanap ko ang salita hindi na ginagamit sa mga site ng developer ng Google at Amazon. At kahit na mayroon ang AWS daan-daan beses na mas maraming alok ng serbisyo kaysa sa GCP, binanggit ng dokumentasyon ng developer ng Google ang paghinto sa paggamit nang halos pitong beses na mas madalas.
Kung sinuman sa Google ang nagbabasa nito, malamang na handa na silang maglabas ng mga chart na istilo ni Donald Trump na nagpapakita na ginagawa nila ang lahat ng tama, at hindi ako dapat gumawa ng mga hindi patas na paghahambing tulad ng "bilang ng mga pagbanggit ng salitang hindi na ginagamit kumpara sa bilang ng mga serbisyo" "
Ngunit pagkatapos ng lahat ng mga taon na ito, ang Google Cloud pa rin ang No. 3 na serbisyo (hindi ako nagsulat ng isang artikulo tungkol sa nabigong pagtatangka na maging No. 2), ngunit kung ang mga tagaloob ay paniniwalaan, may ilang mga alalahanin na maaari nilang ibagsak sa lalong madaling panahon. No. 4.
Wala akong anumang nakakahimok na argumento upang "patunayan" ang aking thesis. Ang mayroon lang ako ay ang mga makukulay na halimbawa na naipon ko sa loob ng 30 taon bilang isang developer. Nabanggit ko na ang malalim na pilosopiko ng problemang ito; sa ilang paraan ito ay namumulitika sa mga komunidad ng developer. Ang ilan ay naniniwala na mga tagalikha ang mga platform ay dapat na nagmamalasakit sa pagiging tugma, habang iniisip ng iba na ito ay isang alalahanin mga gumagamit (ang mga developer mismo). Isa sa dalawa. Sa katunayan, hindi ba ito ay isang isyu sa politika kapag tayo ay nagpasya kung sino ang dapat na pasanin ang mga gastos ng mga karaniwang problema?
Kaya ito ay pulitika. At malamang na may magagalit na mga tugon sa aking pananalita.
Bilang gumagamit Google Cloud Platform, at bilang isang AWS user sa loob ng dalawang taon (habang nagtatrabaho para sa Grab), masasabi kong may malaking pagkakaiba sa pagitan ng Amazon at ng mga pilosopiya ng Google pagdating sa mga priyoridad. Hindi ako aktibong nagde-develop sa AWS, kaya hindi ko alam kung gaano kadalas nilang inaalis ang mga lumang API. Ngunit may hinala na hindi ito nangyayari nang kasingdalas ng sa Google. At talagang naniniwala ako na ang pinagmumulan ng patuloy na kontrobersya at pagkabigo sa GCP ay isa sa mga pinakamalaking salik na pumipigil sa pag-unlad ng platform.
Alam kong hindi ko pinangalanan ang mga partikular na halimbawa ng mga GCP system na hindi na sinusuportahan. Masasabi kong halos lahat ng nagamit ko, mula sa mga network (mula sa pinakaluma hanggang VPC) hanggang sa storage (Cloud SQL v1-v2), Firebase (ngayon ay Firestore na may ganap na ibang API), App Engine (huwag na tayong magsimula) , cloud endpoints Cloud Endpoint at hanggang sa... Hindi ko alam - ganap na lahat ng ito pinilit kang isulat muli ang code pagkatapos ng maximum na 2-3 taon, at hindi nila na-automate ang paglipat para sa iyo, at madalas . As if naman dapat ganun.
At sa tuwing titingin ako sa AWS, tinatanong ko ang sarili ko kung bakit nasa GCP pa rin ako. Malinaw na hindi nila kailangan ng mga kliyente. Kailangan nila mga mamimili. Naiintindihan mo ba ang pagkakaiba? Hayaan mo akong magpaliwanag.
Mayroon ang Google Cloud , kung saan ang mga tao ay nagmumungkahi ng kanilang mga solusyon sa software, at upang maiwasan ang walang laman na epekto ng restaurant, kailangan nilang punan ito ng ilang mga panukala, kaya nakipagkontrata sila sa isang kumpanyang tinatawag na Bitnami upang lumikha ng isang grupo ng mga solusyon na naka-deploy sa "isang pag-click", o dapat Isinulat ko ito sa aking sarili na "mga solusyon," dahil ang mga ito ay hindi malulutas ang isang mapahamak na bagay. Umiiral lang ang mga ito bilang mga checkbox, bilang tagapuno ng marketing, at hindi kailanman pinansin ng Google kung gumagana ang alinman sa mga tool. May kilala akong mga product manager na nasa driver's seat, at masisiguro kong walang pakialam ang mga taong ito.
Kunin, halimbawa, ang isang diumano'y "isang-click" na solusyon sa pag-deploy. . Nasasaktan ako sa mga kalokohan ng Google Cloud SQL, kaya nagsimula akong tumingin sa pagbuo ng sarili kong cluster ng Percona bilang alternatibo. At sa pagkakataong ito ang Google ay tila gumawa ng isang mahusay na trabaho, sila ay magliligtas sa akin ng ilang oras at pagsisikap sa isang pag-click ng isang pindutan!
Mahusay, umalis na tayo. Sundan natin ang link at i-click ang button na ito. Piliin ang βOoβ para sumang-ayon sa lahat ng default na setting at i-deploy ang cluster sa iyong Google cloud project. Haha, hindi gumagana. Wala sa mga kalokohang ito ang gumagana. Ang tool ay hindi kailanman sinubukan at nagsimula itong mabulok mula sa unang minuto, at hindi ito magugulat sa akin kung higit sa kalahati ng "mga solusyon" ay isang-click na pag-deploy (ngayon ay naiintindihan na namin kung bakit ang mga panipi) sa pangkalahatan hindi gumagana. Ito ay ganap na walang pag-asa na kadiliman, kung saan ito ay mas mahusay na hindi pumasok.
Ngunit tama ang Google urges mong gamitin ang mga ito. Gusto ka nila bili. Para sa kanila ito ay isang transaksyon. Wala silang gusto suporta. Hindi ito bahagi ng DNA ng Google. Oo, sinusuportahan ng mga inhinyero ang isa't isa, bilang ebidensya ng aking kuwento sa Bigtable. Ngunit sa mga produkto at serbisyo para sa mga ordinaryong tao sila laging ay walang awa sa , na hindi nakakatugon sa bar para sa kakayahang kumita kahit na mayroon itong milyun-milyong user.
At ito ay nagpapakita ng isang tunay na hamon para sa GCP dahil ito ang DNA sa likod ng lahat ng mga handog sa ulap. Hindi nila sinusubukang suportahan ang anuman; Kilalang-kilala na tumanggi silang mag-host (bilang isang pinamamahalaang serbisyo) ng anumang software ng third party hanggang, hanggang sa gawin ng AWS ang parehong at bumuo ng isang matagumpay na negosyo sa paligid nito, at kapag ang mga customer ay literal na humingi ng pareho. Gayunpaman, nangangailangan ng kaunting pagsisikap upang masuportahan ng Google ang isang bagay.
Itong kakulangan ng kultura ng suporta, kasama ng mentalidad na "sirain natin ito para maging mas maganda", ay nagpapahiwalay sa mga developer.
At hindi iyon magandang bagay kung gusto mong bumuo ng isang mahabang buhay na platform.
Google, gumising ka, sumpain ito. 2020 na ngayon. Talo ka pa. Oras na para tumingin ng mabuti sa salamin at sagutin kung gusto mo talagang manatili sa cloud business.
Kung gusto mong manatili noon itigil ang pagsira sa lahat. Guys, mayaman kayo. Kaming mga developer ay hindi. Kaya pagdating sa kung sino ang sasagutin ang pasanin ng pagiging tugma, kailangan mong dalhin ito sa iyong sarili. Hindi para sa atin.
Dahil mayroon pang tatlong talagang magagandang ulap. Sumenyas sila.
At ngayon ay lilipat ako upang ayusin ang lahat ng aking mga sirang sistema. Eh.
Hanggang sa muli!
PS Update pagkatapos basahin ang ilan sa mga talakayan sa artikulong ito (ang mga talakayan ay mahusay, btw). Ang suporta sa Firebase ay hindi itinigil at walang mga plano na alam ko. Gayunpaman, mayroon silang masamang streaming bug na nagiging sanhi ng pagtigil ng Java client sa App Engine. Tinulungan ako ng isa sa kanilang mga inhinyero na malutas ang problemang ito, noong nagtrabaho ako sa Google, ngunit hindi talaga nila naayos ang bug, kaya mayroon akong isang crappy workaround na kailangang i-restart ang GAE app araw-araw. At ito ay naging sa loob ng apat na taon! Mayroon na silang Firestore. Mangangailangan ng maraming trabaho upang lumipat dito dahil isa itong ganap na kakaibang sistema at hindi na maaayos ang Firebase bug. Anong konklusyon ang mabubuo? Makakakuha ka ng tulong kung nagtatrabaho ka sa isang kumpanya. Marahil ako lang ang gumagamit ng Firebase sa GAE dahil wala pang 100 key ang nai-log ko sa isang 100% native na app at humihinto ito sa paggana bawat dalawang araw dahil sa isang kilalang bug. Ano ang masasabi ko maliban sa gamitin ito sa iyong sariling peligro. Lilipat ako sa Redis.
Nakita ko rin ang ilang mas may karanasan na mga gumagamit ng AWS na nagsasabi na ang AWS ay karaniwang hindi tumitigil sa pagsuporta sa anumang mga serbisyo, at ang SimpleDB ay isang magandang halimbawa. Ang aking mga pagpapalagay na ang AWS ay walang kaparehong dulo ng sakit sa suporta gaya ng Google ay mukhang makatwiran.
Bukod pa rito, napansin ko na 20 araw na ang nakalipas sinira ng Google App Engine team ang pagho-host ng isang kritikal na library ng Go, na isinara ang isang GAE application mula sa isa sa mga pangunahing developer ng Go. Ito ay talagang hangal.
Sa wakas, narinig ko na ang mga Googler na tinatalakay na ang isyung ito at sa pangkalahatan ay sumasang-ayon sa akin (mahal ko kayo!). Ngunit tila iniisip nila na ang problema ay hindi malulutas dahil ang kultura ng Google ay hindi kailanman nagkaroon ng tamang istruktura ng insentibo. Naisip ko na magandang maglaan ng ilang oras upang talakayin ang ganap na kamangha-manghang karanasan sa pagtatrabaho sa mga inhinyero ng AWS habang nagtatrabaho sa Grab. Balang araw sa hinaharap, umaasa ako!
At oo, noong 2005 mayroon silang iba't ibang uri ng karne ng pating sa giant buffet sa building 43, at ang paborito ko ay ang karne ng martilyo. Gayunpaman, noong 2006, inalis nina Larry at Sergei ang lahat ng hindi malusog na meryenda. Kaya noong Bigtable story noong 2007 wala talagang pating at niloko kita.
Nang tumingin ako sa cloud Bigtable apat na taon na ang nakakaraan (give or take), dito na ang gastos. Mukhang medyo bumaba na ngayon, ngunit napakalaki pa rin nito para sa isang walang laman na data warehouse, lalo na dahil ang aking unang kuwento ay nagpapakita kung gaano kawalang-halaga ang isang walang laman na malaking mesa sa kanilang sukat.
Paumanhin sa pananakit sa komunidad ng Apple at hindi nagsasabi ng anumang maganda tungkol sa Microsoft atbp. Okay ka lang, talagang pinahahalagahan ko ang lahat ng talakayan na nabuo ng artikulong ito! Ngunit kung minsan kailangan mong gumawa ng kaunti upang magsimula ng isang talakayan, alam mo ba?
Salamat sa pagbabasa.
Update 2, 19.08.2020/XNUMX/XNUMX. Guhit !
Update 3, 31.08.2020/2/2. Nakipag-ugnayan sa akin ang isang Google engineer sa Cloud Marketplace na naging matandang kaibigan ko. Gusto niyang malaman kung bakit hindi gumagana ang CXNUMXD, at kalaunan ay nalaman namin na ito ay dahil binuo ko ang aking network taon na ang nakalipas, at hindi gumagana ang CXNUMXD sa mga legacy na network dahil nawawala ang subnet parameter sa kanilang mga template. Sa tingin ko, pinakamainam para sa mga potensyal na user ng GCP na tiyaking sapat ang kanilang nalalaman na mga inhinyero sa Google...
Pinagmulan: www.habr.com