曾幾何時，標準是我們的朋友，提供了業界所能接受的藍圖，用于構建可靠的可互操作的同構基礎設施。隨著數字化創新速度的提高，標準已經逐漸沒落。今天無數的軟件應用程序是由無數的開發人員創建的，一度是實現互操作的關鍵——標準，在這一領域未能成功找到自己的定位。

雖然創新的速度加快了，但是新技術的應用卻沒有。很多組織采用了新的技術，但沒有從舊的基礎設施模式中完全轉換到新的技術。隨著時間的推移，這導致了各種各樣的技術孤島。有些與之不同的是因為它們所使用的標稱語言：Java，Python，Ruby，Go等。使用不同的云基礎設施管理平臺：vSphere，OpenStack，AWS，Azure，Google等等。計算范例的不同：容器、虛擬機、裸機等等。更糟糕的是，這些技術孤島使得簡單的操作問題變得復雜，例如運行某個應用程序需要多少成本，運行哪些應用程序以及如何運行。排列的數量是壓倒性的，并且對于不同的使用情況和商業目的而言各自具有優點和缺點，不幸的是，使用標準作為一攬子方式來驅動跨平臺兼容性和互操作性在目前變化如此之快的環境中無法正常工作。例如，電信行業是非常標準化的。多年來，已經形成了多個工作組來為電信棧的特定元素制定標準。最值得注意的是ETSI、MEF和TMForum。這種方式面臨的挑戰是項目的碎片化，互操作性的缺失促使我們找到一種方式來實現端到端一致的標準，即所有層面都是一致的。隨著電信應用組合變得更加多樣化，運營商無法通過購買單個廠商的交鑰匙解決方案來應對所有問題，因為根本沒有一個廠商或一個解決方案能夠覆蓋所有的用例。因此，互操作性的缺失正在造成越來越大的影響。幸運的是，在過去幾年中，我們已經看到了很多開源項目(penStack，NoSQL，Docker，Kubernetes，ONAP)的涌現，這些開源項目正在逐漸取代標準組織的地位，并且正在形成新的電信網絡棧。開源軟件為電信行業提供了除標準之外的更靈活的選擇，其采用量成為了衡量成功的主要標準。以企業為例，企業直到10年前才被標準驅動(如SQL，OMG，Java EE)。今天企業由標準機構建立的標準正在被開源項目所取代，這些開源項目由于被廣泛采用而被視為實際的標準。開源標準有很多積極的屬性。首先，這個過程比較民主，因為每個開發者都可以參與和貢獻。其次，政治影響力的最小化。最后，這個過程更加靈活并能夠快速創新，且沒有必要達成完全的共識也能取得進展。此外，機關規范可以用很多不同的方式來解釋，雖然也不能夠確保兼容性，但是代碼是唯一的依賴標準，且能夠通過定義來確保互操作性。但是開源標準并非沒有挑戰，通常不同開源項目之間的互操作性很小，這就形成了新的技術孤島。OpenStack基金會執行董事Jonathan Bryce在2017年悉尼OpenStack峰會上表示，今天開源項目最大的問題不是創新而是一體化。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上啟動了兩個Fortigate-one實例，另一個在Azure上啟動。我們通過一個共同的TOSCA模型將這兩個實例粘在一起，通過Cloudify在這兩個服務之間創建了一個服務鏈。

“唯一不變的就是變化”，軟件創新科研帶來很多優勢，但是我們需要學習如何消除孤島，防止形成新的孤島，創造更高的互操作性，以及簡化操作的復雜性。上述的例子表明，通過采用標準的程序化方式，即便是在今天我們也可以實現這種互操作性。