かつて標準は私たちの味方であり、信頼性、相互運用性、均質性を備えたインフラを構築するための、業界標準の青写真を提供してくれました。しかし、デジタルイノベーションの加速に伴い、標準は徐々に支持を失っていきました。今日では、無数のソフトウェアアプリケーションが無数の開発者によって開発されており、かつて相互運用性の鍵であった標準は、この分野でその地位を確立できていません。

[[216440]]

イノベーションのペースが加速する一方で、新技術の導入は遅れています。多くの組織は新技術を導入したものの、旧来のインフラモデルから完全に移行できていません。その結果、様々な技術サイロが形成されています。Java、Python、Ruby、Goといった主要言語が異なるものもあれば、vSphere、OpenStack、AWS、Azure、Googleといったクラウドインフラ管理プラットフォームが異なるものもあり、コンテナ、仮想マシン、ベアメタルといったコンピューティングパラダイムも異なります。さらに、こうした技術サイロ化によって、アプリケーションの実行コスト、実行するアプリケーションの種類、実行方法といった、運用上の単純な問題も複雑化しています。

膨大な数の標準規格が存在し、それぞれにユースケースやビジネス目的に応じた長所と短所があります。残念ながら、クロスプラットフォームの互換性と相互運用性を促進するための包括的なアプローチとして標準規格を採用することは、今日の急速に変化する環境においてはうまく機能しません。

例えば、通信業界は高度に標準化されています。長年にわたり、通信スタックの特定の要素に関する標準を策定するために、複数のワーキンググループが結成されてきました。中でも特に注目すべきは、ETSI、MEF、TMForumです。このアプローチの課題は、プロジェクトの断片化です。相互運用性の欠如により、エンドツーエンドで一貫した標準、つまりすべてのレイヤーにわたる一貫性を実現する方法を見つける必要が生じました。

通信アプリケーションポートフォリオの多様化が進むにつれ、通信事業者は単一のベンダーからターンキーソリューションを購入するだけでは、もはやすべての問題に対応できなくなっています。単一のベンダーやソリューションでは、すべてのユースケースに対応できないからです。そのため、相互運用性の欠如がますます大きな影響を及ぼしています。

幸いなことに、ここ数年で多くのオープンソースプロジェクト（penStack、NoSQL、Docker、Kubernetes、ONAPなど）が登場し、標準化団体の役割を徐々に置き換え、新たな通信ネットワークスタックを形成しつつあります。オープンソースソフトウェアは、通信業界に標準規格を超えたより柔軟な選択肢を提供し、その採用率は成功を測る主要な指標となっています。

例えば、10年前は企業はSQL、OMG、Java EEなどの標準規格のみを基準にしていました。今日では、標準化団体によって確立された標準規格は、広く採用されているため事実上の標準とみなされているオープンソースプロジェクトに置き換えられつつあります。

オープンソース標準には多くの利点があります。第一に、すべての開発者が参加し貢献できるため、プロセスは比較的民主的です。第二に、政治的影響は最小限に抑えられます。第三に、プロセスはより柔軟で、完全なコンセンサスがなくても迅速なイノベーションが可能で、進歩を遂げることができます。さらに、オープンソース標準は様々な解釈が可能であり、互換性は保証できませんが、コードが唯一の依存関係の標準であり、定義を通じて相互運用性を確保できます。

しかし、オープンソース標準には課題がないわけではありません。異なるオープンソースプロジェクト間の相互運用性はしばしば制限されており、新たな技術サイロを生み出しています。OpenStack Foundationのエグゼクティブディレクターであるジョナサン・ブライス氏は、シドニーで開催された2017年のOpenStack Summitで、今日のオープンソースプロジェクトにとって最大の問題はイノベーションではなく、統合であると述べました。

SDxCentralの2017年オープンソースネットワークレポートは、オープンソースと標準の関係を概説しています。ソフトウェア中心のソリューションにおいて、従来のウォーターフォールモデルの有効性は限定的です。特に、更新サイクルが短縮され、システムが様々な環境に適応するように設計されるようになると、その効果は顕著になります。仕様と実装を組み合わせ、プロセス全体を加速させる、より反復的なライフサイクルが必要です。抜本的な変化は必要ですが、最終的な目標は変わりません。それは、マルチベンダー間の相互運用性です。

統合と最終的にはスケーラビリティを確保するために、オープンソースかつ標準ベースの媒体を見つけるにはどうすればよいでしょうか?

オープンソースは標準を置き換えるのではなく、標準を推進するものであるべきです。

