在纽约DevOps峰会上，讨论的话题不仅包括DevOps，还涵盖容器、物联网和微服务。会议不仅关注采用DevOps方法实现规模化发展所需的文化转型，还探讨了必要的网络“基础设施”，以确保应用拆分为微服务架构时顺利运行，从而支持快速增长和“万物互联”。
容器、微服务与网络
Docker的Jerome Petazzo (@jpetazzo)探讨了微服务及其与容器的天然契合性。他的讨论重点指出，要实现独立扩展、服务发现和弹性，并管理微服务所形成的日益依赖网络的架构，就需要“网络”。事实上，DNS在服务发现中发挥着自然而重要的作用，可在服务层提供必要的抽象，使服务不依赖网络寻址方案，而是利用DNS快速更新服务的实际位置（在扩展场景中则为服务端点的位置），从而确保无缝连接。
很高兴看到，业界已经认识到，对于应用及其基础设施领域之外的能力，很多情况下需要将“网络”纳入其中并加以依赖。IT应用团队认识到，需要在其架构中纳入“网络”。因此，IT网络团队必须认识到，需要采用更具可编程性和协作性的服务交付方式，为应用团队提供支持。微服务尤其凸显了这一需求，这也是我的演讲“微服务架构如何推动DevOps向网络领域延伸”的主题（链接指向演示文稿）。
John Willis（@botchagalupe）深入探讨了不可变基础设施，并介绍了如何以及为何应将应用基础设施（包括服务器和平台）打造为不可变基础设施。这一概念同样适用于负载均衡、应用安全和加速等与应用紧密相关的服务。他认为，依赖基于脚本的长期管理可能危机重重。顺便说一句，我也认同这一观点。命令顺序、缺乏适当的回滚选项、一般性故障，以及脚本未能处理故障，都可能造成严重中断，尤其是在对中断敏感的生产网络中。不可变基础设施模型的前提是，软件包、配置、应用或数据一经部署便不可修改。采用这一模型，组织可以构建更稳定、更敏捷且更易于管理的环境。他还提供了一套实施不可变基础设施的简单方法：
1. 配置新资源
2. 测试新配置
3. 将流量定向到新版本
4. 保留旧版本，以便回滚
DevOps 是症状，而非解决之道
最后，我还旁听了Mark Thiele（@mthiele10）的演讲。他认为，DevOps是组织健康发展的表现，而不是实现组织健康发展的手段。这位Switch SUPERNAP副总裁建议各组织“假设当前的工作方式无法满足未来的扩展需求”，并持续从人员和流程入手，获得应对下一项重大需求所需的扩展能力。与当今的应用一样，扩展需求并非一成不变，因此IT整体上需要采用更敏捷、更具协作性的方式。Mark更关注效率和业务价值。他指出：“IT的诞生并不是为了降低IT成本”，而是为了创造业务价值。为此，他鼓励各组织从服务而非技术的角度思考，并以协作方式设计和交付这些服务。
协作一直是一个共同主题，大家对各个孤岛内部的隔阂与IT孤岛本身同样关注。打破孤岛壁垒，无论是在IT团队内部还是不同IT团队之间，不仅对于制定和执行应用交付时间、性能、扩展能力及安全方面的策略至关重要，也有助于定义和实施必要的流程，从而优化应用从开发到生产、从应用到用户的端到端交付。
总体而言，微服务与容器之间的联系受到重视，同时还需要采用DevOps方法来管理由此激增的服务及其支撑基础设施。随着各组织开始迈入一个很可能类似于.com时代指数级增长的新阶段，物联网将成为相关技术（容器、微服务和软件定义网络方法）及整体DevOps方法的重要驱动力。
以上就是来自纽约的全部内容。祝您周四愉快！
关于作者
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服务。