2017-07-21 にも書いたとおり Serverless Framework を試している。

ぼくは AWS で使用する気なので、ドキュメントを見ながら進めると、どうやら Administrator としての権限を要求している。

To let the Serverless Framework access your AWS account, we're going to create an IAM User with Admin access, which can configure the services in your AWS account. This IAM User will have its own set of AWS Access Keys.

Note: In a production environment, we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs (we're working on this). Consider using a separate AWS account in the interim, if you cannot get permission to your organization's primary AWS accounts.

https://serverless.com/framework/docs/providers/aws/guide/credentials/#creating-aws-access-keys

「そりゃないだろ」と最小の権限を模索してみたものの、書いてあるとおり厳しいと分かったので、諦めてアカウントを切った。

アカウントを作成する過程で知ったことだけど、いつのまにか AWS Organizations というサービスができている。以前から料金を別のアカウントに束ねることはできたが、いまはアカウントの作成までできるようになっているようだ。ふむ。

あとこれもいつからか分からないけど、 IAM のコンソールで古いアクセスキーやパスワードが注意されるようになっている。そもそも未使用の IAM user も居たので、この機会に削除した。

正直なところ、このように脱線してほとんど進んでいない。

一歩もどって、いまやろうとしていることやその状況をメモしておく。

ある小さなアプリケーションの移植をしようとしている。その実行環境として ECS か Lambda を考えている。ランニングコストの観点で Lambda が良いと思っているのだけど、一方で Lambda の際にどうつくっていくのかがあまり確立できていない。そこでフレームワークを見てみよう……といった次第だ。

いま試そうとしているのは次のとおりだ。

• Serverless Framework
• Apex
• AWS Serverless Application Model (SAM)

絞り込むどころか昨日より候補が増えている気もする。並びが妥当なのかよく分からない。ほしいのはフレームワークというか作り方の目安というか……。

まだ Serverless Framework しか見ていないのだけど、どれも共通しているのは設定ファイルをもとにインフラを整える形で、コマンドラインツールを提供していることだ。

SAM はパッケージ形式を定めたものっぽい。極端な話、 CloudFormation のテンプレートをアプリケーション向けに特化させて、書きやすくしただけな印象。 AWS CLI が食えるパッケージ形式だ。

これは直接的に競合するわけでもない。たとえば Serverless Framework には SAM の形式で〜というプラグインっぽいものもあるみたいだ。コマンド体系の合わないところがあるはずなので、そうする意味はよく分からないが……。

Apex はあくまで Lambda の操作に特化しているみたいだし、それ自体に golang を選択し NPM の依存を排しており、他の言語も使えることを前に出している。ただ、 Serverless Framework ほど気の利いた形にはしていなさそうだ。「気が利く」というのは往々にして「余計なことをする」を意味するものなので、難しいところだ。

いろいろ組み合わせて実現するくらいなら……という気持ちもあるので、いまのところ SAM に従いつつのオレオレでいいかなという気持ちだ。