親愛なるGoogleCloud、後方互換性はあなたを殺している

くそーグーグル、私は再びブログを書きたくなかった。やることがたくさんあります。ブログには、本、音楽、ゲームなど、私が便利に使用できる時間、エネルギー、創造性が必要です。しかし、あなたはそれを書き留めるのに十分私を怒らせました。



それでは、これを乗り越えましょう。



私が最初にGoogleで働き始めたときから、小さいながらも有益な話から始めます。最近Googleについて多くの悪いことを言ったことは知っていますが、私の母会社が定期的に無能なビジネス上の決定を下すと、私は動揺します。とはいえ、私たちは敬意を表する必要があります。Googleの内部インフラストラクチャは本当に並外れており、今日、これ以上良いものはないと言っても過言ではありません。 Googleの創設者は、私がこれまでにないほど優れたエンジニアでした。この話は、この事実を裏付けるだけです。



まず、少し背景があります。GoogleにはBigtableと呼ばれるストレージテクノロジーがあります。これは驚くべき技術的成果であり、最初の（最初ではないにしても）「無限にスケーラブルな」キー値ストア（K / V）の1つであり、本質的にNoSQLの始まりでした。 Bigtableは、最近はかなり混雑したK / Vストレージスペースでも快適ですが、当時（2005年）は驚くほどクールでした。



Bigtableの面白い点の1つは、タブレットサーバーと呼ばれる内部コントロールプレーンオブジェクト（実装の一部として）があり、インデックスが大きく、ある時点でシステムをスケーリングするときにボトルネックになったということです。 Bigtableのエンジニアは、スケーラビリティを実装する方法について頭を悩ませていましたが、突然、タブレットサーバーを他のBigtableストレージに置き換えることができることに気付きました。したがって、BigtableはBigtable実装の一部です。これらの保管施設はすべてのレベルにあります。



もう1つの興味深い詳細は、しばらくの間、BigtableがGoogle内で人気を博し、ユビキタスになり、各チームが独自のリポジトリを持っていたことです。それで、金曜日の会議の1つで、ラリー・ページはさりげなく尋ねました。「なぜ私たちは複数のビッグテーブルを持っているのですか？なぜ1つだけではないのですか？理論的には、1つのストレージでGoogleのすべてのストレージニーズに対応できるはずです。もちろん、実際の開発上の理由（潜在的な失敗の結果など）のために1つだけにジャンプすることはありませんでしたが、理論は興味深いものでした。宇宙全体の1つのリポジトリ（ちなみに、AmazonがSableでこれを行ったかどうかは誰か知っていますか？）



とにかく、これが私の話です。



当時、私はGoogleで2年強働いていましたが、ある日、Bigtableエンジニアリングチームから次のようなメールを受け取りました。

親愛なるスティーブ、



Bigtableチームからのご挨拶。[データセンター名]データセンターで非常に古いBigtableバイナリを使用していることをお知らせします。このバージョンはサポートされなくなりました。最新バージョンへのアップグレードをお手伝いします。



この問題について協力する時間をスケジュールできるかどうか教えてください。



最高の

Bigtableチーム

Googleにはたくさんのメールが届くので、一見すると次のようになります。

,



- . , ----. -----, -- .



, , --.



,

-

すぐに削除するところだったのですが、Bigtableを使わなかったので受信者を間違えたのは明らかですが、意識の端で正式な手紙とは思えないほどの痛い思いをしました。 しかし、それは奇妙でした。 その日の残りの時間、私は仕事とマイクロキッチンでどのようなサメの肉を試すかを交互に考えました。そのうちの少なくとも3つは、狙いを定めたスポンジケーキで私の場所から十分に近かったのですが、書くことの考えは私に成長感を残しませんでした。わずかな不安。 彼らははっきりと私の名前を呼んだ。そして、メールは他の誰かのメールアドレスではなく、私のメールアドレスに送信されます。cc：やbcc：ではありません。トーンは非常に個人的で明確です。多分これはある種の間違いですか？















最後に、好奇心が高まり、彼らが言及したデータセンターのBorgコンソールを見に行きました。



