Salesforce Evergreen によって何が変わるか(あるいは変わらないのか)

Dreamforce 2019にてSalesforce Evergreenが発表されました。

詳細な説明は省きますが、Function as a Service(FaaS)と呼ばれるカテゴリに位置するサービスです。有名なものではAWS Lambdaがありますし、Google やAzure といったプラットフォームもそれぞれGoogle Cloud FunctionsAzure Functions などを出しており、それらを知っている方にはある程度の内容は推測可能ではないかと思います。

Herokuが貢献するFaaSプラットフォーム

さて、Salesforce上でコード主体のプログラムを行う際に利用されている言語/ランタイムとしてApexというものがありますが、これはあくまでSalesforceアプリケーションを拡張するためのものであり、いわゆるSaaS以下のプラットフォームレイヤーで動作するサービスについてはHerokuが担ってきていました。

Herokuは2010年にSalesforceが買収発表して以降、Salesforceとの営業的なシナジーを受けながらもある程度距離を保った位置のままサービスを続けていました。今回のEvergreenの発表にあたって、従来のSalesforceの開発チームに対してHerokuチームがかなり貢献して作られたサービスであると喧伝されています。事実、Evergreenのデモ画面などを見ていると、URLがherokuの環境を指していたりなど、Herokuの匂いを感じさせる点が結構あります。そういう意味では、Herokuが作ったFaaSなのだ、という捉え方も間違いではないでしょう。中身は Kubernetes (Knative) ということなので独自性はあまりないでしょうが、コンテナベースのクラウドを真っ先に商用化し未だ使われ続けているHerokuのプラットフォーム運用に対する知見は十分に信頼に足るものではないかと推測します。

ただ、Function as a Serviceというだけでは、もはやあまり目新しい点がない、というのも事実です。2014年にLambdaが発表されてからすでに5年、先に述べたようにクラウドサービスプラットフォームであればFaaSを手掛けていないものを数えるほうが早くなっています。プログラミング言語のサポートも充実してきており、後発のEvergreenがJavaとNode.js(JavaScript) だけ、というのはちょっと心もとなく見えます。

しかしながら、今回のEvergreenの発表を新たなFunction as a Serviceの登場とだけ捉えていると、おそらく少し見誤ります。Evergreenは、既存のSalesforce顧客やそれにともなうパートナー・エコシステムに対して大きな影響を与えるものであり、そして巨大市場の開放/自由化の兆しを見せるものでもあります。

Salesforceのパッケージングとエコシステム

SalesforceSaaSとはいえ、アプリケーションを拡張できるプラットフォームとしての側面があります。そしてそのプラットフォーム上で動作するカスタム画面や項目/オブジェクトなどのデータベース定義、そしてカスタムロジックなどを全部まとめてパッケージし、Salesforce環境へ配備する仕組みについても持っています。作成したパッケージはAppExchangeというマーケットプレイス経由で配布して不特定多数のSalesforce顧客に利用してもらうことも可能です。こういった仕組みの上にSalesforce以外に多数の企業が参画してエコシステムが構成されているのがこのビジネスアプリケーションプラットフォームの特徴であり魅力である、と言えるかと思います。

ただし、先に述べたように、Salesforceにおいてカスタムロジックを記述する際にはApexという独自言語を利用する必要があります。このことは、Apexが登場した2006年当時を考えますと、マルチテナント環境下でもコードレベルのカスタマイズを実現できるようにするために言語レベルで制約したことは責められることではなかったとは思います。そしてそこから10年以上の歴史とそれに伴うエコシステムの成熟があり、ApexはまあSalesforce開発における必要悪のようなものとして受け入れられてきました。ただ2019年現在ではもっと下のレイヤーでマルチテナンシーのリソース制御が可能になったことで、あまり独自言語の必然性というのが感じられず、単なる参入障壁として働いてきているようにも捉えられます。

もちろん、Apexを用いない開発というのも可能です。Salesforceの外部のサーバであれば自由に言語は選択可能です。APISOAPであればApexより前からありますしREST APIももちろんあります。そしてそれらを利用するためのクライアントライブラリも数々のプログラミング言語で手に入ります。ただ、先に上げたパッケージングの仕組みの外になってしまうことにより配備が複雑になること、そして何よりそれらのコードを動かすサーバの利用費用がかかること -- Apexの場合はライセンス料にコミコミで請求されるので顧客にとってコストには見えない -- という点がApex以外の言語による開発が主流となるのを拒んできた要因なのではないかと思っています。

Evergreen FunctionはSalesforceパッケージのファーストクラス要素

今回、Evergreenの発表で特筆すべきは、それは開発したFunctionを「AppExchangeパッケージとして配布できる」という点です。このことは、EvergreenのFunctionがApexと同様のファーストクラスのSalesforceアプリケーションに利用されるカスタムロジックとなる、ということとして理解できます。つまり、Apexがただ一人受けていたパッケージによる自動コード配備の恩恵をEvergreen Functionも同様に受けられる、ということになります。

