多年前，当云计算刚刚兴起，DevOps还只是一个想法的时候，一个非常小但颇有远见的小组聚在一起讨论基础设施的未来。基础设施2.0工作小组囊括了很多互联网传奇人物：Greg Ness，Christofer Hoff，James Urquhart，Vint Cerf，Bob Grossman，Dan Lynch。基础设施2.0工作组试图预测基础设施在自动化和编排网络中如何发展。

尽管我们进行了认证的尝试，但最终时机不对，产业界还没有准备好将基础设施从次要角色推向主角的转型。

十年后的今天，情况发生了变化，我们不再称之为基础设施2.0，业界现在的时髦的称呼例如DevNetOps、NetOps 2.0或Super-NetOps，虽然有了时髦的称呼，但是支持这一运动的技术仍然保持不变：通过支持API的基础设施实现自动化，从而解决运营规模的不经济问题。

云计算教育业界关于规模经济的问题，现在容器正在重新定义这一概念，它是网络设备或数据路径的集合，以支持应用程序和服务的规模。

在该数据路径中有很多网络和应用程序服务，它们提供了规模化的应用程序、安全性和速度。每一个都需要单独配置和管理。2014年，Computer Economics网络设备与工程师的比例为37比1。一年后，设备与工程师的比例达到了59比1，增幅为60%。更多应用程序，更多设备，更多工程师？

这就是问题的根源，规模化之后带来的效率下降。随着通信变得越来越沉重，用户的速度实际上是在不断降低，不得不牺牲安全以保证速度和稳定性，同时收益也在降低。

这就有了基础设施2.0——DevNetOps，NetOps 2.0，Super-NetOps的用武之地，因为这些技术的目的就是让DevOps应用于网络。

这一概念包含了三个核心标准：可编程（支持API）基础设施，基础设施即代码，集成。

可编程（支持API）基础设施

API是新的命令行界面（CLI）。现在可以使用API实现自动化和编排，REST API可以从任何脚本或编程语言中访问。通过API访问可促进支持应用程序所需的网络和应用程序服务的集成和部署。从与应用程序所有者共享指标到配置新服务，用户无法在没有API的情况下实现有效自动化。

基础设施即代码

基础设施2.0鼓励使用配置的声明性方式，而不是强制的API驱动的方式。如果我们要达到科幻电影中的自动化水平，并且在今天的广告中推广，我们首先必须转向声明性模型，以告知网络做什么，而不是如何去做。

这需要转变观点，将网络设备（无论是硬件还是软件）视为像应用程序基础设施一样可随意使用。将配置文件和模板的集合视为网络架构的关键组件，而不是将布线视为关键组件。

集成

自动化是人工任务的汇集，编排是一个过程的自动化。进程需要有多个任务，这意味着集成是说明风格的必备条件。集成斌不容易，但由于HTTP和REST API的普遍性，集成并没有以前那么可怕。尽管如此，如果用户要通过自助服务为开发人员提供负载均衡服务，仍然需要一种方式来加以启动。大多数情况下需要票务系统，这意味着正在进行集成。

实现基础设施2.0

基础设施2.0背后的核心理念以及我们过去希望实现的理念依然如此。我们需要可编程基础设施来支持声明式管理方法，并且可以将其集成到自动化部署过程中。由于容器和云计算带来的压力，自动化作为竞争优势早已不复存在。

自动化不再是领先的先决条件，而是转变成为企业必须跟上的行业发展脚步。