「FaaS、PaaS、CaaSの間の垣根を取っ払う」Knativeの可能性と課題とは：IBMのダグ・デイヴィス氏に聞いた（1/2 ページ）

「FaaS、PaaS、CaaSの区別などどうでもいい」。Knativeが持つ最大の魅力はこう言えることだと、CNCFサーバレスワーキンググループでCo-chairを務めるIBMのダグ・デイヴィス氏は話す。一方、Buildのプロジェクトからの離脱などの心配要因もある。デイヴィス氏に、Knativeの可能性と課題を聞いた。

[三木泉，＠IT]

　広義のサーバレスを実現する技術としてデビューした「Knative」。CNCF（Cloud Native Computing Foundation）サーバレスワーキンググループのCo-chairを務めているIBMのKnative担当オファリングマネージャー、ダグ・デイヴィス（Doug Davis）氏は、2019年7月に開催された「OpenStack Days/Cloud Native Days Tokyo 2019」で、「Demand Less Choices（より少ない選択肢を求めよ）」というタイトルの講演を行い、この技術の魅力を語った。

　講演中には下の表を示し、「あなたはCaaS（Container as a Service）、PaaS（Platform as a Service）、FaaS（Function as a Service）のどれをどう選ぶかについての悩みから解放されるべきだ」と話した。

この表は、KnativeとCaaS、PaaS、FaaSの技術比較であるかのような印象を与える可能性がある。ちなみに「Fn/Srvr」というのはFaaSを示している

　だが、この表は2つの点で誤解を生みやすい。まず、CaaS、PaaS、FaaS、Knativeを横並びにした比較で、技術的に最も優れているのはKnativeだということを示したものだと受け止められる危険性がある。また、表にもあるように、多くの機能が「WIP（Work in Progress：取り組み中）」であるのに、Knativeが現時点で全ての機能を備えているかのような印象を与える可能性がある。

「FaaS、PaaS、CaaSの区別など忘れてしまえ」

　上記の表は、例えばFaaSでメモリサイズや実行時間に制限があることを（婉曲的に）示している。確かにAWS Lambdaをはじめ、複数のFaaSにはこうした点での制限が存在する。だが、技術的な制約というよりも、サービスとしての設計や運用上の理由によるものではないのか。

　「その通りだ。FaaS自体に制限はない。ファンクションを何日も、何年も動かせるようにしたからといって、『FaaS』と呼ばれなくなるわけではない。制約は、（サービスあるいはプロダクトとしての）実装から来るものであり、技術的なものでは全くない。その証拠に、一部の（FaaS）サービスでは、制限が段階的に緩和されてきた」（デイヴィス氏、以下同）

　だが、このことこそが講演で最も訴えたかったことだと、デイヴィス氏は続ける。

　「表で見せたかったのは、技術的な違いではなく、技術をどのようにエクスポーズする（露出する、見せる）かについての違いだ。例えばCloud Foundryでゼロへのスケール（ゼロへの縮退）ができないのは、やらないことを選択したからだ。つまり私が言いたいのは、『FaaS、PaaS、CaaSといった区別は人工的なものだ』ということだ。私がKnativeを気に入っている理由は、『そんな区別などすっかり忘れてしまえ、Knativeはこれこれの機能を提供する』と宣言できるからだ。Knativeを『FaaS』と呼ぶ人がいれば、『PaaS』と呼ぶ人もいるだろう。『シンプルに使えるKubernetes』と表現する人もいるかもしれない。どう呼ばれようが、私にとってはどうでもいい。『あなたのニーズに合っているなら使ってくれ』ということに尽きる」

　つまり、Knativeはそれ自体が、これまでのFaaS、PaaS、CaaSといった分類にとらわれず、ユーザーエクスペリエンスを向上させる機能をユーザーに提供できるのだと、デイヴィス氏は説明する。

　一方、Cloud FoundryやApache OpenWhiskといった、PaaSやFaaSのオープンソースソフトウェア（OSS）プロジェクトでは、KubernetesおよびKnativeを基盤技術として活用する動きが進行中だ。

　するとますます、FaaS、PaaS、CaaSの間の境界はぼやけてくることになる。全てではないにせよ、既存（および新規）のPaaS、FaaS関連OSSプロジェクトがKubernetes／Knativeという共通の技術を採用した上で、ユーザーに提供したい抽象化レベルや制限を組み込んだものを提供することになるからだ。FaaS（に分類される製品）がPaaSの領域に踏み込んだ機能を提供したり、逆にPaaS（に分類される製品）がFaaS的な機能を付加したりすることも、あり得なくはない。

　「Knativeの採用が広がるに従って、それぞれの好む制限を組み込んだプラットフォームを構築する動きが進むだろう」

「Google CloudのCloud Runは、OSSのKnativeを使っていない」

　「関連して、もう1つの興味深い側面がある、KnativeはOSSだけでなく、仕様でもある」とデイヴィス氏は話す。

　「例えば、Google CloudはKnativeについて、ユーザーに対し2通りの利用法を提示している。1つはKubernetesクラスタ上にデプロイして使う方法、もう1つは『Cloud Run』だ。前者はOSSのKnativeを使っているが、後者はOSSではない実装をベースとしている」

　Google CloudがCloud Runで、OSSではない実装を用いている理由は分からないという。

　「いずれにせよ、KnativeのAPIを採用しながら、これをOSSのKnativeとは全く異なる実装によって提供することは可能だ。それでも、OSSのKnativeと同じAPIを使えるのだから、ユーザーとしては別に気にかける必要はない。APIに準拠している限り、『Knative』と呼ぶことができる」

「Kubernetesをそのまま使うことは減っていく」

　IBMはしばらく前から、アプリケーションプラットフォームで「Unified Stack（統合スタック）」をうたっている。

　CaaSではKubernetes、PaaSではCloud Foundry、FaaSではOpenWhiskに関与してきたIBMだが、KnativeについてもOSSプロジェクトの創設メンバーとなっている。そこで、Cloud FoundryおよびOpenWhiskで進みつつあるKnativeベースへの移行を後押しし、統合的基盤の上で、「Kubernetes」「Knative」「Cloud Foundry」「OpenWhisk」という4種類のデベロッパーエクスペリエンスを提供していくと表明している。