Google Cloud の皆様、下位互換性がないことは致命的です。

くそGoogle、もうブログを書きたくなかった。 やるべきことがたくさんあります。 ブログには時間、エネルギー、創造性が必要ですが、それを有効に活用できるのは、書籍や書籍です。 музыка、私のゲームなど。 しかし、あなたは私を十分に怒らせたので、これを書かなければなりません。

それでは、これで終わりにしましょう。

私が初めて Google で働き始めたときの、短いですが有益な話をさせてください。 最近 Google について悪口をたくさん言っていることはわかっていますが、自分の会社が定期的に無能なビジネス上の決定を下していると腹が立ちます。 同時に、私たちはそれを正当に評価しなければなりません。Google の社内インフラは本当に並外れたものであり、今日これより優れたものはないと言って間違いありません。 Google の創設者たちは私よりもはるかに優れたエンジニアであり、この話はその事実を裏付けるだけです。

まず、背景を簡単に説明します。Google には、と呼ばれるデータ ストレージ テクノロジーがあります。 ビッグテーブル。 これは注目に値する技術的成果であり、最初の (最初ではないにしても) 「無限にスケーラブルな」キー/値ストア (K/V) の 2005 つであり、本質的に NoSQL の始まりでした。 今では Bigtable はかなり混雑した K/V ストレージ スペースでまだうまく機能していますが、当時 (XNUMX 年) は驚くほどクールでした。

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

もう XNUMX つの興味深い詳細は、しばらくの間 Bigtable が人気を博し、Google 内で広く普及し、各チームが独自のリポジトリを持っていたことです。 そこで、金曜日の会議の XNUMX つで、ラリー ペイジは何気なく次のように尋ねました。 なぜ一つだけではだめなのですか？」 理論的には、XNUMX つのストレージで Google のすべてのストレージ ニーズに対応できるはずです。 もちろん、実際的な開発上の理由 (潜在的な失敗の影響など) で XNUMX つだけを選択することはありませんでしたが、理論は興味深いものでした。 ユニバース全体に XNUMX つのリポジトリ (ところで、Amazon がセーブルでこれを行ったかどうか知っている人はいますか?)

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

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

親愛なるスティーブへ

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

この問題について一緒に取り組む時間を計画していただけるかどうか、お知らせください。

ではごきげんよう、
Bigtable チーム

Google では大量のメールが届くので、一見すると次のような内容が表示されます。

親愛なる受取人様、

どこかのチームからこんにちは。 私たちは、何とか何とかなんとかということを伝えたいのです。 どうにか何とかなんとか何とかなんとか、そしてすぐにどうにか何とかなんとか。

あなたの貴重な時間をなんとか計画していただけるかどうか、お知らせください。

ではごきげんよう、
何らかのコマンド

すぐに削除しそうになったが、意識の片隅で、しつこいような痛みを感じた。 かなりではない 形式的な手紙のように見えますが、 明らかに、Bigtableを使用していないため、受信者が間違っていたとのこと。

しかし、それは奇妙でした。

私はその日の残りの時間を、仕事のことと、マイクロキッチンでどの種類のサメ肉を試食するかを交互に考えて過ごしました。そのうちの少なくとも XNUMX つは、狙いを定めてビスケットを投げれば席から命中するほどの距離にありましたが、書こうと思っても、軽い不安感が募るばかりでした。

彼らははっきりと私の名前を言いました。 そしてメールは他人のメールアドレスではなく私のメールアドレスに送られてきましたし、cc:やbcc:でもありませんでした。 トーンは非常に個人的で明瞭です。 もしかしたらこれは何かの間違いなのでしょうか？

最後に、好奇心に負けて、彼らが言及したデータセンターにある Borg コンソールを見に行きました。

そしてもちろん、BigTable ストレージを管理していました。 申し訳ありません、もう一度おっしゃっていただけますか？ 中身を見てみると、なんと！ それは、2005 年 XNUMX 月に Google に入社して最初の XNUMX 週間に私が座っていた Codelab インキュベーターからのものでした。 Codelab では、そこにいくつかの値を書き込むために Bigtable を実行するよう強制されましたが、その後ストレージを閉じることはなかったそうです。 XNUMX年以上経ちましたが、まだ現役でした。

