7.《サーバーレスになるように最善を尽くしますが、過信はしないでください》

すべての製品とサービスにサーバーレスを導入する前に、まず何を考慮すべきかを見てみます。

テクノロジーのトレンドを追っていれば、間違いなく「サーバーレス」の台頭を目にしない日はないでしょう。一部のアカウントでは、「サーバーレス」は次のアプリケーションアーキテクチャスタイルと呼ばれています。「テクノロジーXは不要だ。サーバーレスが将来の方向性だからだ。」もしくは「テクノロジーXはミスリードとなる、サーバーレスの台頭によって。」と言う人もいます。この記事では、マイクロサービスやサーバーレスを導入しないケースを見てみましょう。

これまでのところ、サーバーレスについて私が見た中で最も優れた説明は、Patrick Deboisのスピーチ「サーバーレスからサービスフルへ」の中のものです。 そのスピーチで、彼はサーバーレスに定義を与えました。スピーチでは実際にサーバーレスが何であるか定義していますが、サーバーレスが適当でないケースについては、人々の注意をそらしています（サーバー使用のケースも含め）。 注意を通してこそ、提供されているサービス（SQS、DynaModb、Gmail、Googleカレンダー、Salesforce、Fastlyなど）をよりよく使い、それらを統合して特定の機能を提供することにより、より興味深い定義を描くことができるはずです。

コアインフラストラクチャサービスをサービスプロバイダーにアウトソーシングし、API（および機能）を介してそれらを統合してビジネス価値を実現します。

多くの点で、「既存のサービスを活用して構築する」という考え方は新しいものではありません。サービス指向アーキテクチャの背後にある精神を体現しています。

既存のサービスを利用してしきいを下げることができる場合（つまり、ハードウェアを購入する代わりにAPIを登録する、セキュリティ/ネットワーク/ DNS /オペレーティングシステムをセットアップするなど）、お客様にとって興味深いものをより速く構築できます。これはサーバーレスの1番目の特徴です。 2番目の部分は、これらの異なるサービスのすべてのテクノロジーを所有する必要がないことです。つまり、使用量（メータリング）とSLAに対して料金を支払いさえすれば、難しい技術的な問題を所有して解決する必要はありません。ビジネスの価値に対応するための機能を提供できます。Ben Kehoeは最近のポッドキャストでこれをうまく伝えました。

私はこれに完全に同意します。お客様から「サーバーレスがアプリケーションアーキテクチャの次の開発になるとしたら、マイクロサービスとコンテナをスキップする必要がありますか？」と質問されたときの私の答えは次のとおりです。

サーバーレスになるように最善を尽くしますが、過信はしないでください。

その理由をよく見てみましょう。

技術の専門家として、私達はテクノロジーと、新しい有望なトレンドに惹かれています。サーバーレス、コンテナ、および他の各種コンテナなどが視野に入るでしょう。 しかし結局のところ、技術エキスパートとしての私達の役割は、企業がビジネス価値を発見して使用し、この目標を競合他社よりも早く達成できるようにすることです。

アプリケーションのライフサイクルの「探索」段階（すべてのスタートアップ企業のように）にいる場合、何をすれば顧客に価値を提供するかについての想定をすばやく仮定し、同じ様にすぐに価値を提供できるようにしたいと思います。しかしそれは、お客さまの目に触れるまでは価値を正確に表現することはできません。簡単に実験するためにサービスを一部の顧客に提供し、彼らの反応を観察するのが最善です。顧客の興味を引くものがない場合は、そのサービスについては次に進めるのをあきらめます。このプロセスを行うには、インフラストラクチャの構築、開発コスト、パートナーなどに多額の投資をしてはなりません。これらの実験は可能な限り低いコストで実行する必要があり、サーバーレスの方法はこれを実現する絶好の機会を提供します。 既存のテクニカルサービスを使用して、多くの投資をせずにお客様のためのデジタル資産を作成できます。重要なのは、オンデマンドで支払うことができるということです。新しい製品やサービスに関心がない場合は、多額の費用をかける必要はありません。最初に予測不可能だが強い関心があった場合には、プラットフォーム（Service + Faas）を利用することができます。これは、あまり頭を悩ませる事なくすばやく拡張できます。

顧客に価値を提供する何かを偶然見つけた場合は、その上に構築し、コンテンツを拡張し、その周りに有益なサービスを構築していけば良いのです。この時点で、サービスを拡充するために、部分的にサーバーレスおよび非サーバーレスのアーキテクチャが必要になる場合があります。「ビジネス価値を見出し、差別化を実現するためにどれだけの資本が必要か」という問題について、これら2つの技術的な決定に直面する必要があります。「サービスレベル契約、規制順守、価格、ロードマップをサービスプロバイダーにアウトソーシングするか？」探索段階では、すべてをサービスプロバイダーにアウトソーシングしてもよいと思います。しかし、ビジネスが成熟するにつれて、組織がアウトソーシングによってどのように影響を受けるかについての議論は、お客様に影響を与える実際の問題になります。

新しい製品/サービスの予測可能なパターンを見つけ始め、一部の部分（コストや技術的側面を含む）を最適化することにした場合、サーバーレスの方法は高すぎると思うかもしれません。そして、スタックのより多くの部分を持つことは価値があるかもしれません。サーバーレスとその周囲のインフラストラクチャが、より予測可能な使用パターンを持つアプリケーションにとって高額になるというこの説明をご覧ください。

最後に、すでに多くのお金を生み出しているアプリケーションの場合、魔法のようにこれらをサービスプロバイダーに転送することはできません。ただし、それを部分的に近代化して、会社の新しいデジタルイニシアチブに参加することもできます。

組織は、より高いパフォーマンスのITと組織に向けて大きな一歩を踏み出したことがわかります。コンテナとkubernetesに基づくサービスアーキテクチャ（マイクロサービス/ apis / soaなど）を最新化することにより、論理的な結論に拡張すると組織のサービスプラットフォームとして構築されているため、組織の一部がサーバーレスで実行されます。つまり、組織の一部（探索的作業に従事している部分）は、完全にインフラを整備せずとも実現できる事になります。

企業製品のさまざまな部分とアプリケーション開発ライフサイクルのさまざまな段階では、さまざまなツールとメソッドが必要です。これらのツールとメソッドはすべて、このような要望に答えるように設計されています。「現在の環境を考えると、価値の急速な実現とは何か 最善の方法ですか？」私達は真の「背景」を利用することにもっと注意を払い、これに基づいて投資、所有権、テクノロジーなどについて最良の決定を行う必要があります。

自身の環境で考えてみましょう。

• 製品のライフサイクルはどうか？
• ビジネス上の問題を解決するために必要なテクノロジーは何か。
• 現在のテクノロジーを使用しているチームはどの程度効率的か。
• サーバーレス機能がビジネスにどれほどのポリシーと重要性を持っていると思うか？

twitter @christianpostaであなたの疑問や意見をコメントしたりしてくださるとうれしいです。