GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。

#必要性
よく言われることだが、コードは書いた分だけバグの可能性が上がるので、極力実績のあるOSS、数多のクラウドベンダーによって提供されるIaaS、PaaS、SaaSを使用して自前のコーディングを最小限にとどめたい。また、車輪の再発明もしたくない。その方針で設計、プロトタイピングをしているが、
今のところ、MicroserviceをRESTまたは、メッセージングで繋いでいく方向で検討中。

拡張性、メンテナンス性やモバイルやアプリ（MBaaS）のこと等も考えると、どうしてもGatewayが必要になってくると思う。
認証を一手に引き受けてくれるところも嬉しい。
以前のプロジェクト（よくあるちゃぶ台返しをくらって実現できなかったが）では

Kong

あたりをGKEで展開すればと考えていたが
Amazon API Gatewayを使ったことがなかったので、チーム全員で使ってみながら考えてみた。

とりあえず使ってみる

とりあえずブリッジ的なAPIを作ってみる。
色々確認、モニタリングしながら使ってみたいので、ブリッジ先はmockbin。
モックAPIをGUIで作成して、モニタリングできる。
以前、ブリッジwebサービスを作ったときに使いました。
久々に使ったけどこれ便利だなぁ。

create API

こちらの Amazon API Gatewayから

リソース、メソッドの作成。

なかなか直感的。この図だけで説明がいらない。
直感的かどうかは、個人的にかなり重要視するポイントです。

「メソッドリクエスト」のパラメータセクション。
とりあえずfooというパラメータを定義してみる。
（キャッシュや、パラメータをバインドする必要があるときに使います。）

「統合リクエスト」のパラメータセクション。
上で定義したfooが定義されているので、それをbarに変えてみる。

Gatewayにfoo=abcでリクエストすると、mockbinにはbar=abcでリクエストされる。

あとはDeployのみ。以上。

#所感
直感的で、使いやすい。
ただし、認証がかなり直感的ではない。幾つかあり、我々はIAM（ Identity and Access Management ）認証を使っていくのだが、、、、後々書きます。
認証部分はメンテナンスしていく上でわりと使用頻度が高いので、より直感的に簡単にしたい。（もちろん強固に）

もっと直感的なGatewayないかなと思っていたところ、Googleの営業の方より、Apigeeを教えてもらう。
これぞ求めていたものかも。。。
~~いじっているので、感想は後ほどシェアします。~~
シェアはこちらです。
それでは。