この物語にはいくつかの注目すべき側面があります。 第一に、Bigtable の成果は Google の規模では非常に取るに足らないものであったため、ストレージの追加に誰も気付かなかったのは XNUMX 年後であり、それはバイナリのバージョンが古かったからでした。 比較のために、私はかつて使用することを検討しました Google Cloud 上の Bigtable 私のオンラインゲーム用に。 当時、このサービスには年間約 16 ドルの費用がかかりました。 空 GCP 上の Bigtable。 彼らが詐欺をしていると言っているわけではありませんが、私の個人的な意見では、空のクソデータベースにそれは多額のお金です。

もう一つの注目すべき点は、ストレージです。 XNUMX年経ってもまだ働いている。 なんと？ データセンターは行き来します。 サービス停止が発生したり、定期的なメンテナンスが行われたり、常に変化します。 ハードウェアが更新され、スイッチが交換され、すべてが常に改善されています。 これほどの変更を加えながら、一体どうやって私のプログラムを 2020 年間も実行し続けることができたのでしょうか? これは 2005 年にはささやかな成果のように思えるかもしれませんが、2007 年から XNUMX 年にかけては非常に印象的なものでした。

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

私は彼らに感謝し、ストレージを削除し、通常通りの生活が続きました。 しかしXNUMX年経った今でも、私はその手紙のことを思い出します。 Google Cloud から似たようなメールが時々届くからです。 それらは次のようになります。

Google Cloud ユーザーの皆様

[お客様が使用している必須サービス] サービスは 2020 年 XNUMX 月をもって廃止されます。その後、インスタンスをアップグレードすることはできなくなります。 最新バージョンにアップグレードすることをお勧めします。このバージョンはベータ テスト中であり、ドキュメントや移行パスがなく、親切なサポートが提供される以前から古いものです。

私たちは、この変更が Google Cloud プラットフォームのすべてのユーザーに与える影響を最小限に抑えるよう努めています。

永遠の親友、
Googleクラウドプラットフォーム

しかし、私はそのような手紙をほとんど読んだことがありません。なぜなら、彼らが実際に言っているのは次のようなものだからです。

親愛なる受取人様、

地獄へ行け。 クソ、クソ、クソ。 それは重要ではないので、あなたがしているすべてを放棄してください。 重要なのは私たちの時間です。 私たちはくだらないものを維持するのに時間とお金を無駄にしており、それにうんざりしているので、もうサポートしません。 だから、クソみたいな計画はやめて、フォーラムでスクラップを求めながら、クソみたいなドキュメントを漁り始めろ。ちなみに、私たちの新しいクソは古いクソとは完全に違う。だって、この設計はかなりひどいことになったからね、へー、でもそれはあなたの問題だからね問題は私たちではありません。

私たちは、お客様のすべての開発が XNUMX 年以内に使用できなくなることを確実にするよう努力を続けます。

やめてください
Googleクラウドプラットフォーム

そして事実、私はそのような手紙を月に一度程度受け取ります。 これは非常に頻繁かつ継続的に起こるため、必然的に 押しのけられた GCP からアンチクラウド キャンプに移りました。 私は彼らの独自開発に依存することにもはや同意しません。実際、DevOps にとっては、「時代遅れの」製品を閉鎖する Google のポリシーに追いつくよりも、裸の仮想マシン上でオープンソース システムを維持する方が簡単だからです。

Google Cloud に戻る前に、 近くでも 批判はまだ終わっていないので、他の分野における同社の業績を見てみましょう。 Google のエンジニアはソフトウェア エンジニアリングの規律に誇りを持っていますが、これが実際に問題を引き起こしているのです。 プライドは不注意な人にとっての罠であり、そのせいで多くの Google 従業員は、自分たちの決定は常に正しく、（漠然としたあいまいな定義によると）正しいことの方が顧客のことを気遣うことよりも重要であると考えるようになりました。

Google 以外の大規模プロジェクトからのランダムな例をいくつか紹介しますが、このパターンがあらゆるところで見られることを願っています。 それは次のとおりです。 下位互換性により、システムは数十年にわたって存続し、最新の状態に保たれます.

下位互換性は、以下の目的で設計された成功したすべてのシステムの設計目標です。 開いた つまり、オープン ソース コードやオープン スタンダードを使用して実装されます。 あまりにも当たり前のことを言っている気がして、むしろみんな不快に思うかもしれませんが、そうではありません。 これは政治的な問題なので、例が必要です。

