Скъпи Google Cloud, липсата на обратна съвместимост те убива.

По дяволите Google, не исках отново да пиша блог. Имам толкова много работа. Блогът отнема време, енергия и креативност, които бих могъл да използвам добре: моите книги, музыка, моята игра и така нататък. Но ти ме ядоса достатъчно, че трябва да напиша това.

Така че нека приключим с това.

Позволете ми да започна с кратка, но поучителна история от времето, когато започнах работа в Google. Знам, че напоследък говоря много лоши неща за Google, но се разстройвам, когато собствената ми компания редовно взема некомпетентни бизнес решения. В същото време трябва да му отдадем дължимото: вътрешната инфраструктура на Google е наистина изключителна, безопасно е да се каже, че днес няма нищо по-добро. Основателите на Google бяха много по-добри инженери, отколкото аз някога ще бъда, и тази история само потвърждава този факт.

Първо, малко предистория: Google има технология за съхранение на данни, наречена Голяма маса. Това беше забележително техническо постижение, едно от първите (ако не и първото) „безкрайно мащабируемо“ хранилище на ключ-стойност (K/V): по същество началото на NoSQL. Тези дни Bigtable все още се справя добре в доста претъпканото пространство за съхранение на K/V, но по това време (2005 г.) беше невероятно готино.

Едно забавно нещо за Bigtable е, че те имаха обекти на вътрешна контролна равнина (като част от внедряването), наречени сървъри за таблети, с големи индекси, и в един момент те се превърнаха в пречка при мащабиране на системата. Инженерите на Bigtable се чудеха как да приложат мащабируемост и внезапно осъзнаха, че могат да заменят таблетните сървъри с други 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, че само две години по-късно някой забеляза допълнителното хранилище и само защото версията на двоичния файл беше остаряла. За сравнение, веднъж обмислях да използвам Bigtable в Google Cloud за моята онлайн игра. По онова време тази услуга струваше приблизително 16 000 долара на година. празен Bigtable на GCP. Не казвам, че ви мамят, но по мое лично мнение това са много пари за празна шибана база данни.

Друг забележителен аспект е съхранението все още работи след две години. WTF? Центровете за данни идват и си отиват; изпитват прекъсвания, преминават през планирана поддръжка, променят се през цялото време. Хардуерът е актуализиран, превключвателите са разменени, всичко непрекъснато се подобрява. Как, по дяволите, успяха да поддържат програмата ми да работи две години с всички тези промени? Това може да изглежда като скромно постижение през 2020 г., но през 2005-2007 г. беше доста впечатляващо.

И най-прекрасният аспект е, че външен инженерен екип в някакъв друг щат се обръща към мен, собственик на някакъв малък, почти празен екземпляр на Bigtable, който има нулев трафик за последните две години - и предлагат помощ за актуализирането му.

Благодарих им, изтрих хранилището и животът продължи както обикновено. Но тринадесет години по-късно все още мисля за това писмо. Защото понякога получавам подобни имейли от Google Cloud. Те изглеждат така:

Уважаеми потребител на Google Cloud,

Като напомняне, ние ще прекратим услугата [основна услуга, която използвате] от август 2020 г., след което няма да можете да надграждате своите копия. Препоръчваме надграждане до най-новата версия, която е в бета тестване, няма документация, няма път за мигриране и е предварително остаряла с нашата любезна помощ.

Ние се ангажираме да гарантираме, че тази промяна има минимално въздействие върху всички потребители на платформата Google Cloud.

Най-добри приятели завинаги,
Google Cloud Platform

Но почти никога не чета такива писма, защото това, което всъщност казват е:

Уважаеми получател,

Върви по дяволите. Майната ти, майната ти, майната ти. Зарежете всичко, което правите, защото няма значение. Важното е нашето време. Губим време и пари, за да поддържаме нашите глупости и сме уморени от тях, така че няма да ги поддържаме повече. Така че се откажете от шибаните си планове и започнете да се ровите в нашата скапана документация, да молите за бележки във форумите и между другото, нашите нови неща са напълно различни от старите неща, защото ние прецакахме този дизайн доста зле, хех, но това е вашето проблем, не наш.

