运营的商品化

F5生态系统 | 2019年7月29日

很久以前,汽车使用的都是手动变速箱。由于换挡时需要操纵换挡杆,有些人也会称其为“stick”。在那个年代,自动变速箱还是一种特别配置,通常需要专门订购。之所以称为“自动变速箱”,是因为汽车会自动完成换挡。说实话,这确实很方便。毕竟,手动换挡时需要同时处理很多变量。

如今,自动变速箱已成为标配,而大多数人对手动挡一窍不通。我曾试着教三个年纪最大的孩子开手动挡。如果您也有这个打算,我并不建议尝试,除非您不介意把汽车变速箱弄坏。

我之所以提到这种期望和标准的转变,是为了引出对运维的讨论。这里主要指网络和应用服务基础设施的运维,但同样也适用于其他领域。

网络巫术

运营预期

这一转变确实是向自动化迈进,但同时也改变了对基础设施运维所需知识的要求。

再回到变速器的比喻。如果驾驶手动挡汽车,需要处理许多变量:协调离合器和油门,听发动机的声音并判断何时换挡。此外,还必须知道当前挡位、目标挡位,以及如何操作“换挡杆”挂入目标挡位。

这些操作所需的知识,与手动部署网络和应用服务基础设施所需的知识类似。您需要深入了解网络的运行方式,才能确保流量从一处传输到另一处。

随着云的采用,人们的预期开始偏离这一“标准”。虽然仍需了解一些基本的网络概念,但不一定要理解其工作原理。随着容器的引入,这种预期进一步向右转移,几乎不再需要考虑IP地址。

这会改变人们对运维的预期。我们正从“专家型运维”模式转向“普及型运维”模式。如今,组织内更多岗位都应能够参与网络和应用服务基础设施部署的运维工作。要实现这一目标,就必须简化运维。

具体而言,就是简化运维。仅通过自助服务选项交付网络和应用服务还不够,还必须让实际使用这些服务的人员能够轻松上手。运维必须比现在更加简单。

这可能意味着为了提升可操作性而牺牲可配置性。

可配置性与可运维性

与云和容器一样,构建在网络和应用服务基础设施之上的抽象也延伸到了这些抽象的使用方式。这里指的是常用表达、术语、数据模型,以及实际配置。

对于阅读本文的非程序员来说,这意味着每个构造都有许多相关属性,这些属性共同组成一个“对象”。Virtual Server对象包含IP地址、应用程序Pool、事件、名称以及许多其他特征。其中一些特征本身也是对象或对象列表。遍历这些构造可能很复杂,因为在精细调整基础设施时,可配置性至关重要。需要能够调整非常具体的特征,例如启用或禁用Nagle算法,或调整TCP窗口大小,从而优化性能或容量。

如今,在我们正逐步迈向的标准化运营模式中,可操作性比可配置性更重要。选项越少,恢复正常运行越快。

但这并不意味着只需减少选项。仅仅取消调整选项的能力,只能满足可运维性的基本要求,无法达到简化运维体验的预期。仍然需要了解对象模型。真正需要的是将该模型抽象为更简单的形式。例如,将Virtual Server简化为一个IP地址、一个名称和一个应用实例列表。

商品化需要标准化

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

运维人员(无论来自开发团队还是IT团队)实际上都需要了解大量模型,才能部署和运行平均用于交付和保护应用的14项应用服务。这些服务差异很大,过去因此需要通过各种认证来证明具备管理这些服务所需的专业能力。

另一项运营转变是摆脱这种方法。人们期望不同产品都能做到简单、易用且具有共通性,从而减少设备特定运营模式带来的技术债务。这也是对标准化的期望;并非对协议和网络行为进行标准化,因为网络基础设施领域已经实现了这一点,而是对我们如何表示这些协议和网络行为进行标准化。

运营经济模式的转变

这一趋势也体现在容器化调查中:近四分之一(24%)的受访者认为,缺乏必要技能是采用容器化的主要阻碍,另有33%的受访者认为这是中等程度的阻碍。由于容器和容器编排系统如今已广泛应用于生产环境,因此基础设施无疑也包括这些技术。技能短缺和对速度的追求,正推动基础设施运营走向标准化。

这种愿望和需求体现在Kubernetes资源文件的自然采用上,这些文件试图描述上述基础设施服务。这些资源要求所有运维人员使用通用的(标准化)数据模型(格式),来描述特定服务的部署和配置。根据Diamanti的《2019年容器采用情况调查》,如今IT运维是组织采用容器的首要驱动因素(35%),其影响力接近开发人员(16%)的两倍、集成式DevOps团队(9%)的四倍。因此,必须认识到这一转变,并仔细考虑新基础设施如何融入(或无法融入)标准化运维环境。

无论是否有官方(工作组或基金会)推动,商品化都将促使运维领域形成事实标准。而这一事实标准将更注重可运维性,而非可配置性。

分享
标签: 2019

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

F5纪念2021年世界艾滋病日
F5生态系统 | 2021/12/01

F5纪念2021年世界艾滋病日

值此世界艾滋病日,F5郑重承诺,将与员工、客户、社区和合作伙伴共同努力,消除社会对HIV感染者仍然存在的污名与偏见。

Thingbot正转变为攻击平台
F5生态系统 | 2018/11/29

Thingbot正转变为攻击平台

Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究,并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用,还被转变为攻击平台,这意味着攻击者可以更充分地利用这个必然增长的市场。

借助F5全新Quick Start,在AWS上快速开展业务
F5生态系统 | 2018/11/20

借助F5全新Quick Start,在AWS上快速开展业务

在AWS re:Invent开幕前,我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。

为什么声明式模型对NetOps自动化至关重要?
F5生态系统 | 2018/04/30

为什么声明式模型对NetOps自动化至关重要?

为什么声明式模型对NetOps自动化至关重要?阅读F5博客,了解基础设施即代码如何简化网络扩展。

开源聚焦:F5基础设施即代码与多云可管理性
F5生态系统 | 2017/11/16

开源聚焦:F5基础设施即代码与多云可管理性

开源聚焦:基础设施即代码与多云。阅读博客,了解模板和Terraform如何简化F5应用服务的部署。

破解IT“无解困局”的答案:私有云
F5生态系统 | 2016/09/12

破解IT“无解困局”的答案:私有云

破解IT“无解困局”的答案:私有云。阅读F5博客,了解本地部署的敏捷性如何化解安全与速度难以兼顾的问题。