Serverless と Rust はどちらも古いテクノロジーの第 2 の事業です。

  • 原題: Serverless Is the New Timeshare 、著者: Shai Almog

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

タイムシェアリングバケーションとは、ヨーロッパ発祥のバケーションモデルで、ホテルやリゾートの客室や観光用アパートの使用権を数週間に分割し、10年から40年、あるいはそれ以上の期間で利用するものです。システムは一度に顧客に販売され、会員はホテルやリゾートに年間 7 日間滞在するレジャー手段を得ることができます。また、交換サービス制度とは、会員が自らの客室利用権と他の会員の社外室利用権を交換することで、低コストで各地への旅行を実現するサービスです。

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

私たちは皆、健忘症を持っています。若い開発者と過去のテクノロジーについて話すと、白い目で見られることがよくあります。公平を期すために言うと、その原因の一部は私が少し「緊張している」または「変人」だからですが、一部は若い技術者が古い技術を理解していないためです。

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

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

数年前、私は Node-based という銀行業界の新興企業と話をしていました。銀行はノードとの協力に非常に前向きだという。彼らがより「成熟した」環境で自分たちの作品を書き直していることは知っています。Node などの「新しい」ツールを使用すると、基本的な機能が欠如していることにいつも驚かされます。もちろん、必要なものがすべて収まらない場合は、よりシンプルで小さくなります。コア機能を省略すると、シンプルなものを構築するのが簡単になります。

 

2010 年代の NoSQL ドラマ

1999年に遡り、私は自分のコンサルティング会社を設立していたとき、友人から彼の上司に会ってほしいと頼まれました。私がこのオフィスに行ったとき、「上司」は、他の人が持っていない最も素晴らしいアイデアを持っていると言いました。彼らは資金を持っているので、6 か月以内にローンチし、初日に 100 万人のユーザーに展開する予定です。

私:わかりました。どのようなアイデアですか?

彼: 弊社で働くことにサインアップしたらお知らせします。

私:NDA(NON-DISCLOSURE AGREEMENT、つまり秘密保持契約)に署名します。

彼はしません。素晴らしいアイデアですね。それらの NDA には価値がありません。あなたはサインアップして...

どういうわけか、私はこの会社で働きたいという誘惑に抵抗することができました。約1年後、明らかに彼らは立ち上げられませんでしたが、私のコンサルティング会社はうまくいっていました。友達がまた電話してきました。今回は製品に関してサポートが必要だったので、私はコンサルティングの立場でそこに行き、彼らをサポートしました。

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

彼らのシステムのパフォーマンスは非常に悪かった。ユーザーの速度は、蜂蜜にくっついたアリのように遅いです。どうやら CEO は、初日から 100 万人のユーザーをサポートできる必要があると固く主張していたようです (彼が私に語ったところによると)。彼らはこのことを Oracle Corporation に伝えました。Oracle Corporation は、この容量をサポートするには 3 台のサーバーからなるクラスターが必要だと言いました。次に、オブジェクト指向データベース ベンダーに相談すると、1 台のマシンで 100 万人のユーザーを処理できると約束されました。そこで彼らはオブジェクト指向データベースに全力を尽くしました。私がこれにショックを受けたとき、彼らは、自分たちのデータは各ユーザーが複数のアイテムを持つことができるという点で非常に「オブジェクト指向」であると主張していました...当然です。

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

しかしその後、非構造化データを保有することが万能薬ではないことがわかりました。優れたキャッシュと適切に調整された SQL を使用する場合に比べて、得られるパフォーマンスの向上はごくわずかです。導入ストーリーは複雑であり、支援ツールは SQL の世界のレベルに到達することは決してないかもしれません。

明確にしておきます: NoSQL にはニッチな分野がありますが、これらのデータベースの一般的な用途はあまり優れたものではなく、RDD (リカバリ駆動開発) に由来しています。これは、ブロックを何度か振り返ったことのある私たちが何度も何度も見たパターンです。

  • • 古いテクノロジーは扱いにくく、複雑です
  • • 人々はクリーンでシンプルなものを発明しました
  • • 古いテクノロジーのことは忘れてください
  • • 新しいものは単純化されており、基本的な機能があまりありません
  • • これらの複雑さを再構築する
  • • 新しいものは古くなって不格好になり、再発明する必要がある...洗い流す/繰り返す
  •  

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

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

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

良い使用例が 1 つ思いつきます。それは 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代になるまで、私たちの脳は常にシナプスを追加しています。私たちの十代の頃、私たちはそれらを切り落としました。一説によると、これが私たちが十代の頃に経験するすべての変化の根源にあるということです。機能しなくなったものを切り離す必要があります。そうでなければ、私たちは親が知っていることしか学びません。私たちは自分自身の間違いを犯しても改善することはできません。その世代が失敗したことをもう一度試してください。

その結果、私たちは過ちを繰り返し、新たに恐ろしい過ちを犯してしまいました。私たちは驚くべき飛躍や発見もしました。ここでイノベーションが始まり、エンジニアリングも始まります。

思春期の不安と明るい新しい方向性の違いをどう見分けるのでしょうか?

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

Java は C++ を終わらせるために設計されたものではありません。もちろん、これは幻想である可能性があります。しかし、ゴズリングはシンプルさと軽さを追求してデザインしました。非常に狭いニッチ市場に対処するには、セキュリティ、規模、ネットワーキングに重点を置きます。

Rust は C を殺すように設計されていません。Firefox などのプロジェクトの安定性とパフォーマンスを向上させるように設計されています。

二次発明は、他のスタートアップと同様、最初は非常に小さく狭い使用例に限定するとうまく機能すると思います。これを実行し、その最初の焦点を維持することで、良いものを構築し、その後大きな飛躍を遂げることができます。

おすすめ

転載: blog.csdn.net/Z__7Gk/article/details/132193196