最初に選択するシステムは最も古いシステムです。GNU Emacs は、Windows メモ帳、OS カーネル、国際宇宙ステーションのハイブリッドのようなものです。 説明するのは少し難しいですが、簡単に言うと、Emacs は 1976 年 (はい、ほぼ半世紀前) に作成され、生産性を高めるためのプログラミングを目的としたプラットフォームですが、テキスト エディターを装っています。

私は毎日 Emacs を使用しています。 はい、私も IntelliJ を毎日使用しています。IntelliJ は、それ自体が強力なツール プラットフォームに成長しました。 しかし、IntelliJ の拡張機能を作成することは、Emacs の拡張機能を作成するよりもはるかに野心的で複雑な作業です。 そしてさらに重要なことに、Emacs 用に書かれたものはすべて保存されます。 永遠に.

私は 1995 年に Emacs 用に作成したソフトウェアを今でも使用しています。 そして、それ以前ではないにしても、80 年代半ばに Emacs 用に書かれたモジュールを使用している人がいるはずです。 時々、少しの調整が必要になる場合がありますが、これは非常にまれです。 私はこれまでに Emacs 用に書いたもので、再アーキテクチャが必要なものを知りません (そしてたくさん書いてきました)。

Emacs には、廃止されたエンティティに対して make-obsolete と呼ばれる機能があります。 Emacs の基本的なコンピュータ概念 (「ウィンドウ」とは何か) に関する Emacs の用語は、Emacs がずっと前に導入したものであるため、業界の慣習とは異なることがよくあります。 これは時代の先を行く人にとって典型的な危険です。あなたの条件はすべて間違っています。 しかし、Emacs には非推奨の概念があり、専門用語ではこう呼ばれます。 陳腐化.

しかし、Emacs の世界では、別の実用的な定義があるようです。 言ってみれば、根底にある哲学が異なります。

Emacs の世界 (および以下で説明する他の多くの領域) では、非推奨の API ステータスは基本的に次のことを意味します。「このアプローチは実際には使用すべきではありません。なぜなら、このアプローチは機能する一方で、さまざまな欠点があるからです。ここにリストします。 しかし、結局のところ、それはあなたの選択です。」

Google の世界では、時代遅れになるということは、「あなたに対する約束に違反している」ということを意味します。 これは本当です。 これが本質的に意味するところです。 これは彼らがあなたに強制することを意味します 定期的に 彼らを信じたことへの罰として、いくつかの仕事、おそらく多くの仕事をする カラフルな広告: 私たちは最高のソフトウェアを持っています。 最速！ 指示に従ってすべてを実行し、アプリケーションやサービスを起動すると、XNUMX ～ XNUMX 年後に壊れてしまいます。

1500kmも走れば必ず故障する中古車を売るようなものです。

これらは、「陳腐化」の XNUMX つのまったく異なる哲学的定義です。 Googleの匂いの定義 計画的陳腐化。 これは信じられない 実は Appleと同じ意味での計画的陳腐化。 しかし、Google は間違いなく、回りくどい方法であなたのプログラムを破壊することを計画しています。 私はそこでソフトウェア エンジニアとして 12 年以上働いていたので、このことを知っています。 下位互換性をどの程度守るべきかについては、あいまいな内部ガイドラインがありますが、最終的には個々のチームまたはサービスに依存します。 エンタープライズレベルまたはエンジニアリングレベルの推奨事項はなく、陳腐化サイクルに関する最も大胆な推奨事項は、「システム全体が壊れる前に、顧客にアップグレードに 6 ～ 12 か月の猶予を与えるようにしてください」です。

この問題は彼らが思っているよりもずっと大きく、顧客ケアが彼らのDNAに組み込まれていないため、この問題は今後何年も続くだろう。 これについては以下で詳しく説明します。

この時点で、私は Emacs がかなりの程度成功しており、さらには 基本的に なぜなら、彼らは下位互換性を非常に重視しているからです。 実際、これが私たちの記事のテーマです。 長く存続するオープン システムの成功は、何十年もの間その周囲に存在してきたマイクロコミュニティのおかげです。 拡張機能/プラグイン。 これが生態系です。 私はすでに、プラットフォームの性質とその重要性、そして Google が Android や Chrome 以外でオープン プラットフォームを成功させるために何が必要なのかをその企業の歴史の中で一度も理解していないことについて話しました。

