application配信の比較: 2005年と2015年

コードを書く James Ward 氏 (彼の説明) は最近、今日のアプリケーション展開と 10 年前のapplication展開を比較した素晴らしい記事を書きました。 IT 業界全体であまり知られていない秘密の 1 つは、applicationアーキテクチャとデプロイメントの変更が、applicationの配信 (applicationsが高速で安全であり、消費者にとって利用可能であることを保証する実際のプロセス) に直接影響を与えるということです。 たとえば、マイクロサービスによって今日もたらされている変化は、ネットワーク アーキテクチャとその導入モデルをどのように変更するかという点で重要です。

わかってるよ、わかってるよ。 マイクロサービス、コンテナ化、クラウドへの移行によってネットワークが抽象化され、applicationsへの依存度が低くなると考えられます。 開発者、そしておそらく運用担当者の観点から見ても、それは真実です。 しかし、ネットワークは依然として必要です。交換されるデータは依然としてそれらのパイプを介して流れる必要があり、ネットワーク内に存在するサービスは依然として、アプリを高速化し、安全に保ち、可用性を保証する多くの機能を担当しています。 applicationsが構成され、展開される場所と方法の変更は、アプリケーションがその存在を認識していなくても (そして正直に言うと、applicationがそれを知るべきではないとしても)、必然的にそれらのサービスに影響を与えます。 そういう意味では彼らは守護天使のような存在です。

したがって、たとえapplication側から要求がなかったとしても、関係性を考慮すると、James 氏の記事は、過去 10 年間のapplicationsの提供方法の変化を並行して検討するきっかけとなりました。

デプロイメントアーキテクチャ

2005	2015
コンガライン	プラットフォーム

2005 年当時、ネットワーク チーム (NetOps) は、いわゆる「コンガ ライン」でapplicationsを配信するために必要なさまざまなapplicationサービスを展開していました。 これらは個別のポイントソリューションでした。 アプリを高速化するために必要な場合は、専用のプライベートボックスにWebパフォーマンスの最適化製品を導入します。 負荷分散用の別のボックス、アプリのセキュリティ用の別のボックスなど。 最終的には、多くの箱が長い列に並び、それぞれの箱を両方向に渡らなければなりませんでした。 

2004 年にapplication配信コントローラーが登場し (ただし 2005 年時点ではまだ未熟でした)、今日のプラットフォームへと進化し始めました。 これらのプラットフォームは共通の機能と処理を提供し、モジュール (またはプラグイン、アドオンなど) で拡張できます。 プラットフォーム アプローチは、コンテナ化と仮想化によってapplicationsとサービス間の移動に要する時間が短縮されるのと同じように、「ネットワーク上」で費やされる時間を大幅に短縮します。 また、共通の基盤であるプラットフォームを共有することで、今日のapplicationの提供に必要なさまざまなapplicationサービスの管理を標準化し、運用コストを削減する機能も提供します。

製品からプラットフォームへの進化は、コンテナやマイクロサービスなどの新しいテクノロジーを活用した、より使い捨てで分解されたアーキテクチャへのapplicationのデプロイメントや、同じ標準化されたコアを使用してさまざまなapplicationサービスだけをデプロイするために使用できるクラウド環境への移行において有利です。 これは、展開されたapplicationサービスのフットプリントが拡大しても管理オーバーヘッドが削減され、applicationsの拡大に応じて必要に応じてサービスを追加できることを意味します。

展開方法

2005	2015
手動展開	プログラム可能な展開

2005 年当時、Web ベースの GUI は標準的に使用されるようになりつつあり、applicationサービスのプロビジョニングと構成の主な方法は CLI でした。このプロセスは、他のすべての手動プロセスと同様に時間がかかり、applicationサービスが複雑になるにつれて、さらに時間がかかるようになりました。 人為的ミスによる問題の発生と、その結果生じる影響（ネットワーク内にあると、誤った構成の影響範囲が飛躍的に拡大する）により、その時点での監視にはさらに多くの時間がかかりました。 コピー アンド ペーストは普及していましたが、完璧ではありませんでした。また、サービスの管理にかかる管理オーバーヘッドがかなり大きく、より重要なapplicationsのみがこれらのサービスのメリットを享受できるようになっていました。