そしてもちろん、BigTableストレージを自分で管理していました。申し訳ありません、もう一度おっしゃっていただけますか？その内容を見て、-すごい！それは、2005年6月にGoogleで最初の週に座ったCodelabインキュベーターからのものでした。 Codelabは、Bigtableを起動して、そこにいくつかの値を書き込むように強制しました。その後、リポジトリを閉じたことはおそらくありません。 2年以上が経過しましたが、それでも機能しました。



この話にはいくつかの注目すべき側面があります。まず、Bigtableの作業はGoogleの規模ではそれほど重要ではなかったため、わずか2年後に誰かが追加のストレージに気づきました。それでも、バイナリのバージョンが古くなったためです。比較のために、私はかつて使用を検討しました私のオンラインゲームのためのGoogleCloudのBigtable。当時、このサービスの費用は、 GCP上の空のBigtableで年間約16,000ドルでした。彼らがあなたをだましていると言っているのではありませんが、私の個人的な意見では、これは空のクソデータベースにとっては多額のお金です。



もう1つの注目すべき点は、ストレージが2年後も機能していたことです。..。 WTF？データセンターは行き来します。彼らは中断を経験し、定期的なメンテナンスを受け、常に変化します。ハードウェアが更新され、スイッチが交換され、すべてが絶えず改善されています。これらすべての変更を加えて、どうやって彼らは私のプログラムを2年間実行し続けることができたのでしょうか？これは2020年にはささやかな成果のように思えるかもしれませんが、2005年から2007年には非常に印象的でした。



そして、最も素晴らしい側面は、他の州の外部エンジニアリングチームが、過去2年間トラフィックがゼロであったBigtableの小さな、ほとんど空のインスタンスの所有者である私に連絡し、それを更新するための支援を提供することです。 ..。



私は彼らに感謝し、金庫室を撤去しました、そして人生はいつものように続きました。しかし、13年後、私はまだこの手紙について考えています。GoogleCloudからこのようなメールを受け取ることがあるからです。彼らはこのように見えます：

Google Cloudユーザーの皆様、



2020年8月からサービス[使用する重要なサービス]を終了することをお知らせします。それ以降は、インスタンスを更新できなくなります。ベータテスト中の最新バージョンにアップグレードすることをお勧めします。このバージョンには、ドキュメントや移行パスがなく、事前に親切なサポートを受けて古くなっています。



この変更がGoogleCloudプラットフォームのすべてのユーザーに与える影響を最小限に抑えることをお約束します。



永遠の親友、

Googleクラウドプラットフォーム

しかし、実際には次のように言っているので、私はそのような手紙をほとんど読みません。

親愛なる受信者、



あなたをファック。あなたをファック、あなたをファック、あなたをファック。それは問題ではないので、あなたがすることはすべて捨ててください。重要なのは私たちの時間です。私たちは自分のたわごとをサポートするために時間とお金を費やし、それにうんざりしているので、もうサポートしません。だからあなたのクソ計画を捨てて、フォーラムでスクラップを懇願して、私たちのくだらないドキュメントを掘り下げ始めてください、そしてところで、私たちはこのデザインをかなりひどく台無しにしたので、私たちの新しいたわごとは古いたわごととは完全に異なります私たちの。



1年以内にすべてのデザインが使用できなくなるように引き続き努力しています。



いや、

Google CloudPlatformに行ってください

そして、実は私は月に一度くらいそのような手紙を受け取ります。これは非常に頻繁かつ絶え間なく発生するため、必然的にGCPから反対側のクラウドキャンプに押しやられました。 「時代遅れの」製品を閉鎖するというGoogleの方針に遅れずについていくよりも、開発者が裸の仮想マシン上でオープンソースシステムを維持する方が実際に簡単であるため、私はもはや独自の開発に依存することに同意しません。



