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

ロウアーマンハッタンのあたりを走ってみました。たくさんのランナーがいて、ニューヨーカーはホントに健康意識が高いんだなと感じました。ブロックごとにジムもあり、シェイプを期にしている人も多いんですね。実際西海岸に比べてスタイルのいい人も多かった印象でした。

そういえば今回は宿をAirbnbでホストの家の一部屋を借りたのですが、ランニングのおすすめルートを聞いたり、飼っている犬になつかれたり、とホテルよりも居心地が良かったです。移動の足もすべてUberでしたし、こちらのユニコーンは本当に使われている（というか使わない場合の不利益との差がはっきりとしている）んだなと感じました。

ServerlessConf Day2 report

Old Programmers Can Learn New Tricks

• Dr. Donald Ferguson - SparqTV

• API GatewayとLambdaを用いたAPIにおけるバージョン管理の話や、ハイレベルなアプリケーション・アーキテクチャの話
• AngularJSなどで構築するフロントから、Integration Composition Servicesというリクエスト/レスポンスを統合管理する層を通じて、ユーザー情報（認証/認可/ユーザーマスター）やコンテンツマネジメント、ソーシャルメディアなどそれぞれ独立したマイクロサービスに対してAPIアクセスを行うアーキテクチャを説明
• インタフェースや実装のモデルについて
  • インタフェースはREST、リクエスト/レスポンスはJSONで
  • Lambda Functionに引数を渡すことで複数の処理にディスパッチする層がある
  • Eclipse SDKやLambdaテストUIを用いてゲートウェイなどを介さずに直接テスト実行できるようにするためにこうした
  • このモデルであればSQSやXMPPといったバインディングにも対応できるし、1つのゲートウェイで複数のリソースやHTTPメソッドに対応することができる
• その他
  • ウェブアプリケーションの設計方法には「データモデル→コード→API化」「API設計→コード→データモデル」の2種類あるが、われわれはデータモデルからはじめた。結果的には最後までこれで泣かされた。すべてのステージでタイプスペースとフォーマットのマッピングを行ったり、エラーが発生したりする状況だった。
  • いくつかの理由でJavaを選んだ
    • COBOLがサポートされていない
    • いくつかの再利用できるコードがあった
    • 年寄りなのでサーバーサイドのJavaScriptが怖すぎた
  • 設定やプロパティ管理は難しい
    • どこにどう格納して扱うようにするか、むしろみんなに聞きたい
    • 自分たちはさまざまな理由でいくつか別々の方法で管理している
  • ソフトウェア設定管理
    • すべて一つの方法で管理することができない
    • S3に格納してるものや、Lambda FunctionだったりSQLスクリプト、アプリを統合するマッピング定義とか
• 要望
  • サンプルやパターンが少ないのでありとあらゆるミスをしてしまった
  • グラフデータベース
  • チャットでメッセージをコントロールに使える「サービス」
  • Functionを生成するうえでの抽象化された状態で使えるDSL

How Firebase helps developers create extraordinary experiences

• Mike MacDonald - Firebase / Google & Frank van Puffelen - Firebase / Google

• Firebaseはシンプルなアイデアからうまれた
• Firebaseはプラットフォームとして成長してきた
  • リアルタイムデータベース
  • 認証
  • ホスティング
• Googleのサービスにおける *aaS
  • Software as a Service: Apps
  • Backend as a Service: Firebase
  • Platform as a Service: App Engine
  • Infrastracture as a Service: Compute Engine
• 画像をアップロードしてそれをGCVで解析するデモが行われた

Event-driven and Serverless Programming with OpenWhisk

• Michael Behrendt - IBM & Dr. Andreas Nauerz - IBM

• 動機とゴールへのアプローチ方法
  • 初期のサーバーレスやイベントドリブンに関する研究
  • ビジネスユーザーと開発者、両方に嬉しいことができそう
  • IBM Research(プログラミングモデルグループ)と製品開発部隊で一緒に開発を始めた
• OpenWhiskとはなにか
  • オープンソースとして、あるいはIBM BlueMix上に展開した状態で提供される
  • 設計上の原則
    • イベント発生元に対して開放されたインタフェース
    • 多言語(Polyglot)のサポート
    • 高級プログラミング構造のサポート（たとえばシーケンス制御）
    • リクエスト単位にスケールすること
    • アクションとイベントプロバイダーを共有できるようにする
  • 環境構築について
    • NodeからはじまりScalaにスイッチした
    • DockerやKafka,consul,Akkaなどに対応していった
• OpenWhiskはBlueMix上のコンピュートモデルの一つの選択肢
  • VM(OpenStack)やIBM Containers(Docker)やInstant Runtimes(CloudFoundry)と使い分けることができる
• OpenWhiskのプログラムモデル
  • 「トリガ」を受けたら「ルール」にもとづき「アクション」を実行する
  • アクションはチェイン(これをやったらこれをやって、と順番に実行)することができる
  • フィードからトリガーが上がったり、REST APIでアクションを呼び出すことができる
  • 実行環境はDockerベース
