HashiConf Global 2022 Opening Keynote 我的简单笔记

本期文章有不少引用内容，微信公众号的读者如果有兴趣的话可以在文末找到相关连接。

2022 年 10 月 04-06 日在美国洛杉矶举办了 HashiConf Global 会议，感兴趣的读者也可以参考线上回播^[1]。墙内读者可以移步到 B 站观看 —— B 站搬运 Day1 Keynote^[2] B 站搬运 Day2 Keynote^[3]。因为内容非常丰富，仅凭我一人之力是无法面面俱到地介绍到位的，老样子，我还是简单汇报一下我对于两天的 Opening Keynote 走马观花看的几个点，和我的一些看法，只代表我个人的主观看法，仍然不是一篇“关于 HashiConf Global 2022 只要看这一篇就够了”的文章，强烈推荐感兴趣的朋友还是要自己去看一下回播。

另外因为今年六月已经举办过一届 HashiConf Europe 了，所以有些内容是在六月讲过的，重复的部分我这里就不再赘述了，有兴趣的朋友可以移步阅读前文《HashiConf Europe 2022 我的走马观花》以及 《HashiCorp 云战略调研报告解读》

财富 500 强中 185 家企业已是 HashiCorp 的客户

HashiCorp CEO David McJannet 继续介绍 HashiCorp 如今的规模和成绩，目前看 HashiCorp 已经成功打入高端企业市场。

David McJannet 在加入 HashiCorp 之前曾经供职于 Hortonworks、VMWare 等成熟 IT 企业，当时主要负责产品营销、产品管理和运营。自从 2016 年他成为 HashiCorp CEO 以来，HashiCorp 明显找到了一条非常适合她的发展模式，在继续扎根于开源社区继续引领前沿创新的同时成功地杀入主流高端企业市场，这其实是非常不容易的。

上云的三个阶段

这张图实际上包含了非常丰富的内容，它描述了 HashiCorp 总结的企业上云典型的三阶段模式^[4]，下面是一段我个人根据引文进行的不成熟的摘录和翻译：

在 Tactical Cloud Adoption 阶段，企业刚刚开始尝试使用大型公有云，这往往是因为企业内部的工程师想要使用某一特定的公有云服务。随着团队用云的时间越来越长，他们在云端会创建大量的服务来支撑其内部需求。

随着对云的使用越来越多，网络和安全团队这时会跳出来表达他们的担忧，团队需要同时确保数据安全、机密凭证不被泄露。这时一些团队会开始使用 HashiCorp 产品的开源版本。

随着安全和网络团队最紧迫的问题得到解决，团队继续扩大云服务使用的范围和规模。该组织现在使用了大量筒仓式的云服务，并横跨多云定期提供各种新服务。

这时不断增加的复杂性通常会导致云平台(Cloud Platform)团队的建立，目的是在企业范围内采用更加一致和标准化的方法。HashiCorp 将此称为Industrialisation of Cloud Programme(云程序的工业化)。生产线需要在治理、身份管理和远程访问等领域推出完备且一致的方法。我们可以用基础设施即代码(IaC)来确保这些方法的一致性和可重复性。

团队在这个阶段可能会发现开源版本的 HashiCorp 工具已经不足以满足他们的企业级需求，这时团队会开始考虑评估 HashiCorp 企业版以及 HCP(HashiCorp Cloud Platform)在线服务，以满足更复杂的需求，以及获取更及时的支持服务。

一旦大量工作负载安全运行并在云上实现了高度自动化，那么重点就会转移到将这种云原生的方法应用到整个 IT 部门。客户已经学会了如何运行云平台，他们希望将这种成功带回自有数据中心。HashiCorp 将这个阶段总结为 Private Estate。

HashiCorp 将对这三个阶段的支持总结成了她的企业使命：“为任何应用程序提供、保护、连接和运行任何基础设施的一致方式”，HashiCorp 的付费产品主要着眼于为企业在后两个阶段提供支持和服务。

多云与云平台团队

仍然在强调多云：