私も近くにいるのでGoogleCloudに戻る前にそれらを批判し終えていないので、他のいくつかの分野での会社の業績を見てみましょう。 Googleのエンジニアは、ソフトウェアエンジニアリングの分野に誇りを持っており、これが実際に問題を引き起こしています。プライドは不注意の罠であり、多くのGoogle従業員は、自分たちの決定は常に正しいと考え、正しいこと（漠然とした曖昧な定義による）はカスタマーケアよりも重要であると考えています。



これは、Google以外の他の大規模なプロジェクトからの任意の例ですが、このパターンがどこにでも見られることを願っています。それはこれです：後方互換性はシステムを何十年もの間生きていて最新の状態に保ちます。



後方互換性は、以下のように設計されたすべての成功したシステムの設計目標です。オープンユース、つまり、オープンソースおよび/またはオープンスタンダードで実装されます。誰もが不快にさえ感じるほど明白なことを言っているような気がしますが、そうではありません。これは政治的な問題なので、例が必要です。



私が最初に選択するシステムは最も古いものです。GNUEmacsは、Windows Notepad、OSカーネル、およびInternational SpaceStationのハイブリッドのようなものです。説明するのは少し難しいですが、一言で言えば、Emacsは生産性を高めるためのプログラミングのために1976年（はい、ほぼ半世紀前）に作成されたプラットフォームですが、テキストエディタに変装しています。



私は毎日Emacsを使用しています。はい、私も毎日IntelliJを使用しています。これは、それ自体が強力なツールプラットフォームになっています。しかし、IntelliJの拡張機能を作成することは、Emacsの拡張機能を作成するよりもはるかに野心的で困難です。そしてもっと重要なことに、Emacsのために書かれたものはすべて永遠に続くでしょう。



私は1995年にEmacs用に書いたソフトウェアを今でも使用しています。そして、誰かが80年代半ばにEmacs用に書かれたモジュールを使用していると確信しています。時々微調整が必​​要になる場合がありますが、これは非常にまれです。アーキテクチャを再構築する必要があるEmacs用にこれまでに書いたもの（そしてたくさん書いたもの）は何も知りません。



Emacsには、レガシーエンティティのmake-obsoleteと呼ばれる機能があります。基本的なコンピューターの概念（「ウィンドウ」とは何かなど）のEmacsの用語は、Emacsがずっと前に導入したため、業界の慣習とは異なることがよくあります。これは、時代を先取りする人々にとって典型的な危険です。すべての用語が正しくありません。しかし、Emacsには廃止の概念があり、その専門用語では廃止と呼ばれています。



しかし、Emacsの世界では、異なる実用的な定義があるようです。あなたがそうするならば、もう一つの根底にある哲学。



Emacsの世界（および以下で説明する他の多くの領域）では、レガシーAPIステータスは基本的に、「このアプローチは機能しますが、ここにリストするさまざまな欠点があるため、実際には使用しないでください。しかし、結局のところ、それはあなたの選択です。」



Googleの世界では、廃止された製品ステータスは「私たちはあなたに対する義務に違反している」ことを意味します。本当にそうです。これが本質的な意味です。これは、彼らのカラフルな広告を信じることに対する罰として、彼らがあなたに定期的にいくつかの仕事、おそらく多くの仕事をすることを強制することを意味します：私たちは最高のソフトウェアを持っています。最速！あなたは指示に従ってすべてを行い、アプリケーションまたはサービスを起動し、1、2年後にそれが壊れます。



それは1500キロ後に間違いなく故障する中古車を売るようなものです。



これらは、「陳腐化」の2つの完全に異なる哲学的定義です。 Googleの定義は、計画された廃止のようなにおいがします。本当にそうだとは思いませんAppleと同じ意味で計画された廃止。しかし、Googleは間違いなくあなたのプログラムを回りくどい方法で壊すことを計画しています。私はそこで12年以上ソフトウェアエンジニアとして働いていたので、これを知っています。後方互換性の程度についてはあいまいな内部ガイドラインがありますが、最終的には個々のチームまたはサービスによって異なります。企業またはエンジニアリンググレードの推奨事項はありません。廃止サイクルに関する最も大胆な推奨事項は、「システム全体を壊す前に、顧客に6〜12か月のアップグレードを提供するようにしてください」です。



