Черт, 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. Я не говорю, что вас обманывают, но, по моему личному мнению, это большие деньги за пустую чертову базу данных.
Еще один интересный момент заключается в том, что хранилище по-прежнему работало через два года. Что за чертовщина? Дата-центры приходят и уходят; они испытывают сбои, проходят плановое техническое обслуживание, все время меняются. Железо обновляется, коммутаторы меняются местами, все постоянно совершенствуется. Как, черт возьми, им удалось сохранить мою программу работающей в течение двух лет с учетом всех этих изменений? Это может показаться скромным достижением в 2020 году, но в 2005-2007 годах это было довольно впечатляюще.
И самый удивительный аспект заключается в том, что посторонняя инженерная команда из какого-то другого штата обращается ко мне, владельцу какого-то крошечного, практически пустого экземпляра Bigtable, у которого нулевой трафик в течение последних двух лет — и предлагает помощь в его обновлении.
Я поблагодарил их, удалил хранилище, и жизнь пошла своим чередом. Но тринадцать лет спустя я все еще думаю об этом письме. Потому что иногда мне приходят похожие письма от Google Cloud. Они выглядят так:
Уважаеми потребителю на Google Cloud,
Напомняме ви, че спираме обслужването на услугата [важен сервис, който използвате] от август 2020 година, след което няма да можете да актуализирате своите инстанции. Препоръчваме да се преместите на последната версия, която в момента е в бета тестове, няма никаква документация, нито път за миграция и която вече е остаряла с наша любезна помощ.
Стремим се това изменение да повлияе минимално на всички потребители на платформата Google Cloud.
Най-добри приятели завинаги,
Облачна платформа Google
Но почти не прочитам такива писма, защото наистина в тях се казва следното:
Уважаеми получател,
Отиди си на дявола. Отиди, отиди, отиди. Изхвърли всичко, което правиш, защото не е важно. Важно е нашето време. Изразходваме време и пари, за да поддържаме нашето боклук, и ние сме уморени от това, затова повече няма да го поддържаме. Така че остави твоите проклети планове и започни да търсиш в нашата боклучава документация, изпросвайки остатъци по форумите, и между другото, нашето ново боклук е напълно различно от старото боклук, защото доста сериозно развалихме този дизайн, хех, но това е твой проблем, а не наш.
Все още полагаме усилия, за да направим всичките ти разработки неизползваеми в рамките на една година.
Моля, иди на дявола,
Облачна платформа Google
И работата е там, че получавам такива писма около веднъж на месец. Става толкова често и толкова постоянно, че неизменно ме отблъсна от GCP в лагера на противниците на облаците. Вече не желая да завися от техните проприетарни разработки, защото наистина е по-лесно на девопса да поддържа система с отворен код на гола виртуалка, отколкото да опитва да настигне Google с нейната политика за затваряне на 'остарял' продукти.
Преди да се върна към Google Cloud, защото аз даже не съм близо не е приключил с критиката, нека да разгледаме работата на компанията в някои други сфери. Инженерите на Google се гордеят с дисциплината си в разработката на софтуер, но именно това всъщност създава проблеми. Гордостта е капан за небрежните и накара много служители на Google да мислят, че решенията им винаги са правилни и че правилността (по някакво неопределено определение) е по-важна от грижата за клиентите.
Ще дам няколко произволни примера от други големи проекти извън Google, но се надявам, че ще видите този шаблон навсякъде. Става въпрос за следното: обратната съвместимост поддържа жизнеността и актуалността на системите в продължение на десетилетия.
Обратната съвместимост е целта на проектирането на всички успешни системи, предназначени за отворено предоставяне, т.е. реализирани с отворен код и/или на отворени стандарти. Чувствам, че казвам нещо твърде очевидно, което дори е неудобно за всички, но не. Това е политически въпрос, следователно са нужни примери.
Първата система, която ще избера, е най-старата: GNU Emacs, тя е нещо като хибрид между Notepad на 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 бяха доста глупава идея. И знаете ли защо? Защото изискваха да презапишете и преработите приложението си! Как да предположа, че хората просто така ще вземат и ще презапишат два милиона приложения. Предполагам, че мигновените приложения бяха идея на някой от Google.
Но тук има разлика. Обратната съвместимост е свързана с големи разходи. 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 с Гвидо, седях в палатка с Пол Гръм и куп важни личности. Седяхме в изтощителната жега, чакайки Ларри Пейдж да кацне с личния си хеликоптер, а Гвидо монотонно бубнеше за "Python 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 мощна основа за автоматизирано рефакториране в целия код на компанията (буквално в целия 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, FreeBSD и т.н., за невероятната работа, която са свършили, за да осигурят обратна съвместимост на успешните си платформи (Apple получава в най-добрия случай тройка с минус, тъй като постоянно всичко счупват без уважителна причина, но по някакъв начин общността успява да се справи с това при всяко издание и досега контейнерите с OS X все още не са напълно остарели… засега).
Но чакайте, ще кажете. Не сравняваме ли ябълки с портокали - автономни софтуерни системи на една машина, като Emacs/JDK/Android/Chrome, с многосървърни системи и API, каквито са облачните услуги?
Ами, написах за това вчера в Twitter, но в стил на Лари Уол (създавача на езика за програмиране Perl — бел. пр.), по принципа "отстой/рулез" търсих думата deprecated в сайтовете на разработчиците на Google и Amazon. И макар AWS да има стотици пъти повече оферти за услуги, отколкото GCP, документацията на разработчиците на Google споменава остаряването около седем пъти по-често.
Ако някой от Google чете това, със сигурност са готови да извадят диаграми в стила на Доналд Тръмп, показвайки, че всъщност правят всичко правилно, и че не трябва да правя несправедливи сравнения като "броя упоменавания на думата deprecated в зависимост от броя на услугите".
Но след толкова години Google Cloud все още остава на номер 3 (така и не написах статия за неуспешния опит да стана номер 2), но ако вярваме на инсайдерите, има някои опасения, че скоро могат да паднат на номер 4.
Нямам убедителни аргументи, за да "докажа" своята теза. Всичко, което имам, са цветисти примери, които съм събрал за 30 години работа като разработчик. Вече споменах за дълбоката философска природа на този проблем; донякъде е политизиран в общностите на разработчиците. Някои смятат, че създателите на платформите трябва да се грижат за съвместимостта, а други смятат, че това е безпокойство потребителите (на самите разработчици). Едното или другото. И нали наистина не е ли политически въпрос, когато решаваме кой трябва да поеме разходите за общите проблеми?
Така че, това е политика. И със сигурност ще има гневни реакции на моето изказване.
Как потребител като потребител на Google Cloud платформа и 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 година. Все още губиш. Време е да погледнеш сериозно в огледалото и да отговориш, наистина ли искаш да останеш в облачния бизнес.
Ако искаш да останеш, то спри да чупиш всичко.Хора, вие сте богати. Ние, разработчиците, не сме. Затова, когато става въпрос за това кой да поеме тежестта на съвместимостта, трябва да поемете това. Не на нас.
Защото все още има поне три наистина добри облака. Те ни примамват.
А сега ще продължа да поправям всичките си счупени системи. Ох.
До следващия път!
P. S. Актуализация след прочитането на някои дискусии относно тази статия (дискусиите са великолепни, между другото). Поддръжката на 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 вече обсъждат този въпрос и като цяло са съгласни с мен (обичам ви, момчета!). Но изглежда, че го считат за нерешим проблем, защото в културата на 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