• デモを披露

Alexa-Enabled Apps- Building Voice Experiences for Your Applications

• Noelle LaCharite - Amazon Alexa

• Amazon Echoはすでにもっともよく知られたAlexaエコシステムのエンドポイント、これに最近「Fire TV」もくわわった
• 日々のアクションを声を使って簡単に実現できるようになる
• サービス構成
  • Amazon alexa (クラウド上で提供されるサービス)
    • Automated Speech Recognition (ASR)
      • 自動会話識別
    • Natural Language Understanding (NLU)
      • 自然言語理解
    • そしてつねにこれらは学習を繰り返している
  • Alexa Skills Kit (ASK)
    • ユーザーはここでグレートなコンテンツを作ることができる
  • Alexa Voice Service (AVS)
    • AVSに対応しているechoやFireTVがあればコンテンツをどこにでも届けることが可能
• alexaのプラットフォームはすべてAWSに載っている
  • AVSとのインタフェースのエンドポイント、ASR、NLU、TTS(Text-To-Speach)、自己学習
  • ユーザーのAlexa Skills
• 参考資料
  • Building a How-to Skill: bit.ly/howtoskill
  • How to Build a Fact Skill: bit.ly/factskill
  • How to Build a Trivia Skill: bit.ly/alexatrivia

Serverless Patterns with Azure Functions

• Chris Anderson - Microsoft & Yochay Kiriaty - Microsoft

• Serverlessは現在、PaaSの頂点である
• Function実行フレームワークはserverlessではない
• Azure Functionsの紹介
  • クラウドアプリが簡単につくれる
  • C#, Node.js, Python, PHP, Batchなどなどのファンクションが開発可能
  • サービス間をイベントドリブンにつなぐことができる
  • ファンクションはHTTP APIとしてたたけるエンドポイントを持つ
  • Logic Apps と簡単に統合できる

• デモ
  • アップロードした画像のサムネイル生成

Open Community; Building Welcoming Projects

• Ryan Brown - Ansible/Serverless Code

• ここから以降の時間は、いろんなツールの作者が話すセッションを集めた
• まず、ツールの作者はこういうのをあらかじめ用意しておくといいよ
  • Issueを挙げるときのテンプレート
  • README.md
  • COMTRIBUTING.md
• コミュニティとして活動したり互いに貢献しよう
  • 単純に使ってフィードバックするというのでも貢献はできる
• ダイバーシティが大事

The Lifecycle of Composable Serverless Apps

• Eric Windisch - IOPipe

• Apacheライセンス2.0で提供してるOSSのツール
• ファンクションをチェーン実行できる
• AWS以外でも実行できる
• NodeJSモジュールとして提供 (その他Goライブラリをエクスペリメンタルで提供してる)
• CLIツールもある
• Lambdaと互換性がある

A Toolbuilders View of Serverless

• Mitch Garnaat - Amazon Web Services

• われわれはツールが好きで、不満があるとインテリジェンスを発揮してツールを作ることになる
• たとえばYeobot
  • Slackのbot
  • すべてのAWSのリソースを把握している（複数アカウントとか、リソースの依存性の状況なども）
  • ためしにリソースについて尋ねるといい。答えてくれるはずだ
• Yeobotのインデクシングがどうおこなわれるか
  • 指定のリージョンやアカウントのリソースの情報がKinesisストリームに格納される
  • KinesisストリームがLambdaファンクションを呼び出し、結果をDynamoDBに書き込む
  • DynamoDBテーブルトリガを使ってElasticsearchにインデクシングしたり、別のDynamoDBに格納する
• Yeobotのクエリ方法
  • コンテナ化されたインスタンスがSlackからSNSに飛んでくるイベントをwebsocketで監視
  • Lambdaファンクションがこれは動作すべき関連性があるか判断し、関係があれば別のLambdaファンクションへ処理をディスパッチする
  • 呼ばれたLambdaファンクションは処理を行ったら結果をSNSトピックに書き込む
  • SNSイベントトリガで呼ばれるLambdaファンクションがSlackにレスポンスを投げる
• kappa
  • kappaはpython製のMVT機能を提供するツール
  • YAMLファイルにすべての情報を書いておく
  • CLIツールが基本的なCRUD操作を提供している
  • 変更部分だけアップデートされる（冪等）
• Yeobotの論理構成
  • インデクシングするパイプライン部分
    • 5つのLambdaファンクション
    • 3つのDynamoDBテーブル
    • 1つのKinesisストリーム
  • Slackbot部分
    • コンテナ化されたインスタンス
    • 20以上のLambdaファンクション
    • 5つのDynamoDBテーブル
    • 2つのSNSトピック