この問題は彼らが思っているよりもはるかに深刻であり、カスタマーケアは彼らのDNAの一部ではないため、今後数年間続くでしょう。これについては、以下で詳しく説明します。



今のところ、Emacsは大部分、そしてほとんどの場合、後方互換性を非常に真剣に受け止めているため、成功しているという大胆な発言をします。実際、これは私たちの記事の論文です。成功した長寿命のオープンソースシステムは、何十年にもわたって拡張機能/プラグインの周りに住んできたマイクロコミュニティのおかげです。これがエコシステムです。プラットフォームの本質とその重要性についてはすでに説明しました。また、Googleは、企業の歴史全体において、AndroidやChromeを除いて、オープンプラットフォームを成功させるために何が必要かを理解したことがありませんでした。



実際、あなたがおそらくそれについて考えたので、私はAndroidについて簡単に言及しなければなりません。



まず、AndroidはGoogleではありません..。彼らはお互いにほとんど何の関係もありません。 Androidは2005年7月にGoogleに買収された会社であり、この会社は多かれ少なかれ自律的に運営することを許可されており、実際、長年にわたってほとんど無傷のままです。 Androidは、悪名高い技術スタックであり、同様に悪名高い厄介な組織です。あるグーグルが言ったように、「あなたはただAndroidに入ることができない」。



私の過去の記事の1つで、初期のAndroid設計の決定のいくつかがどれほど悪かったかについて説明しました。ヘック、私がその記事を書いたとき、彼らは「インスタントアプリ」と呼ばれるたわごとを展開していましたが、現在は（驚きです！）廃止されていますそして、あなたがGoogleを聞いて、あなたのコンテンツをこれらのインスタントアプリに持ち込むのに十分愚かだったなら、同情してください。



しかし、違いがあります。大きな違いは、Androidの人々はプラットフォームの重要性を本当に理解しており、古いAndroidアプリが機能し続けるように最善を尽くしていることです。実際、後方互換性を維持するための彼らの努力は非常に極端であるため、数年前のAndroid部門での短い任務中に、最も古いデバイスとAPIのサポートをやめるように説得しようとしていることに気づきました（私は間違っていました過去と現在の他の多くのもの。申し訳ありませんがAndroidの人たち！私はインドネシアに行ったので、なぜそれらが必要なのか理解しています）。



Androidの人々は、ほとんど想像を絶する極端な状況への後方互換性を維持しており、システムとツールチェーンに膨大な量の廃止された技術的負債を積み上げています。なんてこった、あなたは彼らが彼らのビルドシステムでしなければならないいくつかのクレイジーなことを見るべきだった、すべて互換性の名の下に。



このために、私はAndroidに切望されているYou Are NotGoogle賞を授与します。彼らは本当にGoogleになりたくありません。Googleは耐久性のあるプラットフォームを構築する方法を知りませんが、Androidはそれを行う方法を知っています。したがって、Googleは1つの点で非常に賢明です。それは、Android上の人々が独自の方法で物事を行うことを可能にするということです。



ただし、インスタントAndroidアプリはかなり馬鹿げたアイデアでした。なぜなのかご存知ですか？彼らが要求したのでアプリケーションを書き直して再設計してください！まるで人々が200万のアプリを取り、書き直すかのように。インスタントアプリはグーグルのアイデアだったと思います。



しかし、ここには違いがあります。後方互換性は高価です。これらの費用はAndroid自体が負担しますが、Googleは、有料の顧客であるあなたが負担することを主張しています。



APIの後方互換性に対するAndroidの取り組みを見ることができます。文字通り同じことを行う4つまたは5つの異なるサブシステムがある場合、下位互換性への取り組みが核心にあることは確かな兆候です。プラットフォームの世界では、顧客と市場への取り組みと同義です。



ここでのGoogleの主な問題は、エンジニアリングの衛生状態に対する彼らの誇りです。同じことをするための多くの異なる方法があり、古い、あまり望ましくない方法が新しい、より奇妙な方法の隣にあるとき、彼らはそれを好きではありません。これは、システムの初心者の学習曲線を増やし、レガシーAPIを維持する負担を増やし、新機能の速度を遅くし、主な罪は醜いです。グーグル-ティムバートンによる「不思議の国のアリス」のレディアスコットのように：



