Чорт забирай, 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