• ハイレベルな抽象化が必要なわけ
  • IAMポリシー
    • 難しい
    • 依存性などを深く理解して使わないとうまく使えない
  • DynamoDBテーブル
    • ArcaneなDDL
    • スキーマの定義とスループットのような設定値がDDLの中にごちゃ混ぜ
  • Cruddy
    • DynamoDBに対する単純なCRUDラッパー
    • Lambdaからも使えるし、Lambdaじゃなくても使える
    • ユーザーは"prototype"オブジェクトを保存すればよい
• テスト
  • ユニットテスト
    • AWSのAPIコールに対するモック応答
      • レコード/プレイバック方式のplacebo ※他にもあるけど
    • Syntheticなレスポンス
      • 難しそうだけど頑張ればできそう
  • 結合テスト
    • ローカルではなくクラウドで
• その他
  • リソースのアイソレーション
    • 複数のアカウントを使い分けているか？
    • ステージ分割やエイリアスなどを使って環境を扱っているか
  • イベントソース
    • イベントベースのプログラミングなわけで、イベントのオブジェクトが最も大事と位置づけなければいけない
  • ロギング/モニタリング
    • アプリケーションレベルでやらないといけない

Cloud Custodian - Resource Management Rules Engine

• Kapil Thangavelu - Capital One

• Capital OneがリリースしたOSSツール
• インフラ管理のルールエンジン
• YAMLでDSLを記述する
• Lambdaやその他のイベントソースを統合して利用する
• ロードマップ
  • Elasticsearch
  • Flourish ?? ※まだわからないけど
  • 複数言語をたまがるサポート

The Next Serverless Framework

• Austen Collins - Serverless, Inc.

• スタートアップやリーンエンタープライズの世界ではあっという間にマーケットが変わっていく
• Lambdaはコンピュートサービスの夜明け
• 全部lambdaで作ろうぜー
• Serverless Frameworkについて
  • 2015年7月〜 JAWSという名前ではじまった
  • 口コミで一気に広がった
  • ファンドからお金もらった
  • 2015年10〜11月 Serverless Frameworkって名前に変えた
  • Fortune 500 のエンタープライズでも使われている
  • 6人チーム
  • 0.5だけどそろそろ1.0にしようかと思う
• チャレンジ
  • LambdaというかFaaSはマイクロサービス型のプラットフォームなので、従来のマイクロサービスが持つ課題はここでも課題になってくる
  • 複雑性
    • トラディショナルなマイクロサービスよりも多くのサービス数による構成
    • たくさんのファンクション、リソース、ステージ、リージョン、成長するチーム、プロジェクト
    • たくさんの設定やスキャフォールドや依存性
  • ベストプラクティス
    • コードをコンテナ化する
  • コラボレーション
    • サービスチーム間の自律的なコラボレーション
  • DRY
    • ジョブに集中したコードは単一性が高いので再利用製が高い
• 新しい哲学
  • V.1にするにあたり買えなければいけないのは我々の哲学だ
  • すべてはサービスになる
  • プロジェクトやアプリケーションのコンセプトはサービスの独立性を破壊することが開発者の経験上わかっている
  • サービス単位が最上位の組織ユニットになる
  • Serverlessなサービス
    • SOAみたい
    • 組織もサービスと同じ形にすれば独立性が保たれる
    • 1つ以上の関連ファンクションというのはある（ワークフローのような）
    • CFnのように1つのリソーススタックとして扱うというのも手
• Serverlessなサービス 対 複雑性
  • 最小限の設定
    • 設定ファイルのエレガントさがフレームワークのビジネスのキモだ
    • 1つの設定ファイルだけで管理できないといけない
    • serverless.yml
  • 最小限のスキャフォールド
    • 1フォルダ
  • コンセプトは明確
  • よりよく安全なデプロイ方法
• Serverlessなサービス 対 フレキシビリティ
  • コードのパターン
    • ナノサービス
    • マイクロサービス
    • ニューモノリシック(グラフAPI)
    • それらのミックス
  • 多くの人が言語のベストプラクティスにならったコードをコンテナ化するが、パフォーマンスの最適化やデバッグも自分たちでやっている
  • Serverlessなサービスはコードを隠蔽するが、開発者にとってはコンテナのほうが自由に扱いやすい

パネルおよびラップアップ

• 以下のメンバーによるサーバーレスに関するパネル
  • Austen Collins, Eric Windisch, Leo Anthias, Gen Ashley, Chris Gaun, and Ashley Williams
• ラップアップ
  • A Cloud Guruのメンバーが一気に形にしたこのイベント。今後もっとコミュニティとして盛り上げて行こうね、という文脈で、（休み時間に主催者と立ち話をして日本開催は決めていたので）、日本でもさっそく開催することになったよという告知とともに、自分のことを紹介してもらいました。

ServerlessConf 日本開催

ということで日本開催、「開催する」ということだけは決まりました。いろいろ調整して、出来る限り早い時期に開催をしたいなと思っています。アップデートがあればここかツイッターかFacebookあたりで告知することになるかな、と思います。