说了这么多年，云成为基础设施了么？

[Jianzs]

云是基础设施吗 🤔️

基础设施是为一个国家、城市或其他地区服务的一套设施和系统，包括其经济、家庭和企业运作所必需的服务和设施。 ——维基百科

从概念意义上讲，的确，云已经成为了基础设施。但是，你想一下，你在使用电饭煲的时候，你会去考虑你使用的电是水电，还是火电吗？那你在开发应用程序的时候，你是否需要考虑要部署到 AWS 上？还是 Kubernetes 上？云远没有像电一样方便使用。从实用意义上讲，云还没有成为真正的基础设施，有效的接入方式或许是其中一个缺失项。

现在如何使用云的 ☁️

云提供了丰富的能力，包括负载均衡、函数计算、对象存储等，而你是如何使用这些能力的？让我猜一下：你先登录到 AWS 的控制台，在数百种资源中找到 DynamoDB ，进入配置页面创建一个 Table 。然后你去 Lambda 页面创建两个函数，边查看 DynamoDB SDK 的文档，边将你超凡脱俗的想法实现。在一次查阅 SDK 文档后，嗯？我刚才要做什么来着？ Table 设置的 Key 是什么来着？我写入数据为什么会失败？ IAM 、ARN 都是什么？学习使我快乐 😵。OMG ，我只是想开发一段简单程序啊 😤。终于在不断的部署—测试中完成了功能开发，你再去 ApiGateway 的配置页面创建两个 Route 、一个 Deployment ，发布。终于，你完成了一个云应用的全部开发。

整个过程困难重重，仿佛在参加 3 千米障碍跑，而你只是想开发一个云应用。你说你了解 Terraform 、Pulumi ？但是仍少不了去学习各种云能力、IaC 工具的使用，对吗？这绝不是一种好的开发体验。

编程语言是钥匙 🔑

怎么才能让我能够专注于我的创新应用？回顾计算机历史可以发现，编程语言是打开计算机世界的钥匙，程序员通过编程语言与计算机世界进行交互。从二进制编码到汇编，从 C 到 Python ，人类的认知负担越来越低，开发者编程时不再需要关心 CPU 架构、指令集，一切向好。

面向云开发的应用程序仿佛又回到了原点，或许是时候再创造一门新的编程语言了？“什么？！又是一门新的编程语言？我的确希望减轻我使用云的压力，但是我也不想放弃各种方便使用的库！”

我们既想利用编程语言这把钥匙来降低开发者使用云的门槛，又不想放弃现有语言的生态，极致地保障开发者的编程体验。于是我们诞生了一个想法 💡：让现有的一门编程语言成为新的编程语言。也就是说，保持现有语言的语法、生态，但是我们对它重新编译，是面向云的编译，让它成为云开发世界的钥匙。

Plutolang 就是这样一款产品，我们始终认为一款产品不应该强迫开发者采用任何特定的方式编写应用程序，而应该是集成到开发者的工作流程中，让开发者变得更轻松。人们想要的是能改善生活的简单解决方案！

常用语言翻新 🤸‍♀️

当前编程世界有非常多的编程语言，他们绝大多数都被设计成面向单机环境运行，我们该如何对他们进行“翻新”，来让它们能够自然的在云上分布式地运行呢？我们在 TypeScript 这门语言上进行了初步尝试。

首先，回想一下，我们平常是如何开发一个单机应用程序的？如果我需要保存一组键值对以供后续使用，只需要创建一个 Map 对象就好。我可以在一份代码文件中，定义一个 Web 服务器的多个路由处理函数。这些操作都很简单方便，我们目标是要保留这种开发体验。

因此，我们从最常用的扩展方式—依赖库着手，用户之前可能会使用 express 作为依赖库，而现在改为使用 @plutolang/pluto：

import { KVStore, Router, HttpRequest, HttpResponse } from "@plutolang/pluto";

