サーバーレスとサービスとしての機能 （FAAS）は、多くの場合、互いに融合していますが、実際にはFaaSがサーバーレスのサブセットです。 サーバレスは、計算やストレージ、データベース、メッセージング、APIゲートウェイ、 などどんなサービス・カテゴリーにも適用しており、構成、マネジメント、およびサーバの課金がエンド・ユーザーからは見えません。 一方でFaaSは、おそらくサーバーレス・アーキテクチャにおける最も中心的なテクノロジーで、アプリケーション・コードやコンテナがイベントや要求に対応する形でしか実行されない、イベント・ドリブン・コンピューティング・パラダイムに焦点を当てています。

FaaSは、アプリケーションをクラウドに効率的かつ費用対効果の高い方法で 移行したい場合に有効なツールです。 以下のような利点があります：

• インフラストラクチャーではなく、コードに集中できる：  FaaSにより、サーバーを自動的かつ独立的にスケールできるように機能ごとに分割できるため、インフラストラクチャーの管理が不要になります。 これによってアプリ・コードに集中でき、劇的に市場投入までの時間を削減できます。
• 従量課金性： FaaSでは、処置が発生した場合にのみ支払いを行います。 処置が完了すると、すべてが停止します。コードの実行も、アイドル・サーバーも、コストも発生しません。 そのため 、FaaSは特に動的なワークロードまたはスケジュールされたタスクにおいて費用対効果が高いです。 FaaSは、高負荷のシナリオにおいて、上位の総所有コストも提供します。
• 自動的にスケールを調整：  FaaSを使用すると、機能は必要に応じて、自動的かつ独立して瞬時にスケーリングされます。 要求が落ちると、FaaSは自動的に縮小します。
• 耐久力のあるクラウド・インフラストラクチャーの利点を全て享受する：  FaaSは、リージョンごとに複数の利用可能地域を持ち、インクリメンタル費用抜きで任意のリージョン数に展開することができるため、独自の高可用性を提供することが可能です。

FaaSの導入をより簡単にし、より効率的に使うために推奨されている、いくつかのベストプラクティスがあります：

• 各機能が1つずつしか機能を持たないようにする：  FaaSの機能はイベントに対し、1つの作業を行うように設計されるべきです。 コードのスコープ宣言を限定し、効率的かつ軽量にすることで、機能のロードと実行が素早くなります。
• 機能で機能を呼び出さないようにする： FaaSの価値は、機能の独立にあります。 あまりにも多くの機能は、コストを増やしてしまい、機能の独立の意義を失わせてしまいます。
• 機能で使用するライブラリをできるだけ少なくする： あまりにも多くのライブラリを使用することは機能を遅くし、スケールを困難にします。

トランザクションを簡単に分離してスケーリングできるため、FaaSは大量の作業や並行作業の負荷に適しています。 また、データ処理、形式変換、エンコード方式、またはデータ集約といった活動のためのバックエンド・システムの作成に使うこともできます。

FAASはWebアプリケーション、バックエンド、データ/ストリームの処理、またはオンライン・チャットボットやIoT機器用バックエンドの作成にも適したツールです。 FaaSはサード・パーティー・サービスの管理や使用においても力になります。 例えば Androidアプリ開発を検討中の場合、費用を抑えるためにFaaSを用いたアプローチが考えられます。 アプリがバッチ処理といった機能のためにクラウドに接続する時にしか費用が発生しないため、従来型のアプローチに比べて大幅にコストを抑えることが可能です。

FaaSはコンピューティング・パフォーマンスを劇的に改善することも可能です。 例えば最近、2人の学生がIBMのエンジニアと協力して、 モンテカルロ・シミュレーションのためにIBM Cloud Functionsをどのように活用  （モンテカルロ・シミュレーションとは、予測が難しい将来の出来事の結果を推定するために使用される数学的方法）すれば株価を推定できるか研究を行いました。 モンテカルロ・シミュレーションは、重要なハイパフォーマンス・コンピューティング・ワークロードと見なされています。 モンテカルロと IBM Cloud Functions の組み合わせは、チームによる大規模な計算を可能にし、彼らがビジネス・ロジックに集中できる環境を整えました。 FaaSを使用することにより、チームは90秒程度で1,000の並行する呼び出しを伴うモンテカルロ・シミュレーションを完了しました。 比較対象として、同じフローを4つのCPUコアを搭載したノートPCで実行すると、247分かかり、CPU使用率はほぼ100％に達しました。

FaaSのユースケースの例をもっと見るには、「IBM Cloud Cloud Functionsによって提供される主な利点の要約」を参照してください。

FaaS、 PaaS（Platform-as-a-Service）、 コンテナ、 そして 仮想マシン（VM） は、すべてサーバーレス・エコシステムにおいて重大な役割を担います。 FaaSはサーバーレス・スタックの最も中心的、かつ定義となる要素であるため、FaaSが今日の市場においてキー属性間で他の一般的な計算モデルとどのように異なるのか、知っておく価値はあります：

