Serverless と Rust はどちらも古いテクノロジーの 2 回目のスタートアップです。

翻訳者 |蔡珠良

メインフレームを覚えていますか?サーバーレスとは、私たちがこのマシンを所有し、あなたが私にそれを借りに来るようなものです。イノベーションは往々にして巨人の肩の上で生まれます。

タイムシェアはヨーロッパ発祥の休暇モデルです。ホテルやリゾートの客室、観光用アパートなどの利用権を数週間に分割し、10年から40年、あるいはそれ以上の期間、一回限りの会員制で顧客に販売するレジャー休暇の形態です。会員は毎年ホテルまたはリゾートに 7 日間滞在する権利があります。また、交換サービスシステムを通じて、会員は自分の客室使用権を他の会員の他の場所の客室使用権と交換することができ、さまざまな場所で低コストの旅行や休暇の目的を達成することができます。

振り返ってみると、サーバーレスは新しいタイムシェアです。

私たちは皆、記憶喪失です。若い開発者に過去の技術について話すと、たいていは茫然とした表情をされます。公平に言えば、その理由の一部は私が少し「緊張していた」か「変だった」からだが、一部は若い技術者たちが過去の技術を理解していなかったからでもある。

たとえば、若い技術者の中には、2 フェーズコミットが何であるかを知らない人もいます。トランザクション管理は不要になったということでしょうか?

銀行はもはや一貫性を必要としないのでしょうか?この手法は、「同じページ」にいない場合に、異なるサーバー間でトランザクションコンテキストを転送することによって機能します。したがって、1 つのサーバーでのコミットは、すべてのサーバーで成功するか、1 つとしてロールバックされることがほぼ保証される、複数段階のプロセスです。これはかなり驚くべきことで、実際にかなりうまく機能します (もちろんいくつかの注意点はありますが)。驚くべきことに、これはメソッド呼び出しによって実現されます。何もする必要はありません。まったく別のサーバーでリモートメソッドを呼び出しても機能します。

数年前、私は銀行業界の Node ベースのスタートアップ企業と話をしていました。同銀行はNodeとの協力に非常に前向きだと彼らは語った。彼らが作品をより「成熟した」設定で書き直していることは知っています。 Node のような「新しい」ツールを使用するとき、基本的な機能がどれほど欠けているかにいつも驚かされます。もちろん、必要なものをすべて収めなければ、はるかにシンプルで小さくなります。コア機能を放棄すると、シンプルなものを構築するのは簡単です。

2010 年代の NoSQL ドラマ

1999年当時、私は自分のコンサルティング会社を設立する過程にあり、友人が上司に会うように誘ってきました。私はこのオフィスに行きましたが、「ボス」は誰も思いつかなかった素晴らしいアイデアを持っていると言いました。彼らは資金を調達し、6 か月以内に製品をリリースし、初日に 100 万人のユーザーを獲得する予定です。

私：わかりました。何かアイデアはありますか?

彼: 入社が決まったら教えますよ。

私: NDA（秘密保持契約）に署名します。

彼: いいえ。それは素晴らしいアイデアです。それらのNDAは無価値です。サインアップしたら...

なぜこの会社で働きたいという誘惑に抵抗できたのか分かりません。約 1 年後、もちろんまだ会社は立ち上がっていませんでしたが、私のコンサルティング会社は順調に業績を伸ばしていました。友人がまた私に電話をしてきた。今回は製品に関するサポートが必要だったので、コンサルティングの立場でサポートするためにそこへ行きました。

アイデアは、ウェブサイトにチャットアプリケーションを組み込み、サイトの訪問者が互いにチャットできるようにするというものでした。すでに競合他社が立ち上げており、同じアイデアを持つ他の数社と相談中です。代わりに、電子商取引関連のチャットに重点を置いています。しかし、話がそれてしまいました…