Продължаваме да полагаме усилия, за да гарантираме, че всички ваши разработки стават неизползваеми в рамките на една година.

Моля, майната му
Google Cloud Platform

И факт е, че получавам такива писма около веднъж месечно. Това се случва толкова често и толкова постоянно, че те неизбежно отблъснат аз от GCP към анти-облачния лагер. Вече не съм съгласен да разчитам на техните собствени разработки, защото всъщност е по-лесно за devops да поддържат система с отворен код на чиста виртуална машина, отколкото да се опитват да бъдат в крак с Google с политиката му за затваряне на „остарели“ продукти.

Преди да се върна към Google Cloud, защото аз дори не е близо не свършихме да ги критикуваме, нека погледнем представянето на компанията в някои други области. Инженерите на Google се гордеят със своята дисциплина в софтуерното инженерство и това е, което всъщност създава проблеми. Гордостта е капан за непредпазливите и накара много служители на Google да мислят, че решенията им винаги са правилни и че да си прав (по някаква неясна размита дефиниция) е по-важно от грижата за клиентите.

Ще дам някои произволни примери от други големи проекти извън Google, но се надявам да виждате този модел навсякъде. Той е както следва: обратната съвместимост поддържа системите живи и актуални в продължение на десетилетия.

Обратната съвместимост е целта на дизайна на всички успешни системи, предназначени за отворен използване, тоест реализирано с отворен код и/или отворени стандарти. Имам чувството, че казвам нещо твърде очевидно, че всички дори се чувстват неудобно, но не. Това е политически въпрос, така че са необходими примери.

Първата система, която ще избера, е най-старата: GNU Emacs, която е нещо като хибрид между Windows Notepad, ядрото на ОС и Международната космическа станция. Малко е трудно за обяснение, но накратко, 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 е прочут технологичен стек и също толкова прословута бодлива организация. Както каза един служител на Google, „Не можете просто да влезете в Android.“

В предишна статия обсъдих колко лоши бяха някои от ранните дизайнерски решения на Android. По дяволите, когато написах тази статия, те пускаха глупости, наречени „мигновени приложения“, които сега (изненада!) остарялаи съчувствам, ако сте били достатъчно глупави да слушате Google и да преместите съдържанието си в тези мигновени приложения.

Но тук има разлика, съществена разлика, която е, че хората с Android наистина разбират колко важни са платформите, те се опитват да направят всичко възможно да запазят старите приложения за Android работещи. Всъщност усилията им да поддържат обратна съвместимост са толкова екстремни, че дори аз, по време на краткия си престой в подразделението за Android преди няколко години, се оказах в опит да ги убедя да спрат поддръжката за някои от най-старите устройства и API (греших , както беше в много други неща от миналото и настоящето. Съжалявам, момчета от Android! Сега, когато бях в Индонезия, разбирам защо имаме нужда от тях).

Хората с Android тласкат обратната съвместимост до почти невъобразими крайности, натрупвайки огромни количества наследен технически дълг в своите системи и вериги от инструменти. О, боже мой, трябва да видите някои от лудите неща, които трябва да направят в тяхната система за изграждане, всичко това в името на съвместимостта.

За това присъждам на Android желаната награда „Вие не сте Google“. Те наистина не искат да станат Google, който не знае как да създава издръжливи платформи, а Android Той знае,, как да го направим. И така, Google е много умен в едно отношение: позволява на хората да правят нещата по свой собствен начин в Android.

Въпреки това мигновените приложения за Android бяха доста глупава идея. И знаете ли защо? Защото поискаха пренапишете и преработете вашето приложение! Сякаш хората просто ще пренапишат два милиона приложения. Предполагам, че Instant Apps е идея на някой служител на Google.

Но има разлика. Обратната съвместимост идва на висока цена. Самата Android носи тежестта на тези разходи, докато Google настоява тежестта да бъде поета ви, плащащ клиент.

Можете да видите ангажимента на Android за обратна съвместимост в неговите API. Когато имате четири или пет различни подсистеми, които правят буквално едно и също нещо, това е сигурен знак, че в основата има ангажимент за обратна съвместимост. Което в света на платформите е синоним на ангажираност към вашите клиенти и вашия пазар.

