IT从业人员通常注重实践。对于负责将应用部署到生产环境并维护其可用性、安全性和性能的人员来说，作为一种文化转型，DevOps往往不够具体。但现实是，必须打破团队之间及团队内部的壁垒，推动文化转型，而且这一转型必须尽早实现。
在新兴趋势和架构对网络的影响方面，这一点尤为明显。
许多专注于网络的领导者和从业人员并未充分关注不断变化的应用架构格局。例如，除了提到我们的基础设施也有API之外，网络领域很少真正讨论向API和微服务的转变。毕竟，我们有SDN（或SDDC）。
但网络领域的领导者和从业者需要了解这些变化，以及它们必然会对网络产生怎样的影响，并如何影响这些应用向要求严苛的消费者和同事交付。即使某项决策看似完全属于应用架构范畴，最终也可能对网络架构、网络性能和要求产生重大影响。例如，选择多租户还是单租户微服务，会显著影响从安全到基本路由和交换的各类网络服务。如果未能认识到微服务结合使用HTTP/2或HTTP/1时所涉及的架构决策，可能会给网络带来严重问题并降低性能。
开发人员日益认识到，其架构会对自身领域内外产生影响。在高度分布式的应用架构中，服务延迟（两个服务通过网络进行通信所需的时间）是一个广为人知的问题。但开发人员尚未充分了解的是，网络及其服务栈如何帮助减轻此类环境对性能和韧性造成的负面影响。
这正是网络专业人员所了解的。
问题在于，直到海量微服务即将投入生产时，网络工程师才参与进来。此前没有征求他们的意见，而等到他们介入时再提出建议，可能意味着需要对服务或应用进行大幅返工。即使只是将可扩展性放在网络层而非应用内部实现这样一个简单的改动，也会变得异常棘手。但如果在设计服务架构时就考虑到网络可扩展性，整个过程就会顺畅得多。
但实际情况并非如此。至于那些因需要加快应用发布而感到压力的高管（每10位中就有9位）？他们面临的压力更大，因为要交付如此多相互连接、相互关联、相互依赖的服务，需要花时间对网络进行必要的调整。
IT领域有四类运维：基础设施、网络、存储和安全。这四个孤岛（如果您更喜欢中世纪风格的比喻，也可以称为高塔）都必须与其他领域建立沟通桥梁，以便在开发周期的早期促进协作与交流。架构选择方面的协作应在设计阶段进行，而不是等到部署阶段。这种协作可能需要由领导者发起，因为他们能够全面了解各个组织，并掌握其何时开始考虑新技术和新架构。
DevOps并不只是自动化，自动化只是实现目标的一种工具和技术。自动化可以显著减轻负责部署应用上线和交付所需服务的人员负担，让基础设施、网络、存储和安全这四个运维领域的专家有更多精力加强组织间的协作与共享，从而提升应用的扩展能力、性能和安全性。这些应用正是蓬勃发展的应用经济的核心。
企业要取得成功并实现增长，不仅需要IT一线团队协作，也需要管理层共同参与。
关于作者
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服务。