新興企業であれフォーチュン500の企業であれ、ビジネスにおいて最優先されるのは、自社の製品によってお客様を満足させ、成功させることです。しかし、お客様にとっては、成功と満足がたった1つの機能に依存しているように見えることがあります。
「Xさえカスタマイズしていただければ、御社の製品を使えるようになります」-パイプラインの中で最大の見込み客です。「Yさえできるようにしていただければ、御社の製品の利用を10倍に拡大できます」- 最も戦略的な既存のお客様です。
企業は企業の製品がすべての人のためになることを望んでいますが、非常に迅速に対応できるのはエンジニアリングだけです。それはどういうことでしょうか?
本日、Workers for Platformsを発表します。これは、あらゆる製品をプログラム可能にし、お客様がそれぞれのお客様と開発者に瞬時に価値を提供できるように支援する一連のツールです。
プログラム可能なインターフェース
お客様がプログラムによって企業の製品を操作できるようにする方法の1つは、APIを提供することです。APIが今日これほど普及しているのは、これが大きな理由です。コード(企業自身のものであれ、第三者のものであれ)をアプリケーションと連携させることはまさに革命的です。
しかし、まだ問題があります。APIを使用すると、開発者はプログラムによってアプリケーションの操作ができるようになりますが、開発者は最終的には常に、APIによって公開される抽象化によって制限されます。アプリケーション所有者は、お客様が製品をどのように使用するかを予測し、ユースケースをサポートするAPIを構築する必要があります。私がプロダクトマネージャーとして1つ学んだことがあるとすれば、お客様が製品をどのように使用するかを予測することはほとんど不可能だということです。そして、もう1つ学んだことは、たとえ豊富なエンジニアリングリソースがあったとしても、お客様を満足させ続けるために必要なすべての機能を構築することはほぼ不可能だということです。
しかし、別の方法があります。
APIとは対照的に、関数は最低レベルのプリミティブを提供します(プリミティブの上に抽象化を置くのではなく) 。これにより、開発者はそこから適切な動作を定義できます。また、プリミティブの上に独自のAPIを定義することもできます。
この意味では、関数とAPIは実際には相互補完的であり、関数から直接別のAPIを呼び出すこともできます。たとえば、メッセージングシステムでイベントを処理する場合、電子メールAPIを呼び出して電子メールを送信する独自の機能を実装したり、チケットシステムでチケットを作成したりできます。
Workers for Platformsが非常に魅力的である理由はここにあります。Workers for Platformsを使用することにより、お客様の開発者は任意のアプリケーションに独自のロジックを実装するための直接的な方法を公開できます。私たちは、Workers for Platformsを採用する企業にお客様主導のイノベーションの波が押し寄せ、APIがそうであったように、ウェブ上のアプリケーション構築に影響を与える可能性があると考えています。
開発者エクスペリエンスの向上
Workers for Platformsは、製品をプログラム可能にするためのより強力なパラダイムを公開しますが、開発者としてのエクスペリエンスの向上にもつながります。
今日、開発者として、APIやWebhookを使い始める前に、まず対処しなければならない面倒なタスクのリストがあります。まず、サーバー(またはサーバーレス関数)に関係なく、コードをホストする場所を設定し、外部エンドポイントを介してコードを公開する必要があります。OPS、カスタムトークン、新しい認証スキーマの把握など、始める前にすべて対処しなければなりません。次に、そのサービスを保守し、イベントが常に適切に処理されるように、サービスを稼働させなければなりません。
使用している製品に直接組み込まれている関数を使用すると、コードの記述を開始できます。
このモデルがこれまで採用されていないのはなぜですか?
開発者、がイベントがどのように動作するかをプログラムできるようにすることは、当たり前のことのように思えますが、だからといって、それが簡単なこととは限りません。
Cloudflareでは、5年前にまさにこの問題に直面しました。私たちは、ネットワークに多くのお客様をオンボードし、それぞれのお客様が独自の方法でリクエストの結果を決定する必要がありました。Page RulesはURLごとに動作を修正する方法を提供していましたが、お客様はCookie、ヘッダー、ジオロケーションなどに基づいて動作を制御したいと考えていました。
私たちは弊社のエンジニアリングチームがすべてのリクエストに対応することはできないと考え、お客様が当社の製品をそれぞれのニーズに合わせて変更できるようにしました。
この問題へのアプローチを模索する中で、次の2つの要件を満たすソリューションを探しました。
パフォーマンス要件:サイトを高速化するはずのCDNが遅延を発生させることは許容されません。どうすれば、そこにあることに気づかないほど速くできるますか?
セキュリティ要件:信頼されないコードを安全に実行するにはどうすればよいでしょうか?
これらの要件は、パフォーマンスやセキュリティ製品を提供する場合に特に重要ですが、お客様に製品をプログラムする機能を提供する場合にも、これらの課題を解決することは重要です。関数をユーザーに対してクリティカルパスで実行する必要がある場合、遅延を招くようなことも同様に許容されません。そしてもちろん、ユーザーがプログラムできるようにするためだけに、セキュリティが侵害されることを望む人はいないでしょう。
真に高速で安全なマルチテナント環境を構築するのは簡単なことではありません。
この問題を解決するための選択肢を評価したとき、私たちはまず、この問題を解決するためにサーバー上に存在する技術に着目しました。サーバーレス関数は当時既に存在していましたが、コンテナーを使用していたため、コールドスタートで実行されます。それは、非現実的なものでした。そこで私たちはブラウザに着目(特にV8を搭載したChromeに着目)し、同じアプローチをとることを決め、サーバー上で実行しました。
また、このアプローチはシンプルに聞こえますが(おそらく、振り返ってみればそう聞こえがちであることは当然ですが)、大規模なマルチテナント開発プラットフォームを大規模に実行するのは簡単な作業ではありません。お客様が製品をプログラムできるようにする目的の一部が、エンジニアリングの労力を解放して新しい機能の構築に集中することであるなら、このような開発プラットフォームの維持と拡大に労力をかけることは目的を台無しにする可能性があります。
最近になって気づいたことは、この問題を解決しようとしているのは、私たちだけではないということです。
Shopifyのような企業は、次世代のプログラム可能なストアフロント「Oxygen」を構築して、同じ問題を解決しようと試みていました。彼らはセキュアなマルチテナント環境を維持しながら、お客様がカスタムストアフロントを実行し、可能な限り最高のパフォーマンスを提供できるようにしたいと考えていました。
Shopifyのカスタマーストアフロント担当製品ディレクター、Zack Koch氏は、「Shopifyはインターネット上の商業インフラで、数百万もの商業者がこのプラットフォームを利用しています。Cloudflareとの連携で、開発者がユニークで機能性の高いストアフロントを構築する際に必要なツールを提供できるようになりました。Cloudflareとの協力により、スケーラビリティやグローバルな可用性といったコマース体験を構築するうえで避けられない複雑さをある程度緩和し、開発者は自社ブランドの差別化に集中できるようになります」と述べています。
Workers for Platformsで次のプラットフォームを構築するにはどうすればよいでしょうか?
Shopifyのようなプラットフォームと協力して開発者のニーズに対応することで、私たちは開発者エクスペリエンスが万能ではないという別の問題に気づきました。つまり、私たちは幅広い開発者のためにプラットフォームを構築していますが、eコマース開発者は、より専門的なニーズを持っている可能性があり、そのニーズに合わせた開発者エクスペリエンスが最善の解決策になります。また、基盤となるテクノロジーは同じでも、直接のお客様が必要とするのと同じ高レベルの概念でプラットフォームを構築することには意味がありません。
企業のお客様のことを誰よりもよく知るのは企業であるため、プラットフォームプロバイダーである企業には、ユーザーにとって最適なエクスペリエンスを設計していただきたいと考えています。Workers for Platformsは、設計する展開フローに直接統合するための、新しいツールとAPIのセットを公開します(私たちが何をしたのかわかりますか?)。
タグAPIで関数を大規模に管理
APIを使用することで、開発者がプラットフォームにスクリプトをデプロイするときはいつでも、APIを呼び出して新しいWorkerをバックグラウンドでデプロイできます。従来のWorkers製品とは異なり、Workers for Platformsは、数十万から数百万のCloudflare Workersを管理するために大規模に使用されるように設計されています。
デプロイメントサービスまたはユーザーの管理方法に応じて、タグを使用してスクリプトのグルーピングを管理するオプションも提供されるようになりました。たとえば、ユーザーが自分のアカウントを削除し、すべてのWorkerがクリーンアップされていることを確認する場合です。タグを使用することで、スクリプトごとに任意のタグ(ユーザーIDなど)を追加して、一括アクションが実行できるようになりました。
Trace Workers
煙があるところには火があり、コードがあるところにはバグもあるはずです。開発者にコードを記述してデプロイするツールを提供する場合は、デバッグする手段も提供する必要があります。
Trace Workerを使用すると、ログや例外など、Workerによって処理されたリクエストに関するあらゆる情報を収集し、お客様に渡すことができます。Trace Workerは、他のWorkerの実行に関する情報を受け取るWorkerであり、選択した宛先に転送して、ライブロギングや長期保存などのユースケースを可能にします。
以下は、HTTPエンドポイントにトレースデータを送信するシンプルなトレースWorkerです。
以下は event.traces のデータの例です。
addEventListener("trace", event => {
event.waitUntil(fetch("http://example.com/trace", {
method: "POST",
body: JSON.stringify(event.traces),
}))
})
動的ディスパッチで複数のWorkerを連鎖させる
[
{
"scriptName": "Example script",
"outcome": "exception",
"eventTimestamp": 1587058642005,
"event": {
"request": {
"url": "https://example.com/some/requested/url",
"method": "GET",
"headers": [
"cf-ray": "57d55f210d7b95f3",
"x-custom-header-name": "my-header-value"
],
"cf": {
"colo": "SJC"
}
},
},
"logs": [
{
"message": ["string passed to console.log()"],
"level": "log",
"timestamp": 1587058642005
}
],
"exceptions": [
{
"name": "Error",
"message": "Threw a sample exception",
"timestamp": 1587058642005
}
]
}
]
いくつかの初期のお客様との作業でよく聞かれた別のニーズは、お客様のコードを実行する前に、企業独自のコードを実行する機能についてです。たとえば、認証のレイヤーを実行したり、入力や出力をサニタイズしたり、有用な情報(ユーザーIDやアカウントIDなど)をダウンストリームに提供したりする必要がある場合があります。
そのためには、企業独自のWorkerを保守する必要があります。実行が完了したら、_お客様の_コードを使用して次のWorkerを呼び出すことができます。
例:
カスタムドメイン、その他にも!
let user_worker = dispatcher.get('customer-worker-123');
let response = await user_worker.fetch(request);
上記の機能は、今週の時点でお客様に対して有効にした新しいWorkers機能にすぎませんが、プラットフォームの構築に必要なすべてのツールを提供することが目標です。たとえば、Workers for Platformsを使用してCloudflare for SaaSでカスタムドメインを作成することができます。(「その他にも!」の部分にもご期待ください)。
どうすればアクセスできますか?
私たちがリリースするどの新製品でもそうですが、お客様やそのユースケースから学ぶべきことがたくさんあることは間違いありません。私たちは企業に確実に成功を収めていただけるようサポートしたいと考えています。ご興味をお持ちであれば、私たちは企業とそのユースケースについて理解を深め、必要なすべてのツールをセットアップさせていただきます。はじめに、弊社のフォームにご記入ください。折り返しご連絡いたします。
その間に、開発者向けドキュメントをご覧いただいたり、Discordにメッセージを送ってみたりしてください。
まだまだこれから
私たちは5年前にこの問題に直面しました。弊社のサービスを拡張していただける機能をお客様に適した方法で提供する必要があり、Cloudflare Workersを立ち上げたときにそれを実行しました。弊社のグローバルネットワークをお客様がそのニーズに合わせてプログラムできるようにしたことで、開発プラットフォームでより多くのお客様をサポートできるようになり、一方で、弊社のエンジニアリングチームは、最も要求の多いカスタマイズを機能として実現することに専念できるようになりました。私たちは、企業の開発者がそのプラットフォーム上で何を構築するか、そして、企業が思いもよらないようなユースケースを、開発者が思いつくことに驚かされることだろうと信じています。また、企業のエンジニアリングチームが並行してどのようなことに取り組むことができるか見ることを楽しみにしています。