DevOps 与技术雷达
关于 Kubernetes
Kubernetes 现在是当仁不让的首选容器编排平台，在技术雷达中，也将其标记为采用。社区也发展出很多 Kubernetes 周边工具。
诸如 GKE，Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具，以改善采用和运行 Kubernetes 的整体体验。 事实上，它具备用一个调度单元来运行多个容器的能力， 可以让服务啮合(service mesh)和能够支持端点安全的 sidecar 得以实现。
SONOBUOY 是一个以非破坏性的方式在任何 Kubernetes 群集上运行端到端“合规性测试”的诊断工具。正在尝试使用 Sonobouy 作为“基础设施即代码”构建流水线的一部分，并对 Kubernetes 安装进行持续监控，以验证整 个集群的行为和健康状况。
关于架构
微前端（Micro frontends）
微服务架构可以让团队裁剪出独立部署的交付物以及可维护的服务。不幸的是，我们还看到许多团队在后端服务之上创建了前端单体，一个单一且庞大和杂乱无绪的浏览器应用。
小编认为就像上图这样，后端服务完成拆分，前端依然是单体的。所以技术雷达提出了微前端的方法，在这种方法中，Web应用程序被分解为多个特性， 每个特性都由不同的前后端团队拥有。这确保每个特性都 独立于其他特性开发，测试和部署。这样可以使用多种技术 来重新组合特性有时候是页面，有时候是组件最终整合成一个内聚的用户体验。
无服务器架构（Serverless architecture）
无服务器架构（一般更多在谈论函数即服务 Function as a Service）在云的不断发展下，越来越普遍，部署无服务器函数好不疑问能够减少大量传统方式特有的工作，比如涉及服务器和操作系统配置和编排的工作量。技术雷达也建议：做好回退至容器化或实例化部署的准备。
服务啮合（Service Mesh）
服务啮合(Service mesh)在服务发现、安全、 跟踪、监控与故障处理方面提供了一致性，且 不需要像 API 网关或 ESB 这样的共享资产。
服务啮合的一个典型实现包含轻量级反向代理进程，这些进程 可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通 信。通过该代理的共享实现(而非共享的运行时实例)，我 们可以获得服务的互操作性和可观测性。
Service Mesh 现在也被炒的很火，目前有 linkerd 和 Istio 等开源项目，值得大家关注。
持续交付
为基础设施即代码使用流水线
该技术倡导对基础设施使用流水线进行自动化验证，基于基础设施即代码实践（如：Ansible 的 Playbook、Docker 的 Dockerfile），对环境进行自动化的创建和测试。
TDD 开发容器脚本
容器脚本作为代码的一部分，理应使用测试驱动开发。借助 ServerSpec 和 Goss 等框架 ，可以为独立的或编排的容器定义预期的功能，并得到快速反馈。
压力测试
小编推荐技术雷达中的两款压力测试工具 Gatling 和 Locust，在 DevOps 时代社区的端到端持续交付流水线2.0中，也使用了 Locust 进行压力测试。
ASSERTJ-SWAGGER 验证你的 API 更新
ASSERTJ-SWAGGER 是一个 AssertJ 工具库，能够用来验 证 API 的实现是否符合其契约规格。当 API 端点的实现发生了更改但未更新其 Swagger 规格，或未能发布更新后的文 档时，我们的团队就能通过使用 assertj-swagger 来捕获这些问题。
点评：在流水线中应用该工具，可以有效避免API文档与代码不一致的情况
端到端测试分析工具
CYPRESS 能帮助开发人员轻易地构建端到端自动化测试，并且把测试的步骤录制在一个 MP4 文件里。这使得开发者可 以通过查看测试视频来修复测试，而不是在 headless 模式下去重现问题。
Javascript 的静态类型检查工具
FLOW 是一个针对 Javascript 的静态类型检查工具，它可以为整个代码库逐步增加类型检查。技术雷达建议把 Flow 添加到持续集成部署流水线中，并从最关注的代码开始做静态类型检查。
iOS 应用自动发布
fastlane 是一款强大的应用自动化发布管理工具。技术雷达中认为可以采用，小编认为值得推荐给大家。
越来越多的 CI/CD SaaS服务
在本次技术雷达图中，出现了多款 CI/CD 的 SaaS 产品，越来越多的团队也在采用类似云服务。这些工具大多支持构建任务的工作流，并具备扇入(fan-in)和扇出 (fan-out)流模式和手动触发模式，且支持移动开发。也允许开发者在本地运行流水线。技术雷达图中指出团队需要“低摩擦(low- friction)和易于搭建的构建与部署流水线”。
运维技术
基于算法的 IT 运维
小编理解技术雷达中基于算法的IT运维就像 AIOps，在 GOPS（全球运维大会）上海站上还有专门的分享
文章链接如下：
Prometheus 你值得拥有
在DevOps时代社区的流水线2.0中，我们也是采用 Prometheus 作为容器的监控工具，采用 Grafana 配置可视化数据。
多云策略
云厂商很多，云产品更多，在这种环境下，不是与一个提供商“全面”合作， 客户正在以最佳组合的方式，将不同类型的工作负载交由不同的供应商。这并不等同于致力于供应商间可移植性的“跨云策略”，后者价格昂贵且会导致迎合大众的想法。多云策略 则专注于使用每个云能提供的最好的服务。
点评：这是很有意思的一点，客户不在是只取一瓢。沃尔玛在实践 DevOps 过程中研发了 OneOps 是为了在多云之间的切换，不受绑架，看来后续应该还会出现更强大的多云管理工具，帮助企业管理多家云厂商的服务。
其他技术
轻量级架构决策记录
在软件开发中，大家一定遇到过这种情况：别人的代码不敢改。这背后的原因一般分为：不知道这段代码背后的决策原因，为什么写成这样；没有自动化测试保障，担心改了之后影响其他地方。轻量级架构决策记录是一种试图解决类似问题的方法。轻量级架构决策记录是一种用于捕获重要的架构决策及其上下文和结果 的技术。我们建议将这些详细信息进行版本化，而不是wiki 或网站，这样所记录的内容就可以和代码保持同步。
将产品管理思维应用于内部平台
一句话：“不要以为是给内部用的，就不把它当产品。” 这意味着要与内部消费者(开发人员)建立共情，并在设计上彼此协作。平台的产品经理要建立路线图，确保平台为业务交付价值，为开发者改善体验。
处理新功能与遗留系统的模式
Eric Evans 的自治气泡模式，这种方法为新应用程序的开发工作创建一个全新的环境，以避免遗留系统的纠缠。它并不仅仅使用了反腐层，这个新的气泡上下文还能完全控制其支持数据，然后通过异步的方式与遗留系统保持一致。要保护气泡的边界以及保持边界两侧的一致性需要花费一些工作，但是由此产生的自治性和 开发摩擦力的减少是迈向现代化未来架构勇敢的第一步。
点评：在实施 DevOps 过程中，大量的系统还面临着需要解耦合的难题，在面对遗留系统时，如何兼顾新功能开发，自治气泡模式也许是值得探究的方式。
让你的系统变得更加坚固
Netflix 是全球 IT 公司中实践 DevOps 的先驱者，Netflix 有一项独创的实践与工具，叫 Chaos Monkey，即随机终止生产系统中的运行实例，并对结果进行度量，从而帮助验证系统在运行时对生产中断的应对能力。这在传统的软件研发与管理模式下，是不可想象的事情。如今，基于 Chaos Monkey 发展出了混沌工程，在生产环境的分布式系统中运行这些试验， 可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。
3RS 安全技术
3Rs 企业安全:轮换、修复、重建，利用基础设施自动化和持续交付来消除攻击机会。当发现问题后，在非常短的时间内打上补丁，就和一次正常的通过流水线上线发布一样。
最后我摘出最喜欢的一句话送给大家：
仅仅提升薪酬水平是不够的，让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们，这是一个放之四海而皆准的通则。
“以上内容摘取自最新版 ThoughtWorks 技术雷达”。
相关 PDF 下载地址在这里（或点击阅读原文链接）：http://insights.thoughtworks.cn/tech-radar/