レディアスコット：

-アリス、あなたは私が最も恐れていることを知っていますか？

-貴族の衰退？

-醜い孫がいるのではないかと心配でした。



美しいものと実用的なものの間のトレードオフを理解するために、3番目に成功したプラットフォーム（EmacsとAndroidに続く）を見て、それがどのように機能するかを見てみましょう：Java自体。



Javaには大量のレガシーAPIがあります。非推奨はJavaプログラマーに非常に人気があり、ほとんどのプログラミング言語よりもさらに人気があります。主な言語とライブラリであるJava自体では、APIの非推奨が絶えず発生しています。



数千の例のうちの1つだけを取り上げる場合、ストリームを閉じることは非推奨です。 1998年12月のJava1.2のリリース以降、非推奨になっています。これが廃止されてから22年になります。



しかし、私の実際の製品コードはまだ毎日スレッドを殺します..。いいですか？絶対に！もちろん、今日コードを書き直すとしたら、別の方法で実装します。しかし、過去20年間で数十万人の人々を幸せにしてきた私のゲームのコードは、長時間ハングするスレッドを閉じる機能を使用して記述されており、変更する必要はありませんでした。私は自分のシステムを最もよく知っており、本番環境で文字通り25年の経験があります。確かに言うことができます。私の場合、これらの特定の作業ストリームを閉じることは完全に無害です。このコードを書き直すのに時間と労力を無駄にしないでください。また、Oracleが私にコードの書き直しを強制しなかったことをLarry Ellison（おそらく）に賞賛してください。



おそらく、Oracleはプラットフォームにも精通しています。知るか。



峡谷の氷河線のように、時代遅れの波に満ちているすべてのコアJavaAPIの証拠を見つけることができます。 Java Swingライブラリには、5つまたは6つの異なるキーボードナビゲーションマネージャ（KeyboardFocusManager）が簡単に見つかります。非推奨になっていないJavaAPIを見つけるのは実際には困難です。しかし、それらはまだ機能します！ Javaチームは、インターフェースがひどいセキュリティ問題を引き起こした場合にのみ、APIを実際に削除すると思います。



私たちソフトウェア開発者は皆非常に忙しく、ソフトウェアのあらゆる分野で競合する選択肢に直面しています。いつでも、XプログラマーはYを可能な代替品と見なします。ああ、あなたは私を信じませんか？あなたはスウィフトと呼ばれたいですか？同様に、誰もがSwiftに移行し、誰もそれをあきらめませんよね？うわー、あなたがどれだけ知っているか。企業は、デュアルモバイル開発チーム（iOSとAndroid）のコストを数えています。そして、FlutterやReact Nativeのようなこれらの面白い名前のクロスプラットフォーム開発システムが機能し、モバイルチームのサイズを縮小できることに気づき始めています。 2倍、または逆に、2倍の生産性を実現します。リアルマネーが危機に瀕しています。はい、妥協点はありますが、その一方で、de-e-moneyです。



仮に、AppleがGuido van Rossumの例を愚かに取り上げ、Python3がPython2と互換性がないのと同じように、Swift6.0がSwift5.0と後方互換性がないと発表したとします。



おそらく10年前にこの話をしましたが、15年前に私はGuidoと一緒にO'Reilly'sFoo Campに行き、PaulGrahamとたくさんの大きなバンプと一緒にテントに座った。私たちは猛暑の中に座って、ラリー・ページが彼の個人的なヘリコプターで離陸するのを待ちました。一方、グイドは、誰もがそこに移動するのに何年もかかることにちなんで名付けたPython3000について単調につぶやきました。なぜ互換性が失われるのかといつも彼に尋ねたところ、彼は「ユニコード」と答えました。そして、コードを書き直す必要がある場合、他にどのようなメリットがありますか？そして彼は「Yoooooooooooooouuuuuuuniiiiiiicoooooooode」と答えました。



