wip) 最近のServerless、Knativeとか

よくまとまっている気がした

FaaSとBaaSの組み合わせにより実現される

サーバレスアーキテクチャのより完全な定義は、サーバレスコンピューティングとサーバレスデータの両方を含むものです。

Microservicesは、コードの複雑さを運用の複雑さと引き換えにしています。サーバレスは速度を制御を引き換えにします。

Serverless 1.5

AWSは、サーバレスをこの場所に持ち込むという驚くべき仕事をしましたが、サーバレスの現在の状態がその最高点ならば悲しいことでしょう。また、サーバレスで革新し、その将来を定義できるのがAWSだけである場合も悲しいでしょう。オープンソースエコシステムにおけるAWSのバックグラウンドが比較的限られていることを考えると、AWSがサーバレスパラダイムを標準化し、そのような基本的なレベルで業界全体に影響を与えることを期待するのは過剰な期待でしょう。AWSのビジネスモデルと市場での地位は、市場の動向と初期のクローズドイノベーションを特定するのに適していますが、オープンソースモデルは、一般化、標準化、および強制のない業界全体の受け入れに適しています。私は、業界全体がより広範にコラボレーションして、オープンソースモデルを使用して、次世代のサーバレスが作成され、その採用と相互運用性が向上することと期待しています。そのプロセスが開始され、今日の独自のサーバレス製品の相互運用性と移植性を業界はゆっくりと模索しています。

Knativeは、サーバレスの特性（ゼロへのスケーリング、HTTPリクエストに基づく自動スケーリング、サブスクリプション、デリバリ、バインディング、イベントの管理）をKubernetes上のコンテナベースのワークロードに載せようと、現状に挑戦している複数のベンダーによるオープンな共同の取り組みです。コンテナベースのパッケージングとKubernetesベースの実行により、複数のサーバレスプロバイダーで標準化できるオープンな実行モデルが可能になります。

サーバレスアーキテクチャは定義上、イベント駆動型であり、イベントは中心的な役割を果たします。 (略) ビジネスロジックとサーバレスプラットフォームのデータ形式の結合により、相互運用性が妨げられます。CloudEventsは、すべてのサーバレスプラットフォームで動作する標準化されたイベント形式を作成するための活動です。

Serverless のワークロード

マイクロサービスの価値は、WebベースのAPI（通常はRESTスタイル）を使用して、一連の要求/応答スタイルの操作の背後にある複雑なビジネスドメインロジックと永続化ロジックをカプセル化できるという事実にあります。一方、サーバレスおよび関数は、イベントとトリガーに焦点を当てています。関数をAPIゲートウェイの背後に配置して要求/応答スタイルで動作させることはできますが、APIは主要なインターフェースとなることを意図していません。イベントとトリガーが主役です。サーバレスアプリケーションは、アプリケーションが非同期（要求/応答ではなく、単方向のファイア・アンド・フォーゲットスタイル）で、キューまたはその他のデータおよびイベントソースを介して接続する場合に最適に動作する傾向があります。結果として、各関数は1つのアクションのみを実行することを目的としており、他の関数を直接呼び出すことを避け、その結果をイベントストアに書き込む必要があります。

コストと能力の観点から見たときに、とてつもなく魅力的なものではあるが、お金の節約やスケールアップに対する準備という動機は、この技術を適用しようとするスタートアップにとっては、とても貧弱な理由である。

Function are the unit of deployment and scaling.

No machines, VMs, or containers visible in the programming model.

Permanent storage lives elsewhere (SLE).

Scales per request; Users cannot over- or under-provision capacity.

Never pay for idle (no cold servers/containers or their costs).

Implicitly fault-tolerant because functions can run anywhere.

Bring Your Own Code (BYOC).

Metrics and logging are a universal right.

CloudEvents

Knative

Virtual Kubelet

なんとなくの所感

AWS が Lambda を中心に Serverless という概念を作ってきたが、 これまでは、AWS の他のサービスとインテグレーションしてうまく使うと強力、という印象をでない

コストの削減、スケールアップ

運用側、AWSに習熟した人からのメリットが強い気がして、一般のアプリ開発の定番になるには、少し遠く感じる

もう一段階進化がありそう（必要）な気がする

標準化、技術的な改善、ブレーキングなフレームワーク・プラットフォーム

アプリ開発者目線で強力に魅力的になるのが、必要、という気がする

フレームワークにより、Eventがもっとネイティブに扱えると嬉しい

Function はイベントからトリガーされる。他の Function の直接的な呼び出しは避け、キューなどを介して接続される。Serverless なアーキテクチャは非同期なプログラミングモデルになる

現実のアプリケーションでは、同期的なモデルが必要になることは当然ある

現Microservice時代の同期的なRPCと、非同期なServerlessが混在する？