从第19期技术雷达看 DevOps 的发展趋势

2018年下半年的技术雷达发布了。看过的朋友可能和个人感受同样，会发现大部分条目都是和微服务和 DevOps 相关，但这些条目散落在不一样的象限里。本文将这些散落在不一样象限的条目采用如下 5 个主题进行重组：

1. DevOps 合做新实践
2. 云计算新实践
3. 容器新技术
4. 微服务及其误区
5. 安全

特别要提出的是，这期技术雷达采纳了 2018 年的 DevOps 报告 中的四个关键指标(FOUR KEYMETRICS):前置时间，部署频率，平均恢复时间(MTTR)和变动失败百分比。而这四个关键指标也是业界度量 DevOps 效果的统一方式。

每一个指标都创造了一个良性循环，并使团队专一于持续改进:缩短交付周期，减小浪费的活动，从而使你能够更频繁地部署，进而改进他们的实践和自动化流程。经过更好的实践，自动化和监控能够提升你从故障中恢复的速度，从而下降故障频率。

DevOps 的合做

如何更好的在组织内合做是 DevOps 实践中永恒不变的的话题。随着 DevOps 合做理念的深刻，合做的范围愈来愈越广，随之带来了新的问题和挑战。这期的技术雷达介绍了如下几方面的合做：

1. 和外包团队/供应商的 DevOps 合做
2. 和用户/客户/UX设计师的合做
3. 分布式团队之间的合做

和外包团队的 DevOps 合做

而随着 DevOps 应用的加深，会不可避免的碰到组织结构上带来的问题。特别是和外包方的合做，会影响组织的 DevOps 表现。这样的合做每每充满了漫长繁冗且火药味十足的会议和合同谈判，这是 DevOps 运动中不但愿看到的可是又没法避免的问题。在 2018 年的 DevOps 报告中看到外包会带来效能降低——“低效能团队将整部分职能进行外包的可能性几乎是高效能团队的 4 倍，这些 外包功能包括测试或运维等等。”

看到这里，千万不要得出“不要用外包的结论”。这里说得是不要“职能的外包”，而“端到端的外包”（End-2-End OutSourcing）则会免除这种顾虑。不少业界一流的 IT 服务企业都提供端到端的 IT 外包服务，你只须要告诉它们你要DevOps，它们会用最有效的方式交付给你。与供应商一块儿增量交付(INCREMENTAL DELIVERY WITH COTS (commercial off-the-shelf)) 就是这期技术雷达中提出的和外包商一块儿进行 DevOps 策略之一。与供应商的作端到端的 DevOps 性质的外包另一个优势则是这样的供应商适合作“长期合做伙伴”来补充你业务、IT 等多样性的不足，甚至可以帮你培训员工。

而随着组织开始采用四个关键指标，这对对供应商的要求也愈来愈高，但盈利空间相对愈来愈小。和任何行业同样，成本的下降和效率的提高永远是不变的主节奏。外包也要提高本身的能力水平以跟上技术发展的节奏，这是不可避免的成本。

可是，和外包方的合做仍然是在 DevOps 转型过程当中不可避免的痛苦，能够采用一些方式减轻这种痛苦。例如这期技术雷达中介绍的“风险相称的供应商策略(RISK-COMMENSURATE VENDOR STRATEGY) ”，它鼓励在高度关键系统中维持其供应商的独立性。而那些相对不过重要的业务能够利用供应商提供的成熟解决方案，这可让企业更容易承受失去该供应商所带来的影响。这不光是说 IT 产品供应商，一样也指的 IT 服务供应商。

“边界购买（BOUNDED BUY）”就是这样一种实践，在采购产品中即只选择模块化、解耦的，且 只包含于单一业务能力(Business Capability)的限界上下文(Bounded Context)中的厂商产品。应该将这种对 模块化和独立交付能力的要求，加入对供应商选择的验收标准中去。也能够将一小部分业务的端到端维护外包出去，在得到灵活性的同时，又得到高效。

和 UI 的合做 ——DesignOps

