曾几何时，标准是我们的朋友，提供了业界所能接受的蓝图，用于构建可靠的可互操作的同构基础设施。随着数字化创新速度的提高，标准已经逐渐没落。今天无数的软件应用程序是由无数的开发人员创建的，一度是实现互操作的关键——标准，在这一领域未能成功找到自己的定位。

虽然创新的速度加快了，但是新技术的应用却没有。很多组织采用了新的技术，但没有从旧的基础设施模式中完全转换到新的技术。随着时间的推移，这导致了各种各样的技术孤岛。有些与之不同的是因为它们所使用的标称语言：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在这两个服务之间创建了一个服务链。

“唯一不变的就是变化”，软件创新科研带来很多优势，但是我们需要学习如何消除孤岛，防止形成新的孤岛，创造更高的互操作性，以及简化操作的复杂性。上述的例子表明，通过采用标准的程序化方式，即便是在今天我们也可以实现这种互操作性。