実際のところ、Android についてはおそらく皆さんも考えていると思いますので、簡単に説明しておきます。

まず、 AndroidはGoogleではありません。 彼らにはほとんど共通点がありません。 Android は 2005 年 XNUMX 月に Google に買収された会社で、同社は多かれ少なかれ自律的に運営することが許可されており、実際、それまでの数年間はほとんど手つかずのままでした。 Android は悪名高い技術スタックであると同時に、厄介な組織としても悪名高いです。 ある Google 社員はこう言いました。「Android にログインするだけではだめです。」

以前の記事で、Android の初期の設計上の決定がどれほど悪かったかについて説明しました。 てか、私がその記事を書いたとき、彼らは「インスタント アプリ」と呼ばれるくだらないアプリを展開していましたが、それは今では (驚きです!) 時代遅れのそして、あなたがGoogleの言うことを聞いてコンテンツをこれらのインスタントアプリに移動するほど愚かだったとしたら、私は同情します。

しかし、ここには違いがあり、大きな違いがあります。それは、Android の人々はプラットフォームがいかに重要であるかを本当に理解しており、古い Android アプリが動作し続けるよう最善を尽くしているということです。 実際、下位互換性を維持するための彼らの努力は非常に極端で、私でさえ、数年前の Android 部門での短期間の勤務中に、いくつかの最も古いデバイスと API のサポートを中止するよう彼らを説得しようとしていたことに気づきました (私は間違っていました) 、過去と現在の他の多くのことと同様に、Android の皆さん、ごめんなさい! インドネシアに行ったので、なぜ Android が必要なのか理解できました)。

Android の人々は下位互換性をほぼ想像を絶する極限まで推し進め、システムやツールチェーンに膨大な量のレガシー技術的負債を積み上げています。 なんと、互換性の名の下に、ビルド システムでやらなければならないクレイジーなことがいくつか見られるはずです。

このため、私は Android に誰もが欲しがる「You're Not Google」賞を授与します。 彼らは耐久性のあるプラットフォームを作成する方法を知らない Google にはなりたくないのですが、Android は 知っている、 どうやってするの。 したがって、Google はある点で非常に賢明です。つまり、人々が Android 上で自分のやり方で物事を行えるようにしているのです。

しかし、Android 用のインスタント アプリはかなり愚かなアイデアでした。 そして、その理由を知っていますか？ 彼らが要求したから アプリケーションを書き直して再設計する！ あたかも人々が XNUMX 万件のアプリケーションを単純に書き換えるかのようです。 Instant Apps は Google 社員のアイデアだったのではないかと思います。

しかし、違いがあります。 下位互換性には高いコストがかかります。 これらのコストは Android 自体が負担するが、Google は負担を主張する あなた、支払いを行っているクライアント。

API の下位互換性に対する Android の取り組みがわかります。 XNUMX つまたは XNUMX つの異なるサブシステムが文字通り同じことを実行している場合、それは中核部分で下位互換性への取り組みが行われていることを示す確実な兆候です。 プラットフォームの世界では、これは顧客と市場へのコミットメントと同義です。

ここでの Google の主な問題は、自社のエンジニアリング衛生に対するプライドです。 彼らは、同じことを行うのにさまざまな方法があり、古くてあまり望ましくない方法が新しくて派手な方法の隣にあることを好みません。 これにより、システムを初めて使用するユーザーの学習曲線が長くなり、レガシー API を維持する負担が増大し、新機能の速度が低下します。そして大罪は、それが美しくないことです。 Google - ティム・バートンの『不思議の国のアリス』のアスコット夫人のように:

レディ・アスコット:
- アリス、私が一番怖いものは何か知っていますか?
- 貴族社会の衰退？
- そうなるのが怖かった 醜い孫たち.

美しさと実用性の間のトレードオフを理解するために、(Emacs と Android に次ぐ) XNUMX 番目に成功したプラットフォーム、つまり Java 自体がどのように機能するかを見てみましょう。

Java には古い API がたくさんあります。 非推奨は Java プログラマーの間で非常に人気があり、ほとんどのプログラミング言語よりもさらに人気があります。 Java 自体、コア言語、ライブラリは常に API を非推奨にしています。