DevOps 的目标就是尽量的缩短最终用户想法到代码之间的距离，避免传递过程当中的信息失真。特别是用户的反馈，因而有了 DesignOps 实践。这个领域的实践和工具也日渐成熟。这期的技术雷达介绍的一整套支持 UI 的开发环境(也称为UI DEV ENVIRONMENTS)专一于用户体验设计人员与开发人员之间的协做，例如 :Storybook ，react-styleguidist，Compositor 及 MDX。这些工具大部分围绕 React 的生态圈产生。既能够在组件库或设计系统的开发过程当中单独使用，也能够嵌入到 Web应用项目中使用。

分布式团队的合做

随着组织的扩大，分布式的团队是一个没法回避的问题。你极可能会和不一样地理位置的其它同事一块儿开发，例如：不一样的办公楼，不一样的城市，甚至是不一样的国家。但这些问题不是 DevOps 的阻碍，能够经过一系列的工具来弥合地理上的界限。

Visutal Studio Code 目前是最受欢迎的编辑器和开发环境。而 VS Live Share 给分布式的跨地域协做开发的能力，它是用于 Visual Studio Code 与 Visual Studio 的插件。提供实时合做编辑与调试代码、语音通话、共享终端和暴露本地端口等功能，可以减小远程结对编程时遇到的障碍。开发人员能够在使用Live Share 协做时沿用本身的编辑器配置，包括主题、快捷键和扩展。

云计算新实践

若是你仔细看技术雷达，这期的技术雷达把 AWS，Azure 和 Google Cloud Platform 这三个世界上最大的云计算供应厂商放到了 Trail（试验）象限。这说明在采用云计算的时候，须要注意防止被云供应商绑定。从这个角度来讲，Kubernetes 这样平台无关的技术要更好。

设置多云帐号(MULTI-ACCOUNT CLOUD SETUP)能够避免被单一的云供应商绑定，能够平衡的结合采用多个云平台的优点来动态的配置你的云计算经验。

CHAOS KATAS 是一项为基础设施和平台工程师提供技能培训和提高的技术。它将 Kata （我我的更倾向于把 Kata 翻译为 套路）的方法论与Chaos Engineering 的相关技术(具体指在受控环境中模拟故障和停机)进行结合，对工程师进行系统化教学和培训。这里的 Kata 是指触发受控故障的代码模式，它容许工程师发现问题，恢复故障，开展过后分析并找到根本缘由。工程师经过重复执行Kata能帮助他们真正掌握新的技能。

用基础设施即代码提高基础设施的质量

管理云计算资源最有效的形式是采用基础设施即代码技术。在这一方面，早期的 Chef，Puppet 已被 Ansible、Salt 等取代。然后继之秀 Terraform 则简化了不少的云计算平台上的基础设施配置工做。如今，Terraform 已经成为公有云基础设施即代码的第一选择。这期的技术雷达介绍了Terragrunt，它是Terraform 的一个轻量级的封装，用来落地《 Terraform: Up and Running 》书中主张的实践。固然，在采用它以前你能够先读一下这本书。

若是你使用了 AWS，而且向经过编程的方式生成基础设施即代码。你可使用Troposphere，Troposphere 是一个Python 库，可使用 Python 代码生成 JSON 格式的 CloudFormation 描述。这样的代码的复用性和设计都会很好，同时它也有类型检测、单元测试以及 DRY 组合 AWS 资源等功能。�

在云原生的环境下，跨平台，跨实践的基础设施即代码技术将成为下一个基础设施即代码的发展方向。Pulumi就是这样一款“云原生即代码”工具，它提供了一个云原生开发平台，为全部的云原生应用经过一致的编程模型和统一的DevOps实践，帮助团队大幅提高生产力，并以很快的速度将代码迁移到云中。

结合往期的技术雷达，能够看出，在有效的采用基础设施即代码的技术上，除了版本化和自动化之外，基础设施即代码正在向可测试性和合规性的方向发展。对基础设施质量的度量和检测能够经过基础设施即代码来实现。而除了公有云平台，不多能够见到企业对私有的基础设施质量的关注。和软件产品同样，基础设施也会存在技术债，而这些技术债会引起应用程序的技术债的连锁效应。好比，你采用了老旧的设备和老旧的操做系统，在缺少管理的状况下，网络、安全甚至是性能问题愈来愈凸显，而系统会愈来愈脆弱。

Kubernetes 和容器

