HTTP/2 のビジネスケースの作成

HTTP/2 はパフォーマンスを考慮して開発されました。

そうは言っても、特にモバイル アプリが関係する場合は、パフォーマンスが最も重要であるという現実に基づいてビジネス ケースを作成するのは簡単なようです。 コストが生産性で測定されるか利益で測定されるかにかかわらず、モバイル アプリケーションの購入、関与、使用に関して、パフォーマンスの低下は常に消費者が指摘する重大な問題です。

しかし、それは簡単なケースです。 このテーマに関する一連の調査を調べるだけで、誰でもその答えを出すことができます。 アプリが 5 秒以内に応答しない場合、消費者も従業員も落ち着かなくなることは誰もが知っています。 HTTP/2 への移行以外にも、組織が問題に対処するために使用できるパフォーマンス関連のサービスが多種多様にあることを考えると、組織が「クラウド ファースト」のビジネスであると明確に判断して HTTP/2 への移行を決定する前に、さらなる推進力が必要になる可能性があります。

HTTP/2 の機能の多くは、開発者が HTTP/1.1 で頻繁に対処し、標準的な方法となったことを理解した上で生まれたものであると考えてください。 インライン化、連結、ドメイン シャーディングなどのプラクティス。 これらはすべてパフォーマンスの向上に貢献しましたが、残念ながらそれぞれが技術的負債を生み出し、それが今でも開発者と運用者の双方に負担をかけています。 HTTP/2 に移行すると、今後の技術的負債の原因となるこれらの慣行を排除でき、現在存在する負債を「返済」する道が開かれます。

技術的（およびアーキテクチャ的）負債は選択によって発生します。 どのテクノロジーを採用するか、どの製品を購入するか、どのアーキテクチャを実装するかに関して選択します。 また、アプリケーション アーキテクチャ内のどこに特定のソリューションを実装するかに基づいて決定することもできます。

たとえば、HTTP/1.1 のいくつかの制限は、開発者が小さな画像のインライン化と小さなファイルの連結によって回避しました。 実際に、これによってパフォーマンスは向上しましたが、オプションとして (ネットワーク内の) アプリケーションの追加キャッシュが削除されるという代償がありました。 また、インライン イメージや単一の連結ファイルを構成するファイルに対する変更はすべてのアプリケーションに反映される必要があるため、アプリのライフサイクル中にも注意が必要でした。  モジュール性の欠如は、アプリケーションが稼働している限り継続する技術的負債の原因となります。

技術的負債は、実際の負債と同様に、処理が必要です。 それには代償、つまり利息がかかります。 あらゆる変更や更新により、関心は高まります。 開発者の時間と注意が必要です。 テストリソースが必要です。 ネットワークとコンピューティング リソースが必要です。 その結果、組織はイノベーションや拡張よりも「負債」の返済に多くの時間を費やすことになり、競争上の優位性をもたらす新しいテクノロジー、方法論、アーキテクチャの概念を活用することが難しくなります。

この負債に対処する必要がある。 実際には排除されていますが、少なくとも対処する必要があります。

HTTP/1.1 の場合、HTTP/1.1 の負債サイクルを終わらせる手段は、今後 HTTP/2 を採用することです。 HTTP/2 は、さまざまな技術的およびプロトコル上の制限に対処することで、開発者が過去の回避策を捨て、将来に向けて異なる選択を行う方法を提供します。 技術的負債を伴わない選択肢。 確かに、既存のアプリケーションはその負債を抱えたままですが、HTTP/2 を使用するアプリケーションに移行または置き換えることができ、開発と運用の両方を HTTP/1.1 の古いスタンバイによって課せられた制約から解放することができます。

HTTP/2 は、単にプロトコルとアプリの高速化だけを目的としているわけではありません。 また、開発と運用の制約を排除して技術的負債から解放し、組織にパフォーマンスを向上させる他の方法を活用する機会を与えることも重要です。 アプリケーション競争で企業が勝利するのを妨げるような技術的またはアーキテクチャ上の負債が発生する可能性が低い方法。