何千もの例のうちの XNUMX つだけを取り上げると、 スレッドを閉じる 時代遅れとみなされます。 1.2 年 1998 月の Java 22 のリリース以来、非推奨になりました。 この機能が廃止されてから XNUMX 年が経過しました。

しかし、本番環境の実際のコードでは依然としてスレッドが強制終了されています 毎日。 本当にそれが良いと思いますか？ 絶対に！ もちろん、今コードを書き直すとしたら、別の方法で実装するでしょう。 しかし、過去 XNUMX 年間に何十万人もの人々を幸せにしてきた私のゲームのコードには、あまりにも長くハングしているスレッドを閉じる関数が組み込まれています。 それを変更する必要はありませんでした。 私は自分のシステムのことを誰よりもよく知っています。文字通り 25 年間、実稼働環境でシステムを操作した経験があります。そして確実に言えるのは、私の場合、これらの特定のワーカー スレッドを閉じることは完全に問題であるということです。 無害な。 このコードを書き直すのに時間と労力を費やす価値はありません。Oracle が私にコードの書き換えを強制しなかったのは、(おそらく) Larry Ellison に感謝しています。

Oracle もおそらくプラットフォームを理解しているでしょう。 知るか。

その証拠は、峡谷の氷河の線のように、陳腐化の波に満ちているコア Java API のいたるところで見つかります。 Java Swing ライブラリでは、XNUMX つまたは XNUMX つの異なるキーボード ナビゲーション マネージャー (KeyboardFocusManager) を簡単に見つけることができます。 実際、非推奨になっていない Java API を見つけるのは困難です。 しかし、彼らはまだ働いています！ Java チームが実際に API を削除するのは、インターフェースに明らかなセキュリティ上の問題がある場合のみだと思います。

皆さん、これが問題です。私たちソフトウェア開発者は皆非常に忙しく、ソフトウェアのあらゆる分野で競合する代替品に直面しています。 言語 X のプログラマはいつでも、言語 Y を代替候補として検討しています。 ああ、信じられないんですか？ スイフトと呼びますか？ たとえば、誰もが Swift に移行しており、Swift を放棄する人は一人もいません。 うわー、あなたはなんて知っていることが少ないのでしょう。 企業は、XNUMX つのモバイル開発チーム (iOS と Android) のコストを計算しています。そして、Flutter や React Native などの面白い名前のクロスプラットフォーム開発システムが実際に機能し、システムのサイズを削減するために使用できることに気づき始めています。モバイル チームを XNUMX 倍にするか、逆に、チームの生産性を XNUMX 倍にします。 本当のお金がかかっています。 はい、妥協はありますが、一方ではお金です。

仮定として、Apple が愚かにも Guido van Rossum からヒントを得て、Python 6.0 が Python 5.0 と互換性がないのと同じように、Swift 3 は Swift 2 と下位互換性がないと宣言したと仮定してみましょう。

この話をしたのはおそらく3000年ほど前だが、XNUMX年ほど前にはグイドと一緒にオライリーのフー・キャンプに行き、ポール・グラハムや大勢の大物たちとテントに座った。 私たちはうだるような暑さの中で座って、ラリー・ペイジが専用ヘリコプターで飛び立つのを待っていた。一方、グイドは「Python XNUMX」についてドローンで空を飛んでいた。彼はこの名前を、全員がそこに移住するのにかかる年数にちなんで命名した。 私たちは彼になぜ互換性を破るのか尋ね続けましたが、彼は「Unicode」と答えました。 そして、コードを書き直す必要がある場合、他にどのような利点があるのか​​を尋ねました。 すると彼は「よおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお」と答えました。

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

親愛なる受取人様、

Python 2 のサポートは廃止されたことを思い出していただきたいのですが、クソです。

… 等々。 生命の輪。

しかし重要なのは、すべての開発者には選択肢があるということです。 そして、十分な頻度でコードを書き直すよう強制すると、彼らは次のことを考えるかもしれません。 その他 オプション。 あなたがどれほど望んでも、彼らはあなたの人質ではありません。 彼らはあなたのゲストです。 Python は今でも非常に人気のあるプログラミング言語ですが、なんと、Python 3(000) 自体、そのコミュニティ、そしてそのコミュニティのユーザーの間で大混乱を引き起こし、その影響は XNUMX 年間も解決されていませんでした。