Основният проблем на Google тук е гордостта им от тяхната инженерна хигиена. Те не харесват, когато има много различни начини да се направи едно и също нещо, като старите, по-малко желани начини стоят до новите, по-фантастични начини. Това увеличава кривата на обучение за тези, които са нови в системата, увеличава тежестта на поддържането на наследени API, забавя скоростта на новите функции и основният грях е, че не е красиво. Google – като лейди Аскот от „Алиса в страната на чудесата“ на Тим Бъртън:

Лейди Аскот:
- Алис, знаеш ли от какво се страхувам най-много?
- Упадъкът на аристокрацията?
- Страхувах се, че ще имам грозни внуци.

За да разберем компромиса между красиво и практично, нека да разгледаме третата успешна платформа (след Emacs и Android) и да видим как работи: самата Java.

Java има много остарели API. Отказът от употреба е много популярен сред Java програмистите, дори по-популярен, отколкото в повечето езици за програмиране. Самата Java, основният език и библиотеките постоянно отхвърлят API.

За да вземем само един от хилядите примери, затваряне на нишки считани за остарели. Той е отхвърлен от пускането на Java 1.2 през декември 1998 г. Изминаха 22 години, откакто това беше отхвърлено.

Но действителният ми код в производството все още убива нишки всеки ден. Наистина ли мислиш, че това е добре? Абсолютно! Искам да кажа, разбира се, че ако трябваше да пренапиша кода днес, бих го приложил по различен начин. Но кодът за моята игра, която направи стотици хиляди хора щастливи през последните две десетилетия, е написан с функция за затваряне на нишки, които висят твърде дълго, и аз никога не се е налагало да го променям. Познавам системата си по-добре от всеки друг, имам буквално 25 години опит в работата с нея в производството и мога да кажа със сигурност: в моя случай затварянето на тези специфични работни нишки е напълно безполезно. Не си струва времето и усилията да пренапиша този код и благодаря на Лари Елисън (вероятно), че Oracle не ме принуди да го пренапиша.

Oracle вероятно разбира и платформи. Кой знае.

Доказателства могат да бъдат намерени в основните API на Java, които са изпълнени с вълни от остарялост, като линиите на ледник в каньон. Можете лесно да намерите пет или шест различни мениджъра за навигация на клавиатурата (KeyboardFocusManager) в библиотеката на Java Swing. Всъщност е трудно да се намери Java API, който да не е остарял. Но те все още работят! Мисля, че екипът на Java наистина ще премахне API само ако интерфейсът представлява очевиден проблем със сигурността.

Ето как стоят нещата, хора: всички ние, разработчиците на софтуер, сме много заети и във всяка област на софтуера сме изправени пред конкурентни алтернативи. Във всеки един момент програмистите на език X обмислят език Y като възможна замяна. О, не ми вярваш? Искате ли да го наречете Swift? Като че ли всички мигрират към Swift и никой не го изоставя, нали? Леле, колко малко знаеш. Компаниите пресмятат разходите за двойни екипи за разработка на мобилни устройства (iOS и Android) - и започват да осъзнават, че тези системи за разработка на различни платформи със забавни имена като Flutter и React Native всъщност работят и могат да се използват за намаляване на размера на техните мобилни екипи два пъти или, обратно, да ги направи два пъти по-продуктивни. Заложени са истински пари. Да, има компромиси, но, от друга страна, пари.

Нека предположим хипотетично, че Apple глупаво е взела пример от Guido van Rossum и е обявила, че Swift 6.0 е обратно несъвместим със Swift 5.0, подобно на Python 3 е несъвместим с Python 2.

Вероятно разказах тази история преди около десет години, но преди около петнадесет години отидох в O'Reilly's Foo Camp с Гуидо, седях в палатка с Пол Греъм и куп големи изстрели. Седяхме в знойната жега и чакахме Лари Пейдж да излети с личния си хеликоптер, докато Гуидо дрънчеше за „Python 3000“, който той нарече на броя години, които ще са необходими на всички да мигрират там. Постоянно го питахме защо нарушава съвместимостта и той отговаряше: „Уникод“. И ние попитахме, ако трябва да пренапишем нашия код, какви други ползи ще видим? И той отговори: "Yooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo."