• プロビジョニング時間： 他のモデルだと何分、何時間とかかるものが、ミリ秒単位で済みます。
• 進行中の運営： PaaS、コンテナ、VMのそれぞれに存在する難度の変遷に比べると、無いに等しいです。
• 柔軟なスケーリング： 他のモデルは遅い自動化のためにオート・スケーリング規則の注意深いチューニングが必要な中、FaaSは各アクションを常に瞬時かつ本質的にスケーリングします。
• キャパシティ・プランニング： 自動スケーリングと幾らかのキャパシティー・プランニングが必要な他のモデルに比べ、必要ありません。
• 持続的接続と状態： 外部のサービス/リソースでは、接続と状態を保持する機能は限定されます。 他のモデルは、httpを用い、オープンソケットや接続を長時間保ち、状態メモリーを呼び出し間で保つことができます。
• メンテナンス： すべてのメンテナンスがFaaSプロバイダーによって管理されています。 これはPaaSにも当てはまります。コンテナやVMは、更新/管理、コンテナ画像、接続、などを含む特定のオペレーティング・システムを要します。
• 可用性（HA）および 災害復旧（DR）： ここでも、HAはFaaSモデルにおいて余分な労力やとコストを必要としません。 他のモデルは、追加のコストとマネジメントの努力を必要とします。 VMとコンテナの両方において、インフラストラクチャーは自動的に再起動することができます。
• リソース使用率： リソースは決して待機状態にはならず、要求されたときにのみ呼び出されます。 他のモデルは全て、少なくとも一部において待機状態を経る必要があります。
• リソース制限： FaaSは、コード・サイズ、並行アクティベーション、メモリー、稼働の長さなどにおいて リソース制限 を持つ唯一のモデルです。
• 計上の細分性と請求： 他のモデルの時間単位（場合によっては分単位）と比較して、100ミリ秒のブロックあたりで計上します。

KubernetesとKnativeはFaaSの後ろの「配管」として実装できる環境に挙げられます。 Kubernetes はオープンソースのコンテナ・オーケストレーション・ツールであり、クラウド・アプリケーションの管理に必須です。 Knative はKubernetesクラスター内でのサーバーレスの稼働を可能にします。

KnativeとKubernetesを組み合わせることにより、モニタリングやセキュリティー、ロギング、および認証といったKubernetesの機能に加え、自動コンテナ作成、完全な携帯性、 ハイブリッド環境における作業といったKnativeの利点も享受することが可能となります。

このテクノロジーのクリエイターは、開発者がクラウドのアプリを作成する際、サーバーレスとコンテナから片方を選ぶ必要性を排除するべきだと考えたのです。 彼らの目標は、コンテナの可用性や一貫性と、サーバーレスの強力なスケーリング能力やオンデマンド・アクセス能力を統合、拡張することでした。

「Knativeとは？ 」という動画により詳細が載っています。

IBM Cloud Functionsは、IBMによるFaaSの恩恵です。 IBMは、IBM Cloud Functions上で生産ワークロードを稼働させるため、金融、自動車、保険、製造業などを含めたさまざまな業界の顧客に協力してきました。 1千万人以上のデイリー・アクティブ・ユーザーを持つESPNファンタジー・フットボールは、彼らの統計ダッシュボードにIBM Cloud Functionsを採用し、The Weather Underground（Weather Channelの一部）はCloud Functionsを用いてすべてのレーダーマップをレンダリングしています。 これらおよびその他のユースケースは、「IBM Cloud Cloud Functionsによって提供される主な利点の要約」というブログ投稿にて説明されています。

IBM Cloud FunctionsはApache OpenWhiskに基づいています。 OpenWhiskの中核は、Apache財団の指揮で行われているオープンソース・プロジェクトであり、誰でもアクション・コードをリポジトリーの構成要素として提供することが可能になっています。 つまり、OpenWhiskは絶えず成長し、改善されています。 OpenWhiskはアプリケーション開発を加速させるため、アクション・シーケンス付きのアプリを迅速に作成できるようになります。 FaaSの恩恵はクラウド機能のパフォーマンスの詳細に高い可視性をもたらします。

IBM Cloud Functionsはまた、イベント・トリガー・アクションのワークフロー内で、IBM Watson APIのようなコグニティブなサービスへのアクセスを含みます。 支払いは、使用した分に対してのみ発生します。 コストはCloud Functionsでの負荷を稼働させた際のみ増加します。請求は機能の実行に必要となった時間とメモリーに基づいて行われます。

IBM Cloud Professional Developerの役割ベース訓練および認証に含まれる、「サービスとしての機能展開とIBM Cloud Functions」をはじめとする様々なIBM Cloud Optionsのコースを通して、スキルをビルドしましょう。

IBM Cloud Functionsの仕組み についてより詳しく知るには、こちらの動画を参照してください ：