导语
我们生活在开发工具的黄金时代,随着云原生时代的来临,以及组织代码规模的扩张,不断出现的新开发模式又引入了新的复杂性,从而使得新的开发工具纷纷涌现。
InfoQ 在今年三月份发布了一篇译文《构建开发工具正当时》,这篇文章深刻地剖析了软件开发的生命周期,并举例说明了开发工具在每一个生命周期中所发挥的价值。
本文将在《构建》一文的基础上,以工具开发从业人员的视角,介绍云开发工具这一领域的时代背景、价值和发展趋势。
撰写这篇文章的目的是:希望有更多人了解云工具产品研发这一小众的技术领域;希望该领域的从业者们,能够有更好的生存土壤;也希望热爱这一技术方向的小伙伴们,能够感受到你并不孤单。
时代背景
自从三年前,我加入了一家云计算公司,从事工具链产品研发,成为了一名光荣的“工具人”。从那时开始,我始终关注业界动态,关注着国内外相关领域蓬勃发展。
在今年的三月份,我读到了一篇文章《构建开发工具正当时》,由 SourceGraph 的 Co-Founder Beyang Liu 撰写,文中提出了一个非常棒的观点:
长期以来,软件一直被认为是技术进步的助推器,而开发工具是技术进步的二阶助推器(助推器的助推器)。
开发工具作为二阶助推器的价值已经在云计算行业中得到充分体现:
一方面体现在云计算所带来的规模效应上,开发工具对于开发成本的优化,以及软件交付效率的提升,可以通过客户得到千百倍的放大,为客户带来巨大的经济价值,从而间接为云提供商贡献收入。
另一方面则是由于近些年来云原生技术架构的兴起,如鲜花着锦、烈火烹油,在这种新的开发模式中,基础设施的重要性被提升到了前所未有的高度,开发和运维之间的隔阂被打破,二者可以采用相同的声明式语言来构建软件基础架构,这带来了新的机遇和挑战。
而这一领域的开源组织和企业也展现出了蓬勃的生命力:
近年来,以 CNCF 为代表的云原生社区与组织,构建了一系列的开源工具,来帮助开发者完成软件构建的生命周期,涵盖了《构建》一文中提及的“编写、测试、评审、部署、监控”这五个阶段。
Hashicorp E 轮 50 亿美元的估值,则代表了独立工具厂商的兴起,以及它们在商业上的成功。随着多云时代的来临,采用多家云服务提供商已经成为了屡见不鲜的事实。中立的开源软件供应商,一定程度上促进了工具类产品价值的自由流动,从而也承载了巨大的商业价值。
云服务提供商,为了向开发者提供更好的服务,则纷纷投身于各种开源软件的贡献中,例如在 CNCF 的项目中,能看到许多云厂商的身影。
构建开发工具的黄金时代,已经悄然来临!
价值
每当我们开发一款新的工具时,都会面临这样的灵魂拷问:“你的工具能带来什么样的价值”?
价值模型
工具类产品的价值模型,可以从两个方面来看待:
对采用者的价值:对于工具的采用者来说,开发者工具作为软件开发的二阶加速器,改进了现有的开发模式和生产关系,产生了效能,支撑了企业的扩张;扩张的企业用规模效应产生边际效益,反哺了开发工具的投资,从而产生飞轮效应。
对服务提供商的价值:对于云服务提供商来说,一方面云开发工具可以降低用户的采用成本,从而间接影响用户的决策,形成厂商间的竞争优势。另一方面,云服务商通过为流行的开源工具,编写大量的厂商集成代码,可以获取天然的用户池,并且用户池规模会随着时间的推移而形成自然的增长。
增长逻辑
云开发工具类产品的增长逻辑,与常规的商业产品有很大的不同,它的理念从根本上更接近于开源社区的“礼物文化”。这个概念来自于知名开源技术作家 Eric Raymond 的《大教堂与集市》一书,是指开源社区的贡献和赠予是一种非零和的博弈。开发者工具的开放并不会给云厂商造成经济上的损失,反而可以获得声誉、品牌影响力上的回馈。
云服务提供商通过将自己的服务,集成到流行的开源工具中,使得工具的采用者能够使用自己熟悉的工具来管理云服务。对于云厂商来说,可以获取更多的潜在用户。而对于开源工具的创造者来说,来自服务提供商的帮助,可以使工具扩大影响范围,拓展能力的边界,并拥有积极的贡献者。
就像《大教堂与集市》中提到的,开源世界构建在一种“礼物文化”之上,而非一种零和的商业竞争,云厂商贡献自己的力量,而社区回馈以潜在的用户群体,从而实现一种双向的赠予。
服务提供商集成自身云开发工具的增长驱动力,主要由以下三个部分构成:
自然增长:当流行的工具生态扩张时,厂商的潜在用户池也将随之产生自然的增长,满足了服务提供商本身用户规模扩张的诉求。
内生增长:由于工具能够显著降低用户的采用成本,厂商内部进入工具生态的产品,具有天然的增长优势。从而产生为更多服务品类提供工具支持的内生诉求。
外部增长:厂商是否提供用户所熟知的工具,对于许多用户来说是一个不容忽视的成本指标,能显著影响用户的采用决策。从而使用户向服务提供商提出了扩张工具品类的诉求。
因此,潜在用户池、服务品类和工具品类的扩张,共同构成了开发者工具增长的基石,为开发者工具的增长赋予了价值和意义。
机遇与挑战
面向云的开发工具,已经具有很长的历史,但整体看来,云开发工具仍是一个新兴的领域,依然面临着许多机遇与挑战。本节将以云资源管理为例,带领大家直观感受一下,开发者工具是如何从专有领域走向通用领域,最终与软件开发融为一体。
云资源管理工具的设计目标是解决两个问题:一个是对资源的生命周期的管理,例如资源的增删改查、对依赖关系的管理;另一个是对多云的支持。
云资源管理工具的发展历史比较长,大体看来可以分为三个阶段,每一个阶段都面临着各自的问题和挑战:
第一阶段:使用通用编程语言和工具直接调用 API(SDK、CLI)。在这一阶段,用户采用 SDK 来直接调用 API,从而管理资源的生命周期,这常常适用于最小化的概念验证与原型开发。这种方式的潜在问题是,当面临多个云供应商的时候,每一个供应商的 API 和 SDK 千差万别,从而存在额外的启动成本,并且成为基础设施规模发展速度的限制性因素。面向特定厂商的基础设施研发,是这一阶段的特点。
第二阶段:基础设施即代码(IaC,Infrastructure as Code)。这一阶段的方案,通过将多个云供应商集中抽象为一种拓扑描述的文本格式,几乎可以管理任何资源而无需学习新的工具,降低了云服务商的采用成本。并基于此实现了基础设施即代码(IaC)的理念,使得基础架构能够和项目源码一同管理和交付。但这种方式带来了一个新的问题,即基础架构描述文件的可复用性和可测试性受到了工具本身描述能力的限制,大家会发现,描述基础设施所用的 DSL,越来越像一门通用的编程语言,支持模块化、控制流等语句。那么我们为什么不直接用通用的编程语言来进行资源管理呢?面向特定语言/架构风格的基础设施研发,是这一阶段的特点。
第三阶段:基础设施即软件(IaS,Infrastructure as Software)。这一阶段的工具采用通用编程语言(例如 Python、Go 等)来进行资源管理。与第二阶段的方案类似,它们同样屏蔽了多云管理方式的差异,与此同时,由于该阶段的方案采用通用编程语言,从而消除了学习 DSL 的成本,并借助主流编程语言的成熟工具链,可以很方便地进行抽象复用、静态分析、测试等等。基础设施与特定的厂商和架构风格解耦和应用软件融为一体,是这一阶段的特点。
在这一技术领域演进的过程中,涌现出许多概念:
声明式(Declaritive)API。声明式 API 区别于命令式(Imperative)API,命令式 API 通过编排对系统状态的操作步骤,来完成最终系统状态的变换。声明式 API 则致力于通过描述系统的期望状态,通过自动化的调和来使系统达到最终状态。一个典型的例子如 Kubernetes 的 Operator,用户创建和更改所需的资源描述文件,Operator 通过一定的调和逻辑尽力而为地使基础设施推进至期望的状态。
不可变基础设施(Immutable Infrastructure)。不可变基础设施是指当基础设置被创建后就不能进行任何修改操作。比较典型的例子是容器应用的最佳实践,每当应用需要更新时,创建新的实例以替换。不可变基础设施使得变更的状态是清晰和明确的,可以快速升级、回滚和重建一个特定的环境。
基础设施即代码(IaC, Infrastructure as Code)。IaC 是一个相对较旧的概念,但随着近年来云原生和一些流行的 IaC 工具的兴起,IaC 成为了云时代的重要技术。IaC 不仅仅指“将基础设施以代码的形态表达”,更重要的是,将代码世界中的一些软件工程的最佳实践和原则,应用到基础设施的管理中。例如模块化、测试技术等。
基础设施即软件(IaS, Infrastructure as Software)。IaS 是 IaC 的一个实例,IaS 是指通过通用编程语言来声明资源,编写基础设施代码。IaS 可以使基础设施与应用本身能够复用相同的工具链,打破 Dev 和 Ops 之间的隔阂,在抽象层次,可测试性方面取得根本性的飞跃。
GitOps。GitOps 是一种采用 Git 来管理基础设施(infrastructure)和配置(configuration)的编程实践,通常认为由 Weaveworks 提出,其核心在于使 Git 作为基础设施和应用的单一事实来源(trusted source),受版本管理。当 Git 中的内容变更时,基础架构和应用也随之自动变更和交付。声明式 API、基础设施即代码是 GitOps 的基础。
这里介绍几款典型的云资源管理工具:
CFEngine。CFEngine 是最古老的配置管理工具之一,于 1993 年发布。CFEngine 最初是其作者 Mark Burgess 的一个研究项目,在发展的过程中实践了非常多的学术理论,并引发了后续配置管理领域的相关研究。
Puppet。Puppet 是一种开源的配置管理软件,于 2005 年发布。Puppet 基于一种声明式的编程语言来描述系统配置。
Chef。Chef 是一种开源的配置管理软件,于 2009 年发布。通过使用 Chef 工具,可以集中式的管理服务器集群。除此之外,Chef 还提供了一系列周边工具,例如可以采用 Chef InSpec 编写面向基础设施的合规策略。
Ansible。Ansible 是一种开源的配置管理软件,于 2012 年发布。Ansible 可以通过编写 YAML 格式的配置来编排自动化过程。Ansible 是最流行的配置管理工具之一,有着大量可复用的代码和非常广泛的服务提供商支持。
SaltStack。SaltStack 是一种开源的配置管理软件,于 2011 年发布。SaltStack 的特点是基于事件驱动的设计,以及由丰富的远程执行模块构成的中心化管理能力。
Terraform。Terraform 是 Hashicorp 出品的一款多云资源编排工具,于 2014 年发布。Terraform 采用一种名为 HCL 的 DSL 来描述基础设施。Terraform 是最流行的多云资源管理工具之一,基于图的结构使它能够高效地处理资源之间的拓扑依赖关系,目前支持 200+ 软件和服务。
Pulumi。Pulumi 也是一款流行的资源管理工具,于 2017 年发布。Pulumi 采用多种通用编程语言来进行资源管理,并通过名为 Crosswalk 的子项目,实现与 Kubernetes 的互操作,目前支持 5 种编程语言。
cdktf、cdk8s。二者分别由 Hashicorp 和 AWS 推出,它们构建在 Terraform 与 Kubernetes 之上,实现了一个转换逻辑,可以使用多种通用编程语言来生成二者所需的资源定义文件,从而使基础设施可以采用通用编程语言来编排。
其中,配置管理工具和 Terraform 是 IaC 概念的典型代表,Pulumi 和 CDK 则专注于实现 IaS,他们共同构成了 GitOps 的最佳实践。
回看这二十多年,从 IaC 到 IaS,象征着 Dev 和 Ops 之间的墙在一定程度上被打破。从单一的厂商/技术栈,到多供应商、多架构风格的转变,象征着开发者工具对于软件价值自由流动所起到的推进作用。它们共同构成了工具类软件对于生产模式和生产关系的变革,云资源管理工具这一领域方向,正是开发者工具行业的一个缩影。
本节较为完整地介绍了云资源管理工具这一热点技术方向。还有很多领域和项目未曾提及,例如持续交付,可观测性、策略即代码、沙箱运行时等等。并不意味着它们不重要,而仅仅是篇幅所限,欢迎大家一起交流。
总结
本文从一个云开发者工具产品从业人员的个人视角,介绍了云开发工具领域的背景、价值和发展趋势。
开发工具作为软件的“二阶助推器”,在云原生时代的重要性愈发凸显,开源社区与厂商纷纷投身于工具的研发当中。工具能够解除供应商锁定,提高工程效率,使企业和云服务提供商在商业竞争中抢占先机。
在云原生时代的浪潮中,到处都可以见到开发工具的身影,多云管理、API 构建、以至于软件交付、工程效能、安全合规等领域,都将成为这一技术方向的机遇和挑战。
云开发工具的时代已经来临,你准备好了吗?
你在从事哪些工具的开发,欢迎留言👏。
附录:
《构建开发工具正当时》: https://www.infoq.cn/article/toataglje5qf5ovd2yct
Blog: Beyang Liu: https://beyang.org/
News: Hashicorp E 轮 50 亿美元: https://techcrunch.com/2020/03/16/hashicorp-soars-above-5b-valuation-in-new-175m-venture-round/
作者简介:
李宇飞,目前从事云计算工具链产品研发,关注云原生、基础架构和软件分析等领域,欢迎同行交流。
评论