Ако инсталирате Google Cloud Platform SDK („gcloud“), ще получите следното известие:

Уважаеми получател,

Бихме искали да ви напомним, че поддръжката за Python 2 е остаряла, така че майната ви

… и така нататък. Кръговрата на живота.

Но въпросът е, че всеки разработчик има избор. И ако ги принудите да пренаписват кода достатъчно често, може да се замислят друг настроики. Те не са ваши заложници, колкото и да ви се иска да бъдат. Те са ваши гости. Python все още е много популярен език за програмиране, но, по дяволите, Python 3(000) създаде такава бъркотия в себе си, в своите общности и сред потребителите на своите общности, че последствията не са изяснени в продължение на петнадесет години.

Колко програми на Python са пренаписани в Go (или Ruby, или друга алтернатива) поради тази обратна несъвместимост? Колко нов софтуер е написан на нещо различно от Python, въпреки че може да бъде написано на Python, ако Гуидо не беше изгорил цялото село? Трудно е да се каже, но Python очевидно е пострадал. Това е огромна бъркотия и всички губят.

Да кажем, че Apple взема пример от Guido и нарушава съвместимостта. Какво мислите, че ще се случи след това? Е, може би 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, МАЙНАТА ТИ APPLE, FreeBSD и т.н., за това, че вършат толкова страхотна работа за обратна съвместимост на техните успешни платформи (Apple получава C в най-добрия случай с The недостатъкът е, че те прекъсват всичко през цялото време без основателна причина, но някак си общността го заобикаля с всяко издание и контейнерите на OS X все още не са напълно остарели... все още).

Но чакай, казваш. Не сравняваме ли ябълки с портокали – самостоятелни софтуерни системи на една машина като Emacs/JDK/Android/Chrome срещу мултисървърни системи и API като облачни услуги?

Е, туитнах за това вчера, но в стила на Лари Уол (създател на езика за програмиране Perl - прибл. пер.) на принципа "гадно/правилно" потърсих думата отхвърлена в сайтовете за разработчици на Google и Amazon. И въпреки че AWS има стотици пъти повече предложения за услуги от GCP, документацията на Google за разработчици споменава оттегляне около седем пъти по-често.

Ако някой в ​​Google чете това, вероятно е готов да извади диаграми в стил Доналд Тръмп, показващи, че всъщност правят всичко както трябва и че не трябва да правя несправедливи сравнения като „брой споменавания на думата отхвърлена спрямо брой услуги" "

Но след всички тези години Google Cloud все още е услуга номер 3 (никога не съм писал статия за неуспешния опит да стана номер 2), но ако се вярва на вътрешните хора, има някои опасения, че те скоро могат да паднат до номер 4.

Нямам убедителни аргументи, с които да "докажа" тезата си. Всичко, което имам, са колоритните примери, които съм натрупал в продължение на 30 години като разработчик. Вече споменах дълбоко философския характер на този проблем; в някои отношения това е политизирано в общностите на разработчиците. Някои вярват, че създатели платформите трябва да се грижат за съвместимостта, докато други смятат, че това е проблем потребители (самите разработчици). Едно от две. Наистина, не е ли политически въпрос, когато решаваме кой да поеме разходите за общи проблеми?

Така че това е политика. И вероятно ще има гневни отговори на речта ми.

Като потребител Google Cloud Platform и като потребител на AWS от две години (докато работех за Grab), мога да кажа, че има огромна разлика между философиите на Amazon и Google, когато става въпрос за приоритети. Не разработвам активно на AWS, така че не знам много добре колко често премахват стари API. Но има подозрение, че това не се случва толкова често, колкото в Google. И аз наистина вярвам, че този източник на постоянни противоречия и разочарование в GCP е един от най-големите фактори, които спират развитието на платформата.

Знам, че не посочих конкретни примери за GCP системи, които вече не се поддържат. Мога да кажа, че почти всичко, което съм използвал, от мрежи (от най-старите до VPC) до съхранение (Cloud SQL v1-v2), Firebase (сега Firestore с напълно различен API), App Engine (да не започваме дори) , облачни крайни точки Облачна крайна точка и до... не знам - абсолютно всичко това ви принудиха да пренапишете кода след максимум 2-3 години и никога не автоматизираха миграцията вместо вас и често изобщо не е имало документиран път на миграция. Сякаш така е трябвало да бъде.

