クラウドと同様に、SDNも定義疲れに悩まされている

クラウドの歴史の初期、それほど昔のことではありませんが、クラウドの主なモデル (IaaS、PaaS、SaaS のこと) を区別せずに、「クラウド」の比類のない市場浸透を宣伝する成長レポートや採用レポートがよく見られました。 その結果、3 つのモデルすべてが驚異的な成長を遂げ、一部の予測どおり、クラウドによって私たちが知っているデータ センターが消滅するのではないかと思われました。

それから数年が経ち、より詳細な市場分析が進むにつれて、クラウドの驚異的な成長は主に SaaS 側で起こったことが示されました。これは、LOB (事業部門) の利害関係者が、IT 部門がパッケージ ソフトウェアを実装するモデルから、SaaS 部門が今日必要なものを提供するモデルに移行することにメリットを見出したことによるものです。 間違いなく、これまでのところ「クラウド」の最大の成長は、オンプレミスから「クラウド内」のアプリケーションへのビジネス運用の移行です。

2018 年までに、クラウド ワークロード全体の 59% が Software-as-a-Service (SaaS) ワークロードとなり、2013 年の 41% から増加すると予測されています。 Cisco は、2013 年の 44% から 2018 年までにクラウド ワークロード全体の 28% が Infrastructure-as-a-Service (IaaS) ワークロードになると予測しています。また、2013 年の 15% から 2018 年にはクラウド ワークロード全体の 13% が Platform-as-a-Service (PaaS) ワークロードになると予測されています。  次のグラフは、2013 年から 2018 年までの IaaS、PaaS、SaaS の予測の比較分析を示しています。 ( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )

したがって、一般的に組織に「クラウド」を導入しているかどうかを尋ねると、おそらく「はい」という答えが返ってくるでしょう。 これでは、企業がどのようなクラウドを採用しているかはわかりません。そのため、企業が採用することによってどのような課題に直面する可能性があるかを予測したり、コメントしたりすることはほぼ不可能です。 結局のところ、各クラウド モデルには独自の課題が伴います。共通する課題もありますが (ID 管理は 3 つのモデルすべてに共通する問題になる場合があります)、共通しない課題もあります。Web アプリケーションのセキュリティは、SaaS ではなく、IaaS で展開されたアプリにとって主に課題となります。

つまり、基本的に、「クラウド」という用語は、何らかの修飾語がなければ意味がありません。

これは今日の SDN にも当てはまります。SDN ではさまざまなモデルが使用されており、それぞれに独自のアーキテクチャ要件があり、そのため課題もあります。

私の同僚である Nathan Pearce が、SDN の定義にオーバーレイ プロトコル (VXLAN および NVGRE) を含めることについて語った次の批判を検討してください。 どの SDN プロトコルが適しているか。 Nathan は、オーバーレイ プロトコルを SDN の定義に含める場合は、他のカプセル化プロトコルも SDN として指定する必要があることを正しく示唆しています。

もちろん、問題は、クラウドと同様に、SDN も複数のモデルを幅広く含んでいることです。 OpenFlow に基づき、ステートレス ネットワーク (レイヤー 2 ～ 4) のみを含む従来の (またはクラシックとも呼ばれる) 定義があります。 ネットワークの運用化に重点を置いたアーキテクチャ モデルがあり、プロビジョニングと管理の自動化の観点から SDN のプログラマビリティの側面にアプローチします。 これは一般的に「ネットワーク管理とオーケストレーション」（MANO）と呼ばれます。

次に、フルスタックにわたって自動化されたネットワークを構築するためにプログラマビリティに依存する、一種のミックスモデルがあります。このモデルは、OSI の 7 つのレイヤーすべてを包含しますが、リアルタイムのトラフィックに基づいてルーティングとポリシーの適用を調整するネットワークの機能に重点を置いています。  これはより正確には「自動化されたネットワーク」と呼ばれます。

これら 3 つのモデルにはそれぞれ独自の課題 (および利点) が伴います。 また、組織が目標を達成するためにこれらのモデルを組み合わせることを妨げるものは何もありません (82% の組織がマルチクラウド戦略を計画しているのと同様です (RightScale、State of the Cloud 2015))。 しかし、SDN を導入または実装しているかどうかを尋ねて「はい」と答えたとしても、実際に何をしているのかまったくわからないというのが事実です。 OpenFlowですか？ オープンスタック？ オープンデイライト？ ネットワークを自動化するためのスクリプトをいくつか書きましたか?

SDN の採用に関する現在の統計はあまり刺激的なものではなく、市場の成熟度が同段階にあったクラウドの状況にはまったく及ばない。

しかし、定義の相違を考慮すると、実際に起こっているのは採用や関心の欠如ではなく、むしろ共通の定義の欠如である可能性が非常に高い（そして可能性が高い）と言えます。

これを裏付けるデータとしては、組織は SDN (あるいは、定義疲れの問題を抱える DevOps) を実行しているとは言わないかもしれないが、実際には実行している可能性が高い、というものがあります。

弊社の最新のアプリケーション配信の現状レポート (2016 年版、2016 年に公開予定) にまとめられた結果では、SDN が「やるべきこと」となってから何年も経っていることを考えると、実際に「SDN を実践している」という回答の数は非常に少ないものでした。 しかし、自動化とスクリプトの使用に関する回答を詳しく調べてみると、まったく別の話が見えてきます。 回答者の 67% が少なくとも 1 つの自動化ツールまたはフレームワークを使用しており、半数以上が 2 つ以上を使用しています。

ここで言う「ツール」や「フレームワーク」には、Python、Juju、Chef、Puppet、OpenStack、VMware、Cisco が含まれます。

このようなフレームワークやツールの使用は、従来の OpenFlow ベースの定義ではなく、自動化とオーケストレーションに重点を置いた SDN の後者の 2 つの定義への関心が高まっていることを示しています。

しかし、私たち（調査をまとめた私たち）は、それぞれの SDN モデルについて質問したのではなく、「SDN」全般について質問しました。 「クラウド」という広義の包括的な用語が、早期導入調査の結果に解釈の余地を残したのと同様に、定義にも解釈の余地を残します。

SDN という用語をどのように使用し、それが何を意味するかについて、より慎重になる必要があります。 オーバーレイプロトコルは含まれていますか? オーバーレイプロトコルは含まれていないのですか? ネットワーク自動化について話しているのでしょうか、それともネットワークの自動化について話しているのでしょうか? それとも、従来の OpenFlow 駆動型ネットワーク モデルに焦点を当てているのでしょうか?

この質問に対する答えは、最終的に、SDN が現在どのように受け入れられているのか (または受け入れられていないのか) を誰もがよりよく理解できるようにし、オーバーレイ プロトコルを「SDN」に含めるべきだと誰かが提案したときに、私の同僚たちが頭を爆発させるのを (願わくば) 止めることになるでしょう。