Kubernetes 已是容器生态的核心，由于除了 Docker 之外，还有其它的替代容器方案能够选择。但编排方案的选择却不会太多。为了保持容器镜像的大小，你们每每会采用 Alpine 和 Busybox 这样袖珍的镜像做为基础镜像。避免安装和配置那些无用的软件包和SDK。如今有了 DISTROLESS DOCKER IMAGES 这样的选择，能够被翻译作 “非发行版的 Docker 镜像”，它由 Google 开发，并给每种语言运行时都创建了�发行版无关的镜像，兼顾了安全性和大小两方面。

在 Kubernetes 运维方面，这期的技术雷达新增了两个工具。Kube-Bench 和 Heptio ARK。前者是大名鼎鼎的 K8S 机器学习社区 Kubeflow 推出的一款基础设施配置扫描工具，基于 K8S的 CIS 评分自动检查 Kubernetes 配置，涵盖用户身份验证，权限控制和数据安全等方面。后者是Kubernetes 跨云的解决方案厂商 Heptio 推出的一个集群和持久化卷的灾难恢复管理工具。使用 Ark 能够显著缩短基础架构发生故障时的恢复时间，还能轻松地将 Kubernetes 资源从一个集群迁移到另外一个集群，或者复制生产环境用于测试和排错。Ark支持主流的云存储提供商(包括 AWS ，Azure 和 GoogleCloud )，而且从版本0.6.0开始，提供了插件系统用于兼容其余备份与卷存储平台。虽然 GKE 等 Kubernetes 托管环境已经提供了这类服务，但若是须要自行运维 Kubernetes ，不管是在本地仍是云端，都请仔细考虑使用 Heptio Ark 进行灾难恢复。

Rook 是一款运行在Kubernetes集群中的开源云原生存储编排工具，如今仍然在CNCF 进行孵化。与Ceph集成以后的Rook，能将文件、块和对象存储系统引入到 Kubernetes 集群中，并能与使用这些存储的其余应用和服务一块儿无缝地运行。经过使用一些 Kubernetes operator，Rook能够在控制层上编排Ceph，这样就能够避免挤占应用程序和Ceph之间的数据通道。

Kubernetes 一直是 无服务器架构（Serverless Architecture）的理想平台，围绕着 Kubernetes 已经有了不少 Serverless 解决方案，如 Kuberless 和 OpenFaaS。Knative 是 Google 推出的基于 Kubernetes Serverless 方案，你能够把它部署在任何 Kubernetes 集群上。

Service Mesh 提供一致的发现、安全性、跟踪、监控和故障处理，而无需共享API网关或ESB等设施。典型的实现是将每一个服务进程和轻量级反向代理以Side-Car 的方式一块儿部署，反向代理进程可能在单独的容器中。这些代理与服务注册表，身份提供者，日志聚合器和其余服务进行通讯。服务互操做性和可观测性是经过此代理的共享实现而不是共享运行时实例得到的。

随着集中式的微服务网关和服务注册/发现机制的逐渐臃肿，Service Mesh 会接起微服务规模化的接力棒。随着 Linkerd 和 Istio 等开源项目将逐步成熟，这使得 service mesh 更容易实现。目前 Istio 仍遭受了来自性能方面的担忧，但我相信在某些场景下，这些性能损耗是能够被复杂性平衡的。

Kubernetes 生态圈的发展一直围绕着微服务进行的。因此，结合微服务技术的发展更能够看清Kubernetes的发展轨迹。

微服务及其误区

微服务的实践正在渡过深水区，判断的依据很简单：关于微服务的工具出现的愈来愈少，而实践和经验愈来愈多。这代表不少不会有不少新的通用问题须要解决。事件风暴(EVENT STORMING) 被放入了“采用”环中，这意味着事件风暴将做为微服务实践的核心技术之一。事件风暴是一项团队活动，旨在经过领域事件识别出聚合根，进而划分微服务的限界上下文。在活动中，团队先经过头脑风暴的形式罗列出领域中全部的领域事件，整合以后造成最终的领域事件集合，而后对于每个事件，标注出致使该事件的命令（Command），再而后为每一个事件标注出命令发起方的角色，命令能够是用户发起，也能够是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。事件风暴还有一个额外的好处是能够加深参与人员对领域的认识。