但是这里我也想引用 ThoughtWorks 在 2018 年的 Tech Radar 中提出的一个概念：`Generic cloud usage`^[5]。简而言之，Generic cloud usage 是指企业为了避免供应商锁定，构建了复杂且难以维护的抽象层来隔离平台间的不一致，并且拒绝使用云平台提供的一些极具特色的优秀服务，比如说拒绝将文件存储在 AWS S3 上，而是选择用 EC2 虚拟机构建自己的对象存储服务，这是需要权衡避免的。ThoughtWorks 同时也提出了另一种更加推崇的策略：`PolyCloud`^[6]。

随着对云的使用越来越广泛，越来越复杂，再加上多云带来的额外的复杂性，团队开始重度依赖“平台团队”来提供“基础设施、网络、安全、应用编排”四个层面的一致交互方式和体验。根据《Platform Teams》^[7]一文的描述：

平台团队是产品团队用来交付面向业务的功能的构建块。产品建立在平台之上，这些平台使产品团队能够更快地行动。

这又是一个比较大的话题，本篇还是不做过多展开了，有兴趣的话以后单开一篇来讨论。

人才问题

再次强调了目前阻止企业多云战略成功实施的最主要问题是能够把云用好的人才不足。David McJannet 举了过去企业从大型机转向 PC Server 的 CS 架构时期的例子，当年的转型时期也曾经出现过相关人才稀缺的问题，这需要时间。

目前已有 25000+ 名持证工程师通过了各项 HashiCorp 的认证考试^[8]。

目前这些认证涵盖了 Terraform、Vault 和 Consul 三款产品。Nomad 不但还没有属于自己的 HCP SaaS 服务，也没有对应的认证考试，看起来 Nomad 还需要一段时间的打磨。

HCP Vault 的新功能

HCP Vault 宣布支持性能副本、多因素认证以及一些扩展插件（例如 EKS、MongoDB、LDAP 等），前两项都是原本 Vault 企业版中的功能。Vault 有两种副本，高可用副本平时不对外提供服务，仅在主节点宕机时接管服务，实现高可用；对大型集群来说，单个 Vault 服务节点可能性能无法满足需求，这时可以使用 Vault 的性能副本(Performance Replication)。

Vault 的数据加密新功能

Vault 正在模仿硬件安全模块（Hardware Security Module），努力成为一个软件定义的安全模块。同时新版的 Vault 将支持 transform 与 transit 引擎的 BYOK(Bring Your Own Key)。

所谓 BYOK，就是用户可以通过 Vault 将自己生成的密钥同时托管于不同的云平台以及自有数据中心中的 HSM 中并统一管理，同时使用这些密钥进行数据加解密或是签名和验证。transit 是 Vault 提供的无需暴露密钥即可完成对数据进行标准强度加解密的加密即服务^[9]功能，而 transform 则提供了“保持格式的加密”^[10]服务，例如美国国家标准技术局签发的 `FF3-1`^[11] 标准，它可以把形如 1111-2222-3333-4444 这样的信用卡号加密成形如 9300-3376-4943-8903 这样与明文格式一致的密文。该功能仅在 Vault 企业版中提供。

Vault 生态新功能

动态机密引擎如今支持了 Redis，包含开源版、企业版以及 AWS ElasticCache 发行版。

Consul 的 Cluster Peering

Consul 发布了 Cluster Peering 的正式版本。在此之前，如果有几个数据中心的 Consul 集群要协同工作，它们可以组成联邦（Federation）

联邦中需要一个主集群，联邦中的集群两两都要联通，所有的密钥、策略、服务配置等信息都会在整个联邦中传播。

Peering 的不同点在于没有主集群，也不需要两两联通，每个集群仍然维持原有的密钥、策略和各种配置。用户自行选择配对的集群，也可以控制在配对的集群之间共享哪些服务信息。

Consul Dataplanes

Consul 通过 Consul Connect^[12] 提供了服务网格的能力，借助 Consul 控制面获取服务注册信息，然后通过 xDS 协议配置 Envoy 来作为服务网格的代理。如果在 Kubernetes 平台上，因为 Kubernetes 已经提供了强大的服务发现功能（Service），所以再去用 Consul 健康检查、Gossip 协议传播服务注册信息就显得叠床架屋多此一举了。新的 Consul Dataplanes 功能支持在一个容器中打包 Consul 与 Envoy，直接使用 Kubernetes 提供的服务发现功能来配置 Envoy。

