运营商品化

在过去，汽车的变速器是手动的。 有些人可能将其称为“棍棒”，因为它具有换档机制。 在那个年代，自动变速器是一种需要经常订购的特殊装置。 它的名字来源于汽车自动换档的方式。 说实话，这挺好的。 毕竟，当您尝试手动换档时，有很多变量需要管理。 

如今，自动变速器已成为标准。 对于大多数人来说，手册是一个谜。 我尝试教我的三个大孩子如何驾驶汽车。 如果您正在考虑的话，我不建议您尝试。 如果你喜欢汽车的变速器的话就不行。 

我提到这种期望和标准的转变是作为运营讨论的序言。 主要是网络和应用服务基础设施，但在这些领域之外也同样如此。 

运营预期 

这种转变是朝着自动化方向的，但这也是对运营基础设施所需知识的期望的转变。 

回到我的变速器类比，如果你驾驶的是手动变速器，那么你就有很多变量需要管理。 您需要协调离合器和油门。 您需要听发动机的声音并知道何时换档。 您还必须知道您处于什么档位，要换到什么档位，以及如何移动“操纵杆”来到达那里。 

这些反映了您手动部署网络和应用服务基础设施所需的知识类型。 您需要了解很多有关网络运行的知识，以确保流量从一个地方传输到另一个地方。 

云的采用开始使人们的期望远离这一“标准”。 虽然您仍然需要了解一些基本的网络概念，但您不一定需要了解它们的工作原理。 随着容器的引入，期望进一步向右移动——几乎不需要甚至考虑 IP 地址。 

这样做会改变运营预期。 我们正在从专家运营经济转向商品化运营经济。 如今，预计组织内更广泛的角色能够访问部署网络和应用服务基础设施的运营方面。 为了达到这个目的，简化是必要的。 

具体来说，就是操作简化。 通过自助服务选项提供网络和应用服务是不够的，它还必须能够供那些需要使用它们的人使用。 它必须比现在更加简单。 

这可能意味着牺牲可配置性来换取可操作性。 

可配置性与可操作性 

与云和容器一样，网络和应用服务基础设施之上的抽象扩展到这些抽象的使用。 我指的是白话。 术语。 数据模型。 实际配置。 

对于那些非程序员类型的读者来说，我的意思是每个构造都有一组与之相关的属性，这些属性构成了“对象”。 虚拟服务器对象具有 IP 地址、应用池、事件、名称和一大堆其他特征。 其中一些特征实际上是对象——或对象列表。 遍历这些结构可能很复杂。 因为在微调基础设施时可配置性是必不可少的。 您希望能够调整非常具体的特性 - 例如切换 Nagle 算法或调整 TCP 窗口大小 - 以优化性能或容量。 

现在，在商品化的运营模式中 - 这也是我们前进的方向 - 可操作性比可配置性更重要。 选项更少，正常运行时间更快。 

但这并不意味着简单地剥夺选择权。 单纯地取消选项的调整功能只能满足操作性的基本要求，并不符合简化操作体验的期望。 您仍然需要了解对象模型。 需要做的是将模型抽象成一些更简单的东西。 比如，将虚拟服务器简化为 IP 地址、名称和应用实例列表。 

商品化需要标准化

这是一项重大的任务，因为应用服务基础设施没有通用的运行模型。 虚拟服务器、入口控制和安全策略的表示方式因产品和服务而异。 

Ops——无论是在开发方面还是 IT 方面——都需要有效地了解大量的模型，以便部署和操作用于交付和保护应用程序的平均十四个应用服务。 存在很大的差异，过去导致需要大量的证书来验证管理这些服务所需的专业知识。 

另一个操作上的转变则远离这种方法。 人们期望产品的简单性、易用性和通用性，以此来减少特定于设备的操作模型所产生的技术债务。 这是对标准化的期望；而不是对协议和网络行为的期望，这些在网络基础设施领域已经存在。 但我们如何表示这些协议和网络行为。

我们在有关容器化的调查中看到了这一点，其中近四分之一 (24%) 的受访者认为必要的技能是采用容器化的主要障碍，33% 的受访者认为这是中等障碍。 基础设施（其中当然包括容器和容器编排系统，因为它们在当今的生产环境中非常普遍）正因缺乏技能和对速度的渴望而走向商品化运营。 

这种愿望和需求体现在对试图描述所述基础设施服务的 Kubernetes 资源文件的有机采用中。 这些资源强制所有操作使用通用（商品化）数据模型（格式）来描述给定服务的部署和配置。 鉴于 IT 运营是当今组织中采用容器的首要驱动力 (35%)（根据Diamanti 的 2019 年容器采用调查）——其影响力几乎是开发人员 (16%) 的两倍和集成 DevOps 团队 (9%) 的四倍——认识到这种转变并仔细考虑新的基础设施如何适应（或不适合）商品化的运营环境非常重要。 

无论有没有官方（工作组或基金会）的努力，商品化都会推动事实上的标准投入运营。 事实上，这个标准将强调可操作性而非可配置性。