この下位互換性がないために、どれだけの Python プログラムが Go (または Ruby、またはその他の代替) で書き直されたでしょうか? Python 以外で書かれた新しいソフトウェアがどれだけあるのか。 になり得る Python で書かれていたら、グイドが村全体を焼き払っていなかったら? 言うのは難しいですが、Python は明らかに苦しんでいます。 それは大混乱で全員が負けます。

そこで、Apple が Guido からヒントを得て、互換性を破壊したとしましょう。 次に何が起こると思いますか？ まあ、おそらく開発者の 80 ～ 90% は、可能であればソフトウェアを書き直すでしょう。 言い換えれば、ユーザーベースの 10 ～ 20% が自動的に Flutter などの競合言語に移行することになります。

これを複数回行うと、ユーザーベースの半分を失うことになります。 スポーツと同じように、プログラミングの世界でも、現在のフォームが重要です。 всё。 XNUMX 年間でユーザーの半分を失った人は、大敗者とみなされます。 プラットフォームの世界では流行に敏感でなければなりません。 しかし、古いバージョンをサポートしないと、時間の経過とともに破滅してしまうのはここです。 なぜなら、開発者を解雇するたびに、(a) 契約を破ったことで怒られるため、開発者を永久に失い、(b) 競合他社に譲渡することになるからです。

皮肉なことに、私は Grok を作成したときに、Google が下位互換性を無視するプリマドンナになるのにも貢献しました。Grok は、コード自体の自動化と計測を容易にするソース コード分析および理解システムです。IDE に似ていますが、ここではクラウド サービスに保存されています。 Google ソース コードの数十億行すべてを大規模なデータ ウェアハウスに具体化して表現します。

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

これにより、Google のコードベースは内部的にほぼ超自然的にクリーンになることができます。なぜなら、誰かが醜い孫だから眠らせる必要があると判断して SomeDespicivelyLongFunctionName を SomeDespicivelyLongMethodName に名前変更すると、これらのロボット使用人が家中を走り回り、すべてを自動的に掃除してくれるからです。

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

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

Emacs、Android、Java について少し紹介しました。 最新の成功した長命プラットフォームである Web 自体を見てみましょう。 1995 年にフラッシュ タグを使用して以来、HTTP がどれだけの反復を経てきたか想像できますか? Web ページ上の「工事中」アイコン。

しかし、それはまだ機能します！ そして、これらのページはまだ機能しています。 そうです、皆さん、ブラウザは下位互換性の世界チャンピオンです。 Chrome は、正しく頭がねじ込まれている稀な Google プラットフォームのもう XNUMX つの例であり、ご想像のとおり、Chrome は他の Google とは独立したサンドボックス企業として事実上運営されています。

また、オペレーティング システム開発者の友人たちにも感謝したいと思います。Windows、Linux、NOT APPLE FUCK YOU APPLE、FreeBSD など、成功したプラットフォームでの下位互換性という素晴らしい仕事をしてくれました (Apple は最高で C を獲得しています)。欠点は、正当な理由もなく常にすべてを壊してしまうことですが、コミュニティはリリースのたびにどういうわけかそれを回避しており、OS X コンテナはまだ完全には廃止されていません...まだ)。

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

さて、昨日これについてツイートしましたが、ラリー・ウォール (プログラミング言語 Perl の作成者 - およそパー) のスタイルで、「sucks/rules」の原則に基づいてこの単語を調べてみました。 非推奨の Google および Amazon の開発者サイトで。 そして、AWS は 数百 Google の開発者向けドキュメントでは、サービスの提供数が GCP の XNUMX 倍であるにもかかわらず、非推奨について言及する頻度が約 XNUMX 倍になっています。

Google の誰かがこれを読んでいるなら、おそらくドナルド・トランプ流のグラフを引っ張り出してきて、実際にすべてが正しく行われていることを示し、「非推奨という単語の言及数と非推奨という単語の言及数のような不公平な比較をすべきではない」と主張するでしょう。サービスの数「」

しかし、何年も経った今でも、Google Cloud は依然として第 3 位のサービスです (私は第 2 位になろうとして失敗したという記事を書いたことはありません)。しかし、内部関係者の話が信じられるのであれば、近いうちに Google Cloud が第 4 位のサービスに落ちるのではないかという懸念があります。 XNUMX番。