const kvstore = new KVStore("pluto");
const router = new Router("pluto");
router.get("/hello", async (req: HttpRequest): Promise<HttpResponse> => {
	await kvstore.set("hello", "pluto");
	return {
		statusCode: 200,
		body: "Hello, Pluto";
	}
});

开发者仍然是定义一个个应用需要的变量，编写一个个的路由处理函数，就像往常一样。在经过编译后，kvstore 、router 等变量就会成为一个个云上的组件资源（如 DynamoDB 、ApiGateway 等），而定义的路由处理函数将成为云上的一个 Lambda 函数，自然地享受云所提供的按量计费、快速扩缩等特性。

这背后的主要思路是：从用户代码中推导出应用程序所依赖的云资源，以及资源间的依赖关系，构建出云资源拓扑图，也就是针对云环境的参考架构（ Architecture Reference ）。进一步对用户代码进行拆分、改写，导出多个计算模块，同时依赖于参考架构，可以生成一份与用户代码不直接相关的基础设施代码，其中包含对资源的定义与计算模块的发布。最终，执行这份基础设施代码就能创建与部署应用程序在云上的运行环境。可以在这篇文章中了解详细的工作流程。

保障用户开发体验的关键在于编译时执行的代码不能与用户代码直接关联，否则就需要开发者在开发时指定哪些代码是编译时执行的，哪些代码是运行时执行的。

而这个思路的关键点就在于：编译时执行的代码是根据推导出的参考架构生成而来，不需要在编译时执行用户代码。这也是与其他 Infrastructure from Code 技术的关键区别。

Pluto ♇

Pluto 根据这个思路首先在 TypeScript 上进行尝试，让 TypeScript 成为面向云应用开发的一门新语言，就像 Pluto 从行星被重新分类为矮行星。虽然目前仍处于 PoC 阶段，但是可以给大家看看我们在 Demo 中实现的效果。

这是 Demo 的 B 站视频链接：「 Pluto 开发云应用」

Demo 中，我在一份代码文件中，定义 3 个变量，KVStore 、Queue 、Router 各一个，同时定义了两个路由处理函数和一个消息订阅处理函数。在执行 pluto deploy 后，所有的基础设施资源和计算模块都被有序地部署到 AWS 云上。

然后，我新建了一个 Stack ，指定运行时是 Kubenetes ，不需要修改代码，我又将这个应用程序发布到了 Kubernetes 上。你觉得这种开发体验如何？

这里有更多的示例应用：

• 基于 OpenAI API 快速构建属于你自己的聊天机器人
• 每天给 Slack 频道发送一则计算机笑话

---

Pluto 目前仍处于 PoC 阶段，尚未准备好投入生产使用。如果你对“语言翻新”这个想法或者“Pluto”这款产品有任何想法，或者想参与开发，我们都十分欢迎，欢迎加入我们的 Slack 和 GitHub，或者 钉钉交流群: 40015003990 。

参考

• Pluto 工作原理
• Pluto 解决什么问题
• Pluto 和其他技术有什么不同

有没有在薅 AWS 羊毛的 V 友？薅起来方便不？用 Pluto 这个东西的话，就写 TS 代码，就能直接发布到 AWS 上，还是蛮方便的。

你要是有啥疑问，或者不好用的话，随时联系我哈

[GeekGao]

其实就是云原生的理念，但与其学习一种新的图灵完备语言 or DSL ，我还是会偏向使用 BaaS 服务 😂
非要用 Code As Infra ，那我用 Terrorform 也行啊。

[WinterWu]

Terroform 的核心是它占据了生态位，大家都在适配它。重新搞一个意义不大，因为执行层面很容易做到适配和兼容，但是这么多云的适配才是核心问题。做不好直接废，做好了人家直接支持就好了。

[Jianzs]

@GeekGao 对，还是 V 站大佬多，的确还是云原生，但是想再降低些门槛。