在微服务的应用中，分布式追踪一直是一个困扰人们好久的问题。CNCF 的 Jaeger 的机制一样来源于谷歌的 Dapper，并遵循 OpenTracing 。它在 Kubernetes 集群中安装它也很简单，它能够和Istio 配合使用，在 Kubernetes 集群中与 Envoy集成进行应用程序追踪。而 CNCF 所提供的工具渐渐会和 Spring Cloud 这种微服务全家桶的解决方案结合，变成将来微服务架构的基准参考模型。

除了 Java 社区之外，其它语言的社区也跃跃欲试。例如这一期技术雷达介绍的 Ocelot，它是基于.NET Core实现的轻量级API网关项目，它能够经过轻松的配置来实现路由转发、请求聚合、服务发现、认证受权、限流熔断、负载均衡等特性，它还集成了Service Fabric、Consul、Eureka等功能。目前 Ocelot 的功能已经至关完整，它在.NET Core社区的活跃度也很高。目测可以做为将来 .NET 社区微服务实践的首选。

而在 Python 社区，出现了一个超轻量级的微服务框架 NameKo，它也是 Flask的 替代方案。与 Flask 不一样的是 Nameko 只包含了 WebSocket、HTTP、AMQP 支持等有限功能。我很是喜欢这种简单而轻量的框架，若是你采用 Python 做为微服务的实现语言，你能够考虑考虑它。

JavaScript 社区曾经有一个从前端到后端“一统天下”的设想。也出现了 MEAN 这样的全栈 Javascript框架。如今 F# 社区出现了一个有力的竞争者：SAFE 。SAFE 技术栈是 Suave、Azure、Fable 和 Elmish 的简称。SAFE 囊括了一系列技术，造成了先后端一致的 Web 开发技术栈。SAFE 在服务端和浏览器端都使用了 F# 语言，所以注重于异步函数式类型安全的编程机制。它不只提供了一些提升开发效率的功能好比热加载; 还容许替换技术栈里的某些模块，例如服务器端 Web 框架或云提供商。它颇有但愿成为微软技术栈下 Serverless 微服务架构的候选者。

微服务的误区

随着微服务愈来愈火，不少组织开始盲目的追求微服务架构。但不少团队都把架构经过把简单的 API 进行复杂的整合使架构更加难以维护。它用运维复杂性换取了开发的复杂性。然而，这须要坚实的自动化测试，持续交付和 DevOps 能力做为支撑。

这期技术雷达提出的分层式微服务架构(LAYERED MICROSERVICES ARCHITECTURE)的组织是一种反模式，他们在某些方面存在着明显的矛盾。这些组织都陷入了以技术角色为主来划分服务的误区，好比，用户体验API、进程 API 或系统 API等。这样会致使业务变动仍然会有缓慢而昂贵的多团队合做。

另一点是，当中台战略逐渐开始流行后，会致使前台团队和后台团队被从技术上分开，而缺少了微服务所须要的总体业务能力。中台更多强调的是内部应用的产品化和 SaaS 化能力。而不只仅是割裂为独立的微服务。这样，你须要额外的一个中间层来作前台和中台之间的转换。而这样一个中间层，不管是放到前台和中台都是不合理的。我仍然推荐围绕业务能力组建一个端到端的微服务团队。

因为微服务不少都支持基于事件的异步调用方式，这也影响到了前端用户体验的设计。这就是在面向用户的工做流中使用请求 — 响应事件 (REQUEST-RESPONSE EVENTS IN USER-FACING WORKFLOWS)的系统设计。这样一来，要么UI被阻塞，要么用户就必须等页面收到响应消息后从新加载。作出这类设计的主要依据每每是为了性能或是为了用统一的方式来处理后端之间的同步和异步通讯。但这样作会在开发、测试和运维上所增长没必要要的复杂度，远远超过了采用这种统一方式带来的好处。因此，在用户可接受的场景下，直接使用同步HTTP 请求来处理后端服务之间的同步通讯，而没必要改为事件驱动的设计。若是设计的精妙，使用HTTP通讯不多会成为分布式系统的瓶颈。