2015 年に DevOps 革命が起こりました。 API とテンプレートベースの構成の両方におけるプログラミング可能性は、ネットワークにおいてもすべてを変えています。 applicationサービスは、Puppet や Chef などの一般的なフレームワークを使用して API 経由で自動化できるようになり、Cisco APIC や VMware NSX などのオーケストレーション ソリューションと事前に統合され、Python、Perl、bash、curl によってカスタム駆動されるようになりました。 applicationサービス テンプレートを使用すると、標準化、再利用が可能になり、インフラストラクチャを「コードとして」扱うことが促進され、継続的な配信プラクティスをネットワークに拡張できるようになります。

application開発において継続的デリバリーほど普及しているわけではありませんが、applicationデリバリーは、サービスプロビジョニングの高速化による市場投入までの時間の短縮や、自動化と再利用による運用コストの削減を実現するプログラム可能なデプロイメント オプションをサポートするように進化してきました (そして進化し続けています)。

展開フォームファクタ

2005	2015
ビッグアイアン	仮想化

2005 年には、より大きく、より優れ、より高速で、より高性能なネットワーク ハードウェアの構築が急がれました。 イーサネット速度の向上と Web ベースapplicationsの爆発的な増加により、applicationサービスの要件をサポートするために、ネットワークに導入された大規模なハードウェアが補完的に拡張されることになりました。

今日では、密度とリソースの最適な利用に焦点が当てられています。 つまり、仮想化とクラウド コンピューティングは、どちらもapplication配信プラットフォームの仮想化によってサポートされます。 application配信プラットフォームは、AWS、Microsoft Azure、Rackspace などのクラウド環境だけでなく、専用ハードウェアまたは市販のハードウェアに展開可能な仮想アプライアンスにも展開できるようになりました。 この機能は、クラウド環境をサポートするだけでなく、マイクロサービスなどの新しいアーキテクチャに適応するためにも必要です。 今日のマイクロサービスとサーバー自体は、James Ward 氏が指摘するように、「使い捨て、不変、そして短命」です。

つまり、DevOps の領域に移行するapplicationサービス (負荷分散、applicationセキュリティ、最適化) の多くは、ソフトウェア定義データ センターの基準を満たす必要があります。 少なくとも、大規模な不変かつ使い捨てのモデルに適合できる必要があります。 現在、多くのapplication配信プラットフォームが存在し、プログラム可能な展開オプションと組み合わせることで、課題に対応できるようになっています。

展開責任

2005 年、そして今日でも多くの組織では、ネットワーク チームがapplication配信の展開と管理の全責任を負っています。 調達からプロビジョニング、構成まで、配信のあらゆる側面は、ネットワーク運用によって処理されてきましたし、多くの場合、現在でも処理されています。 この断片的なモデルでは、要件が明確にされ、チケットが作成され、エンジニアが手動でプロビジョニングし、アプリの提供に必要なapplicationサービスを構成する際に遅延が発生していました。

現在でも多くの組織でこの状況が続いていますが、クラウドとマイクロサービスの影響と DevOps の導入により状況は変わりつつあります。 IT as a Service への要望は強く、applicationサービスの構成の責任が運用チームや開発チームに移行しています。 applicationアファイン サービスは、物理的にもトポロジ的にもアプリの近くに配置する必要があります。これにより、DevOps が主導権を握り、これらのサービスのプロビジョニングと構成を担当することになります。

これは、ネットワーク チームがapplication配信から手を引いているという意味ではありません。 俊敏性よりも信頼性の実現に重点を置いた、より伝統的な方法で提供されるapplicationサービスを必要とするapplicationsと企業の懸念事項が多数存在します。 これらのサービスは、現在も、そしておそらく今後も、ネットワーク チームの管轄下にあります。 しかし、他のものは DevOps の責任に移行しており、今後も移行し続けるでしょう。

application配信は過去 10 年間で大きく進歩しました。 製品セットから統合プラットフォームへと進化し、プログラマビリティを獲得し、ビッグアイアンからハイパーバイザーとクラウド展開をサポートするものへと変化しました。 モバイルapplications、マイクロサービス、DevOps によってapplicationsの構築、展開、配信の方法が根本的に変化し続ける中、最終的にそれらのapplicationsを配信し、高速、安全、可用性を維持するサービスが継続的に進化することが予想されます。