ご来場くださった方々、どうもありがとうございました。パネル内で話せなかったことやあとがきをまとめてみました。
ツールの補足
さきほどのパネルディスカッションで紹介したCloudWatch logsを見るツールは https://t.co/1ZmrgWfbYJ Kinesis Streamを雑にtailするツールは https://t.co/YAzsMZEQvj です #awssummit
— suzuken (@suzu_v) June 2, 2016
銀の弾丸はない
AWS Lambda、個人的には「簡単に立ち上がって隔離されたアプリケーション実行環境」としてつかってます。EC2でもECSでもできることがやれればいい。サービスつくる上で必要なものが動けばいいし、そのために試しやすい環境がすぐできるのはうれしい、というスタンスでつかってます。
— suzuken (@suzu_v) June 2, 2016
なので、これからLambdaで動いてるところを要件によってはEC2に移す、ということもするかもしれない。でもそれはよくて、初速をLambdaであげて実際に現場で動くものをつくれてリリースもできているのでよい。開発よりも運用の比重があがってきたときにどうなるか、あたりも大事。
— suzuken (@suzu_v) June 2, 2016
アプリケーションエンジニアとしてはすぐに本番のリソースと結び付けられて独立した実行環境が得られるのはメリットは大きい。ただし落ちづらいコード、スループットの出づらい実装になっていると使えないものに。そこはアプリケーションエンジニアとして責任をもつ必要がある。
— suzuken (@suzu_v) June 2, 2016
サーバーレス、という文脈で言うとLambdaみたいなものはとても便利に見えるだろうし、実際できることできないことははっきりしている。運用という観点から言うと、チームとしてインフラとアプリというもののスタンスを変えなければならないところもあるかもしれない。
— suzuken (@suzu_v) June 2, 2016
サービスをチームとしてサーブしている以上、そしてLambdaのようなものによって運用フェーズと開発フェーズが近くなる以上、そこで何を重要視するか？というのはチームによって違うと思う。たしかに検証はしやすいし、本番に近い状態でテストもできるのはメリットも大きい。
— suzuken (@suzu_v) June 2, 2016
とはいえ、じゃあ本当にこれはちゃんとサービスを動かし続けられるのか？というのをアプリケーションエンジニアがちゃんと動作モデルやエラーのケースまでケアしてコードを書く必要がある。普段からこれをやっているチームはすんなり運用までいけるかもしれないけど、そうじゃないと検証だけになるかも
— suzuken (@suzu_v) June 2, 2016
そういう文脈があるので、サーバーレス = デプロイが簡単ですぐ環境を得られる、ということだけではなくてチームとしてこういう領域を扱えるようにしていくというのをセットにしていかないとうまくいかないんじゃないかな、とも思う。だから使うだけで急に何かがよくなるわけではない。
— suzuken (@suzu_v) June 2, 2016
おわりに
パネルディスカッションの機会をつくっていただいたAWSのみなさま、モデレータの西谷さん、パネリストの木田さん、どうもありがとうございました。
追記 2016/06/15 12:50
セッションの動画が公開されました。
