0. 背景
サーバレスアーキテクチャという言葉を聞いたことがあった。
英語のサーバレス（Severless）という言葉から、サーバが存在しないと勝手に思ったが。
本当に？サーバが存在しないって、そんなのできる？という疑問もあったので、どういう意味が調べてみた。
1.サーバは存在する
サーバレスというのは、サーバのバックエンドが存在しないという意味ではない。
バックエンドは存在する。
しかし、直接サーバを管理する必要がないということ。
2.なぜサーバレスというものが生まれたか
仮に、ウェブアプリを開発していると想像してみる。
サーバが必要であれば、サーバを買うしかない、という時があった。
サーバ用のパソコンを買って、社内のどこか、家のどこかに置く。
そして、電源を入れて、動かせる。
もし、ウェブアプリに接続が急に増えて、サーバが耐える通信トラフィックを超えそうだったら？
早く、メモリを注文してサーバに追加しなければならない。
つまり、ハードウェアも、ソフトウェアも管理しないといけない。
その中で、AWSのEC２というサービスが現れ、サーバを借りて使用することができるようになった。
それにより、急なトラフィックの増加にも、簡単に対応できるようになった。
直接メモリを追加する必要なく、お金さえ払えば、AWSの方で容量など簡単に追加できるから。
この時点、サーバのハードウェアを直接管理するリスクは、ウェブアプリ開発側ではなく、AWSサービス提供会社が負うことになったはずだ。
しかし、サーバのソフトウェアを直接管理する際の責任は、まだウェブアプリ開発側が持っている。
サーバのセキュリティー、アップデート、バックアップなど。
サーバのソフトウェア管理も誰かに任せて、本当の仕事、アプリ開発に集中したいならどうしたらいいか？
3.バックエンドを小さい関数に分ける
バックエンドを小さい関数に分け、直接管理しないサーバにアップする。
例えば、AWSのLamda。
サーバレスではない場合、サーバは24時間リクエストに応答するため、待機している。
サーバレスの場合、アップロードした関数は、基本的に寝ている。リクエストがあった場合のみ、動作することになる。
4.メリット
リーズナブルな費用
サーバレスではない場合、リクエストがあっても、なくても、かかる費用は変わらない。
24時間リクエストに応答するため、待機しているから。
サーバレスの場合、リクエストがあって、関数が実行されたら、お金を払う。
もし急にユーザーが1000名増えたら？AWSは関数のコピーを作成して実行する。
ユーザーがいなくなったら？また寝る。
サーバの管理を気にせず、本質的な作業に集中できる
サーバのセキュリティー、アップデート、バックアップなどから開放できる。
本当に必要な作業、アプリ開発に集中できる。
5.デメリット・懸念
関数の開始までかかる時間
リクエストが来るまで、サーバの関数は寝ている。
リクエストが来たら、関数を起こして、実行する準備が必要。
大きな差はないかも知れないが、サーバが24時間待機していた時に比べると、より時間がかかるはずだ。
1msの遅れも許されない場合は、サーバレスはいい選択ではないかも知れない。
(よく使われる関数は、眠らせずに待機しておく設定があるかも？)
サーバ提供者に依存しすぎでは？
まず、アプリをサーバレスに相応しい仕組みに変更するか、最初からサーバレスを考慮して設計する必要がある。
また、サーバに対して直接コントロールできなくなる。
そして、もし他のクラウドサービスに引っ越し（マイグレーション）が必要になったら、簡単にできそうかどうかもわからない。