私の論文を「証明」するための説得力のある議論はありません。 私が持っているのは、開発者として 30 年間にわたって蓄積してきたカラフルなサンプルだけです。 この問題の非常に哲学的な性質についてはすでに述べました。 ある意味、開発者コミュニティでは政治化されています。 そう信じている人もいます クリエイター 互換性を考慮する必要があるプラットフォームもあれば、これが懸念事項であると考えているプラ​​ットフォームもあります ユーザー (開発者自身)。 XNUMX つのうち XNUMX つ。 確かに、共通の問題のコストを誰が負担するかを決定するとき、それは政治問題ではないでしょうか?

つまり、これは政治なのです。 そして、おそらく私のスピーチに対して怒りの反応があるでしょう。

Как ユーザー Google Cloud Platform、そして XNUMX 年間 (Grab で働いていた間) AWS ユーザーとして、優先順位に関して Amazon と Google の哲学には大きな違いがあると言えます。 私は AWS で積極的に開発を行っていないため、AWS が古い API をどのくらいの頻度で削除するのかよく知りません。 しかし、このようなことは Google ほど頻繁には起こらないのではないかという疑いがある。 そして私は、GCP における絶え間ない論争と不満の原因が、プラットフォームの発展を妨げる最大の要因の XNUMX つであると心から信じています。

サポートが終了した GCP システムの具体例を挙げていないことは承知しています。 ネットワーク（最も古いものから VPC まで）からストレージ（Cloud SQL v1 ～ v2）、Firebase（現在は完全に異なる API を備えた Firestore）、App Engine（始めましょう）に至るまで、私が使用したほぼすべてのものだと言えます。 、クラウド エンドポイント Cloud Endpoint 以降... わかりません - 絶対にこれ全部 最長 2 ～ 3 年後にコードの書き直しを強制され、移行は決して自動化されず、多くの場合、 文書化された移行パスがまったくありませんでした。 まるでそうあるべきかのように。

そして、AWS を見るたびに、なぜ自分はまだ GCP を使用しているのかと自問します。 彼らは明らかに顧客を必要としていません。 彼らが必要とする バイヤー。 違いが分かりますか？ 説明しましょう。

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

たとえば、おそらく「ワンクリック」導入ソリューションを考えてみましょう。 ペルコナ。 私は Google Cloud SQL の悪ふざけにうんざりしていたので、代わりに独自の Percona クラスターを構築することを検討し始めました。 そして今回は Google が良い仕事をしたようで、ボタンをクリックするだけで私の時間と労力を節約してくれることになりました。

よかった、行きましょう。 リンクをたどってこのボタンをクリックしてみましょう。 すべてのデフォルト設定に同意し、Google Cloud プロジェクトにクラスターをデプロイするには、「はい」を選択します。 ハハ、それはうまくいきません。 こんなくだらないことは何も機能しません。 このツールは一度もテストされておらず、最初の瞬間から腐り始めました。「ソリューション」の半分以上がワンクリックで導入できたとしても、私は驚かないでしょう（引用符が付けられている理由が今ではわかりました） 一般的に 動作しません。 ここは絶対に絶望的な暗闇であり、立ち入らない方が良いです。

しかしGoogleは正しい 衝動 あなたがそれらを使用してください。 彼らはあなたにそうしてほしいのです 買った。 彼らにとって、それは取引なのです。 彼らは何も望んでいない サポートする。 それは Google の DNA の一部ではありません。 はい、Bigtable との私の話からもわかるように、エンジニアはお互いをサポートしています。 しかし、一般の人向けの製品やサービスでは、 常に 冷酷だった サービスを終了する、たとえ何百万人ものユーザーがいるとしても、収益性の基準を満たしていません。

これは、すべてのクラウド サービスの背後にある DNA であるため、GCP にとって大きな課題となります。 彼らは何もサポートしようとしていません。 彼らがサードパーティ製ソフトウェアを（マネージドサービスとして）ホストすることを拒否していることはよく知られています。 までAWS が同じことを行い、それを中心に成功するビジネスを構築するまで、そして顧客が文字通り同じことを要求するまで。 ただし、Google に何かをサポートしてもらうには、ある程度の努力が必要です。

このサポート文化の欠如は、「壊してもっと美しくしよう」という考え方と相まって、開発者を遠ざけます。

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

