Serverless
Serverを持たないbackend
Serverlessは、eventが発生した時に初めて起動する
起動して、関数を実行して、終了する、という感じ
そのため、statefulな処理には向いていないっぽいmrsekut.icon
やりようはあるんだろうけど
requestがない期間は費用が発生しない
最小限の費用になる
serverを常時稼働しているときよりずっと安い
serverの管理や運用が不要
例
参考
コスト観点
稼働した時間だけ課金
設計・計画フェーズの工数短縮
バージョン管理の作業の最小化
デメリット
何に向いているか
いつ処理が必要になるかわからないが、1回の処理が短時間で終わるもの
管理の大部分をAWS側に任せられる
OSやミドルウェアのメンテが不要
ミドルウェアはLAMPのA,M,Pらへんのこと
OSや言語のversionを上げる時に、サービス停止する必要がない
必要なCPUとメモリを設定するだけでいい
サーバーへの攻撃を避けられる
サーバーのリソースを意識しない
柔軟なスケーラビリティ
事前に必要なキャパシティを考慮しなくても、リクエスト数や負荷によって自動的にスケーリング（拡張／縮退）される
可用性・回復性の向上
デフォルトで可用性と耐障害性機能が備わっているものが多い
設計はEC2のときとどれぐらい変わるのか
どういう箇所を気をつけて実装することになるのか
EC2で実装していたコードはどれぐらい流用できるのか
どういうサービスがserverleeに向いているのか
serverlessを使った時に起こりがちな問題
table:比較
拡張の単位 仮想マシン アプリケーション 機能
存続期間 数日から数か月 数秒から数分 数ミリ秒から数秒
パフォーマンス 予測可能 予測可能性が低い 予測可能性が最も低い
運用コスト 高 中 低
運用管理性 高 中 低
プロバイダー・ロックイン 中～高 低 高