アプリケーションの構築に関しては通常、デベロッパーはコードをデプロイするために、処理とストレージのためのリソースの定義、パッチ適用、ロード バランシングなど、多くのサーバー管理タスクを実行する必要があります。こうした余分な項目はすべて、長いプロビジョニング時間と、運用上のオーバーヘッドの増加をもたらし、最終的に開発チームの作業効率低下を招きます。

サーバーレス コンピューティングは、デベロッパーに目に見えない「サーバーレス」のエクスペリエンスを提供し、サーバーやアプリケーションの実行に必要なものを考える必要性を排除します。サービス プロバイダがバックグラウンドですべての作業を行い、コードを実行し、要件を満たすためのリソースを確保します。アイドル状態の容量に対して料金が請求されることはありません。

サーバーレスは、家に水道を引くようなものと考えてください。自分の井戸を掘り、水質をテストし、家に水道を引くために必要なすべての外部配管を設置して維持することができます。あるいは、都市の主要な水道に接続することもできます。水道の蛇口を回すだけで、必要なときに必要な量の水が供給され、市は実際に消費した水量に対して毎月の請求書を送付します。

同様に、クラウド プロバイダは、サーバーレスアプリの実行に必要なインフラストラクチャ リソースとランタイム環境を自動的にスピンアップし、実行が完了すると自動的にゼロまでスケールダウンします。通常、実行時間中のリソースに応じて課金されます。ただし、サービスやベンダーによって異なる場合があります。

でも、他のタイプのクラウド コンピューティングでは、従量課金制でオンデマンドのリソースが提供されるのではないですか？Infrastructure as a Service（IaaS）やPlatform as a Service（PaaS）などのクラウド サービス モデルでも、コンピューティング リソースへのオンデマンド アクセスが提供されるのは事実です。

ただし、割り当てられたクラウド インフラストラクチャは、使用していない場合でもアクティブなままです。また、ユーザーの需要に応じてサーバーの容量を拡張したり、アプリケーションをスケールアップまたはスケールダウンするように構成したりすることも、お客様の責任となります。

サーバーレス アーキテクチャはイベント ドリブンです。このモデルでは、イベントによってコードの実行がトリガーされた場合にのみ、プロバイダからリソースが提供され、リクエストに応じて即座に自動的にスケーリングされます。

サーバーレス コンピューティングの大きなデメリットの一つは、まだ比較的新しいテクノロジーであるということです。そのため、現時点では、考えられるすべてのユースケースに対応できるわけではありません。

また、サーバーレス コンピューティングが進化し続けるにつれて、現存する弱点の一部が時間とともに解決されることも明らかです。特に、サーバーレスのオープンソース実装や、クラウド サービスをよりオープンにして、ソリューションをさまざまなプラットフォームや環境に移植できるようにする方法については、すでに多くの取り組みが行われています。

• ユースケースの適合性が限定的: サーバーレス アーキテクチャは、長時間実行されるプロセスや、非常に低いレイテンシが要求されるケースなど、特定の要件があるアプリケーションには必ずしも適していない
• パフォーマンスの制約: サーバーレス関数では、コールド スタート（最初の実行の遅延）が発生する可能性があり、実行時間やメモリに制限がある場合もある
• ベンダー ロックイン: サーバーレス アプリケーションをクラウド プロバイダ間で移行する場合、API や構成の違いにより、作業が複雑になる可能性がある
• サーバーの可視性の低下: デベロッパーに対して基盤となるインフラストラクチャの可視性が限られているため、パフォーマンスの問題のトラブルシューティングやリソース使用率の最適化が困難
• 起動が遅い: サーバーレス関数では、関数の呼び出しに遅延が発生する「コールド スタート」が発生することがあり、レイテンシに影響する可能性がある