Salesforce Evergreen に夢を見る
今年も技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか？
先日 Dreamforce が開催され、まだ時差ぼけが治っていない方も多いかもしれませんが、クリスマスまで25日ですので、今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しましょう！
この記事は Salesforce Platform Advent Calendar 2019 - Qiita 第1日目の投稿です。
はじめに
今年は Dreamforce では Developer 向けに大きな発表がありました。
そうです。
Salesforce Evergreen です。
Salesforce Evergreen とは？
Salesforce Developer Blog の記事によると Customer 360 Platform の新しい機能です。また、Salesforce Evergreen はフルマネージドな Kubernetes 上に構築されたサーバレス機能（Functions-as-a-Service）、一般的に利用される高性能なデータストア（マネージドデータストア）を提供します。
Salesforce Evergreen で何が変わるのか？
Salesforce プラットフォームでは苦手としていたことについて、解消されることが期待されます。その苦手なこととは下記のようなものです。
1. 重い処理を実行すること
2. 複雑なアーキテクチャを実装すること
3. 既存資産を活用すること
重い処理を実行する
Salesforce Evergreen では Function-as-a-Service によって機能を実装することができます。Saleasforce プラットフォームではマルチテナントを実現するためにサーバー処理能力を占有するような重い処理を実行することが苦手でした。
Salesforce Developer の多くを苦しめているガバナ制約などの制限となります。Salesforce プラットフォームでも重い処理は非同期的に実行することで回避できることもありますが、それでも重い処理は Heroku や Amazon EC2 などの外部サービスにオフロードしていました。
今回発表された Salesforce Evergreen では、上記のようにして回避していた課題を Function-as-a-Service として実装することでよりシームレスに開発できるようになります。
Low Code で Salesforce 製品の機能を自社にフィッティングするだけであれば、既存の Apex を利用して Salesforce プラットフォームに実装しても大きな問題はありません。
しかし、AppExchange に登録されているような業務システム製品では勤怠計算処理、会計集計処理など計算量が多い機能がありますが、Salesforce プラットフォームの制約のため機能の一部を妥協していることもあります。
Salesforce Evergreen を利用することでより複雑・高負荷な機能を実装できるようになり、より優れた機能を提供できるようになることが期待できます。
複雑なアーキテクチャを実装する
Salesforce プラットフォームはすべてのプログラムを一つのものとして管理してしまいます。Salesforce DX CLI を使ったり、第2世代管理パッケージを利用したりすることで分割して管理できるようになってきていますが、Microservices まで分解して管理することはできませんでした。
Salesforce Evergreen を利用することで機能を独立的に管理できるようになります。これによって開発するチームの責任分担もやりやすくなります。また、アーキテクチャも自由に設計できるようになるため、複雑な問題に対処するためにリッチなクラス構造を整えることができます。
加えて、Apex ではできなかったローカル開発が可能になり、ローカル環境で実行できる自動テストを実行できるようになります。Apex テストではテスト実行に時間がかかってしまっていた処理も継続的インテグレーション環境を構築し、並行実行することで時間短縮も可能になります。自動テスト環境は開発者にとっての基本的人権とも言えるところなので、この部分が大きく改善することは大きな意味があります。
既存資産を活用する
Salesforce プラットフォームでは開発言語が Apex に制限されるため、Javaなどで開発した既存資産は利用できませんでした。Salesforce プラットフォームに業務システムを寄せようとした場合、必要な業務システムは Salesforce プラットフォーム上にすべて再構築する必要がありました。
Salesforce Evergreen を利用すると JavaScript / Java のソースコードを実行できるため、既存資産にあるビジネスロジックを流用することができます。
それ以上に既存資産として有効活用できるものとして、インターネット上に多く公開されているライブラリやフレームワークです。Salesforce プラットフォームではライブラリを一元管理する仕組みがなく、個別に再実装したり、ソースコードをコピーして利用していました。
パッケージ管理ツールで利用しているパッケージをインポートして利用できるようになれば、余計なソースコードの管理が削減できることは開発生産性にも効果的です。
Apex は生き残るのか？
さて、皆さん気になっていることではないでしょうか？
Evergreen の登場によって、Apex がオワコンになる可能性が高まってきますが、将来的には必要なくなってしまうのでしょうか？
私の答えは「なくならない」です。
なぜか？
それは、Microservices が通常の開発ではオーバースペックだからです。ちょっとインテグレーションしたい場合にそこまでやってしまうと構築コストが跳ね上がってしまいます。"No Code" では実現しきれなかった処理で、"Low Code" で実現するスクリプト言語としてはなくならないと思います。
では、その構築コストに見合う開発を行なっている人たちは誰か？
SIer の一部もそれに見合う人たちもいると思いますが、一番活用するのは AppExchange にプロダクトを公開している ISV/OEM パートナーです。彼らは Salesforce プラットフォーム上に巨大な業務システムを構築しています。一枚岩のシステムは巨大になると管理コストが負担になってきたり、複数の開発チームで分担しにくくなってきます。
それらの問題を解決するための手段として、Microservices が発明され、大きなプロダクトを持つ企業を中心に広まってきています。そういった意味では、Salesforce Evergreen は ISV/OEM パートナーに向けた機能追加と言えるかもしれません。
しかし、ISV/OEM パートナーもすでに Apex で記述した大量の既存資産を抱えているため、Salesforce Evergreen に容易にはトランスフォームできません。このトランスフォームをうまく成し遂げた、または新たに参入して Salesforce Evergreen を使いこなした企業が大きく成長するのかもしれません。
おわりに
Dreamforce で Salesforce Evergreen が発表されたことを受けて、どういった影響がありそうか考えてみました。ISV/OEM パートナーとして開発しているものとしては新しい挑戦ができる楽しみ、と、やらなければ生き残れないのでは？という焦燥感を抱きました。
2020年2月には Developer Preview として実際に触れる環境が提供され始めます。まだまだこれから情報が増えていく段階ではあるので、楽しみにして待ちたいと思います。
最後に、アドベントカレンダーで Salesforce Evergreen について何かを書こうと思っていた矢先に、stomita (id:shinichitomita) さんによるガチ分析なブログが公開されました。非常に鋭く面白い内容ですので、ぜひそちらもどうぞ。
Enjoy Advent Calendar!