这里是我没有表述清楚，我尝试解答下大佬提出的几个问题，当时也是我自己的看法：

1 ）学习成本：Pluto 目前是基于 TypeScript 去做的，就是不想让用户再去学一门新的语言，也不想放弃现有生态。

2 ）和 BaaS 服务相比，这种方式把配置过程和编程过程都尽可能的统一到一个界面，这样少了上下文切换的开销，思维应该会更连贯，更舒服些。

3 ）对于到大佬说的 Terraform 之类的工具，的确用熟了挺方便，但是一方面是随着功能越来越丰富，它的复杂性其实是在越来越高，并且它的上手门槛也蛮高的，对于普通开发者或者刚入门的开发者来说。

其实，总的来说，就是希望能够进一步降低上云的门槛，同时还能让写代码更连贯、更爽。大佬觉得这个思路怎么样？不知道是不是过于 YY 。

[Jianzs]

@WinterWu 对，Pluto 并没有想取代 Terraform ，相反，目前阶段就是在用 Pulumi ，用 Pulumi 的原因刚好也是你说的，多云适配。这里其实有一张图，说了 Pluto 和 IaC 工具的关系，我明明上传 imgur 了，但是不知道为啥显示不出来，麻烦大佬复制这个网址看下吧。 [http://cdn.zhengsj.cn/ob-1698301951197.png]( http://cdn.zhengsj.cn/ob-1698301951197.png)

目前 Demo 上做到了不改代码就能适配 AWS 和 K8s ，你可以看看 Demo 的视频，[「 Pluto 云开发」]( https://www.bilibili.com/video/BV1HB4y1d7cq/)，就 2 分钟，前面是部署到 AWS 上，后面没改代码，就部署到了 K8s 上。

这个效果，我个人感觉还是不错的，大佬觉得呢？

[Jianzs]

@Jianzs #4 不好意思，Demo 视频链接有点问题： https://www.bilibili.com/video/BV1HB4y1d7cq/

[learningman]

不应该强迫开发者采用任何特定的方式编写应用程序
但是你现在就在强迫我用你的库

[WinterWu]

怎么说的，这个肯定会有一定的诉求。但你也提到 pulumi 了，Pulumi 对多云支持也是依赖 Terraform 生态，同时它本身已经支持很多语言了。Terraform 的 CDK 也在做这方面工作，TS 应该都是支持的。
我做了一段时间后，发现一个问题，用其它语言编程方式去做其实只适合中小规模管理。大规模管理还是要用 Terraform 来定义，Why? 因为它是结构化的，容易和企业现有体系做集成、做统计分析等工作。
额外来说，我们最终没采用，为何，因为主要在阿里云，阿里云对 terraform 的支持就是一坨，不知道现在如何。

[WinterWu]

如果你是准备在这个领域创业，那么我要泼冷水了，别搞了，没人会为这个付钱。
如果你是练手、伟大理想什么的，非常棒。

[Jianzs]

@WinterWu #7 感谢！的确规模管理是个问题。目前也是想以个人开发者或中小团队为目标受众，毕竟做大企业的话，各种权限、管理太复杂了，不想搞这些，就想搞搞让云开发更爽的事情，也暂时不考虑盈利。

等 Pluto 试水阿里云了，再邀请大佬来试试，哈哈哈哈

[Jianzs]

@learningman 哈哈哈哈，确实，不过狡辩一下，这种方式已经是非常低的侵入了，写个啥不也得引个库不是？至少还是能把业务逻辑都写到一块，还能用到一些特性能力，比如 FaaS 之类的

也想过能不能直接对 express 这种去搞，但是就不纯粹了，就更像阿里云的 serverless devs 那种脚手架工具了，后续再继续考虑考虑。

[yedkk]

terraform 比 typescript 简单多了，比脚本语言还要简单。我觉得做云运维的一般都会 python ，但是会 js ，ts 的很少。