彼らのシステムのパフォーマンスは非常に悪いです。ユーザーは蜂蜜の中に閉じ込められたアリのように遅いです。どうやら、CEO は初日に 100 万人のユーザーをサポートする必要があると主張したようです (彼が私に語ったところによると)。彼らはこのことを Oracle に伝えましたが、Oracle はこの容量をサポートするには 3 台のサーバーのクラスターが必要だと言いました。その後、彼らはオブジェクト指向データベースベンダーと話をし、1 台のマシンで 100 万人のユーザーを処理できると約束しました。そこで彼らはオブジェクト指向データベースに焦点を当てました。私がこれに衝撃を受けたとき、彼らは、各ユーザーが複数のプロジェクトを持つことができるため、データは非常に「オブジェクト指向」であると主張しました...うーん。

トランザクションの境界が理解されておらず、ストレージコードがすべてのコードに混在しているため、速度が遅くなります。これは信頼できず、理解できません。オブジェクト指向データベースの時代を覚えていないかもしれませんが、それは 2010 年代に業界を席巻した NoSQL の流行の先駆けでした。コンサルタントとして働いていた頃、私はこの物語の再放送を何度も見ました。今回はほとんどの企業が成功裏に立ち上げました。

しかし、その後、非構造化データを持つことが万能薬ではないことが分かりました。適切なキャッシュと適切に調整された SQL を使用する場合と比較すると、パフォーマンスの向上はごくわずかです。デプロイメントのストーリーは非常に複雑なので、ツールはおそらく SQL の世界のレベルに達することは決してないでしょう。

明確に言うと、 NoSQLには独自の優れた領域がありますが、これらのデータベースの一般的な用途はあまり良くなく、RDD (Resume Driven Development) から派生したものです。これは、何度か経験を積んだ私たちが何度も見てきたパターンです。

• 古い技術は扱いにくく複雑です

• 人々はシンプルできれいなものを発明した

• 古い技術を忘れる

• 新しいものは単純すぎて、基本的な機能はあまりありません

• こうした複雑さを再構築する

• 新しいものは古くて扱いにくい複雑なものとなり、再発明が必要になります…これを繰り返します

サーバーレスは新しいメインフレーム

過去 1 か月間、サーバーレスの作業をたくさん行ってきましたが、これは大きな後退だと感じています。これは、PaaS で発生した問題の繰り返しです。実はメインフレームです。以前は、共有メインフレームで作業を実行するために料金を支払っていました。これは仮想化環境に少し似ていますが、考え方は似ています。つまり、私たちはその環境を所有しません。これはクラウド SaaS にも当てはまると言えますが、サーバーレスの概念はそれをはるかに超えています。

デバッグ体験もひどいです。コードや基本的なアプリケーションロジックを根本的に制御することはできません。なぜ人々がそれを基本的なタスク以外の用途に使用するのか理解しようとしています。

これに適した使用例として、Webhook が考えられます。 Webhook の配管コードを取得するのは常に面倒です。これらは頻繁に発生するものではなく、対処するのは面倒な作業です。サーバーレス関数を使用してデータベースにコンテンツを追加し、作業を完了するのは非常に簡単です。コールバックはとにかくデバッグが難しいため、サーバーレスでのデバッグエクスペリエンスが悪いことは大きな障害にはなりません。しかし、他のすべての使用ケースについては、私は完全に混乱しています。

スループットの確認と測定には多くの時間を費やしますが、わずかに大きいサーバーとローカル呼び出しのみを使用すると、おそらく必要以上のスループットが生成されます。私たちが煩わされるベンダーとの提携は一切ありません。 Linode、Digital Ocean などのホスティングを使用すると、多くの費用を節約できます。市場投入までの時間という点では、キャッシュと高速なローカルツールのみを使用する方が、クラウドで構築できるものよりもはるかに簡単です。