微服务架构的一个显著特征是系统组件和服务是围绕业务能力进行组织的。不管系统规模大小，微服务都须要将系统功能和信息进行有意义的分组和封装，以便拆分后的微服务能彼此独立地交付业务价值。微服务是从业务角度对架构的从新审视，而之前的服务架构方式会从技术角度组织服务。

安全

技术雷达历来没有像这一期有这么多的安全相关的内容。今年的信息安全事件频发，并和技术的发展结合在一块儿，每每给人们一种“新技术必定会带来安全问题”的错觉。而安全的主要因素是人，工具只是下降工做量和节省工做时间的一种方式，它不能替代安全设计和安全活动自己。我把安全单独列为一节主要是为了可以使您对安全实践有一个端到端的认识。

运维相关的安全实践和工具

对敏感数据保持适当的控制是至关困难的，尤为是在出于对数据备份和恢复的目的而将数据复制到主数据系统以外的时候。密钥粉碎(CRYPTO SHREDDING)是经过故意覆盖或删除用于保护该数据的加密密钥来使敏感数据没法读取的作法。例如，可使用随机密钥对数据库中客户我的详细信息表的全部记录进行一对一加密，而后使用另外一张表来存储密钥。若是客户行使了“被遗忘的权利”，您能够简单地删除相应的密钥，从而有效地“粉碎”加密数据。当你有信心对小规模加密密钥集合维持适当控制，但对较大数据集的控制信心不足时，此项技术很是有效。

在云计算平台上维护基础设施首要的工做就是设立一个安全的框架，其次须要实践和工具来进行安全检查。

继混沌工程（Chaos Engineering）以后，安全混沌工程(Security Chaos Engineering) 也发展的愈来愈好，使用此技术的团队确信他们的安全策略足以应对常见的安全故障模式。不过，这方面的实践仅有 ChaoSlingr一个工具，且仅支持 AWS 平台。就像以前提到的 Chaos Engineering Katas，我相信将来会有 Security Chaos Engineering Katas 做为平常安全的练习。

随着云计算平台基础设施即代码的复杂度提高，相应的安全扫描工具也应运而生。Watchmen是个采用 Python 编写的工具，它为由交付团队自主拥有和运营 AWS 帐户配置提供基于规则驱动的扫描。技术雷达所提到的 Scout2 已经再也不维护，它被迁移到了ScoutSuite，目前支持 AWS，但即将包括 Azure 和 Google Cloud Platform。我强烈建议你将这些工具集成到你的基础设施流水线（Pipeline for Infrastructure）里。

开发相关的安全实践和工具

咱们已经经历了一些把密码存储到代码库上致使的数据泄露实践。将安全凭据或其余机密提交到源代码仓库是一个主要的攻击向量。GIT-SECRETS 是防止将密码或其余敏感信息提交到 git 仓库的小工具。AWS 实验室也提供了一个同名的工具，git-secrets 内建支持常见的 AWS 密钥和凭据，也能够为其余的提供商进行快速配置。

SNYK是一个能够查找、修复及监控 npm 、Ruby 、Python 、Scala 、Golang 、.NET 、PHP 、Java 与 Docker 依赖树中漏洞的平台。将 Snyk 加入构建流水线后，它会基于一个托管的漏洞数据库，持续地监控和测试你的库依赖树。在发现漏洞时，还能够给出能够解决该安全问题的最小的依赖版本。目前它支持多种 Git 仓库服务和 PaaS 平台服务。

若是你想对 Web 应用进行安全扫描，你能够采用 Archery，它是一个开源的安全工具，并正在将其与其余工具(包括 Zap )相结合，轻松地将安全工具集成到构建与部署系统中。你也能够经过 Archery 的工做面板，跟踪漏洞及应用程序和网络的安全扫描结果。

一样，随着微服务的流行，它的安全问题也被提高到了最高的高度。SPIFFE (Secure Production Identity Framework For Everyone， 适用于全部人的安全生产身份框架) 以特制X.509证书的形式为现代生产环境中的每一个工做负载提供安全标识。 SPIFFE消除了对应用程序级身份验证和复杂网络级ACL配置的需求，Istio 默认就采用了 SPIFFE。

参考

www.thoughtworks.com/cn/radar/

cloudplatformonline.com/2018-state-…

puppet.com/resources/w…