Google、目を覚まして、くそー。 今は2020年です。 あなたはまだ負け続けています。 鏡をしっかり見て、本当にクラウド ビジネスに残りたいかどうかを答えるべき時が来ています。

残りたいならそれで すべてを壊すのはやめてください。 皆さん、あなたたちは金持ちです。 私たち開発者はそうではありません。 したがって、互換性に関する負担を誰が負うのかということになると、あなた自身がそれを引き受ける必要があります。 私たちのためではありません。

本当に優れたクラウドが少なくともあと XNUMX つあるからです。 彼らは手招きしている。

そして今度は、壊れたシステムをすべて修復することにします。 えー。

次回まで！

PS この記事に関するいくつかの議論を読んだ後に更新してください (ところで、議論は素晴らしいです)。 Firebase のサポートはまだ中止されておらず、私が知っている計画はありません。 ただし、Java クライアントが App Engine で停止するという厄介なストリーミング バグがあります。 同社のエンジニアの XNUMX 人がこの問題の解決を手伝ってくれました。 Googleで働いていたとき、しかし実際にはバグは修正されなかったので、GAEアプリを毎日再起動しなければならないというくだらない回避策がありました。 そしてそれがXNUMX年間も続いたのです！ 現在は Firestore が導入されています。 これはまったく異なるシステムであり、Firebase のバグは決して修正されないため、移行するには多くの作業が必要になります。 どのような結論が導き出せるでしょうか? 助けを得ることができます 会社で働いているなら。 GAE で Firebase を使用しているのはおそらく私だけでしょう。100% ネイティブ アプリでログに記録するキーの数は 100 未満で、既知のバグにより数日ごとに機能しなくなるからです。 自己責任で使用する以外に何が言えるでしょうか。 Redis に切り替えます。

また、経験豊富な AWS ユーザーが、AWS は通常、どのサービスのサポートも停止することはなく、SimpleDB がその好例であると言っているのを見たことがあります。 AWS には Google のようなサポート終了の病気が存在しないという私の仮定は正当化されているようです。

さらに、20 日前に Google App Engine チームが重要な Go ライブラリのホスティングを破壊し、コア Go 開発者の XNUMX 人の GAE アプリケーションをシャットダウンしたことにも気づきました。 本当に愚かでした。

最後に、Google 社員がすでにこの問題について議論しており、ほぼ私に同意していると聞きました (皆さん、愛しています!)。 しかし彼らは、Googleの文化には適切なインセンティブ構造がなかったため、この問題は解決不可能だと考えているようだ。 Grab で働いていたときに AWS エンジニアと働いた本当に素晴らしい経験について、少し時間をとって話してみようと思いました。 いつか将来、願っています！

そう、2005年にはビル43の巨大なビュッフェでさまざまな種類のサメ肉が売られていたのですが、私のお気に入りはシュモクザメの肉でした。 しかし、2006 年までに、ラリーとセルゲイは不健康なスナックをすべてやめました。 つまり、2007 年の Bigtable の記事では実際にはサメは存在せず、私はあなたを騙していました。

私が XNUMX 年前にクラウド Bigtable を検討したとき (多少なりとも)、コストがかかったのはここでした。 現在は少し下がったようですが、空のデータ ウェアハウスにとってはまだひどい数字です。特に、私の最初の話では、空の大きなテーブルがその規模ではどれほど重要ではないかが示されています。

Apple コミュニティを気分を害し、Microsoft などについて何も良いことを言っていなかったことをお詫びします。大丈夫です。この記事が生み出したすべての議論に本当に感謝しています。 でも、時には議論を始めるために少し波風を立てる必要があることもありますよね？

読んでくれてありがとう。

更新 2、19.08.2020 年 XNUMX 月 XNUMX 日。 ストライプ APIを正しく更新します!

更新 3、31.08.2020 年 2 月 2 日。 Cloud Marketplace の Google エンジニアから連絡を受けましたが、そのエンジニアは私の古い友人であることが判明しました。 彼は CXNUMXD が機能しない理由を突き止めたいと考えていました。最終的に、それは私が何年も前にネットワークを構築しており、テンプレートにサブネット パラメーターが欠落しているためにレガシー ネットワークで CXNUMXD が機能しなかったためであることがわかりました。 潜在的な GCP ユーザーにとって、Google のエンジニアを十分に知っているかどうかを確認するのが最善だと思います...

出所： habr.com