該死的谷歌，我不想再寫部落格了。 我有很多事要做。 寫部落格需要時間、精力和創造力，我可以充分利用這些：我的書， ，我的遊戲等等。 但你已經讓我很生氣了，所以我必須寫這篇文章。
那麼就讓我們結束這件事吧。
讓我從我剛開始在谷歌工作時發生的一個簡短但富有啟發性的故事開始。 我知道我最近說了很多關於谷歌的壞話，但是當我自己的公司經常做出不稱職的商業決策時，我感到很沮喪。 同時，我們必須給予它應有的評價：Google的內部基礎設施確實非常出色，可以肯定地說，今天沒有比這更好的了。 谷歌的創辦人是比我更優秀的工程師，這個故事只是證實了這個事實。
首先，介紹一下背景：Google有一種資料儲存技術，稱為 。 這是一項了不起的技術成就，也是第一個（如果不是第一個）「無限可擴展」鍵值儲存 (K/V) 之一：本質上是 NoSQL 的開始。 如今，Bigtable 在相當擁擠的 K/V 儲存空間中仍然表現良好，但在當時（2005 年）它已經非常酷了。
Bigtable 的一個有趣的事情是，它們有稱為 Tablet 伺服器的內部控制平面物件（作為實作的一部分），具有很大的索引，並且在某些時候它們成為擴展系統時的瓶頸。 Bigtable 工程師正在困惑如何實現可擴展性，突然意識到他們可以用其他 Bigtable 儲存空間來取代平板伺服器。 所以Bigtable是Bigtable實作的一部分。 這些儲存設施遍布各級。
另一個有趣的細節是，有一段時間 Bigtable 在 Google 內變得流行和普遍，每個團隊都有自己的儲存庫。 因此，在周五的一次會議上，Larry Page 順便問道：「為什麼我們有不只一個 Bigtable？ 為什麼不只一個呢？” 理論上，一個儲存應該足以滿足 Google 的所有儲存需求。 當然，他們從來不會僅僅出於實際開發的原因（例如潛在失敗的後果）而選擇一個，但這個理論很有趣。 整個宇宙的一個儲存庫（順便問一下，有人知道亞馬遜是否對他們的 Sable 這樣做過嗎？)
無論如何，這是我的故事。
當時，我在 Google 工作了兩年多，有一天我收到了一封來自 Bigtable 工程團隊的電子郵件，內容如下：
親愛的史蒂夫，
來自 Bigtable 團隊的問候。 我們想通知您，在[資料中心名稱]，您正在使用非常非常舊的 Bigtable 二進位。 該版本不再受支持，我們希望幫助您升級到最新版本。
如果您可以安排一些時間共同解決此問題，請告訴我。
一切順利，
大表團隊
在谷歌上你會收到很多郵件，所以乍一看我讀到了這樣的內容：
親愛的收件人，
來自某個隊伍的問候。 我們想傳達這樣的訊息：等等等等。 哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
如果您可以安排一些寶貴的時間來進行等等，請告訴我們。
一切順利，
某種命令
我幾乎立刻就把它刪除了，但在我意識的邊緣，我感到一種痛苦的、揮之不去的感覺： 不是真的 雖然看起來像是一封正式的信 明顯，收件人被誤認為是因為我沒有使用 Bigtable。
但這很奇怪。
那天剩下的時間裡，我交替思考工作和在微型廚房裡嘗試什麼樣的鯊魚肉，其中至少有三個離我的座位足夠近，可以從我的座位上瞄準扔一塊餅乾，但是寫作的想法從未讓我感到越來越強烈的輕微焦慮。
他們清楚地說出了我的名字。 並且該電子郵件發送到我的電子郵件地址，而不是其他人的電子郵件地址，並且不是抄送：或密件副本：。 語調非常個性化且清晰。 也許這是某種錯誤？
最後，好奇心戰勝了我，我去看了他們提到的資料中心的 Borg 控制台。
當然，我還管理 BigTable 儲存。 對不起，什麼？ 我看了看裡面的內容，哇！ 它來自於 2005 年 XNUMX 月我在 Google 工作的第一週所在的 Codelab 孵化器。 Codelab 強迫你運行 Bigtable 在那裡寫入一些值，而且我顯然在那之後從未關閉過儲存。 儘管兩年多過去了，它仍然有效。
這個故事有幾個值得注意的面向。 首先，Bigtable 的工作對於 Google 的規模來說實在是微不足道，以至於兩年後才有人注意到額外的儲存空間，而且只是因為二進位版本已經過時了。 為了進行比較，我曾經考慮過使用 對於我的線上遊戲。 當時，這項服務每年的費用約為 16 美元。 空的 GCP 上的 Bigtable。 我並不是說他們在欺騙你，但以我個人的觀點，對於一個空的該死的資料庫來說這是很多錢。
另一個值得注意的方面是存儲 兩年後仍在工作。 搞什麼？ 資料中心來來去去； 它們會經歷停電，進行定期維護，並且一直在變化。 硬體更新，交換器更換，一切都在不斷改進。 他們到底是如何讓我的程式在所有這些變化的情況下運行兩年的？ 這在2020年看來是一個不起眼的成就，但在2005-2007年卻相當令人印象深刻。
最美妙的方面是，其他州的一個外部工程團隊找到了我，我是 Bigtable 的某個小型、幾乎空的實例的所有者，他擁有 零流量 過去兩年 - 並提供更新協助。
我感謝了他們，刪除了存儲，生活照常進行。 但十三年後，我仍然想起那封信。 因為有時我會收到 Google Cloud 的類似電子郵件。 它們看起來像這樣：
尊敬的谷歌雲端用戶，
謹此提醒，我們將於 2020 年 XNUMX 月起停止[您使用的基本服務]服務，此後您將無法升級實例。 我們建議升級到最新版本，該版本正處於 Beta 測試階段，沒有文檔，沒有遷移路徑，並且在我們的幫助下已經過時了。
我們致力於確保這項變更對 Google Cloud 平台的所有使用者的影響降到最低。
永遠最好的朋友，
谷歌雲端平台
但我幾乎從來沒有讀過這樣的信，因為他們實際上說的是：
親愛的收件人，
去死吧。 操你媽，操你，操你。 放棄你所做的一切，因為它並不重要。 重要的是我們的時間。 我們浪費時間和金錢來維護我們的垃圾，我們厭倦了它，所以我們不會再支持它。 所以放棄你他媽的計劃，開始挖掘我們的垃圾文檔，在論壇上乞討碎片，順便說一句，我們的新狗屎與舊狗屎完全不同，因為我們把這個設計搞砸了，嘿，但這就是你的問題，不是我們的。
我們將繼續努力確保您的所有開發項目在一年內變得無法使用。
請滾蛋
谷歌雲端平台
事實上，我大約每個月都會收到一次這樣的信。 這種情況發生得如此頻繁和持續，以至於他們不可避免地 推開 我從 GCP 轉到了反雲陣營。 我不再同意依賴他們的專有開發，因為事實上，對於 DevOps 來說，在裸虛擬機上維護開源系統比試圖跟上 Google 關閉「過時」產品的政策更容易。
在我返回 Google Cloud 之前，因為我 差遠了 批評完了，我們再看看公司在其他一些方面的表現。 谷歌工程師對他們的軟體工程學科感到自豪，而這正是導致問題的真正原因。 驕傲對粗心的人來說是一個陷阱，它導致許多谷歌員工認為他們的決定總是正確的，並且正確（透過一些模糊的定義）比關心客戶更重要。
我將隨機給出一些來自 Google 以外的其他大型專案的範例，但我希望您能隨處看到這種模式。 如下： 向後相容性使系統能夠保持數十年的活力和最新狀態.
向後相容性是所有成功系統的設計目標 開放 使用，即透過開源程式碼和/或開放標準實現。 我覺得我說的話太明顯了，以至於每個人都感到不舒服，但事實並非如此。 這是一個政治問題，所以需要例子。
我選擇的第一個系統是最古老的：GNU Emacs，它是 Windows 記事本、作業系統核心和國際太空站的混合體。 解釋起來有點困難，但簡而言之，Emacs 是一個創建於 1976 年（是的，差不多半個世紀前）的平台，用於編程以提高工作效率，但偽裝成文本編輯器。
我每天都使用 Emacs。 是的，我也每天使用 IntelliJ，它本身已經發展成為一個強大的工具平台。 但是，為 IntelliJ 編寫擴充功能是一項比為 Emacs 編寫擴充功能更加雄心勃勃、更加複雜的任務。 更重要的是，為 Emacs 編寫的所有內容都被保留 永遠.
我仍然使用 1995 年為 Emacs 編寫的軟體。 我確信有人在 80 年代中期（如果不是更早的話）正在使用為 Emacs 編寫的模組。 它們可能需要不時地進行一些調整，但這確實很少見。 我不知道我為 Emacs 編寫過的任何內容（而且我已經寫了很多）需要重新架構。
Emacs 有一個名為 make-obsolete 的函數，用於處理過時的實體。 用於基本計算機概念（例如“視窗”是什麼）的 Emacs 術語通常與行業慣例不同，因為 Emacs 很久以前就引入了它們。 對於那些走在時代前沿的人來說，這是一個典型的危險：你所有的術語都是不正確的。 但 Emacs 確實有一個棄用的概念，用他們的行話來說就是 報廢.
但在 Emacs 世界中似乎有不同的工作定義。 如果你願意的話，這是一種不同的基本哲學。
在Emacs 領域（以及我們將在下面介紹的許多其他領域），已棄用的API 狀態基本上意味著：「您確實不應該使用這種方法，因為雖然它有效，但它存在各種缺點，我們將在這裡列出。 但歸根結底，這是你的選擇。”
在 Google 的世界中，被棄用意味著「我們違反了對您的承諾」。 這是真實的。 這就是它的本質意義。 這意味著他們會強迫你 經常 做一些工作，也許很多工作，作為對相信它們的懲罰 ：我們有最好的軟體。 最快的！ 您按照說明執行所有操作，啟動您的應用程式或服務，然後砰的一聲，一兩年後它就崩潰了。
就像賣二手車一樣，1500公里後一定會壞掉。
這是「過時」的兩種完全不同的哲學定義。 谷歌對氣味的定義 。 我不相信這個 事實上 計劃報廢與蘋果公司的含義相同。 但谷歌肯定計劃以一種迂迴的方式破壞你的程序。 我知道這一點是因為我在那裡擔任軟體工程師超過 12 年。 他們對於應遵循多少向後相容性有模糊的內部指導方針，但這最終取決於每個團隊或服務。 沒有企業級或工程級建議，就過時週期而言最大膽的建議是“在破壞整個系統之前，請嘗試給客戶 6-12 個月的時間進行升級。”
這個問題比他們想像的要嚴重得多，而且會持續多年，因為客戶關懷並不在他們的基因裡。 下面詳細介紹這一點。
在這一點上，我要大膽聲明，Emacs 在很大程度上是成功的，甚至是 大多 因為他們非常重視向後相容性。 事實上，這就是我們這篇文章的主題。 成功、長壽的開放系統的成功歸功於在其周圍生活了數十年的微型社區 擴充/插件。 這就是生態系。 我已經討論過平台的本質及其重要性，以及 Google 在其整個企業歷史中從未了解過在 Android 或 Chrome 之外創建成功的開放平台需要什麼。
實際上，我應該簡單提一下 Android，因為您可能正在考慮它。
首先， 安卓不是谷歌。 他們彼此幾乎沒有任何共同點。 Android 是一家於 2005 年 XNUMX 月被 Google 收購的公司，該公司被允許或多或少地自主運營，實際上在接下來的幾年裡基本上沒有受到影響。 Android 是一個臭名昭著的技術堆棧，也是一個同樣臭名昭著的多刺組織。 正如一位谷歌員工所說，“你不能只登入 Android。”
在上一篇文章中，我討論了 Android 的一些早期設計決策有多糟糕。 哎呀，當我寫那篇文章時，他們正在推出名為“即時應用程式”的垃圾，現在（驚訝！） ，如果你愚蠢到聽從谷歌並將你的內容轉移到這些即時應用程序，我表示同情。
但這裡有一個區別，一個顯著的區別，那就是 Android 人真正了解平台的重要性，他們盡力讓舊的 Android 應用程式繼續運行。 事實上，他們為保持向後相容性所做的努力是如此極端，以至於就連我，幾年前在Android 部門短暫工作期間，也發現自己試圖說服他們放棄對一些最古老的設備和API 的支援（我錯了） ，就像過去和現在的許多其他事情一樣。對不起 Android 傢伙！既然我去過印度尼西亞，我明白為什麼我們需要它們）。
Android 人員將向後相容性推向了幾乎難以想像的極端，在他們的系統和工具鏈中累積了大量的遺留技術債。 天啊，你應該看到他們在建置系統中必須做的一些瘋狂的事情，所有這些都是以相容性的名義。
為此，我授予 Android 令人垂涎的「你不是 Google」獎。 他們真的不想成為不知道如何創造耐用平台的谷歌，但Android 知道， 怎麼做。 因此，谷歌在某一方面非常聰明：允許人們在 Android 上按照自己的方式做事。
然而，Android 的即時應用程式是一個非常愚蠢的想法。 你知道為什麼嗎？ 因為他們要求 重寫和重新設計您的應用程式！ 就好像人們會簡單地重寫兩百萬個應用程式一樣。 我猜即時應用程式是一些谷歌員工的想法。
但有一個差別。 向後相容性的代價很高。 Android本身承擔了這些費用，而谷歌則堅持由其承擔 вы，付費客戶。
您可以在其 API 中看到 Android 對向後相容性的承諾。 當您有四個或五個不同的子系統實際上執行相同的操作時，這是一個明確的信號，表明核心致力於向後相容。 在平台世界中，這就是對客戶和市場的承諾的代名詞。
谷歌的主要問題是他們對自己的工程衛生感到自豪。 他們不喜歡有很多不同的方法來做同一件事，而舊的、不太理想的方法與新的、更奇特的方法並存。 它增加了系統新手的學習曲線，增加了維護遺留 API 的負擔，降低了新功能的速度，最主要的罪過是它不漂亮。 谷歌 - 就像蒂姆伯頓的愛麗絲夢遊仙境中的阿斯科特女士一樣：
阿斯科特女士：
- 艾莉絲，你知道我最害怕什麼嗎？
- 貴族的衰退？
- 我擔心我會 醜陋的孫子.
為了理解美觀與實用之間的權衡，讓我們來看看第三個成功的平台（繼 Emacs 和 Android 之後），看看它是如何運作的：Java 本身。
Java 有很多過時的 API。 棄用在 Java 程式設計師中非常流行，甚至比大多數程式語言中更流行。 Java 本身、核心語言和函式庫都在不斷地棄用 API。
僅舉數千個例子之一， 被認為是過時的。 自 1.2 年 1998 月發布 Java 22 以來，它已被棄用。 自此被棄用以來已經過去 XNUMX 年了。
但我在生產中的實際程式碼仍然在殺死線程 天天。 你真的認為這樣好嗎？ 絕對地！ 當然，我的意思是，如果我今天重寫程式碼，我會以不同的方式實現它。 但是我的遊戲程式碼在過去二十年裡讓數十萬人感到高興，它是用一個函數編寫的，可以關閉掛起時間過長的線程，而且我 從來不需要改變它。 我比任何人都更了解我的系統，我確實有 25 年在生產中使用它的經驗，我可以肯定地說：就我而言，關閉這些特定的工作線程是完全可行的 無害。 不值得花費時間和精力來重寫這段程式碼，並感謝 Larry Ellison（可能）Oracle 沒有強迫我重寫它。
Oracle 可能也了解平台。 誰知道。
在整個核心 Java API 中都可以找到證據，這些 API 充滿了過時的浪潮，就像峽谷中冰川的線條一樣。 您可以在 Java Swing 庫中輕鬆找到五到六個不同的鍵盤導航管理器（KeyboardFocusManager）。 實際上很難找到一個未被棄用的 Java API。 但他們仍然有效！ 我認為，只有當介面帶來明顯的安全問題時，Java 團隊才會真正刪除 API。
事情是這樣的，夥計們：我們軟體開發人員都非常忙碌，在軟體的每個領域我們都面臨著競爭的替代品。 在任何給定時間，使用 X 語言的程式設計師都將語言 Y 視為可能的替代品。 哦，你不相信我嗎？ 你想把它稱為 Swift 嗎？ 就像，每個人都在遷移到 Swift，沒有人放棄它，對吧？ 哇，你知道的真少。 公司正在計算雙行動開發團隊（iOS 和 Android）的成本 - 他們開始意識到那些名字有趣的跨平台開發系統（如 Flutter 和 React Native）實際上可以工作，並且可以用來減少他們的規模移動團隊的效率提高了一倍，或者相反，使他們的生產力提高了一倍。 這涉及真金白銀。 是的，有妥協，但另一方面，是金錢。
讓我們假設蘋果愚蠢地接受了 Guido van Rossum 的暗示，並宣稱 Swift 6.0 與 Swift 5.0 向後不相容，就像 Python 3 與 Python 2 不相容一樣。
我大概十年前就講過這個故事，但大約十五年前，我和 Guido 一起去了 O'Reilly 的 Foo Camp，和 Paul Graham 以及一群大人物坐在帳篷裡。 我們坐在酷熱的天氣裡等待拉里·佩奇乘坐他的私人直升機飛出去，而吉多則喋喋不休地談論“Python 3000”，他以每個人遷移到那裡需要的年數命名。 我們一直問他為什麼要破壞相容性，他回答說：“Unicode。” 我們問，如果我們必須重寫程式碼，我們還會看到什麼其他好處？ 他回答說：“Yooooooooooooooouuuuuuuniiiiiiicoooooooode。”
如果您安裝 Google Cloud Platform SDK（「gcloud」），您將收到以下通知：
親愛的收件人，
我們想提醒您，對 Python 2 的支援已被棄用，所以去你的吧
… 等等。 生活圈。
但關鍵是每個開發人員都有選擇。 如果你強迫他們足夠頻繁地重寫程式碼，他們可能會考慮 其他 選項。 他們不是你的人質，無論你多麼希望他們成為你的人質。 他們是你的客人。 Python 仍然是一種非常流行的程式語言，但是該死的，Python 3(000) 在其自身、其社群及其社群的用戶中造成瞭如此混亂，其後果十五年來都沒有得到解決。
由於這種向後不相容性，有多少 Python 程式被用 Go（或 Ruby，或其他替代方案）重寫？ 有多少新軟體是用 Python 以外的語言編寫的，儘管它 可能 用 Python 寫的，如果 Guido 沒有燒毀整個村莊？ 很難說，但 Python 顯然受到了影響。 這是一個巨大的混亂，每個人都輸了。
因此，假設蘋果受到 Guido 的啟發並破壞了相容性。 您認為接下來會發生什麼事？ 好吧，如果可能的話，也許 80-90% 的開發人員會重寫他們的軟體。 換句話說，10-20% 的用戶群會自動轉向某種競爭語言，例如 Flutter。
多次這樣做，您將失去一半的用戶群。 就像在體育運動中一樣，在程式設計世界中，目前的形式也很重要。 所有。 任何在五年內失去一半用戶的人都將被視為減肥大王。 你一定是平台世界裡的潮流者。 但這是不支援舊版本隨著時間的推移會毀掉你的地方。 因為每次你解僱一些開發人員時，你（a）永遠失去他們，因為他們對你違反合約感到憤怒，並且（b）將他們交給你的競爭對手。
諷刺的是，當我創建Grok 時，我還幫助Google 成為了一個忽略向後兼容性的首席女主角，Grok 是一個源代碼分析和理解系統，可以輕鬆自動化和檢測代碼本身- 類似於IDE，但這裡是雲端服務儲存大型資料倉儲中所有數十億行 Google 原始碼的具體表示。
Grok 為 Google 員工提供了一個強大的框架，用於在整個程式碼庫（實際上是整個 Google）中執行自動重構。 系統不僅計算你的上游依賴關係（你所依賴的），也計算你的上游依賴關係（你所依賴的） 下降 （這取決於您）所以當您更改 API 時，您知道您正在破壞的每個人！ 這樣，當您進行更改時，您可以驗證 API 的每個用戶是否已更新到新版本，並且實際上，通常使用他們編寫的 Rosie 工具，您可以完全自動化該過程。
這使得谷歌的程式碼庫內部幾乎是超自然的乾淨，因為他們有這些機器人僕人在房子裡跑來跑去，如果他們將SomeDespicouslyLongFunctionName 重命名為SomeDespicouslyLongMethodName，就會自動清理所有東西，因為有人認為這是一個醜陋的孫子，他需要睡覺。
坦白說，它對谷歌內部運作得非常好。 我的意思是，是的，Google 的 Go 社群確實與 Google 的 Java 社群笑得很開心，因為他們有持續重構的習慣。 如果你重新啟動某件事 N 次，這意味著你不僅把它搞砸了 N-1 次，而且過了一段時間，很明顯你可能在第 N 次嘗試中也搞砸了它。 但是，總的來說，他們仍然最重要的是保持代碼「乾淨」。
當他們試圖將這種態度強加給他們的雲端客戶端和其他 API 的使用者時，問題就開始了。
我已經向您介紹了一些 Emacs、Android 和 Java； 讓我們看看最新的成功且長期存在的平台：網路本身。 你能想像自 1995 年我們使用閃爍標籤以來 HTTP 經歷了多少次迭代？ 和網頁上的「正在建造」圖示。
但它仍然有效！ 而且這些頁面仍然有效！ 是的，夥計們，瀏覽器是向後相容性方面的世界冠軍。 Chrome 是罕見的 Google 平台的另一個例子，它的頭腦正確地擰緊了，正如您可能已經猜到的那樣，Chrome 實際上是作為一家與 Google 其餘部分分開的沙盒公司運營的。
我還要感謝作業系統開發人員中的朋友：Windows、Linux、NOT APPLE FUCK YOU APPLE、FreeBSD 等，他們在他們成功的平台上做瞭如此出色的向後相容性工作（Apple 最多只能得到一個C ）缺點是它們總是無緣無故地破壞一切，但不知何故，社區在每個版本中都繞過了它，並且 OS X 容器仍然沒有完全過時......還）。
但是等等，你說。 我們不是在比較蘋果和橘子嗎——單機上的獨立軟體系統（如 Emacs/JDK/Android/Chrome）與多伺服器系統和 API（如雲端服務）？
好吧，我昨天在推特上提到了這一點，但是按照 Larry Wall（編程語言 Perl 的創建者 - 大約是 per.）的風格，根據“糟糕/規則”的原則，我查了這個詞 棄用 在 Google 和 Amazon 開發者網站上。 儘管 AWS 已經 數百 Google 的開發者文件中提到棄用的服務數量是 GCP 的幾倍，提及棄用的頻率大約是 GCP 的七倍。
如果谷歌的任何人正在閱讀這篇文章，他們可能已經準備好拿出唐納德·特朗普式的圖表來表明他們實際上做的一切都是正確的，並且我不應該進行不公平的比較，例如「不建議使用的字詞的提及次數與服務數量" "
但這麼多年過去了，Google雲端仍然是第三大服務（我從來沒有寫過一篇關於試圖成為第二名的失敗嘗試的文章），但如果內部人士可信的話，有人擔心他們可能很快就會跌落第三名。3號。
我沒有任何令人信服的論點來「證明」我的論文。 我所擁有的只是我作為開發人員 30 年來積累的豐富多彩的示例。 我已經提到這個問題的深刻哲學本質； 在某些方面，它在開發者社群中被政治化了。 有些人認為 創造者 平台應該關心相容性，而其他人則認為這是一個問題 用戶 （開發商自己）。 二分之一。 事實上，當我們決定誰應該承擔共同問題的成本時，這不是一個政治問題嗎？
所以這就是政治。 我的演講可能會引起憤怒的反應。
如 用戶 谷歌雲端平台，並且作為兩年的 AWS 用戶（同時為 Grab 工作），我可以說，在優先事項方面，亞馬遜和谷歌的理念存在巨大差異。 我並沒有積極在 AWS 上進行開發，因此我不太清楚他們刪除舊 API 的頻率。 但有人懷疑這種情況並不像谷歌那麼頻繁發生。 我堅信，GCP 中持續存在的爭議和挫折感是阻礙該平台發展的最大因素之一。
我知道我沒有列出不再受支援的 GCP 系統的具體範例。 我可以說我用過的幾乎所有東西，從網路（從最舊的到VPC）到儲存（Cloud SQL v1-v2）、Firebase（現在是具有完全不同API 的Firestore）、App Engine（我們甚至還沒有開始） 、雲端點 Cloud Endpoint 以及...我不知道 - 絕對是這一切 最多 2-3 年後強迫你重寫程式碼，而且他們從來不會為你自動遷移，而且經常 。 就好像本來就該如此一樣。
每次我查看 AWS 時，我都會問自己為什麼我仍然使用 GCP。 他們顯然不需要客戶。 他們需要 покупатели。 你明白其中的差別嗎？ 讓我解釋。
谷歌雲有 ，人們提出他們的軟體解決方案，為了避免空蕩蕩的餐廳效應，他們需要用一些建議來填充它，因此他們與一家名為Bitnami 的公司簽約，創建了一堆「一鍵」部署的解決方案，或者應該我自己寫“解決方案”，因為這些解決不了任何問題。 它們只是作為複選框、行銷填充物而存在，而谷歌從不關心這些工具是否真正有效。 我認識一些一直處於主導地位的產品經理，我可以向你保證這些人不在乎。
以所謂的「一鍵式」部署解決方案為例。 。 我對 Google Cloud SQL 惡作劇感到厭倦，所以我開始考慮建立自己的 Percona 叢集作為替代方案。 這次谷歌似乎做得很好，他們只需點擊一個按鈕就可以節省我一些時間和精力！
太好了，我們走吧。 讓我們點擊連結並點擊此按鈕。 選擇「是」同意所有預設設定並將叢集部署到您的 Google 雲端專案中。 哈哈，這不行。 這些廢話都不起作用。 該工具從未經過測試，並且從第一分鐘就開始腐爛，如果超過一半的“解決方案”是一鍵部署，我不會感到驚訝（現在我們明白為什麼要引用） 一般來說 不起作用。 這是絕對無望的黑暗，最好不要進入。
但谷歌是對的 來電 你要使用它們。 他們希望你 買。 對他們來說，這是一筆交易。 他們什麼都不想要 支持。 它不是谷歌 DNA 的一部分。 是的，工程師們互相支持，我與 Bigtable 的故事就證明了這一點。 但在為一般人提供的產品和服務中 總是 是無情的 ，即使擁有數百萬用戶，也達不到獲利標準。
這對 GCP 來說是一個真正的挑戰，因為這是所有雲端產品背後的 DNA。 他們並不試圖支持任何事情；他們只是想支持任何事情。 眾所周知，他們拒絕託管（作為託管服務）任何第三方軟體 直到，直到 AWS 做同樣的事情並圍繞它建立一個成功的業務，並且當客戶確實有相同的要求時。 然而，要讓谷歌支持某些東西需要付出一些努力。
這種缺乏支持的文化，加上「讓我們打破它，讓它變得更美麗」的心態，疏遠了開發人員。
如果你想建立一個長期存在的平台，這並不是一件好事。
谷歌，醒醒吧，該死的。 現在已經2020年了。 你還是輸了。 是時候認真審視鏡子並回答您是否真的想留在雲端業務了。
如果你想留下來的話 停止破壞一切。 夥計們，你們很有錢。 我們開發人員不這樣做。 所以，誰來承擔相容的重擔，就需要你自己承擔了。 不適合我們。
因為至少還有三朵真正的好雲。 他們招手。
現在我將繼續修復所有損壞的系統。 呃。
直到下一次！
PS 閱讀本文的一些討論後進行更新（順便說一句，討論很棒）。 Firebase 支援尚未停止，據我所知也沒有任何計劃。 然而，他們有一個令人討厭的串流錯誤，導致 Java 用戶端在 App Engine 中停滯。 他們的一位工程師幫我解決了這個問題， 當我在谷歌工作時，但他們從未真正修復過該錯誤，所以我有一個糟糕的解決方法，必須每天重新啟動 GAE 應用程式。 就這樣，已經四年了！ 他們現在有了 Firestore。 遷移到它需要大量工作，因為它是一個完全不同的系統，而且 Firebase 錯誤永遠不會被修復。 可以得到什麼結論呢？ 您可以獲得協助 如果你在公司工作。 我可能是唯一在 GAE 上使用 Firebase 的人，因為我在 100% 原生應用程式中記錄了不到 100 個金鑰，並且由於已知錯誤，它每隔幾天就會停止工作。 除了自行承擔使用風險之外，我還能說些什麼。 我要切換到 Redis。
我也看到一些更有經驗的 AWS 使用者表示 AWS 通常永遠不會停止支援任何服務，SimpleDB 就是一個很好的例子。 我的假設是，AWS 沒有像谷歌那樣出現相同的支援終止問題，這似乎是有道理的。
此外，我注意到 20 天前，Google App Engine 團隊破壞了一個關鍵 Go 庫的託管，關閉了一位核心 Go 開發人員的 GAE 應用程式。 實在是太蠢了。
最後，我聽說 Google 員工已經在討論這個問題並且普遍同意我的觀點（愛你們！）。 但他們似乎認為這個問題無法解決，因為Google的文化從來沒有正確的激勵結構。 我認為花一些時間來討論我在 Grab 工作期間與 AWS 工程師一起工作的絕對令人驚奇的經歷是件好事。 未來的某一天，我希望！
是的，2005 年，43 號樓的巨型自助餐上確實提供了不同類型的鯊魚肉，我最喜歡的是鎚頭鯊肉。 然而，到 2006 年，拉里和謝爾蓋戒掉了所有不健康的零食。 所以在 2007 年的 Bigtable 故事中，確實沒有鯊魚，我欺騙了你。
當我四年前查看雲端 Bigtable 時（不管怎樣），這就是成本所在。 現在似乎有所下降，但這對於一個空的資料倉儲來說仍然是一個可怕的數字，特別是因為我的第一個故事表明一個空的大表在其規模上是多麼無關緊要。
很抱歉冒犯了蘋果社區，並且沒有對微軟等說任何好話。你沒事，我真的很感謝這篇文章引發的所有討論！ 但有時你需要引起一點波瀾才能引發討論，你知道嗎？
謝謝閱讀。
更新 2，19.08.2020 年 XNUMX 月 XNUMX 日。 條紋 !
更新 3，31.08.2020 年 2 月 2 日。 Cloud Marketplace 的一位 Google 工程師聯絡了我，他是我的老朋友。 他想弄清楚為什麼 CXNUMXD 不起作用，我們最終發現這是因為我幾年前就構建了網絡，而 CXNUMXD 無法在舊網絡上運行，因為它們的模板中缺少子網參數。 我認為潛在的 GCP 用戶最好確保他們認識足夠的 Google 工程師...
來源： www.habr.com