企業は常に、品質を落としたりリソースを使い果たしたりすることなく、アジャイルな製品フィードバック・ループを維持しながら、ソフトウェアのデリバリーを迅速化する方法を模索しています。これらの競合する利益を管理することはほとんど不可能に感じられるかもしれませんが、サーバーレス・コンピューティングはそれを可能にします。

サーバーレスとは何ですか？

最も単純に言えば、サーバーレスはソフトウェア・コンポーネントを表す分類です。これらのコンポーネントは、価格、消費量、スケール、信頼性に関する契約を開発者に提供します。これらの属性を示すものはサーバーレスであると言われます：

・プロビジョニングも管理も必要ない。サーバーレスとは、インフラがないことを意味するのではなく、インフラのプロビジョニングとメンテナンスがビルダーから抽象化されることを意味します。

・コストは使用量に応じて予測可能にスケールする。サーバーレスでは、使用量とコストは直線的な関係にあります。使用量が増えればコストも上がり、トラフィックが減ればコストも下がります。

・計画的なダウンタイムがない。インフラを維持する必要がないサーバーレスは、メンテナンスウィンドウがないことを意味し、可用性の向上を意味します。

・1回のAPIコールで準備完了。S3にファイルを置いたり、AWS Fargateでコンテナを起動したりと、ここにも多少のバリエーションはあるが、サーバーレス・サービスは、瞬時に消費される準備が整っています。

サーバーレスはコンピュート以上のもの

もしこれがAWS LambdaやMicrosoft Azure Functionsのように奇妙に聞こえるなら、それはこの2つのサービスがサーバーレス・コンピュートの例だからです。しかし、サーバーレス・テクノロジーを活用する場合、エンジニアが自由に使えるのはコンピュートだけではありません。

サーバーレス・コンポーネントは、アプリケーション・アーキテクチャのあらゆるレベルに存在します。データ、イベント管理、ワークフロー調整、オブジェクト・ストレージ、APIゲートウェイなどのサービスがあります。この例では、入力を処理し、出力を永続化し、変更データ・キャプチャを介して変更を伝播するように設計されたウェブベースのリクエストがあります。ここにあるすべてのコンポーネントはサーバーレスです。

これらの単一目的のサーバーレス・コンポーネントは、上記のすべての属性を体現しています。これらは積み木のように組み合わされ、超軽量から大規模まであらゆる場所で機能する堅牢なアーキテクチャを提供します。

しかし、コンポーネントが単一用途である場合、開発者やアーキテクトはどのようにこれらの機能を設計するのでしょうか？そこで、企業は人材に投資する覚悟が必要になります。

サーバーレスは技術以上のもの

あらゆるテクノロジー・ソリューションの中核をなすのは、設計者、構築者、オペレーターといった人々です。従来の “サーバーフル “な世界では、ソフトウェア・ソリューションを市場に投入するためのタスクは、しばしばサイロ化され、シーケンシャルまたはウォーターフォール方式で実行されます。エンジニアと運用チームは一緒に働くが、常に調和しているわけではありません。設計がユーザーのワークフローのニーズと一致しない場合、チームは問題を改善するためにプロセスを遡らなければなりません。

サーバーレスに投資した設計とは対照的に、いくつかのことが起こり始めます。最初の成果は、製品を出荷するために必要な仕事の役割と機能が圧縮され始めることです。プロダクト担当者は、コストとスケールをより密接なレベルで理解し始めるでしょう。サーバーフル・デリバリーでは、インフラを厳密に稼働させることに集中していたオペレーション・エンジニアは、サーバーレス・コンポーネントの選択と構成を支援するようになります。

２つ目の成果は、自律性を持って顧客に価値を提供するデリバリー・チームは、実験やピボットをより迅速に行えるようになるということです。このようなチームは、インフラやサンクコストに多大な投資をすることもなく、キューさえあればよかったのにストリームで構築された設計に制約されることもありません。サーバーレス・ビルドは、適応性、設定可能性、モジュール性に優れており、カスタム・ビルドのインフラで厳密に作業する競合チームよりも優位に立つことができます。

