どうも、セクションナインの吉田真吾（@yoshidashingo）です。

今年5月にNY、ブルックリンで開催されたServerlessConf NYCから約2ヶ月。2箇所目として「東京」が9/30&10/1、3箇所目として「ロンドン」が10/26-28に開催されることが発表され、サーバーレスの勢いはますます増しています。

東京開催についてセクションナインが担当することになりましたが、NYCで話したスピーカーやスポンサーも決まっており、もう少ししたら詳細の発表やチケット販売を開始できるようになると思います。お待たせしてすいません。

Serverlessとは？

サーバーレスはクラウドコンピューティングの「使った分だけ」という原則についてもっとも近い考え方です。

特にここにきて注目されている要因は2つあり、(1)クラウドプラットフォーム側がリクエスト単位に実行環境を準備できるようになった(後述：関連するパラダイムシフト)という話と、(2)ユーザーが、クラウドの特徴を活用する前提でアプリと統合されたアーキテクチャをはじめから考えるようになってきたことでServerlessifyしやすくなってきたという認識です。

martinfowlerブログ（執筆者はMike Roberts氏）に記載されているように活用形態として代表的なのが「UIドリブンアプリケーションのバックエンド」と「メッセージドリブンアプリケーション」というのが現在の共通認識ですが、今後はプラットフォーム側の提供するソリューションの拡大や、ユーザー側の使い方によってもう少し対象範囲が広くなっていくかもなと思っています。

martinfowler.com

あと、元A Cloud GuruのAntのスライドも、マネージドなSaaSからサーバーレスなサービスまで広く整理するにおいて非常に分かりやすいです。

http://www.slideshare.net/acloudguru/ant-stanley-being-serverlesswww.slideshare.net

活用シーンの例

代表的なものとして以下のような物が考えられます。自分の組織で管理するもよし、SaaSも活用するもよしです。

APIサービスとして単機能をAPI Gateway+Lambdaで実装する。認証/認可を行い属性やステータスを管理するDBサービスなど。
シングルページアプリケーションのバックエンドをAPI Gateway+Lambdaで機能実装する。あるいは静的ページであれば(HugoやStaticPress)S3に配置し必要に応じてCloudFrontやACMを設定して配信する。
iOSアプリやAndroidアプリのバックエンドをAPI Gateway+Lambdaで機能実装する。
ログが格納されたらイベントドリブンで解析して、結果をどこかに永続化して、またイベントを発火して終わる。
などなど...

Serverlessはベンダーロックインか？

理想から言うとむしろアプリのポータビリティが上がるので逆ですね。コードを持ち込むだけだったり（FaaS利用）、インタフェースが標準化されたり（REST APIベース）、あらゆるプラットフォームにデプロイできたりその定義を再利用できたり（フレームワーク）という方向に向かっているので、将来的な心配はしなくていいのではないかと思います。

そもそもベンダーロックインが「悪」だとされるのは「ライセンスを資産として買い切りさせられるために減価償却の5年間は乗り換えられない」「仕様がブラックボックスなのに、バグっぽい挙動を問い合わせるためには細かい情報を自分で収集して提供しないといけない（ベンダーとユーザーの情報の非対称性）」などを指して言われることが多いと思うので、ここらへんがクリアになるようにプラットフォームを選定しておけば問題ないと思います。

FaaSやAPI以外へのサーバーレスの拡大の可能性

現状のFaaSは単一コアでの一定時間/メモリ量でのコード実行に限られており、Hadoopのような並列分散処理のようなことを簡単には実現できない（S3に上げたデータをLambdaで切り分けてDynamoDBに入れてから各データを並列実行とか実装するだけでだいぶしんどいしディスクやネットワークのIOを最適化できない）です。プラットフォームの中身を気にしなくてもそういった処理が現実的な処理時間やコストで実現可能になる可能性はあると思います。

エラー処理の作りやすさや、複雑なワークフローのジョブネットを簡単に構築できたりというあたりも今後より重要視されてくるかもしれません。

運用のResponsibility、NoOps

通常Opsはカスタマーに提供するサービスレベルを設計し、十分担保できる技術を採用したりサービスを採用したりしますが、いわゆる世に出回っている便利なSaaSにはこのサービスレベル設計において必要な情報（SLA、SLO、内部仕様の公開、トラブルシュートのためのドキュメント、などなど）が足りてない傾向にあることはたしかです。お金を払ってサービスを利用しているからといってそれを用いてカスタマーに提供しているサービスの最終責任者が自分であることには変わりません。そのSaaSがSPoFにならないか、トラブった場合にどう影響範囲を切り離したり別のサービスに切り替えたり、あるいは縮退運転するか、などは自分で考える必要があります。

そういったもろもろをPodcastで語ってみました

cloudinfra.audio

ServerlessConfはどんなイベントか

ベンダーニュートラリティ

今後のサーバーレスの広がりを考えると、特定のベンダーだけが得意な分野ではなくなっていくものと推定されます。なぜなら、UIドリブンアプリケーションやイベントドリブンアプリケーションという、Webシステムの文脈だけでなく、たとえば大規模分散コンピューティング環境や、IoT、音声認識やテキスト分析、深層学習といった分野でもServerlessでアプリ利用する瞬間だけ実行環境が用意されるというモデルに近づくことが予想されているからです。

ということで、当初からそういった文脈をすべてオープンに受け入れて会話できる新しいコミュニティが必要だなと認識しており、いい機会だったので日本市場でのServerlessConfの実施のライセンスをしてもらったのが発端です。

やっていく気持ち

ということで、サーバーレスは「ユーザーがポータビリティの高いコードやインタフェース定義を作ることに専念し、自分の要件に合ったプラットフォームを選別して(あるいは適切なプラットフォームがなければそれは自分で作るかもしれないが)、その知見を共有しあいながら議論を高めていける」極めてフェアなプラットフォームの利用形態ではないかと考えています。

よってこのコミュニティに現在大事なのは、どのようにしてポータビリティの高いアプリを作り、プラットフォームやツールを選別しているかといった知見を自分自身で体験して共有するということであり、自分がその議論を先導するための「やっていく気持ち」をもって取り組むことだと思います。

スピーカーとスポンサーを募集しています

ということでServerlessConf Tokyoではスピーカーとスポンサーを募集しています。どちらもサイトから必要事項を添えてメールでご応募ください。

tokyo.serverlessconf.io

スピーカー

上記で述べたようにさまざまな文脈が入り混じって混沌としているのが現在のサーバーレスです。自分はこの分野においてサーバーレスとの関係をこう考えている、などの意見を積極的に発表していくことが、日本におけるサーバーレスの文脈の深化につながっていきます。

以下のような文脈を想定しており、すでにかなりの応募をいただいています。第1弾としては8/8(月)くらいまでには選定したいと思っています。

サーバーレスな環境を提供するプラットフォームの話
サーバーレスを便利に利用するフレームワークの話
サーバーレスを使った開発の話
サーバーレスを使ったOpsの話

スポンサー

ServerlessConfはサーバーレスの活用を推進するたくさんのエンジニアによって構成され、参加者の幅はフロントでJSをコーディングしている人からインフラを作っているエンジニアまで多岐に広がっています。このリージョナルイベントをスポンサーシップとして応援してください。また、今後Meetup系の小規模イベントを合同企画させていただくことも可能になると思います。興味があればぜひお問合せを。