この点を説明するために、標準ドライバーとオープンソース ドライバーのアプローチを比較してみましょう。

標準主導：ETSIはネットワーク機能仮想化（NFV）業界において重要な役割を果たしており、NFVシステムの共通アーキテクチャを定義し、共通の分類を確立しています。しかし、このアーキテクチャをサポートすると主張する実際の製品は大きく異なり、ETSIサポートを謳う製品でさえ、真の互換性や相互運用性は確保されていません。

オープンソース主導：ONAPは、オープンソースを共通標準の開発を主導するツールとして活用するという、従来とは異なるアプローチを採用しています。ONAPは当初、オープンソース事業者の視点からアーキテクチャを定義し、現在では様々な標準化団体から関連コンポーネントを採用し、アーキテクチャに統合しています。これは間接的に、ONAPと連携する様々な標準化団体間の連携強化を促進しています。

両者を比較すると、ONAPとETSIの範囲の違いがわかります。ONAPは、ETSIのエンドツーエンドのアーキテクチャを限定的にカバーしています。

「ちょうどいい」の基準を定義する

標準は、実装ではなく、様々なオープンソースプロジェクトやクラウドコンピューティングインフラ間の相互運用性に焦点を当てるべきです。標準は依然として必要ですが、その範囲は、低レベルの詳細な仕様を通して基盤となるアーキテクチャを定義することから、同じ標準やAPIに準拠する必要のないプロジェクト間の相互運用性を確保する「ちょうど良い」標準へと移行する必要があります。

また、常に新しい標準を見つけようとするのではなく、既存の標準またはアーキテクチャ間の統合と操作性も考慮する必要があります。

IT業界は、各コンポーネントの実装の詳細を定義することから脱却し、業界全体でサブシステム間の相互運用を可能にする「ちょうど良い」標準を定義する必要があります。したがって、仮想マシンの起動方法や特定のネットワークデバイスの設定方法を扱うのではなく、システムとサービス間の相互運用性に焦点を当てるべきです。このモデルにおいて、標準の最も重要な役割は、ロックインを回避することではなく、大規模な自動化を可能にするのに十分な相互運用性を実現するために、より高いレベルの抽象化を提供することです。

「ちょうど良い」フォーカスの基準：

• 標準化された実装ではなく、相互運用性。
• 柔軟性を維持しながら要件を抽象化します (同じ API に準拠する必要はありません)。
• 違いを隠そうとするのではなく、違いを最小限に抑え、それらに対応する一貫したアーキテクチャを提供します。

TOSCAプロジェクトは、適切な標準がどのように実践されているかを示す優れた事例をいくつか提供しています。TOSCAは、特定のプロジェクトのニーズに合わせて簡単に拡張できる、かなり疎結合なモデリングアプローチを提供します。

• 例1：マルチクラウドの相互運用性。TOSCAは、最小公分母に影響を与えることなく相互運用性を実現します。この場合、要件の定義は標準化しますが、供給の実装は維持します。これにより、特定の要件とその要件を満たす様々なリソース間の相互運用性に高い柔軟性がもたらされます。これらのリソースに前提条件として同じAPIへの準拠を強制する必要はありません。
• 例2：TOSCA/YANG。TOSCAはクラウド環境におけるアプリケーションのライフサイクルを扱うための仕様であり、YANGはネットワークデバイスの構成を定義するために一般的に用いられる仕様です。他の言語に欠けている部分を補うためにTOSCAやYANGを拡張するのではなく、両者を統合し、互いに独立したものにしましょう。TOSCAでアプリケーションの作成とライフサイクル管理を行い、YANGで実際のデバイスを構成することで、両方の長所を活かすことができます。
• 例3：サービスチェーニング。TOSCAは、異なる環境（AzureとOpenStackなど）で実行されているネットワークサービス間、および異なるオーケストレーションエンジン（ONAPとAzure ARM）間の相互運用性をサポートします。例えば、最近のプロジェクトでは、OpenStackとAzure上にそれぞれ1つのFortigateインスタンスを立ち上げました。これらの2つのインスタンスを共通のTOSCAモデルでバインドし、Cloudifyを介して2つのサービス間のサービスチェーンを作成しました。

「唯一不変なものは変化である。」ソフトウェアの革新と研究は多くの利点をもたらしますが、サイロを排除し、新たなサイロの形成を防ぎ、相互運用性を高め、運用の複雑さを簡素化する方法を学ぶ必要があります。上記の例は、標準化された手順を採用することで、今日でもこの相互運用性を実現できることを示しています。