では、企業はどのようにしてサーバーレスモデルを活用できるのでしょうか？

サーバーレスを始めるには

古くからある「何から始めればいいのか」という疑問は、まず人々を襲います。経験豊富な企業であっても、そのスタートは時に麻痺してしまうものだが、サーバーレスの場合はそうではないはずです。企業が消費者向けソフトウェアを出荷しているか、企業間ソフトウェアを出荷しているか、業務をサポートする内部ツールとしてソフトウェアを提供しているかに関わらず、2つの自然な出発点があります。

新機能

新しいソフトウェアの構築は、企業のサーバーレスの旅を始めるのに最適な場所です。この試みは大規模である必要もありません。新しいテクノロジーを試す場合、難易度の両端から始めるのは良い選択です。ビルドが簡単であれば、企業はすぐに成果を確認し、自信を得ることができます。ビルドが難しく、要求が高ければ、企業は挑戦的なことに取り組み、自信を深め、テクノロジーに関する重要な仮定を証明または反証することができます。しかし、もし企業が難しいことから始めたいのであれば、経験豊富なエキスパートを招き、組織の能力をブートストラップすることが有効かもしれません。サーバーレスの知識は野火のように広がるので、この取り組みに対してポジティブな意味で準備をしておきましょう。

新しいビルドにサーバーレスを導入する場合、一般的に以下の領域が良い出発点となります：

・API開発。これはAmazon API Gateway、AWS Step Functions、Lambda、DynamoDBといったコンポーネントを組み合わせたものです。

・データパイプライン データの移動は、どのようなアプリケーションにおいても共通の課題です。サーバーレスコンポーネントは、従来のバッチベースのオペレーションを軽快でリアルタイムなデータ移動の強豪に変えることができます。Step Functions、DynamoDB、Amazon Kinesis、Amazon SQSのようなツールはすべて、こうしたワークロードに役立ちます。

既存のアプリケーション

多くの企業では、常に新しい機能を展開し、真新しいパターンを試すことができるわけではありません。そのため、既存のアプリケーションから小さく始めることは非常に価値があります。

サーバーレス・ビルドに適した一般的なシナリオは、既存のアプリケーションの拡張です。そのようなユースケースの1つは、APIに機能を追加することです。LambdaやAPI Gateway、あるいは既存のロードバランサーを活用することで、モノリシックなコンポーネントを邪魔することなく新しい機能を追加することができます。覚えておいてください： Lambdaとサーバーレスは同義語ではないが、Lambdaをイベントドリブンのコンピュートエンジンとして使うことは、それが意図した通り、非常に自然な出発点です。

LambdaでAPIを拡張する良さは、企業が既存のツールチェーンを持ち込めることです。.NET Coreが重い？Lambdaなら問題ありません。企業はJavaに傾倒している？Lambdaならそれが可能です。Lambdaには、RustやGoのコードを起動するLinuxベースのランタイムも用意されています。あるいは、コンテナへの投資がすでに大きいのでしょうか？Lambdaはそれらも実行できます。

最初のLambda関数が設置されれば、企業は他のサーバーレス・コンポーネントへのソリューションを模索し、拡張するためのスキルと自信を身につけることができます。重要なのは、小さく始めて、学び、適応し、統合することです。

まとめ

Momentoのようなサーバーレス・テクノロジーを使えば、より少ないリソースで、より速く、より質の高い成果を達成することができます。サーバーレスをビジネスで活用するための最初のステップは、実験文化を醸成し、新機能であれ既存アプリケーションであれ、着手する場所を選ぶことです。

今すぐ包括的なガイドをダウンロードして、企業規模でのサーバーレス化をさらに深めましょう。