与 AWS Lambda 通过服务网格进行双向调用

Consul 现在支持通过一个代理节点，将 AWS Lambda 函数也纳入服务网格。可以将一个 AWS Lambda 函数映射成 Consul 服务网格中的一个代理节点，随后服务网格中对该服务的调用会被 Envoy 发往这个代理节点，随后通过 TLS 加密流量转发到 AWS Lambda 函数。

同时从 Lambda 函数调用服务网格中的服务功能也进入了 Public Beta 阶段。未来的 Consul 将会支持服务网格与函数计算服务的双向调用。

你会发现 HashiCorp 非常善于发掘利基市场^[13]。Nomad 抓住了传统遗留应用（虚拟机、IIS 网站等）很难转化为云原生应用的痛点，而 Consul 应该是目前极少见的支持与函数计算双向调用的服务网格。

HCP Consul 可以作为多个 Consul 服务的统一管理面板

现在 HCP Consul 可以作为一个统一的控制面板，同时管理 HCP Consul 集群以及基于开源版 Consul 自建的集群。

Terraform 的一些统计数字

HashiCorp 在今年的 HashiConf Europe 和本次 Global 会议上都确认，HashiCorp 所有产品的年下载量是 2.5 亿次，这中间 Terraform 独占 1 亿，说明 Terraform 目前仍然是 HashiCorp 绝对的核心产品。

自从 2017 年创建 Terraform Registry 以来，已经有 10000+ 个 Terraform Module 登记注册了。一个题外话，实际上根据《金山世游的 HashiStack 实践》当中采访到的信息来看，大规模使用 Terraform 的企业团队会倾向于编写维护大量的私有 Module，其数量可能是公共 Module 的 9-10 倍之多。目前 Registry 对 Module 的分类检索方式还比较少，不少人反馈他们很难搜索到适用于自己场景的 Module。未来个人感觉 Registry 其实还要探索更好的组织搜索方式。

今天已经有 2400+ 个 Provider 在 Registry 注册了。有趣的是在六月的 HashiConf Europe 上这个数字还是 2000+，不知道是这几个月大爆发了还是两个数字统计口径不同：

Terraform 正在成为与云交互的第一选择，越来越多的企业和团队选择只使用 Terraform 来编排云端的各种服务，如果某个服务还没有开发对应的 Terraform Provider，他会发现越来越多的客户流失，最终别无选择必须开发 Provider。实际上到这一步 Terraform 已经实现了在 IaC 领域的霸权。

目前有 470+ 客户付费购买了 Terraform Enterprise。

迄今为止共执行了 350 万次 Sentinel 规则检查。

2000+ 的 Terraform Cloud 客户，250000+ 的 Terraform Cloud 用户。平均每个客户账户下有 125+ 个用户，说明有不少中大型组织在使用 Terraform Cloud。

自从去年推出 Terraform Cloud Run Task^[14]以来，共有 15 个合作伙伴提供了不同的 Run Task，执行了 30 万次检查。

今年推出的 Terraform Drift Detection^[15] 功能，已经有 2000+ 个 Workspace 配置使用了。

Terraform Continuous Validation

在今年的 HashiConf Europe 中，发布了 Terraform Cloud 的配置漂移检测^[16]功能。如今，在配置漂移检测的基础上，Terraform Cloud 新增了持续验证^[17]功能。Terraform 1.2 开始我们可以在 resource 块的 lifecycle 块中声明 `precondition` 和 `postcondition` 块^[18]。precondition 的表达式如果执行结果为 false 会阻止创建该资源，而 postcondition 的表达式执行结果为 false 会阻止继续创建其他资源。我们可以为资源以 postcondition 的形式编写健康检查，例如在创建 API 网关后通过 curl 确认它是可以正常工作的。这新增的持续验证功能可以定期执行管理资源的 precondition 和 postcondition，如果结果为 false 则可以在第一时间通知相关用户。比如下面这个例子：

我们在 postcondition 中定义了使用的主机镜像必须是通过 Packer 构建的最新版本，在我们创建基础设施时它的确是通过 DataSource 查询使用了最新的，但一旦我们发布了更新版本的镜像，持续验证会发现该 postcondition 执行为 false，从而提醒我们及时更新主机镜像。

