AWSポエム

AWSのAPI GatewayとLambdaを組み合わせたツールを考えてモヤモヤしている。

これから先マネージドのサービスがどんどん出てくると思うし、そうなった時に今までみたいな1アプリケーションのサービスは勿論だが、API Gatewayのような小さな機能単位でサービス化されるマイクロサービスの様な物が増えて行くと感じている。

で、いざそうなった時に各種マイクロサービスを利用して連携しているとベンダーロックインが酷くなるという問題があると思う。開発環境がローカルの場合、そもそもそのサービスの様に振る舞いを肩代わりしてくれる様な物が乏しいし、じゃあいざそうなって別サービスに移行(部分的でも)しましょうとなった時にベンダーロックインが足枷となり気付いたら何も出来ないみたいな状況になる事は避けたいと思っている。

と言うわけで、その辺も考えた上でAPI GatewayとLambdaの連携方法を考えている。

そもそもAWS自体がその辺2つの連携は前提としている雰囲気が漂っているので、わざわざ作らずともその様な雰囲気を買ったツールは出てくると思う。観測範囲内だとjaws-stack/JAWSとかr7kamura/fluctがそういう流れを汲んでいるのかなと感じる。fluctは本当に今言った2つのサービススタックを活用した感じだし、JAWSはもうちょっと広い範囲でAWSというプラットフォームに依存した、しかしフルマネージドなサービスのコンポーネントを全力で活用するようなシステムを実装して行く感じに思える。現状はまだAPI Gatewayには対応していないっぽいが、そうなるのも時間の問題な気がする。で、この辺はやはりフルマネージドなサービスをどんどん展開しているプラットフォームじゃないと厳しいというのがあるので、AWSで実現しようというのは正しい流れなきがする。

この方向性は間違っているとも思っていないし、これ自体はとても良いと思うのだが、ベンダーロックインの問題は依然残っていて、AWSスタックの中で完結しているならそれはそれで良いのではと思える一方で、ベンダーロックインされているプロダクトはあまり健全ではないのではという気持ちにもなる。

この辺を解消すべく、一先ずはローカルでもAWSスタックでも動作するアプリと言うのを考えている。具体的に言うとまずはexpressフレームワーク(?)を使ったシンプルなアプリケーションでrequireのパスを書き換えただけでAWS上で動作できるようなものを考えている。特にこれ以上の事は考えていなくて、requireを書き換えて動作させたらデプロイされるのかみたいな細かいところまではまだ考えていない。完全に構想段階なのだが、ゆくゆくはAWSスタック以外でも動作ができるような構造と言うのを念頭に置きたいと考えている。ただ、あまり深くは考えていないのでそれを吐露するためにこのポエムを書いた。ベロベロに酔っているので支離滅裂でも許して欲しい。

あとherokuはあまり流行ってはいないけどその辺も結構考えられているのではないかと感じる今日この頃。

広告


コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中