Чорт вазьмі, Google, я не хацеў зноў пісаць у блог. У мяне так шмат спраў. Вядзенне блога патрабуе часу, энергіі і крэатыву, якія я мог бы выкарыстоўваць з карысцю: мае кнігі, , мая гульня і гэтак далей. Але ты мяне дастаткова раззлаваў, і давядзецца гэта напісаць.
Так што давай скончым з гэтым.
Пачну з невялікай, але павучальнай гісторыі з тых часоў, калі я толькі пачаў працаваць у Google. Ведаю, што ў апошні час я нагаварыў шмат дрэннага пра Google, але мяне хвалюе, калі родная кампанія рэгулярна прымае некампетэнтныя бізнес-рашэнні. Пры гэтым трэба аддаць належнае: унутраная інфраструктура Google сапраўды экстраардынарная, можна смела сцвярджаць, што сёння няма нічога лепшага. Заснавальнікі Google былі значна лепшымі інжынерамі, чым я калі-небудзь постаці, і гэтая гісторыя толькі пацвярджае дадзены факт.
Спачатку крыху перадгісторыі: у Google ёсць тэхналогія захоўвання дадзеных пад назвай . Гэта было выдатнае тэхнічнае дасягненне, адно з першых (калі не першае) бясконца якое маштабуецца сховішча пар ключ-значэнне (key-value store, K/V): у сутнасці, пачатак NoSQL. У нашы дні Bigtable усё яшчэ добра пачуваецца ў даволі перапоўненай прасторы сховішчаў K/V, але ў той час (2005 год) яно было ўзрушаюча крутое.
Адна пацешная дэталь Bigtable складаецца ў тым, што ў іх былі ўнутраныя аб'екты плоскасці кіравання (як частка рэалізацыі) пад назовам tablet-серверы, з вялікімі азначнікамі, і ў нейкі момант яны сталі вузкім месцам пры маштабаванні сістэмы. Інжынеры Bigtable ламалі галаву, як рэалізаваць маштабаванасць, і раптам зразумелі, што могуць замяніць tablet-серверы іншымі сховішчамі Bigtable. Так што Bigtable - гэта частка рэалізацыі Bigtable. Гэтыя сховішчы там на ўсіх узроўнях.
Яшчэ адна цікавая дэталь складаецца ў тым, што на нейкі час Bigtable сталі папулярнымі і ўсюдыіснымі ўсярэдзіне Google, і ў кожнай каманды было сваё сховішча. Таму на адным з пятнічных сходаў Лары Пэйдж нядбайна спытаў мімаходзь: «А чаму ў нас больш аднаго Bigtable? Чаму не абысціся толькі адным?» Тэарэтычна, аднаго сховішчы павінна было хапіць для ўсіх запатрабаванняў захоўвання Google. Вядома, яны ніколі не пераходзілі толькі на адно па практычных прычынах распрацоўкі (напрыклад, наступствы патэнцыйнага збою), але тэорыя была цікавай. Адно сховішча для ўсяго Сусвету (дарэчы, хто-небудзь ведае, Amazon такое зрабіла са сваім Sable?)
Так ці інакш, вось мая гісторыя.
У той час я працаваў у Google крыху больш за два гады, і аднойчы мне прыйшоў ліст ад інжынернай каманды Bigtable прыкладна такога зместу:
Паважаны Стыў,
Прывітанне ад каманды Bigtable. Мы хочам паведаміць, што ў дата-цэнтры [назва дата-цэнтра] вы карыстаецеся вельмі, вельмі стары бінарны файл Bigtable. Гэтая версія больш не падтрымліваецца, і мы жадаем дапамагчы вам перайсці на апошнюю версію.
Калі ласка, дайце ведаць, калі вы можаце запланаваць некаторы час для сумеснай працы над гэтым пытаннем.
Усяго найлепшага,
Каманда Bigtable
У Google вам прыходзіць шмат пошты, таму з першага погляду я прачытаў прыкладна так:
Паважаны атрымальнік,
Прывітанне ад нейкай каманды. Мы хочам паведаміць, што бла-бла-бла-бла-бла-бла. Бла-бла-бла-бла-бла-бла, і бла-бла-бла неадкладна.
Калі ласка, дайце нам ведаць, калі вы можаце запланаваць частку свайго каштоўнага часу на бла-бла-бла.
Усяго найлепшага,
Нейкая каманда
Я амаль выдаліў яго адразу ж, але на мяжы прытомнасці адчуў цяжкае, ныючыя пачуццё, што гэта не зусім падобна на фармальны ліст, хоць відавочна, Што з адрасатам памыліліся, таму што я не выкарыстоўваў Bigtable.
Але гэта было дзіўна.
Рэшту дня я напераменку думаў пра працу і пра тое, які выгляд акульага мяса паспрабаваць у мікра-кухні, з якіх па меншай меры тры былі дастаткова блізка, каб патрапіць з майго месца трапным кідком бісквіту, але думка аб лісце не пакідала мяне з расце пачуццём лёгкай трывогі.
Яны відавочна назвалі маё імя. І ліст адпраўлены на мой адрас электроннай пошты, а не на чыйсьці яшчэ, і гэта не cc: ці bcc:. Тон вельмі асабісты і выразны. Можа, гэта нейкая памылка?
Нарэшце, цікаўнасць узяла верх і я пайшоў зірнуць на кансоль Borg у дата-цэнтры, які яны згадалі.
І вядома, у мяне ва ўпраўленні было сховішча BigTable. Што што? Я зірнуў на яго змесціва, і - трэба ж! Яно было з інкубатара Codelab, у якім я сядзеў першы тыдзень працы ў Google у чэрвені 2005 гады. Codelab прымушаў вас запусціць Bigtable, каб вы запісалі туды некаторыя значэння, і я, відаць, так і не закрыў сховішча пасля гэтага. Яно ўсё яшчэ працавала, хаця прайшло больш за два гады.
У гэтай гісторыі ёсць некалькі адметных аспектаў. Па-першае, праца Bigtable быў настолькі неістотная ў маштабе Google, што толькі праз два гады лішняе сховішча нехта заўважыў, ды і то толькі таму, што версія бінарніка састарэла. Для параўнання, я калісьці разглядаў магчымасць выкарыстання для маёй анлайн-гульні. У той час гэтая паслуга каштавала прыкладна $16 000 у год за пустую Bigtable на GCP. Я не кажу, што яны вас падманваюць, але, на маю асабістую думку, гэта вялікія грошы за пустую гробаную базу дадзеных.
Яшчэ адзін адметны аспект заключаецца ў тым, што сховішча па-ранейшаму працавала праз два гады. WTF? Дата-цэнтры прыходзяць і сыходзяць; яны адчуваюць перабоі, яны праходзяць планавае тэхнічнае абслугоўванне, яны ўвесь час мяняюцца. Жалеза абнаўляецца, камутатары мяняюцца месцамі, усё пастаянна ўдасканальваецца. Як, чорт вазьмі, яны змаглі захаваць маю праграму запушчанай на працягу двух гадоў з улікам усіх гэтых змен? Гэта можа здацца сціплым дасягненнем у 2020 годзе, але ў 2005-2007 гадах яно было вельмі уражлівым.
І самы выдатны аспект складаецца ў тым, што старонняя інжынерная каманда ў нейкім іншым штаце звяртаецца да мяне, уладальніку нейкага малюсенькага, практычна пустога асобніка Bigtable, у якога нулявы трафік на працягу апошніх двух гадоў - і прапануюць дапамогу, каб абнавіць яго.
Я падзякаваў ім, выдаліў сховішча, і жыццё пайшло сваёй чаргой. Але праз трынаццаць гадоў я ўсё яшчэ думаю пра гэты ліст. Бо часам мне прыходзяць падобныя лісты ад Google Cloud. Яны выглядаюць так:
Паважаны карыстальнік Google Cloud,
Нагадваем, што мы спыняем абслугоўванне сэрвісу [важны сэрвіс, які вы карыстаецеся] са жніўня 2020 года, пасля чаго вы не зможаце абнавіць свае інстансы. Рэкамендуемы перайсці на апошнюю версію, якая праходзіць бэта-тэставанне, не мае ніякай дакументацыі, ніякага шляху міграцыі і якая загадзя састарэла з нашай ветлівай дапамогай.
Мы імкнемся да таго, каб гэтая змена мінімальна паўплывала на ўсіх карыстачоў платформы Google Cloud.
Лепшыя сябры назаўжды,
Воблачная платформа Google
Але я амаль не чытаю такія лісты, таму што насамрэч у іх гаворыцца наступнае:
Паважаны атрымальнік,
Пайшоў ты да д'ябла. Пайшоў ты, пайшоў ты, пайшоў ты. Адкінь усё, што ты робіш, таму што гэта не важна. Што важна, дык гэта наш час. Мы марнуем час і грошы, каб падтрымліваць наша дзярмо, і мы стаміліся ад гэтага, таму больш не будзем яго падтрымліваць. Так што кідай свае гробаныя планы і пачынай капацца ў нашай бруднай дакументацыі, выпрошваючы з'едкі на форумах, і, дарэчы, наша новае дзярмо цалкам адрозніваецца ад старога лайна, таму што мы даволі моцна сапсавалі гэты дызайн, хех, але гэта твая праблема, а не наша.
Мы па-ранейшаму прыкладаем намаганні, каб усе твае распрацоўкі сталі непрыдатныя для выкарыстання на працягу аднаго года.
Калі ласка ідзі нах,
Воблачная платформа Google
І справа ў тым, што я атрымліваю такія лісты прыкладна раз на месяц. Гэта адбываецца так часта і так увесь час, што яны непазбежна адштурхнулі мяне ад GCP у лагер супернікаў аблокаў. Я больш не згодзен залежаць ад іх прапрыетарных распрацовак, таму што на самой справе дэвапсу лягчэй падтрымліваць сістэму з адчыненым зыходным кодам на голай віртуалцы, чым спрабаваць угнацца за Google з яе палітыкай зачынення «састарэлых» прадуктаў.
Перш чым вярнуцца да Google Cloud, таму што я нават блізка не скончыў іх крытыкаваць, давайце паглядзім на працу кампаніі ў некаторых іншых абласцях. Інжынеры Google ганарацца сваёй дысцыплінай распрацоўкі праграмнага забеспячэння, і менавіта гэта насамрэч выклікае праблемы. Гонар - гэта пастка для неасцярожных, яна прымусіла шматлікіх супрацоўнікаў Google думаць, што іх рашэнні заўсёды правільныя і што правільнасць (па нейкім нявызначаным невыразным вызначэнні) важней, чым клопат аб кліентах.
Прывяду некалькі адвольных прыкладаў з іншых вялікіх праектаў за межамі Google, але спадзяюся, што вы ўбачыце гэты шаблон усюды. Ён заключаецца ў наступным: зваротная сумяшчальнасць падтрымлівае жывучасць і актуальнасць сістэм на працягу дзесяцігоддзяў.
Зваротная сумяшчальнасць - гэта мэта праектавання ўсіх паспяховых сістэм, прызначаных для адкрытага выкарыстання, гэта значыць рэалізаваных з адчыненым зыходным кодам і/ці на адчыненых стандартах. Я адчуваю, што кажу нешта занадта відавочнае, што ўсім нават няёмка, але не. Гэта палітычнае пытанне, таму патрэбны прыклады.
Першая сістэма, якую я абяру, самая старая: GNU Emacs, гэта свайго роду гібрыд паміж Нататнікам Windows, ядром АС і Міжнароднай касмічнай станцыяй. Гэта крыху складана растлумачыць, але ў двух словах Emacs — гэта платформа, створаная ў 1976 годзе (так, амаль паўстагоддзя таму) для праграмавання, каб павысіць вашу прадуктыўнасць, але маскіруецца пад тэкставы рэдактар.
Я выкарыстоўваю Emacs кожны божы дзень. Так, я таксама выкарыстоўваю IntelliJ кожны дзень, яна ўжо сама ператварылася ў магутную інструментальную платформу. Але напісанне пашырэнняў для IntelliJ – значна больш амбіцыйная і складаная задача, чым напісанне пашырэнняў для Emacs. І што яшчэ важнейшае, усё напісанае для Emacs захоўваецца вечна.
Я па-ранейшаму выкарыстоўваю праграмнае забесьпячэньне, якое напісаў для Emacs яшчэ ў 1995 годзе. І ўпэўнены, што нехта выкарыстоўваюць модулі, напісанае для Emacs у сярэдзіне 80-х, калі не раней. Час ад часу яны могуць запатрабаваць малаважнай наладкі, але гэта сапраўды даволі рэдка. Я ня ведаю нічога з таго, што я калі-небудзь пісаў для Emacs (а я напісаў шмат), у чым давялося б перабудаваць архітэктуру.
У Emacs ёсць функцыя пад назовам make-obsolete для састарэлых сутнасцяў. Тэрміналогія Emacs для фундаментальных кампутарных канцэпцый (напрыклад, што такое "акно") часта адрозніваецца ад галіновых канвенцый, таму што Emacs увёў іх вельмі даўно. Гэта тыповая небяспека для тых, хто апярэдзіў свой час: усе вашыя тэрміны некарэктныя. Але ў Emacs сапраўды ёсць канцэпцыя састарэння, якая на іх жаргоне называецца састарэнне.
Але ў свеце Emacs, падобна, іншае працоўнае вызначэнне. Іншая асноватворная філасофія, калі хочаце.
У свеце Emacs (і ў многіх іншых галінах, якія мы разгледзім ніжэй) статус састарэлых API у асноўным азначае: «Вы сапраўды не павінны выкарыстоўваць гэты падыход, таму што, хоць ён і працуе, ён пакутуе ад розных недахопаў, якія мы пералічым тут. Але, у рэшце рэшт, гэта ваш выбар».
У міры Google статут састарэлага прадукта азначае: "Мы парушаем свае абавязанні перад вамі". Гэта насамрэч так. Вось што гэта па сутнасці азначае. Гэта азначае, што яны прымусяць вас рэгулярна прарабляць некаторую працу, магчыма, вялікую працу, у пакаранне за тое, што вы паверылі ў іх : у нас лепшае праграмнае забеспячэнне. Самае хуткае! Вы робіце ўсё па інструкцыі, запускаеце свой дадатак або сэрвіс, а затым - бац, праз год ці два яно ламаецца.
Гэта ўсё роўна што прадаваць ужываны аўтамабіль, які сапраўды зламаецца праз 1500 км.
Гэта два зусім розныя філасофскія азначэнні "састарэння". Вызначэнне Google пахне . Я не веру, што гэта на самой справе запланаванае састарванне ў тым жа сэнсе, як у Apple. Але Google вызначана плануе зламаць вашыя праграмы, вакольным шляхам. Я ведаю гэта, таму што прапрацаваў там інжынерам-праграмістам больш за 12 гадоў. У іх ёсць расплывістыя ўнутраныя рэкамендацыі, у якой меры варта выконваць зваротную сумяшчальнасць, але ў канчатковым выніку гэта залежыць ад кожнай асобнай каманды ці службы. Няма ніякіх рэкамендацый карпаратыўнага або інжынернага ўзроўню, і самая смелая рэкамендацыя з пункту гледжання цыклаў састарэння - гэта "паспрабуйце даць кліентам 6-12 месяцаў на абнаўленне, перш чым зламаць ім усю сістэму".
Праблема значна больш сур'ёзная, чым яны думаюць, і яна захаваецца яшчэ доўгія гады, таму што клопат аб кліентах не ўваходзіць у іх ДНК. Больш падрабязна пра гэта ніжэй.
На дадзены момант я збіраюся зрабіць смелае сцвярджэнне, што Emacs паспяховы ў значнай ступені і нават у асноўным таму, што яны так сур'ёзна ставяцца да зваротнай сумяшчальнасці. Уласна, гэта і ёсць тэза нашага артыкула. Паспяховыя доўгажывучыя адкрытыя сістэмы абавязаны сваім поспехам мікрасупольнасцям, якія дзесяцігоддзямі жывуць вакол пашырэнняў/плагінаў. Гэта і ёсць экасістэма. Я ўжо разважаў аб сутнасці платформаў і аб тым, наколькі яны важныя, і аб тым, што Google ніколі за ўсю сваю карпаратыўную гісторыю не разумела, што ўваходзіць у стварэнне паспяховай адкрытай платформы, не лічачы Android або Chrome.
Наогул-то я павінен сцісла згадаць Android, таму што вы напэўна падумалі пра яго.
Па-першае, Android - гэта не Google. Яны не маюць амаль нічога агульнага адзін з адным. Android – гэта кампанія, якая была набытая Google у ліпені 2005 года, гэтай кампаніі было дазволена працаваць больш-менш аўтаномна і фактычна яна засталася ў значнай ступені некранутай на працягу мінулых гадоў. Android - гэта сумна вядомы тэхнічны стэк і гэтак жа сумна вядомая калючая арганізацыя. Як выказаўся адзін гуглер, "нельга проста так узяць і ўвайсці ў Android".
У адной з мінулых артыкулаў я ўжо разважаў, наколькі дрэннымі былі некаторыя з ранніх дызайнерскіх рашэнняў Android. Чорт вазьмі, калі я пісаў той артыкул, яны займаліся разгортваннем лайна пад назвай «імгненныя прыкладанні», якія зараз (сюрпрыз!) , І спачуваю, калі вы былі дастаткова дурныя, каб паслухацца Google і перанесці свой кантэнт у гэтыя імгненныя прыкладання.
Але тут ёсць розніца, істотная розніца, якая заключаецца ў тым, што людзі з Android сапраўды разумеюць, наколькі важныя платформы, яны з усіх сіл імкнуцца захаваць працаздольнасць старых прыкладанняў Android. Насамрэч, іх намаганні захаваць зваротную сумяшчальнасць настолькі экстрэмальныя, што нават я, падчас свайго кароткага знаходжання ў падраздзяленні Android некалькі гадоў таму, выявіў, што спрабую пераканаць іх адмовіцца ад падтрымкі некаторых з самых старых прылад і API (я памыляўся, як і у многіх іншых рэчах мінулага і сучаснасці.Выбачайце, хлопцы з Android!Цяпер, калі я пабываў у Інданезіі, я разумею, навошта яны нам патрэбныя).
Людзі з Android падтрымліваюць зваротную сумяшчальнасць да амаль няўяўных крайнасцяў, што нагрувашчвае велізарную колькасць састарэлых тэхнічных даўгоў у іх сістэмах і ланцужках інструментаў. Аб божа, вы б бачылі некаторыя вар'яты рэчы, якія ім даводзіцца рабіць у сваёй сістэме зборкі, і ўсё гэта ў імя сумяшчальнасці.
За гэта я прысуджаю Android запаветную ўзнагароду "Ты не Google". Яны сапраўды не жадаюць становіцца Google, якая не ўмее ствараць даўгавечныя платформы, а вось Android ведае, як гэта рабіць. І таму Google паводзіць сябе вельмі мудра ў адным стаўленні: дазваляе людзям у Android рабіць усё па-свойму.
Аднак імгненныя прыкладанні для Android былі даволі дурной ідэяй. І ведаеце, чаму? Бо яны патрабавалі перапісаць і перапраектаваць ваша прыкладанне! Як быццам людзі проста так возьмуць і перапішуць два мільёны дадаткаў. Мяркую, што імгненныя прыкладанні былі ідэяй нейкага гуглера.
Але тут ёсць розніца. Зваротная сумяшчальнасць спалучана з вялікімі выдаткамі. Android сам нясе цяжар гэтых выдаткаў, у той час як Google настойвае на тым, каб гэты цяжар неслі вы, платны кліент.
Вы можаце ўбачыць прыхільнасць Android зваротнай сумяшчальнасці ў яе API-інтэрфейсах. Калі ў вас чатыры ці пяць розных падсістэм для выканання літаральна аднаго і таго ж, гэта дакладная прыкмета, што ў аснове ляжыць прыхільнасць зваротнай сумяшчальнасці. Што ў свеце платформаў з'яўляецца сінонімам прыхільнасці вашым кліентам і вашаму рынку.
Галоўная праблема Google тут – іх гонар сваёй інжынернай гігіенай. Ім не падабаецца, калі ёсць шмат розных спосабаў рабіць адно і тое ж, прычым старыя, менш пажаданыя спосабы сядзяць побач з новымі, больш мудрагелістымі спосабамі. Гэта павялічвае крывую навучанне для пачаткоўцаў у сістэме, гэта павялічвае цяжар падтрымкі састарэлых API, гэта запавольвае хуткасць новых функцый, і галоўны грэх - гэта непрыгожа. Google - як Лэдзі Эскот з «Алісы ў Краіне цудаў» Ціма Бертана:
Лэдзі Эскат:
- Аліса, ведаеш, чаго я баюся больш за ўсё?
- Заняпаду арыстакратыі?
- Я баялася, што ў мяне будуць брыдкія ўнукі.
Каб зразумець кампраміс паміж прыгожым і практычным, давайце зірнем на трэцюю паспяховую платформу (пасля Emacs і Android) і паглядзім, як яна працуе: сама Java.
У Java маса састарэлых API. Састаранне вельмі папулярна сярод Java-праграмістаў, нават папулярней, чым у большасці моў праграмавання. У самой Java, асноўнай мове і бібліятэках стала адбываецца састарванне API.
Калі ўзяць толькі адзін з тысяч прыкладаў, лічыцца састарэлым. Яно састарэла з моманту выпуску Java 1.2 у снежні 1998 гады. Прайшло 22 гады з таго часу, як гэта састарэла.
Але мой рэальны код у прадакшне па-ранейшаму забівае патокі кожны дзень. Няўжо гэта добра? Абсалютна! Я маю на ўвазе, канешне, калі б я перапісаў код сёння, я б рэалізаваў гэта па-іншаму. Але код маёй гульні, якая за апошнія два дзесяцігоддзі зрабіла шчаслівымі сотні тысяч людзей, напісана з функцыяй зачынення струменяў, якія вісяць занадта доўга, і мне ніколі не даводзілася яго мяняць. Я ведаю сваю сістэму лепш за ўсіх, у мяне літаральна 25-гадовы досвед працы з ёй у прадакшне, і я магу дакладна сказаць: у маім выпадку закрыццё гэтых канкрэтных працоўных патокаў цалкам бясшкодна. Не варта марнаваць час і сілы на перапісванне гэтага кода, і хвала Лары Элісан (напэўна), што Oracle не прымусіла мяне перапісваць яго.
Мусіць, Oracle таксама разбіраецца ў платформах. Хто яго ведае.
Доказы вы можаце сустрэць па ўсіх ключавых Java API, якія працяты хвалямі састарэння, падобна лініям ледніка ў каньёне. У бібліятэцы Java Swing можна лёгка знайсці пяць ці шэсць розных мэнэджэраў навігацыі з клавіятуры (KeyboardFocusManager). На самой справе цяжка знайсці Java API, які не з'яўляецца састарэлым. Але яны ўсё яшчэ працуюць! Думаю, каманда Java па-сучаснасці выдаліць API толькі ў тым выпадку, калі інтэрфейс выкліча абуральную праблему бяспекі.
Вось у чым справа, рабяты: мы, распрацоўшчыкі праграмнага забеспячэння, усё вельмі занятыя, і ў кожнай вобласці праграмнага забеспячэння мы сутыкаемся з канкуруючымі альтэрнатывамі. У любы момант часу праграмісты на мове X разглядаюць мову Y як магчымую замену. О, вы мне не верыце? Вы хочаце назваць Swift? Маўляў, усё мігруюць на Swift і ніхто ад яго не адмаўляецца, праўда? Ого, як мала вы ведаеце. Кампаніі лічаць выдаткі на падвойныя каманды мабільнай распрацоўкі (iOS і Android) – і яны пачынаюць разумець, што гэтыя крос-платформавыя сістэмы распрацоўкі са смешнымі назвамі, такія як Flutter і React Native, сапраўды працуюць, і з іх дапамогай можна скараціць памеры сваіх мабільных каманд удвая ці, наадварот, зрабіць іх удвая прадуктыўней. На коне рэальныя грошы. Так, ёсць кампрамісы, але, з іншага боку, дэ-е-еньгі.
Выкажам здагадку гіпатэтычна, што Apple па дурасці ўзяла прыклад з Гвіда ван Рассума і абвясціла, што Swift 6.0 зваротна несумяшчальны са Swift 5.0, шмат у чым як Python 3 несумяшчальны з Python 2.
Напэўна, я расказваў гэтую гісторыю гадоў дзесяць таму, але гадоў пятнаццаць таму я ездзіў у лагер O'Reilly's Foo Camp з Гвіда, сядзеў у палатцы з Полам Грэмам і кучай вялікіх гузоў. Мы сядзелі ў цяжкай спякоце і чакалі, калі Лары Пэйдж вылеціць на сваім асабістым верталёце, а Гвіда манатонна бубніў аб «Пітон 3000», які ён назваў па колькасці гадоў, якое спатрэбіцца ўсім, каб туды міграваць. Мы ўвесь час пыталі яго, чаму ён парушае сумяшчальнасць, і ён адказваў: "Unicode". І мы пыталіся, калі нам давядзецца перапісаць наш код, то якія яшчэ перавагі мы ўбачым? І ён адказваў “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Калі ўсталяваць Google Cloud Platform SDK ("gcloud"), то вы атрымаеце наступнае апавяшчэнне:
Паважаны атрымальнік,
Мы хацелі б вам нагадаць, што падтрымка Python 2 састарэлая, так што пашыеёёёёй тыыыыыы
… і гэтак далей. Кола жыцця.
Але справа ў тым, што ў кожнага распрацоўшчыка ёсць выбар. І калі прымусіць іх перапісваць код дастаткова часта, то яны могуць падумаць і пра іншых варыянтах. Яны не вашыя заложнікі, як бы вам гэтага ні хацелася. Яны - вашы госці. Python па-ранейшаму вельмі папулярная мова праграмавання, але, чорт пабяры, Python 3(000) стварыў такі бардак у сябе, у сваіх супольнасцях і ў карыстачоў сваіх супольнасцяў, што наступствы не могуць разгрэбці ўжо пятнаццаць гадоў.
Колькі праграм Python было перапісана на Go (ці Ruby, ці нейкай іншай альтэрнатыве) з-за гэтай зваротнай несумяшчальнасці? Колькі новага праграмнага забеспячэння было напісана на чымсьці іншым, акрамя Python, хаця яно магло быць напісана на Python, калі б Гвіда не спаліў усю вёску? Цяжка сказаць, але Python відавочна пацярпеў. Гэта вялізны бардак, і ўсё ў пройгрышы.
Такім чынам, дапусцім, Apple бярэ прыклад з Гвіда і парушае сумяшчальнасць. Як думаеце, што будзе далей? Ну, можа, 80-90% распрацоўшчыкаў перапішуць сваё праграмнае забеспячэнне, калі атрымаецца. Іншымі словамі, 10-20% карыстацкай базы аўтаматычна сыходзяць на нейкую канкуруючую мову, напрыклад, Flutter.
Зрабіце гэта некалькі разоў - і вы страціце палову сваёй карыстацкай базы. Як і ў спорце, у свеце праграмавання бягучая форма таксама значыць ўсё. Любы, хто страціць палову карыстальнікаў за пяць гадоў, будзе лічыцца Вялікім Тоўстым Няўдачнікам. Вы ж павінны быць у трэндзе ў свеце платформ. Але менавіта тут адмова ад падтрымкі старых версій з часам вас загубіць. Таму што кожны раз, калі вы пазбаўляецеся ад часткі распрацоўшчыкаў, вы (а) губляеце іх назаўжды, таму што яны злуюцца на вас за парушэнне кантракту, і (б) аддаяце іх сваім канкурэнтам.
Па іроніі лёсу, я таксама дапамог Google ператварыцца ў такую прымадонну, якая ігнаруе зваротную сумяшчальнасць, калі стварыў Grok, сістэму аналізу і разумення зыходнага кода, якая палягчае аўтаматызацыю і абсталяванне інструментарыем на аснове самога кода - падобна на IDE, але тут хмарны сэрвіс захоўвае матэрыялізаваныя прадстаўлення ўсіх мільярдаў радкоў зыходнага кода Google у вялікім сховішчы дадзеных.
Grok падаў гуглерам магутную аснову для правядзення аўтаматызаванага рэфактарынгу па ўсёй кодавай базе (літаральна па ўсім Google). Сістэма вылічае не толькі вашыя ўзыходзячыя залежнасці (ад якіх вы залежыце), але і сыходныя (якія залежаць ад вас), таму пры змене API вы ведаеце ўсіх, каго ламаеце! Такім чынам, пры занясенні змен вы можаце праверыць, што кожны спажывец вашага API абнавіўся да новай версіі, а ў рэальнасці часта з дапамогай прылады Rosie, які яны напісалі, вы можаце цалкам аўтаматызаваць працэс.
Гэта дазваляе кодавай базе Google унутрана быць амаль звышнатуральна «чыстай», бо ў іх гэтыя рабатызаваных слугі ходзяць па ўсёй хаце і аўтаматычна ўсё падчышчаюць, калі яны перайменавалі SomeDespicablyLongFunctionName у SomeDespicablyLongMethodName, таму што хтосьці вырашыў, што гэта брыдкі ў трэба ўсыпіць.
І, сапраўды кажучы, гэта даволі добра працуе для Google… унутрана. Я маю на ўвазе, так, супольнасць Go ў Google сапраўды па-добраму пасмейваецца з супольнасці Java у Google з-за іх звычкі да бесперапыннага рэфактарынгу. Калі вы нешта перазапускаеце N раз, то гэта азначае, што вы не толькі сапсавалі гэта N-1 раз, але і праз некаторы час становіцца зусім ясна, што вы, верагодна, сапсавалі гэта і з N-ай спробы. Але, па вялікім рахунку, яны застаюцца вышэй гэтай мітусні і захоўваюць код "чыстым".
Праблемы пачынаюцца, калі яны спрабуюць навязаць такое стаўленне сваім хмарным кліентам і карыстальнікам іншых API.
Я крыху пазнаёміў вас з Emacs, Android і Java; давайце паглядзім на апошнюю паспяховую доўгажывучую платформу: сам Вэб. Можаце ўявіць, праз колькі ітэрацый прайшоў HTTP з 1995 года, калі мы выкарыстоўвалі мігатлівыя тэгі. і значкі "У распрацоўцы" на вэб-старонках.
Але гэта ўсё яшчэ працуе! І гэтыя старонкі ўсё яшчэ працуюць! Так, рабяты, браўзэры - сусветныя чэмпіёны па зваротнай сумяшчальнасці. Chrome – гэта яшчэ адзін прыклад рэдкай платформы Google, у якой галовы прышрубаваны правільна, і, як вы ўжо здагадаліся, Chrome эфектыўна дзейнічае як ізаляваная кампанія асобна ад астатняга Google.
Я таксама хачу падзякаваць нашым сябрам сярод распрацоўшчыкаў аперацыйных сістэм: Windows, Linux, НЕ APPLE ПАЙШЛА ТЫ APPLE, FreeBSD і гэтак далей, за тое, што яны прарабілі такую вялікую працу па зваротнай сумяшчальнасці на сваіх паспяховых платформах (Apple атрымлівае ў лепшым выпадку тройку з мінусам, бо яны ўвесь час усё ламаюць без усялякага ўважлівага чынніку, але нейкім чынам супольнасць спраўляецца з гэтым у кожным рэлізе, і дагэтуль кантэйнеры з OS X яшчэ не цалкам састарэлі… пакуль).
Але пачакайце, скажаце вы. Хіба мы не параўноўваем яблыкі з апельсінамі - аўтаномныя праграмныя сістэмы на адной машыне, такія як Emacs/JDK/Android/Chrome, з шматсервернымі сістэмамі і API, як у хмарных сэрвісах?
Ну, я напісаў пра гэта ўчора ў твітары, але ў стылі Лары Уола (стваральнік мовы праграмавання Perl - заўв. зав.) па прынцыпе «адстой/рулёз» я пашукаў слова асуджаецца на сайтах для распрацоўшчыкаў Google і Amazon. І хоць у AWS у сотні разоў больш прапаноў паслуг, чым у GCP, дакументацыя распрацоўнікаў Google згадвае састарванне прыкладна ў сем разоў гушчару.
Калі хтосьці з Google чытае гэта, то, напэўна, яны гатовыя выцягнуць дыяграмы ў паказваючы стылі Дональда Трампа, што на самой справе робяць усё правільна, і што я не павінен рабіць несправядлівыя параўнання, такія як «колькасць згадак слова deprecated у залежнасці ад колькасці сэрвісаў ».
Але праз столькі гадоў Google Cloud па-ранейшаму застаецца сэрвісам №3 (я так і не напісаў артыкул аб няўдалай спробе стаць №2), але калі верыць інсайдэрам, ёсць некаторыя асцярогі, што яны могуць хутка апусціцца да №4.
У мяне няма важкіх аргументаў, каб «даказаць» сваю тэзу. Усё, што ў мяне ёсць, - гэта маляўнічыя прыклады, якія я назапасіў за 30 гадоў працы ў якасці распрацоўніка. Я ўжо згадваў пра глыбока філасофскую прыроду гэтай праблемы; у некаторым сэнсе яна палітызаваная ў супольнасцях распрацоўшчыкаў. Некаторыя лічаць, што стваральнікі платформаў павінны клапаціцца аб сумяшчальнасці, а іншыя лічаць, што гэта клопат карыстальнікаў (самых распрацоўшчыкаў). Адно з двух. І сапраўды, хіба гэта не палітычнае пытанне, калі мы вырашаем, хто павінен несці выдаткі за агульныя праблемы?
Таму гэта палітыка. І напэўна будуць гнеўныя адказы на мой выступ.
Як карыстальнік хмарнай платформы Google, а таксама як карыстач AWS на працягу двух гадоў (працуючы ў кампаніі Grab), магу сказаць, што існуе велізарная розніца паміж філасофіямі Amazon і Google, калі гаворка заходзіць аб прыярытэтах. Я не вяду актыўную распрацоўку на AWS, таму не вельмі добрае ведаю, наколькі часта яны прыбіраюць старыя API. Але ёсць падазрэнне, што гэта адбываецца далёка не так часта, як у Google. І я шчыра веру, што гэтая крыніца пастаянных спрэчак і расчараванняў у GCP з'яўляецца адным з самых вялікіх фактараў, якія стрымліваюць развіццё платформы.
Ведаю, што не назваў канкрэтныя прыклады сістэм GCP, падтрымка якіх спынена. Магу сказаць, што практычна ўсё, што я выкарыстаў, ад сетак (ад самых старых да VPC) да сховішчаў (Cloud SQL v1-v2), Firebase (зараз Firestore з зусім іншым API), App Engine (давайце нават не будзем пачынаць), хмарных канчатковых кропак Cloud Endpoint і да… я не ведаю абсалютна ўсё гэта прымушала перапісваць код максімум праз 2-3 гады, і яны ніколі не аўтаматызавалі для вас міграцыю, а часта . Нібы так і належыць.
І кожны раз, калі я гляджу на AWS, я пытаюся ў сябе, якога чорта я да гэтага часу сяджу на GCP. Ім відавочна не патрэбны кліенты. Ім патрэбны пакупнікі. Разумееце розніцу? Давайце растлумачу.
У Google Cloud ёсць , на якім людзі прапануюць свае праграмныя рашэнні, а каб пазбегнуць эфекту пустога рэстарана, трэба было запоўніць яго некаторымі прапановамі, таму яны заключылі кантракт з кампаніяй Bitnami, каб стварыць кучу рашэнняў, якія разгортваюцца «адной пстрычкай мышы», ці я сам павінен напісаць « рашэнні», таму што гэтыя ні чорта не вырашаюць. Яны проста існуюць як сцяжкі, як маркетынгавы напаўняльнік, і Google ніколі не турбавала, ці працуе які-небудзь з інструментаў у рэальнасці. Я ведаю менеджэраў па прадукце, якія былі за рулём, і магу вас запэўніць, што гэтым людзям напляваць.
Возьмем, да прыкладу, рашэнне з разгортваннем нібы «адной пстрычкай мышы» . Мне да смерці надакучылі выхадкі Google Cloud SQL, так што я пачаў разглядаць у якасці альтэрнатывы стварэнне ўласнага кластара Percona. І на гэты раз Google накшталт зрабіла добрую справу, яны збіраліся зэканоміць мне крыху часу і намаганняў адным націскам кнопкі!
Ну цудоўна, паехалі. Пяройдзем па спасылцы і націсніце гэтую кнопку. Выбіраемы «Так», каб пагадзіцца на ўсе параметры па змаўчанні і разгарнуць кластар у сваім хмарным праекце Google. Ха-ха, не працуе. Нічога з гэтага лайна не працуе. Інструмент ніколі не тэставаўся, і ён пачаў падгніваць з першай хвіліны, і мяне не здзівіць, калі больш за палову «рашэнняў» для разгортвання адной пстрычкай мышы (зараз мы разумеем, чаму двукоссі) наогул не працуюць. Гэта абсалютна беспрасветная цемра, куды лепш не ўваходзіць.
Але Google прама заклікае вас выкарыстоўваць іх. Яны хочуць, каб ты іх купіў. Для іх гэта транзакцыя. Яны не хочуць нічога падтрымліваць. Гэта не частка ДНК Google. Так, інжынеры падтрымліваюць адзін аднаго, аб чым сведчыць мая гісторыя з Bigtable. Але ў прадуктах і паслугах для звычайных людзей яны заўсёды былі бязлітасныя ў , Які не адпавядае планцы прыбытковасці, нават калі ў яго мільёны карыстальнікаў.
І гэта ўяўляе рэальную праблему для GCP, таму што гэтая ДНК стаіць за ўсімі хмарнымі прапановамі. Яны не імкнуцца штосьці падтрымліваць; добра вядома, што яны адмаўляюцца размяшчаць (як кіраваны сэрвіс) любое іншае праграмнае забеспячэнне да таго часу, пакуль AWS не зробіць тое ж самае і не пабудуе вакол паспяховы бізнэс, і калі кліенты літаральна запатрабуюць тое ж самае. Аднак трэба прыкласці пэўныя намаганні, каб прымусіць Google нешта падтрымліваць.
Гэта адсутнасць культуры падтрымкі, у спалучэнні з прынцыпам "давайце зламаем, каб зрабіць прыгажэй", адчужае ад іх распрацоўшчыкаў.
І гэта не вельмі добра, калі вы хочаце пабудаваць доўгажывучую платформу.
Google, прачынайся, чорт пабяры. Цяпер 2020 год. Ты ўсё яшчэ прайграеш. Нетутэйша час пільна паглядзець у люстэрка і адказаць, ці сапраўды ты жадаеш застацца ў хмарным бізнэсе.
Калі хочаш застацца, то спыні ўсё ламаць. Хлопцы, вы ж багатыя. Мы, распрацоўшчыкі - не. Таму, калі справа даходзіць да таго, хто зваліць на сябе цяжар сумяшчальнасці, вам трэба ўзяць гэта на сябе. Не нам.
Таму што ёсць яшчэ па меншай меры тры сапраўды добрых аблокі. Яны вабяць да сябе.
А зараз я пайду далей чыніць усе свае зламаныя сістэмы. Эх.
Да наступнага разу!
PS Абнаўленне пасля чытання некаторых абмеркаванняў гэтага артыкула (абмеркаванні пышныя, дарэчы). Падтрымка Firebase не спынена, і няма ніякіх планаў, аб якіх я ведаю. Тым не менш, у іх ёсць непрыемная памылка струменевай перадачы, якая прымушае Java-кліент спыняцца ў App Engine. Адзін з іх інжынераў дапамог мне справіцца з гэтай праблемай, калі я працаваў у 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 !
Апдэйт 3, 31.08.2020. Са мной звязаўся інжынер Google у Cloud Marketplace, які аказаўся маім старым сябрам. Ён хацеў высветліць, чаму не працуе C2D, і ў рэшце рэшт мы высветлілі: прычына ў тым, што я стварыў сваю сетку некалькі гадоў таму, а C2D не спрацоўвае ў састарэлых сетках з-за адсутнага параметра падсеткі ў іх шаблонах. Думаю, што патэнцыйным карыстачам GCP лепш пераканацца, што ў іх дастаткова знаёмых інжынераў у Google…
Крыніца: habr.com