Policy 成为 Terraform Registry 的第三种类型

过去 Terraform Registry 中可以注册 Provider 和 Module，现在我们还可以看到 Sentinel 的 Policy。

另外，由于 Sentinel 是 Terraform 付费版专享的功能，并且拥有一种特定的 DSL 语法，所以掌握 Sentinel 的人才并不多，开源界目前有更多的 Opa^[19] (Open Policy Agent)的 Policy。Terraform Cloud 开始支持原生的 Opa Policy 检查（企业版的支持还需要一些时间）

就像我在之前的文章《火线安全》里引用的数据说的那样：

根据趋势科技的调查^[20]，公有云平台上发生的安全事故中约有 65-70% 是由配置错误引发的。如此简单的问题，却又引发了如此多的严重事故，我们能不能做的更好？

未来一段时间，Policy 将会成为 IaC 领域建设的一个新热点。我自己的一个感受是，目前的确没有一个很好的 Opa Policy 的 Registry，Terraform Registry 既然支持了 Sentinel Policy，那么感觉支持 Opa Policy 应该也只是一个时间问题。这一块实际上是有创业空间的。BridgeCrew^[21] 依靠用 Python 编写 Policy 的 Checkov^[22] 都可以被 Palo Alto Networks 以 1.56 亿美元现金以及其他股权置换收购^[23]，它的一个杀手锏功能就是提供合规到 Policy 的映射和认证，例如如果你的 Terraform Plan 满足某一组 Policy 的检查，就认证你符合 HIPAA^[24] 合规或是 nist-800-53^[25] 合规。未来会需要专业团队或是机构来为不同云平台编写合规对应的规则集合，并结合类似 Continuous Validation 这样的机制来确保持续合规。

零代码调用 Terraform 创建基础设施

对于不熟悉 Terraform 的人来说，如果想要试用团队积累的大量成熟的 Terraform Module，还要先去准备 Terraform 环境，学习 Terraform 使用知识和语法，这仍然是一个门槛。HashiCorp 为这种场景设计了零代码调用 Terraform 创建基础设施的功能，目前该功能可以在 Terraform Cloud 中使用，Terraform 企业版的支持也即将到来。

Nomad 1.4，更简化的 Nomad 部署

在过去 Nomad 往往需要与 Consul 以及 Vault 一起部署，依靠 Consul 来实现服务发现，依靠 Vault 来存储机密凭据。假如每个集群都需要部署三个节点，那么为了部署一个生产环境高可用的 Nomad 集群，我们可能必须要部署三个 Nomad Server，三个 Consul Server 以及三个 Vault Server 共九个节点。为了简化 Nomad 的部署，最新版的 Nomad 支持了原生的服务发现以及静态机密存储：

一点感想

今年是 HashiCorp 上市后的第一年，明显的一个感受是更多的新功能都是发布在 HCP SaaS 版本中的。如今的 HashiCorp 已经不能再称为是一家创业公司了，作为上市公司 HashiCorp 也有财务压力，要实现每年的利润递增。按照华尔街的尿性，HashiCorp 能够不玩股票回购的游戏，继续增加在产品研发上的投入就非常好了。如今的 HashiCorp 也会越来越多地面临两难选择，后续研发的主要精力是放在开源版本上，还是向付费版倾斜？

HashiCorp 如今面临着一个经典的挑战——右上角的牵引力

《创新者的窘境》一书中曾经以希捷为例子加以说明：

下图描绘了希捷公司向高端市场移动的具体细节，该公司所采取的战略正是大多数硬盘制造商都会采取的典型策略。大家知道，最开始是希捷公司创造硬盘产品，进而主导了台式计算机的价值网络。图中的竖线描绘了希捷每年的产品（包括希捷公司产品线上容量最低的硬盘至容量最高的硬盘）相对于市场需求容量所处的市场地位。在图中显示每年容量跨度的竖线上，黑色方块衡量的就是希捷公司每年推出的硬盘的容量中值。