パッケージ開発者は、あらかじめ自身でサーバを用意しておく必要もなく、また顧客に合わせてコードをデプロイする必要もなく、ただ顧客がパッケージをインストールしたタイミングで自動的にコードを動作させる準備が整い、リクエストに応じて実行される。

これらのことがパッケージの利用ユーザにまったく意識されることなく達成されるのであれば、わざわざApexにせずとも従来言語で十分では?とみな考えてもおかしくはないはずです。

EvergreenはApexをリプレイスする?

実際にEvergreenを見て感じたのは、「これはSalesforceは確実にApexの後継に置きにきているな」というものです。 パッケージとしてメタデータとしてSalesforceに一発で配備できる、ファーストクラス要素としてのEvergreen Functionの扱いを見るに、そのことは間違いではないと考えます。

ただし、EvergreenがApexを置き換え可能だとしても、あくまでまだ一部に過ぎない、とは思います。 事実、現状ではEvergreenはHeroku Spaces が動く環境、つまりAWS内で実行されるものになっていますので、Salesforceのデータベースがあるデータセンターとのロケーションとはネットワーク的に隔たりがあり、Apexでできていたトランザクショナルな処理は向かない(orできない)可能性があります。 また、基本的にはPlatform Eventに代表されるような非同期での呼び出しが主で、同期的な更新には向いていないのではないかとも考えられます。 まだあまり情報が出ていないので本当のところの詳細は不明ですが、これらの点はちゃんと見守っていきたいところです。

しかしながら、もし上記のことが制約としてあったとしても、すべての企業がそのような処理を欲しているわけではないでしょう。 これらのことを別に考えなくても良い業務処理、つまりApexでなくてもよいビジネスロジックは確実に存在します。 今までApexに投資してきていた企業は、プラットフォームが持っていた箱庭によって守られてきていた部分もありましょう。 ある面、今日Apexの開発者が重宝されるのはなかなか市場で獲得できないからといったこともあるかと思います。 これらの状況がEvergreenによって覆る可能性は多くあります。 Salesforceのエコシステムへの新規参入が前よりは容易になるでしょうし、ただApexができるというだけで価値を持つと言ったこともそんなになくなるのではないかと思います。

費用負担がどうなるかが今後の焦点

Apexでは、マルチテナントにおけるリソース制御の解として、ガバナ制限という静的な制限をおいてコード実行をチェックしていました。このことは大きな制約であり、数々のApex開発者を悩ませてきたものでもあります。 現在コンテナベースの環境では(特に利用CPUやメモリ制限などの)リソース制限はもっと低レイヤーで達成可能なものがあり、さらに自在に伸縮可能となっています。 逆に言うと、Apexでは上限を厳しくおくことでライセンスにコミコミとできていた費用が、Evergreenではその実行費用をどこが負担するのか、といったところが不確かになってきます。

これらはあくまで個人的な予想でしかないのですが、AppExchangeのパッケージとして配布できることを想定する以上、Evergreenの実行にかかる費用を利用顧客側が負担する、というのは難しいのではないかと考えています。実行費用の負担が発生するのであればパッケージ開発者側(ISVパートナー)に負担が行くべきではないかと考えます。これは、例えばとんでもなくリソースを使いまくるコードを書いたらそれはそのコードを書いた人が責任を負うべき、という説明で納得できるかと思います。 この考え方をカスタム開発の場合においても適用すると、開発されたコードもその実行も同一Salesforce顧客のものになるので(コードの開発はSIベンダーが行うにしろ納入先は顧客のSalesforceになる)、Evergreenの実行に際し追加費用が発生すればそれはそのSalesforce顧客に対して請求されるものになるでしょう。

ただ、どちらにせよ、コードの実行に際して追加費用が発生する、というのはいままでSalesforceの世界ではあまりやっていなかったことです。Apexが制限以上の動作ができないという前提の元、Salesforce顧客はライセンス利用料金にコミコミで、ISVパートナーはレベニューシェアで、コード実行の利用にかかる負担をしてきました。可能であれば、EvergreenもHerokuの場合と同様にフリー枠を設けて、制限値以内はApexと同様にライセンス利用料金(あるいはレベニューシェア)の内で、制限値以上のリソースが必要な場合のみその組織に追加コストで、というのが妥当な落とし所ではないでしょうか。

まとめ

以上、Evergreenについてまだ発表から間もないため、かなりの部分が予想に偏っていますが、あながちおかしい予想でもないのではないかな、と考えています。 すくなくともエコシステムに与える影響は過小に見積もらないほうがいいと思っています。 ただしそれは顧客に対して良い方向に働くものであるのは間違いないので、そのエコシステム内の参加者は適宜柔軟に対応できるようにしていくのが正しい姿勢といえるでしょう。