И всеки път, когато погледна AWS, се питам защо, по дяволите, все още съм на GCP. Те явно не се нуждаят от клиенти. Те се нуждаят от покупатели. Разбирате ли разликата? Нека обясня.

Google Cloud има Пазар, където хората предлагат своите софтуерни решения, и за да избегнат ефекта на празния ресторант, те трябваше да го напълнят с някои предложения, така че сключиха договор с компания, наречена Bitnami, за да създадат куп решения, които се внедряват с „едно щракване“ или трябва Сам го пиша „решения“, защото те не решават нищо. Те просто съществуват като квадратчета за отметка, като маркетингов пълнител и Google никога не се интересува дали някой от инструментите наистина работи. Познавам продуктови мениджъри, които са били на шофьорското място, и мога да ви уверя, че на тези хора не им пука.

Вземете, например, предполагаемо решение за внедряване с „едно щракване“. Перкона. Беше ми писнало до смърт от измамите на Google Cloud SQL, така че започнах да гледам изграждането на собствен клъстер Percona като алтернатива. И този път изглежда, че Google са свършили добра работа, щяха да ми спестят малко време и усилия с едно натискане на бутон!

Е, страхотно, да тръгваме. Нека последваме връзката и щракнете върху този бутон. Изберете „Да“, за да приемете всички настройки по подразбиране и да разположите клъстера във вашия облачен проект на Google. Хаха, не става. Нищо от тези глупости не работи. Инструментът никога не е бил тестван и започна да гние от първата минута и няма да ме изненада, ако повече от половината от „решенията“ са внедрявания с едно щракване (сега разбираме защо кавичките) като цяло не работи. Това е абсолютно безнадежден мрак, в който е по-добре да не влизате.

Но Google е прав подтици да ги използвате. Те искат от теб закупени. За тях това е сделка. Те не искат нищо поддържа. Това не е част от ДНК на Google. Да, инженерите се подкрепят взаимно, както се вижда от историята ми с Bigtable. Но в продуктите и услугите за обикновените хора те винаги бяха безмилостни в затваряне на всяка услуга, което не отговаря на летвата за доходност, дори ако има милиони потребители.

И това представлява истинско предизвикателство за GCP, защото това е ДНК зад всички облачни предложения. Те не се опитват да подкрепят нищо; Добре известно е, че те отказват да хостват (като управлявана услуга) софтуер на трети страни до, докато AWS не направи същото и изгради успешен бизнес около него, и когато клиентите буквално изискват същото. Необходими са обаче известни усилия, за да накарате Google да поддържа нещо.

Тази липса на култура на поддръжка, съчетана с манталитета „нека го разбием, за да стане по-красив“, отблъсква разработчиците.

И това не е добре, ако искате да изградите дълготрайна платформа.

Google, събуди се, по дяволите. Сега е 2020 г. Все още губиш. Време е да се погледнете внимателно в огледалото и да си отговорите дали наистина искате да останете в облачния бизнес.

Ако искаш да останеш тогава спри да чупиш всичко. Момчета, вие сте богати. Ние, разработчиците, не го правим. Така че, когато става въпрос за това кой ще поеме тежестта на съвместимостта, вие трябва да я поемете върху себе си. Не за нас.

Защото има поне още три наистина добри облака. Те привличат.

И сега ще продължа да поправям всичките си повредени системи. Ех

До следващия път!

PS Актуализация, след като прочетете някои от дискусиите по тази статия (дискусиите са страхотни, btw). Поддръжката на 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 г. Ивица актуализира API правилно!

Актуализация 3, 31.08.2020 г. С мен се свърза инженер на Google в Cloud Marketplace, който се оказа мой стар приятел. Той искаше да разбере защо C2D не работи и в крайна сметка разбрахме, че е защото бях изградил моята мрежа преди години и C2D не работеше на наследени мрежи, защото параметърът на подмрежата липсваше в техните шаблони. Мисля, че е най-добре потенциалните потребители на GCP да се уверят, че познават достатъчно инженери в Google...

Източник: www.habr.com