从最新一期技术雷达看 DevOps 的发展
目录
今年4月份，我第一次以主编的身份参加技术雷达的翻译工作。有幸第一时间参加到技术雷达的翻译过程中。通过我在翻译其间对条目的了解和观察，我写下了《 DevOps发展的九个趋势》
今年11月份，我再一次以执行主编的身份参加第17期技术雷达的翻译工作。17 期技术雷达中两大主题：Kubernetes 和 Cloud as the New Normal 都是 DevOps 相关的。而且本期技术雷达涌现了众多 DevOps 相关的新条目。一方面说明了 DevOps 在 IT 业的重要性日渐增加，一方面也支撑起了 DevOps 社区在工具和实践上的创新。虽然每个人对 DevOps 的理解不尽相同，但能持续的着眼在具体的问题并提供实际的解决方案则是值得称道的。
这些新的变化对我上一期的 DevOps 技术趋势判断和发展有了新的思考和认识，借由此文分享给大家。
回顾2017年 DevOps 发展 #
在今年 4月第16期技术雷达发布后，我分析了 DevOps 发展的九个趋势。我认为这九个趋势代表了2017年 DevOps 技术的发展方向。让我们来结合最新的技术雷达回顾一下2017年这些趋势的发展。
趋势1：微服务目前仍然是DevOps技术应用和发展的主要领域 #
现状：微服务的相关技术仍然不断涌现。但人们似乎过于乐观的估计了微服务的投资回报速度。架构演进是一个长期的过程，而实践中的陷阱和问题越来越多。不断涌现的诸多工具和解决方案说明了微服务的反思已经开始。让我们期待更多微服务的案例出现。
趋势2：以Docker为核心的数据中心方案逐渐走向成熟 #
现状：Kubernetes 生态圈在 Docker 编排工具的争霸大战中笑道了最后，本期技术雷达把 Kubernetes 移动到了“采用”中，证明 Kubernetes 是经得住时间考验的工具。随着越来越多的厂商和社区开始围绕 Kubernetes 构建自己的产品，我相信基于 Kubernetes 的产品和工具会越来越多。
趋势3：不完整的DevOps实践阻碍着DevOps的发展 #
现状：虽然 DevOps 社区的活跃程度催生了一大批的工具和平台，但却在推广实践上发力不足。接受了局部技术改进后的 DevOps 演进似乎立刻停止，使得 DevOps 难以发挥出更大的价值。随着时间的发展，这种局面会愈来愈常见。如方法论的推广落后于工具的发展，那么 DevOps 运动的寿终正寝也将为期不远。
趋势4：领域特定的DevOps实践开始出现 #
现状：虽然并没有十分特别的领域特定的 DevOps 技术出现。但受到 DevOps 启发的 DesignOps 和 DevSecOps 也分别有了自己的社区群体。期待它们在未来有进一步的表现。
趋势5：采用DevOps进行技术债务重组和技术资产管理 #
结果：我写下这个趋势的第二周就进入了这样一个技术资产管理项目并工作到现在。在这 6 个月中我和同事们采用了 DevOps 理念和技术进行技术资产重组和互联网企业 IT 资产并购，并体会到了其中的诸多益处，大大节约了产品上线时间和上线风险，而且产品的开支的随着时间以更快的速度递减。随着 CloudNative 的技术和概念的成熟，相信这类的项目和案例会越来越丰富。
趋势6：安全成为推动DevOps全面发展的重要力量 #
结果：OWASP Top10 和 OWASP Top10 Mobile 的姗姗来迟虽然并未进入本期技术雷达。但并不表明技术雷达对安全有所松懈，这反而是一种更加负责的态度。而安全相关的实践已从使用工具进入安全场景的设计。例如最新期的 3Rs 安全 和 上一期就提到的 KeyCloak，以及本期提到的用于安全的 Sidecar 模式。
趋势7：Windows Server和.NET平台下的DevOps技术潜力巨大 #
现状：随着 Azrue 的成熟 和 Windows Conatiners 的推出，Windows 领域的 DevOps 关键工具链即将打通。但是 MS-DevOps 的“最后一公里”显得比较艰难。MS-DevOps 的社区的发展并不活跃，使得 Windows Server 的相关实践略显不足，这进一步限制了 DevOps 相关技术在 Windows 平台上的作为。
趋势8：非功能性自动化测试工具的逐渐完备 #
现状：更多的工具开始围绕“自动化测试”展开，关于自动化测试为开发带来的诸多益处以无需多言。在本期技术雷达里我们看到了更多这样的技术出现，例如：TDD in Containers，Flood.io 用于负载测试，Heptio Sonobuoy 用于合规测试。而一个成熟稳健的架构，必须要经得起来自各方面的测试。
趋势9：Python成为DevOps工作中所不可或缺的语言 #
现状：Python 仍然重要，但 Go 语言在 Ops 相关工具中的地位也在逐步提升。
2018 年的 DevOps 技术的发展趋势 #
虽然条目众多，但我们可以从技术雷达中整理出 4 个 DevOps 发展脉络：
趋势1：微服务的实践进入深水区 #
微服务在部分企业的成功给所有的企业描述了一个美好的愿景，但通往这条美好之路的路程则并不那么一帆风顺。
微服务是成功的结果，而非成功的原因，我把成功的架构转型经验的结果架构称之为微服务架构。但这并不是微服务成功的动因，毕竟这些最初成功应用微服务企业最开始的时候并没有“微服务”的概念。而能够让微服务成功一定是在特定场景下遵守了某些重要的原则。而这些特定的场景和原则似乎被人忽视，而只能从表象上描述这一成功的结果。
随着微服务在各种场景下的应用，针对不同行业，不同组织，不同技术上下文的实践被慢慢总结出来。有些是成功经验，有些则是反思。例如: **Service Mesh （服务啮合）**和 **Overambitious API gateways（过度庞大的API网关产品）**就是相互关联的技术。而 KONG API Gateway 就是一个十分不错的 API 网关工具，但结合了不同的上下文，可以得到不同的结果。
成功微服务实践者一直在强调康威定理的重要性，而现实中的企业往往忽视条经验。同样的技术和工具，在不同的业务上下文和组织结构里，就会得出不同的结果。Kafka 的使用并不能表示你正在往正确的路上走，仅仅替换了工具而非思维和架构模式会将你带入 Recreating ESB antipatterns with Kafka（用 Kafka 重建 ESB 反模式）。所以，采用某些技术或工具一定要识别对正确的场景。
另一方面，成功的经验和重复被证明成功的微服务实践则作为框架被流传了下来。Spring Cloud 作为微服务解决方案的杰出代表继续在技术雷达中拥有自己的一席之地，以至于现在任何一本关于微服务的书都是以 Spring Cloud 展开的。此外，技术雷达里有增添了 Spring Cloud 的新成员：Spring Cloud Contract 是和 Spring 框架结合紧密的消费者驱动契约测试的工具。这说明消费者驱动的契约测试被证明是有效的微服务测试方法。尽管技术雷达第一次提出消费者驱动的契约测试已经过去了3年。
当微服务的架构转型到了深水区，微服务的标准实践架构即将出现，一扫微服务生态圈的混乱情况。就如曾经发生在 Docker 社区中的一样。
趋势2：如果你正在使用 Docker，请向 Kubernetes 迁移 #
技术雷达一直保持着对 Docker 社区的关注度，因为这是我们普遍采用的技术。但在大规模的使用上面，技术雷达则相对保守，尽管技术雷达从 2015 年就开始关注 Kubernetes ，但直到这次才放到“采用”区域里，证明了Kubernetes 已经非常成熟。围绕着 Kubernetes 生态工具链也逐渐完善，无论是厂商（Google 的 GKE 解决方案，还是 AWS 的 EKS）提供的完整平台。还是社区的 Kops 和 Sonobuoy 这样的，都不断在增强 Kubernetes 在生产环境的实际应用能力。
如果你之前也在观望容器大战，现在可以果断进入 Kubernetes 了，如果你准备在生产环境使用 Docker，请优先考虑 Kubernetes。如果你已经用了 Kubernetes，那么恭喜你！希望你能将你的杰出实践经验分享给大家。
趋势3：Cloud Native DevOps #
云计算技术不光极大降低了 IT 运营成本，更改变了开发和运维的工作方式。DevOps 在企业级的应用遇到的更多阻力在云端，无论是应用架构还是工作方式。
很多企业仍然仅仅把云平台当做一个 “远程托管机房”，并没有发挥出云平台组件和 SDK 带来的组合性优势。
CloudNative 最大的思维转变当属 Stateless Infrastructure（无状态基础设施）。这样可以大幅度保障应用的可用性和水平扩展能力，当传统的计算资源和存储资源已经通过云计算技术达到了海量。应用的瓶颈就来自于应用架构和基础设施结构。如果还在思考基础设施的状态如何监控和保存，就又进入了老的思维模式，只不过换了新的工具而已。
Serverless Framework 和 Apex 框架就是采用 CloudNative 思维的代表，在实际的应用中它颠覆了我们对软件开发和运维的很多认识。把基础设施当做一个资源相对无限的状态机，你的应用就是这个状态机的状态配置，并通过版本化的手段在线保存状态。把对基础设施和设备的依赖降低到最小：只需要一个代码库。
而在这样的情形下，我们不需要构建一套开发环境和测试环境（你并不想只十几行代码就需要搭建一套虚拟的云计算环境）。而全部都在生产环境上工作，只不过生产环境有高级别的隔离，且各部分状态不同，有的是在生产状态，有的是在开发测试状态。
此外，更多的开发基础设施和测试工具以平台的形式也相继推出，它们不光提升了安全性和稳定性，更降低了企业 IT 资产总和管理成本。例如：CircleCI 和 BuildKite 就是持续集成服务器的平台化实现，只需要在代码里有很少的配置就可以解决搭建整套持续交付流水线的各种繁琐步骤和功能。Flood.io 则是通过在云端模拟大量的用户访问请求进行负载测试，这不光有助于你发现自己的基础设施和应用的瓶颈，更能帮你预演在高流量的状况下整个团队的响应能力。
由于众所周知的原因，我们无法访问本期技术雷达提到的 GCP（Google Cloud Platform），有限的使用 AWS 和 Azure，但仍然无法阻挡云计算的发展迅猛之势。
当云计算平台提供了一系列廉价而又灵活的基础设施之后。实践 DevOps 的你需要思考如何把传统的实践推向极致。
趋势4：自动化，更多的自动化 #
自动化永远是 DevOps 的核心主题之一，各种自动化测试工具和平台的兴起似乎在说明我们以往的自动化测试是不够的。新的自动化测试工具和方法正在越来越多。本期我们看到了关于 TDD in Containers 和 Sonobuoy，由于新版本 Chrome 的 Headless 模式的发布，未来的自动化测试则会越来越多，越来越完整。
我们可以把基础设施想象成一个软件产品，通过基础设施流水线构建这样的产品。我们甚至可以使用基础设施流水线把生产环境的更新做到极致：每天进行生产环境的从头构建，自动化配置网络以及基础设施，自动化还原数据库备份，每天产生一个可用的架构。这样的生产环境上就会有两个架构：一个生产中，一个待生产。你不在需要开发环境和测试环境，每天的工作都保存在待生产的架构上。由于第二天就要发布，因此今天会把所有的工作控制在明天发布之前完毕，而且要符合生产要求。这样就可以迫使团队把自己的工作自动化并且提升交付质量。也避免在自己的电脑上或者某个代码分支上存储很久。
数据中心的灾后重建就是极为痛苦的事情，因此需要做灾备预演。而现有的阶段性灾难预演已经无法满足要求。所以对于云端的基础设施来说，有灾难要预演，没有灾难要制造灾难预演。这样可以使你基础设施和应用架构达到极端的可用性和可恢复性，同时实现了3Rs安全。就像《持续交付》一书中所说的：经常做那些让你感到痛苦的事情。由于 AWS 提供了 VPC 级别的隔离，我已经可以通过 CloudFormation + Ansible 做到这一点，未来会把相关经验分享给大家。
另一方面，我们看到了 基于算法的IT运维（Algorithmic IT Operations），甚至提出了 AIOps 的概念。但基于算法的运维仍处在初步阶段。虽然我很乐于看见新的技术发展趋势，但每个领域的 AI 热潮是掩盖了真正的问题，还是让我们更快的找到了问题的正确答案？还有待观察。
最后 #
17 期的技术雷达的关注重点在 DevOps 上。一方面说明企业级应用正在全面的向云迁移，另一方面也说明云平台上的技术发展也在同样进步。在这个过程中我们遇到了新的问题，同时也遇到了新的机遇。当前这一系列的DevOps 技术的浪潮会带来什么样的发展，明年的技术雷达将会揭晓。