这是探讨数字化转型所带来挑战的系列博客中的第二篇。
云环境乱象。
此刻，某位聪明的工程师可能正在指出，这个说法有些多余。毕竟，云本身就是一片混乱：缺乏治理，对那些没有明确计划便被投入云端深处的应用，其安全防护也采取放任态度。
这里不妨稍作停顿，指出与云相关的混乱通常是人员和流程问题，而非技术问题。
这并不是说云没有技术挑战，或者至少没有架构挑战。其中一些挑战与虚拟网络的复杂性有关，但大多数属于架构层面。其中一项架构挑战源于云本身以单个应用为中心的特性。
仔细想想，公有云及其部署模型被视为理想的云形态（用柏拉图主义者的话说，就是“云的理念”）。这意味着私有云也应遵循其原则，并具备相同的特征。
这意味着需要提供API和自助式配置，以及仪表板和基于Web的控制台。但这也意味着要进行架构转型，转向完全以单个应用为中心的部署模式。
在云环境中，按应用构建架构已成为常见做法。服务按单个应用进行部署和配置，并形成一条从用户到端点、途经这些服务的专用数据路径。这与传统数据中心的网络设计形成鲜明对比；在传统设计中，大量网络和应用服务基础设施由多个应用共享。
在DevOps和敏捷开发领域，与公有云一样强调按应用构建架构时，“共享基础设施”这一理念便面临挑战。
传统的共享基础设施和网络会形成“从入口到应用的唯一固定路径”。在当今快速发展的数字化世界中，这种方式带来的挑战包括：
- 基础设施版本协调一个应用可能需要升级或补丁所提供的功能，而另一个应用则依赖现有版本。共享基础设施通常不允许同一系统中存在多个版本，因此可能会为了满足一个应用的需求而阻碍另一个应用。
- 部署计划冲突。 当共享资源受到影响时，企业会进入协调阶段，由应用相关方设法解决部署计划冲突。这一过程可能很漫长（而且总是令人头疼）。如果新应用或更新因计划冲突而推迟，任何一方都无法从中受益。
- 影响范围。不言而喻，如果我的应用导致共享系统发生故障，依赖该系统的所有应用都会出现故障。共享基础设施的影响范围很大，这是企业不愿向IT部门以外的人员开放更多部署流水线访问权限的重要原因。
- 故障排除。逐条翻查聚合日志十分费力。有些非常成功的公司，正是凭借挖掘海量日志并将数据拆分还原为各应用流的能力发展起来的。共享系统的故障排除既复杂又耗时，还会延长平均解决时间，而这是现代IT的一项关键KPI。
在云环境中，这些通常都不是问题。每个应用都有自己的路径，因为应用通常会按照各自的计划部署在各自的环境中，而且往往由不同的团队负责部署。
为了避免让我们（以及数据中心）不堪重负，无论是否采用私有云，都需要在本地环境中采用这种方法。
共享网络服务仍然不可或缺。防火墙、入侵防御系统/入侵检测系统（IPS/IDS）、DDoS防护和用户检查基本不受具体应用影响，可以（也应该）在整个企业范围内实施。除此之外，其他服务和基础设施则按应用提供（也可称为应用专属服务和基础设施）。这种逻辑隔离既能保障业务的稳定性和安全性，又能支持更靠近应用、变化更频繁且可能不够稳定的环境。同时，它还为传统应用（包括旧式应用和沿用已久的应用）保留了数据路径，因为这些应用不需要新型应用所需的速度和支持。按应用构建的网络可以是私有云、多个容器集群，也可以是二者的组合。
二者相结合，将打造更稳定、更具韧性，同时兼具灵活性和速度的网络。
按应用构建网络的方法不仅可以缓解共享式方法与现代应用架构和交付模式结合所带来的问题，还具有多种优势：
- 独立的流水线和计划。部署准备就绪后，我可以自行安排部署时间，因为部署不会影响其他应用或基础设施，只会影响我自己的应用和基础设施。这种灵活性有助于满足现代数据中心中各种不同的计划需求。
- 限制故障影响范围。如果我的部署导致专用系统崩溃，影响仅限于我自己的系统，不会波及任何其他应用。这种为每个应用提供专用数据路径的方法也让故障排查更加容易，因为我可以确定所有系统上的日志和错误消息都与我和我的应用有关。
- 扩展能力不受平台资源限制。在高度多变的动态环境中，几乎无法预知下一波访问高峰何时到来、某些内容是否会迅速走红，甚至是否会遭受攻击。无论原因是什么，当共享系统（硬件或软件）上的应用需求激增时，其扩展能力都会受限于平台的可用资源。采用按应用划分的架构有助于缓解这一限制，使各个组件能够根据需要进行横向扩展，以满足需求。
- 支持真正的基础设施即代码模型。共享系统使用共享配置，即使只是包含每应用策略的基础配置。在尝试实施基础设施即代码模型时，这种方式可能会造成混乱，尤其是多个应用同时尝试更新时。更改可能会在没有预警的情况下影响其他应用；当所需资源被其他应用锁定时，提交和克隆操作也可能失败。每应用架构可确保部署工件仅属于一个应用，并由应用所有者（无论是开发、DevOps、NetOps还是其他团队）妥善管理。
虽然按应用架构无法解决数字化转型带来的所有问题，但它可以在很大程度上帮助控制云环境造成的混乱。它为安全标准化提供了更多机会，同时也能支持大多数企业正在采用的多云环境。
敬请关注本系列的下一篇文章。届时，我们将深入探讨如何应对因数字化转型带来的上市压力而忽视安全的问题。
关于作者
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服务。