1983 年至 1985 年间，希捷公司将产品线的重心，放在台式计算机部门所要求的平均容量上。1987 年至 1989 年间，具有市场破坏性的 3.5 英寸硬盘从价值网络的下方侵入了台式计算机市场。希捷公司为应对此次冲击所采取的措施，不是与破坏性技术正面交锋，而是向高端市场“撤退”。希捷公司继续根据台式个人计算机市场所要求的容量，生产各种型号的产品，但到 1993 年，它的工作重点已明显转向中端计算机市场，例如文件服务器和工程工作站。

破坏性技术的确对这些企业产生了毁灭性的影响，因为率先将各代破坏性硬盘推向市场的企业，并不满足于固守在最初的价值网络内。相反，它们会利用每一代新产品全力进军高端市场，直到所生产的硬盘具备的容量足以吸引更高价值网络内的客户。正是这种不断向上的流动性，使得破坏性技术严重威胁到了成熟企业的地位，同时又让新兴企业产生了极大的吸引力。

...这也促使这些企业建立了一种非常特别的提高赢利能力的模式。一般来说，企业会发现很难在保持它们在主流市场的地位的同时，通过降低成本来提高赢利能力：企业所承担的研究、开发、市场营销和行政管理成本，对于保持其在主流业务方面的竞争力具有至关重要的作用。进入高端市场，生产能够获得更高毛利率的产品，这通常是增加利润的一种更为直接的方式。进入低端市场则与上述目标背道而驰。

投入研发资源来推出利润率更高、性能更高的产品，这不但能确保更高的收益率，还能让企业减少投入。随着企业的管理者不断做出决策——应该给哪些新产品开发提案提供资金，应该搁置哪些提案。针对具有更高利润率的更高端市场，来开发更高性能产品的提案总是能立刻得到所需要的资源。换句话说，理性的资源分配流程，就是推动企业跨越硬盘行业价值网络的界限不断向上流动，同时限制企业向下流动的根本原因。

...更高端的市场总是愿意为增大部分的容量支付更高的价格。同样是 1MB 的容量，如果可以卖得更贵，为什么要卖得便宜呢？因此，硬盘生产企业向右上角方向的迁移是非常合理的。

今天的 HashiCorp 令人鼓舞的一面是有了越来越多的付费大客户，这些大客户愿意支付较高的溢价换取更好的支持服务，但相应的在产品设计和功能的取舍上也要相应地予以倾斜；而另一面，作为一家科技企业，如果想要保持产品始终引领技术发展的潮流，永远代表先进的生产力，那么不能脱离右下方使用免费开源版本的社区。HashiCorp 之所以能够建立起今天的霸权，与他可以打造的一流的开发者体验和社区紧密相关。未来的 HashiCorp 能否抵制住右上角的牵引力，既不脱离右下角的免费社区，同时又能在右上角大客户领域持续开疆拓土，在股价上给股东一个交代，让员工和管理层能够拿到实实在在的收益，这实在是一个非常复杂的问题。

HashiCorp 的灵魂人物，Co-Founder Mitchell Hashimoto 在 2021 年选择辞任 Co-CTO 职务，回归个人开发者角色^[26]，是不是就有这方面的考量？在公司继续在右上角开疆拓土的同时，他作为灵魂人物和创始人，密切关注右下角的发展？一个很有意思的猜想。

如何界定 HashiCorp 的生态边界是一个问题

我们看到最近一年在 HCP 服务中增加了许多新功能，例如配置漂移检测就是过去其他一些 Terraform Cloud 竞品所主打的卖点。HashiCorp 自己非常善于寻找利基市场，在 Kubernetes、Istio 等一统江山的势头中也挖掘出 Nomad、Consul Connect 这样的细分竞品，杀出一小片空间，那未来 HashiCorp 与围绕着 Terraform 生态创业的其他一些团队来说他们的关系会怎么样，HashiCorp HCP 功能的边界在哪里，会是一个很微妙的问题。

要像对待付费客户那样对待初学者

HashiCorp 的文档工程应该是我见过的最好的，而且他们对各个站点各个文档、学习材料在视觉和用户体验上的统一也做的极好，你阅读各个产品主站上的文档与阅读 learn.hashicorp.com^[27] 上的教程时的体验基本完全一致。HashiCorp 致力于云运营（Cloud Operation）的民主化，也就是将优秀的统一的体验和各种最佳实践的门槛降到极低，易于推广。国内致力于走开源工具类创业的团队需要认真学习。

参考资料