最後に新しい家に引っ越したのはいつですか?
引っ越したとき、家具は処分しましたか? 装飾品? 写真ですか? 敷物ですか? おそらくそうではないでしょう。 古くて使い古した持ち物を新しいものと交換する機会を得たかもしれませんが、家族の大部分はあなたと一緒に引っ越しました。
エンタープライズ アプリ ポートフォリオは、実は家庭を構成するもののようなものです。 組織が新しいアーキテクチャを採用し、新しいアプリを開発する場合、既存のアプリを破棄することはありません。 時間の経過とともにポートフォリオの一部が淘汰されることは必ずありますが、従来のアーキテクチャを使用して何年も前にサービスに導入されたアプリは、ビジネス価値を提供し続けている限り、今でもサービスに使用されているというのが一般的な事実です。
この主張を裏付けるデータはほとんどなかったにもかかわらず、何年もの間、これは事実であると主張されてきました。 この前提の真実性に異論を唱える人はいませんが、それを裏付ける実証的データがようやく得られたのは喜ばしいことです。
当社の「アプリ サービスの現状」調査では、アプリ サービスの将来に影響を与えると思われるトレンドとテクノロジーについて質問しています。 クラウドは1つです。 自動化とオーケストレーションもその一つです。 しかし、おそらくアプリ サービスに最も大きな影響を与えるのは、当然ながら、これらの中間機能が提供し、保護するアプリケーションです。
そこで、使用されているアプリケーション アーキテクチャとエンタープライズ アプリ ポートフォリオの構成について質問しました。
結果はおそらく誰も驚かないだろうが、最新のアーキテクチャ、特にマイクロサービスの急速な導入は、一時的な興味以上のものとなるかもしれない。
以前の投稿でご存知のとおり、現在、エンタープライズ ポートフォリオ全体で最も一般的なアプリ アーキテクチャは、従来の 3 層 Web アプリ (36%) です。 しかし、そのすぐ後には、その前身であるクライアント サーバー (34%) が続きます。 メインフレームとモノリスは依然としてアプリ ポートフォリオの 11% を占めていますが、最新のアーキテクチャ (ここではモバイルとマイクロサービスとして定義) がそれらを上回り、それぞれアプリ ポートフォリオの 14% と 15% を占めています。
それは興味深いですが、「伝統的」建築と「現代的」建築に分類すると、さらに魅力的になります。 この分析の目的上、「従来の」アーキテクチャには、モノリス、クライアント サーバー、3 層 Web アプリが含まれるものと定義します。 「モダン」なアーキテクチャはモバイルとマイクロサービスです。
これらのカテゴリを使用すると、大部分 (76%) が両方を組み合わせて使用していることがわかります。
残りの 24% は従来のアーキテクチャを強く支持しており、21% はアプリ ポートフォリオに従来のアーキテクチャのみを使用しています。 残りは冒険的と言え、近代的な建築だけに頼っています。 エンタープライズ アプリ ポートフォリオ内のアプリ アーキテクチャの平均数は 3 ですが、すべてのアーキテクチャでアプリを運用している組織が 18% に上ることからも、一部のエンタープライズの長寿命性がうかがえます。 全部5つ。
さらに興味深いのは、11% の組織が 1 つのアーキテクチャのみを採用していることです。
組織は異種のアプリ ポートフォリオを維持しています。 最新のアーキテクチャを採用しながらも、従来のアーキテクチャ カテゴリに属するアプリの使用と統合を継続しています。 アプリが寿命を迎え、最新の同等のアプリに置き換えられるにつれて、アプリのポートフォリオ構成が時間とともに変化することが予想されますが、この変化には時間がかかります。 場合によっては、かなりの時間がかかります。
3 層 Web が大幅に減少する前に、クライアント サーバーが減少するとともに、マイクロサービスに基づくアプリが大幅に増加すると予想しています。 しかし、メインフレームやモノリスは、このようなアーキテクチャを介して提供されるビジネスとアプリケーションの密接な結合を考慮すると、近い将来に劇的に消滅するとは予想していません。 現実には、デジタル変革によってビジネスとテクノロジーの緊密な統合が推進されており、メインフレーム上で稼働する「古い」モノリスでは、すでにそのような緊密な統合が実現されていることがよくあります。
つまり、全体としては、自社のアプリがビジネスにとって重要であると回答した回答者は 3 分の 1 未満 (31%) でしたが、アプリ ポートフォリオの半分以上をモノリスが占める回答者の場合、その割合は 38% に跳ね上がります。 明らかに、モノリスとメインフレームは、その潜在的な古さにもかかわらず、ビジネス価値を生み出し続けています。
では、アプリ サービスおよびセキュリティ プロバイダーは、「アプリは拡張可能で、安全で、高速である必要がある」という明白な事実以外に、なぜアプリ アーキテクチャを重視するのでしょうか。
アプリケーション アーキテクチャは、これまでも、そしてこれからも、アプリ サービスの提供方法に大きな影響を与え続けます。 たとえば、従来のアーキテクチャは、アプリケーション配信コントローラ (ADC) などの従来のプロキシベースの配信メカニズムに適しています。 しかし、API と分散実行モデルに大きく依存する最新のアプリでは、多くの場合、そのようなアプリの運営者に適した新しい配信メカニズムが導入されています。 コンテナネイティブのオプションと「サービスとしての」モデルは、多くの場合、最新のアプリと組み合わせられます。 また、Web およびアプリケーション サーバー プラグイン ( NGINX モジュールなど) は、アプリケーション サービスの配信メカニズムとしてますます魅力的になっています。
現実には、マイクロサービスがネットワークを分断しています。 そうすることで、配信アーキテクチャの重心がアプリへとシフトします。これにより、一部の重要なアプリ サービス (特に可用性とセキュリティ) がアプリに近づき、場合によってはアプリ内に組み込まれます。
これにより、業界としてのアプリケーション サービスの展開および運用方法と、プロバイダーとしての F5 によるアプリケーション サービスの提供方法が変わります。