这是探讨数字化转型所带来挑战的系列博客中的第4篇。
规模不经济。
随着业务不断发展，尤其是经过较长时间后，往往会积累许多需要处理的负担。需要支持的应用数量很少会减少，通常会增加，有时甚至会在几年内呈指数级增长。即使在平稳时期，应用数量也往往每4年翻一番。当新技术强势涌入时，这一数字还会进一步增加。
每个应用都需要更多运维支持（简单来说，包括网络、计算、存储和安全）。但我们知道，纵向扩展终有极限（单靠增加硬件无法无限解决问题），人力资源也是如此。我们不能为了跟上应用增长而不断增加运维人员。这样做会增加管理开销，降低沟通效率，因为我们不仅要费力弄清职责归属，甚至连找到相应负责人沟通都很困难。
这正是“部署递减定律”揭示的现象。当运维工作增加到一定程度时，反而会阻碍部署，迫使我们开始权衡取舍。就像浮士德与魔鬼交易一样，我们选择速度而牺牲安全性，选择规模而牺牲稳定性。最终，我们会到达一个拐点，理论上的方法已走到尽头，开发、运维和业务团队开始转向其他途径寻求解决方案。
简而言之，为应对不断增加的应用数量，运维人员的增聘终有上限，否则就会触及“部署递减定律”。
因此，要让运维跟上应用数量的增长和加快部署的需求，自动化至关重要。因为无论输入速度有多快，计算机的处理速度都更快。
但请注意，自动化并不只是编写脚本。
我们已经编写了大量脚本，这无疑是让我们至少能跟上部署步伐的一个因素。要真正实现成功的自动化，就不应按单个设备或应用逐一执行。确实不应该这样做，因为这种方式无法扩展。如果要为每台设备或每个应用分别编写一个脚本，那就没有正确实施自动化。
自动化需要以流程和一致执行为核心（所以它其实是编排，不过我一直在为这个观点据理力争，却始终难以改变大家的看法）。这意味着需要采用自动化，而不只是通过脚本实施变更。为此，需要采用一种融合DevOps原则的新方法，例如基础设施即代码。
基础设施即代码
基础设施即代码是一种比喻。也就是说，实际的基础设施可能是软件或硬件，也可能位于云端或本地。对于部署而言，具体实现方式并不重要，因为我们将使用API和部署工件来实现基础设施即代码的行为。通过将配置与设备解耦，我们可以将设备视为黑盒。
关键在于部署工件，即用于为所需服务预配和配置设备的模板、脚本及策略。这些工件存储在本地存储库中。它们完整描述了特定服务，无论是网络、安全、存储还是应用基础设施服务，并可用于按需重新创建该服务。这些工件可用于自动执行单项任务，例如添加防火墙规则、部署负载均衡器和配置WAF；随后还可将这些任务整合到编排流程中，以实现持续部署。
这一点对于解决规模不经济问题至关重要，因为单纯使用脚本仍需逐台设备执行。脚本可以将原本需要5分钟的工作缩短到5秒，但仍需手动调用，并由人员推动整个流程。它无法满足自动化整个*流程*这一更重要的需求，而要在数字经济中保持竞争力，就必须通过这种自动化实现所需的规模经济。
敬请关注本系列的最后一篇文章，我们将深入探讨如何安全可靠地交付越来越多部署在容器化环境中的应用。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。