コンテナは素晴らしい進歩であり、これを非常に簡単にしてくれますが、K8S のようなコンテナの使用に伴う複雑さに圧倒されてしまうこともあります。誤解しないでください。 K8Sは素晴らしいです。しかし、私たちの98%はそれを本当に必要としておらず、また使用すべきでもありません。小規模なスタートアップの場合、Kubernetes は時間と労力の無駄になります。

JavaとRustに戻る

Java は、忘れっぽさをうまく表現できる言語の一例です。 Smalltalk がありましたが、とても良かったです。 Java が最初に登場したとき、それは奇妙な C スタイルの構文を持つ粗雑なソリューションでした。 Java は Smalltalk と C++ の多くの優れたアイデアを放棄しました。いくつかの議論の余地のあるアイデア (チェック例外、プリミティブなど) を採用しています。しかし、それはうまくいきました。それは人々の注目を集めます。それを悪用することが可能です。

元々は、他のプラットフォームが追加した不要な機能や過剰なエンジニアリングをすべて排除した軽量言語となることを目指していました。今見てみると、もう誰もこれを「軽量」とは言いません。開発者たちは、Java の欠点について不満を言うために、より軽量でシンプルな言語の作成に忙しくしています。成功すれば、彼らは出発点に戻るでしょう。大きくなりすぎた軽量言語。 Java は今や、あるべき姿に到達しました。これは、良い書き直しの数少ない例の 1 つです。

Rust は数少ない例外の 1 つであるようです。まったく新しい方法で C を再発明します。長期的に生き残れるかどうかは分かりません。しかし、その過程で多くの複雑な問題に対処する必要があることは間違いありません。

意識的な再発明

既存の言語やツールの再発明が大衆市場で成功する理由は何でしょうか。また、これらのツールが廃れてしまう理由は何でしょうか。

SQL は復活し、新しいスタートアップ企業の間で再び人気を集めています。 C++ については同じことは言えません。それらはどう違うのでしょうか?

JVM の世界にある基本的な機能が欠けているにもかかわらず、Node と Python は依然として人気があります。一体何が起こっているのでしょうか？そして彼らはこの人気を維持できるのでしょうか？彼らはそれをまた追加するつもりですか?

10代になるまで、私たちの脳はシナプスを増やし続けます。 10代の頃は、私たちはそれを断ち切りました。一説によると、これが私たちが十代の頃に経験するすべての変化の根源だと言われています。私たちにとってもはや役に立たないものを切り離す必要があります。そうでなければ、私たちは両親が知っていることだけを学ぶことになります。自分自身の間違いを犯しても改善することはできません。その世代が失敗したことをもう一度試してください。

その結果、私たちは間違いを繰り返し、新たなひどい間違いを犯してしまいます。私たちはまた、いくつかの驚くべき飛躍と発見も成し遂げました。ここからイノベーションが始まり、エンジニアリングも始まります。

十代の不安と明るい新しい方向性の違いをどうやって見分けるのでしょうか?

正直に言うと、それはできません。年配者として、初めてこれを見たとき、私はその多くが愚かだと思いました。私たちはこれらのことを試しましたが失敗しました。なぜその間違った方向を繰り返すのですか?そこにイノベーションがあるのです。しかし、成功した試みをよく見てみると、何かがうまくいったことがわかります。

Java は C++ の終焉となるように設計されたわけではありません。もちろん、これは空想かもしれません。しかしゴスリングはそれをシンプルで小型になるように設計した。非常に狭いニッチ市場に対応するには、セキュリティ、規模、ネットワークに重点を置きます。

Rust は C の終焉を意図したものではありません。Firefox のようなプロジェクトをより安定させ、パフォーマンスを向上させることを目的としています。

他のスタートアップと同様に、二次発明は、当初非常に小規模で狭いユースケースに限定していたときには、非常にうまく機能したと思います。これを実行し、最初の焦点を維持することで、何か良いものを構築し、偉大さへと飛躍することができます。