导读：IT的执行可以被理解为在时间和空间两个技术轴上开展， 如果想要达到更快的自动化和更小的步骤，那么选择时间轴显然更好，然后才考虑空间轴结构。当通过优化架构设计和编排来补充敏捷的渠道输出时，微服务才是最优选择。

DevOps的原理已经发布一段时间，并投入新兴的实践中已经有十多年了，DevOps发展的关键技术是容器和微服务编排系统，如Kubernetes。回顾DevOps的发展，开发人员的较小边界和强制包装通过像持续集成和交付这样渠道的保留，为今后DevOps的部署提供了更可靠的案例。
微服务架构并不是万无一失的，但它仍是当今具有速度和敏捷性的最频繁持续部署的最佳选择。

这些趋势对网络空间的意义是：

微服务网络和网络作为微服务

在服务网格与软件定义网络的技术试验中，微服务场景有三个关键位置联网：
1.在微服务设计中，这些部分变得越来越小，各部分间的网络越来越大，越来越繁忙，并且至关重要。 而且，除了微服务本身的零信任型保护之外，重要的是让网络被锁定。
2.服务发现，服务/ API网关，DNS服务告知，服务扩展和负载均衡，都属于网络管辖范围。
3.除了微服务之外，API、卷或磁盘上的任何状态的复制、备份或分析也可以在网络上进行。
鉴于网络对于微服务成功的重要性，网络组件大多是整体式的，这一点与微服务有很大的冲突。 更糟糕的是，部署应激是一种发生频率突增的反应：网络运营商有冗长的变更控制、异常的维护窗口，新的代码版本支持6-18个月的查询和可用性的多个修订。

DevNetOps的一小步

可以通过运行阶段的Spinnaker编排来开始使用“DevNetOps”：网络代码模型和存储库将被应用到所有配置、模板、代码和软件映像工件的CI / CD渠道。 通过对网络团队的新流程和技能培训（如编码和物流审查以及测试和分段仿真等），可以将小型CLI推送到生产环节进行修复，并重新恢复自动化程序， 避免产生更大的错误。
在时间轴上得到更正和信赖的途径是将自动化地操作时间线作为微修改步骤的渠道。
以前的操作实践可以由用户重新发明，可以利用供应商和开源的工具提供的帮助，但是供应商需要在架构方面占主导地位，他们是DevNetOps团队的首席“Dev”合作伙伴，追求微服务的目标比以往任何时候都更清晰。

DevNetOps的小部件：微服务

经过长年的对更大、更不良的网络设备的筛选 ，淘汰了一些比较大的不适合的供应商，他们的共同点是都忽视了云、容器和微服务每一步的发展。
很明显就像DevOps一样，微型工具是敏捷渠道的完美项目代表，尽管网络行业已经有了进步的迹象，但是仍然还有很长的路要走。
解决方案的一些优势包括支持Arista与其可扩展操作系统（EOS）交付分离的补丁包; 开放计算项目在其网络项目中普及软件和硬件分解; 和Juniper网络支持节点拼接和通用机箱分解，以实现更细的模块化和边界管理。此外，就像横向扩展的Clos那样的数据中心网络设计结构，在大型聚合设备上逐渐受到青睐。 在软件定义的网络中，像OpenContrail这样的项目现在被分为类容器。
在DevOps的世界中，部署质量是一定不需要担心的，但是对于DevNetOps来说，供应商和客户之间的24/7支持率几乎不会降低 操作者通过进行更改来转移部署时的应激反应。 此外，有不足的供应商更改代码与其捕获的时间间隔越长，产生的混沌就越多，引导的难度随之也就越大。
面临这些挑战，最佳应对方法就是微小、频繁的供应商交付，用户测试和部署。 从DevOps如何得到微服务成功的支持汲取灵感，如果现在更加关注DevNetOps持续和敏捷的业务，使供应商和架构师提供更好的微服务和网络设计，那么DevNetOps未来就会发展得更好。

原文：https://thenewstack.io/microservices-knock-knock-knockin-devnetops-door/