Google Cloud Platform SDK（「gcloud」）をインストールすると、次の通知が届きます。

受信者の



皆様、Python 2のサポートは廃止されましたので、お知らせします。

…など生命の輪。



しかし重要なのは、すべての開発者には選択肢があるということです。そして、あなたが彼らにコードを何度も書き直してもらうなら、彼らは他のオプションについて考えるかもしれません。彼らはあなたがどれだけ彼らになりたいとしても、あなたの人質ではありません。彼らはあなたのゲストです。 Pythonは今でも非常に人気のあるプログラミング言語ですが、Python 3（000）は、それ自体、コミュニティ、およびコミュニティのユーザーの間で、その結果が15年間解決されていないような混乱を引き起こしました。



この後方互換性のために、Go（またはRuby、またはその他の代替手段）で書き直されたPythonプログラムはいくつありますか？どのくらいの新しいソフトウェアは、それがあっても、Pythonの以外の何かに書かれていたかもしれませんGuidoが村全体を焼き払っていなかったら、Pythonで書かれていますか？わかりにくいですが、Pythonは明らかに苦しんでいます。これは大きな混乱であり、誰もが負けます。



それで、AppleがGuidoの例に従い、互換性を破ったとしましょう。次に何が起こると思いますか？そうですね、開発者の80〜90％は、可能であればソフトウェアを書き直します。つまり、ユーザーベースの10〜20％が、Flutterなどの競合する言語に自動的にアクセスします。



これを数回行うと、ユーザーベースの半分が失われます。スポーツのように、プログラミングの世界では、現在の形もすべてを意味します。..。 5年間でユーザーの半分を失った人は誰でも大きな脂肪の敗者と見なされます。プラットフォームの世界でトレンドになっているはずです。しかし、これは古いバージョンのサポートを放棄することは時間の経過とともにあなたを殺す場所です。開発者の一部を取り除くたびに、（a）契約を破ったことに腹を立てているため、開発者を永久に失い、（b）競合他社に渡します。



皮肉なことに、私も、コードベースの自動化とツールを容易にするソースコード分析および理解システムであるGrokを作成したときに、Googleを一種の下位互換性のあるプリマドンナに変えるのを手伝いました-IDEに似ていますが、ここではクラウドサービスストアが具体化されています大規模なデータウェアハウス内の数十億行すべてのGoogleソースコードの表現。



Grokは、コードベース全体（文字通りGoogle全体）で自動リファクタリングを行うための強力なフレームワークをGoogle社員に提供しました。システムは、アップストリームの依存関係（依存している）だけでなく、ダウンストリームの依存関係（依存している）も計算するため、APIを変更すると、誰もが壊れていることがわかります。このように、変更を加えるときに、APIのすべてのコンシューマーが新しいバージョンに更新されていることを確認できます。実際には、多くの場合、彼らが作成したRosieツールを使用して、プロセスを完全に自動化できます。



これにより、Googleのコードベースは内部的にほぼ超自然的に「クリーン」になります。これは、ロボットの使用人が家の中を駆け巡り、SomeDespicablyLongFunctionNameの名前をSomeDespicablyLongMethodNameに変更した場合、誰かが醜い孫だと思ったために、すべてを自動的にクリーンアップするためです。眠らせる必要があります。



そして正直なところ、それはグーグルにとってかなりうまく機能します...内部的に。つまり、はい、GoogleのGoコミュニティは、継続的なリファクタリングの習慣があるため、GoogleのJavaコミュニティを非常に笑っています。何かをN回再起動すると、それはN-1回台無しにされただけでなく、しばらくすると、おそらくN回目の試行で台無しにされたことが明らかになります。しかし、概して、彼らは大騒ぎの上にとどまり、コードを「クリーン」に保ちます。



問題は、クラウドクライアントや他のAPIのユーザーにこの態度を押し付けようとしたときに始まります。



Emacs、Android、Javaを少し紹介しました。最新の成功した長寿命のプラットフォームであるWeb自体を見てみましょう。点滅する<blink>タグとWebページの作成中のアイコンを使用した1995年以降、HTTPが何回繰り返されたかを想像できます。



