DevOps 峰会： 网络受邀参加聚会的地方

在纽约 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 方法。 马克更关注的是业务效率和价值，并指出“IT 的创建不是为了降低 IT 成本”，而是为了增加业务价值。 为此，他鼓励组织从服务而非技术的角度思考，并采用协作的方式来设计和提供这些服务。

协作一直是一个共同的主题，人们对孤岛内部孤岛的关注程度与对 IT 孤岛本身的关注程度一样高。 跨越孤岛（无论是 IT 团队内部还是跨 IT 团队）不仅对于制定和执行有关应用的交付时间、性能、规模和安全性的政策非常重要，而且对于定义和实施优化应用从开发到生产、从应用到用户的端到端交付所需的流程也非常重要。

总体而言，强调了微服务和容器之间的联系，以及使用 DevOps 方法管理由此产生的服务和支持基础设施爆炸式增长的必要性。 随着企业开始着手进行类似于网络时代经历的指数级增长，物联网将成为技术（容器、微服务和软件定义的网络方法）和总体方法 DevOps 的重要驱动力。

以上就是来自纽约的全部内容。 星期四快乐！