しかし、それでも機能します！そして、これらのページはまだ機能しています！はい、皆さん、ブラウザは世界の後方互換性のチャンピオンです。 Chromeは、頭が正しくねじ込まれている珍しいGoogleプラットフォームのもう1つの例です。ご想像のとおり、Chromeは他のGoogleとは別の独立した会社として効果的に機能します。



また、オペレーティングシステム開発者の友人にも感謝したいと思います。Windows、Linux、NOT APPLE FOLLOW YOU APPLE、FreeBSDなど、成功したプラットフォームで多くの後方互換性作業を行ってくれました（Appleはせいぜい3倍になります）マイナス、理由もなく常にすべてを壊しているのですが、どういうわけかコミュニティはすべてのリリースでこれを処理し、これまでのところOS Xコンテナは完全に古くなっていません...まだ）。



しかし、待ってください、あなたは言います。リンゴとオレンジを比較していませんか？Emacs / JDK / Android / Chromeのような単一のマシン上のスタンドアロンソフトウェアシステムと、クラウドサービスのようなマルチサーバーシステムとAPIを備えていますか？



さて、昨日ツイートしましたが、ラリーウォールスタイルのサック/ルールで、GoogleとAmazonの開発者サイトで廃止された単語を調べました。 AWSにはGCPの数百倍のサービスがありますが、Googleの開発者向けドキュメントには、約7倍の頻度で非推奨が記載されています。



Googleの誰かがこれを読んだら、おそらくドナルドトランプのスタイルを示す図を引き出す準備ができているでしょう。彼らは実際にすべてを正しく行っているので、「サービスの数に応じて廃止された単語の言及の数」などの不当な比較を行うべきではありません。 "。



しかし、非常に多くの年後、Googleクラウドはまだ＃3（私は＃2になるに失敗した記事を書いたことはありません）が、あなたがインサイダーを信じるならば、彼らはすぐに＃4に落とすことが、いくつかの懸念があるである



私は良いを持っていませんあなたの論文を「証明する」ための議論。私が持っているのは、開発者として30年以上にわたって蓄積したカラフルな例だけです。この問題の哲学的な性質についてはすでに述べました。ある意味で、それは開発者コミュニティで政治化されています。プラットフォームの作成者は互換性を気にする必要があると考える人もいれば、これがユーザーの関心事であると考える人もいます。（開発者自身）。 2人に1人。確かに、一般的な問題の費用を誰が負担すべきかを決定するとき、それは政治的な問題ではありませんか？



だからこれは政治です。そして、私のスピーチには確かに怒った反応があるでしょう。



などのユーザーGoogleのクラウドプラットフォーム、および（グラブで）2年間のAWSユーザーとして、私はそれが優先事項になるとアマゾンやGoogleの哲学の間に大きな差があると言うことができます。私はAWSで積極的に開発していないので、AWSが古いAPIを削除する頻度はよくわかりません。しかし、これはGoogleほど頻繁には起こらないという疑いがあります。そして私は、GCPにおける絶え間ない論争とフラストレーションのこの原因が、プラットフォームの開発における最大の制約の1つであると心から信じています。



サポートされなくなったGCPシステムの具体例を挙げていないことは知っています。ネットワーク（最も古いものからVPCまで）からストレージ（Cloud SQL v1-v2）、Firebase（現在は完全に異なるAPIを備えたFirestore）、App Engine（起動すらしない）まで、私が使用した事実上すべてのものと言えます。クラウドエンドポイント以前...わかりません-このコードの強制的な書き直しは最大2〜3年で絶対にすべてであり、移行が自動化されることはなく、文書化された移行パスがまったくないことがよくありました。あるべきかのように。



そして、AWSを見るたびに、なぜ私はまだGCPに座っているのかを自問します。彼らは明らかにクライアントを必要としません。彼らはバイヤーを望んでいます。違いがわかりますか？説明させてください。



Google Cloudには、ソフトウェアソリューションを提供するマーケットプレイスがあり、空のレストランの影響を避けるために、いくつかの提案を入力する必要があったため、Bitnamiと契約して、「ワンクリック」で展開される一連のソリューションを作成しました。私は自分で「解決策」を書かなければなりません。なぜなら、これらはひどいことを解決しないからです。それらは単なるフラグとして、マーケティングフィラーとして存在し、Googleはツールのいずれかが実際に機能したかどうかを気にしませんでした。私は運転した製品マネージャーを知っています、そして私はこれらの人々が気にしないことをあなたに保証することができます。



たとえば、「ワンクリック」展開ソリューションPerconaを取り上げます。..。私はGoogleCloud SQLのアンティックに飽き飽きしていたので、代わりに独自のPerconaクラスターを作成することを検討し始めました。そして今回、Googleは良い仕事をしているようでした。ボタンをクリックするだけで、時間と労力を節約できました。



さて、素晴らしい、行きましょう。リンクをたどってこのボタンを押しましょう。 「はい」を選択してすべてのデフォルトに同意し、クラスターをGoogleクラウドプロジェクトにデプロイします。ハハ、それは動作しません。このたわごとのどれも動作しません。ツールはテストされたことがなく、最初の1分から腐り始めました。ワンクリック展開の「ソリューション」の半分以上（引用符の理由がわかりました）がまったく機能しなくても、私は驚かないでしょう。これは絶対に絶望的な暗闇であり、入らない方が良いです。



ただし、Googleでは明示的にそれらを使用することをお勧めします。彼らはあなたにそれらを買って欲しいのです。彼らにとって、それは取引です。彼らは何もサポートしたくありません。それはGoogleのDNAの一部ではありません。はい、Bigtableでの私の話からも明らかなように、エンジニアはお互いをサポートしています。しかし、一般の人々向けの製品やサービスでは、たとえ数百万人のユーザーがいるとしても、収益性の基準を満たしていないサービスをシャットダウンすることに常に冷酷でした。 このDNAはすべてのクラウド製品の背後にあるため、これはGCPにとって真の課題です。彼らは何もサポートしようとはしません。サードパーティのソフトウェアを（マネージドサービスとして）ホストすることを拒否することはよく知られています



AWSが同じことを行わず、成功するビジネスを構築しない限り、そして顧客がまったく同じことを要求する場合。ただし、Googleに何かをサポートさせるにはある程度の努力が必要です。



このサポートの文化の欠如は、「それを壊して美しくする」という原則と相まって、開発者を彼らから遠ざけています。



そして、長寿命のプラットフォームを構築したいのであれば、それは良くありません。



グーグルは目を覚ます、くそー。 2020年です。あなたはまだ負けています。本当にクラウドビジネスにとどまりたいのなら、鏡をよく見て答える時が来ました。



あなたが滞在したいなら、すべてを壊すことをやめなさい..。君たちは金持ちだ。私たち開発者はそうではありません。したがって、互換性の負担を誰が負うかについては、自分で負担する必要があります。私たちのためではありません。



本当に良い雲が少なくとも3つあるからです。彼らは彼らに手招きします。



そして今、私は壊れたシステムをすべて修正し続けます。ええ



次回まで！



この記事のいくつかの議論を読んだ後のPSアップデート（ちなみに議論は素晴らしいです）。 Firebaseは廃止されておらず、私が知っている計画もありません。ただし、厄介なストリーミングエラーが発生し、JavaクライアントがAppEngineで停止します。私がGoogleで働いていたときに、エンジニアの1人がこの問題を解決してくれました。, , , 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 API!



アップデート3、2020年8月31日。クラウドマーケットプレイスのGoogleエンジニアから連絡があり、私の旧友であることが判明しました。彼はC2Dが機能しない理由を知りたがっていましたが、最終的にはわかりました。理由は、数年前にネットワークを作成したためです。テンプレートにサブネットパラメータがないため、C2Dはレガシーネットワークでは機能しません。潜在的なGCPユーザーは、Googleに十分な知識のあるエンジニアがいることを確認したほうがよいと思います...