Pluto 要解决什么问题？

我们为什么要做 Pluto？一句话，把云用好的难度太高。

太烦了

问个问题，你在进行业务开发时，编写代码的时间在所有时间的占比是多少？80%？60%？40%？还是更低？想要部署到 Kubernetes，却需要学习 Docker、CRD、YAML 规则，想要部署到云平台，却迷失在眼花缭乱的产品文档，在各个页面反复横跳、点击。这些情况你是否遇到过？要上云太麻烦了！

太难了

当然，想避免这些麻烦，你可以选择去学习基础设施即代码（IaC）工具，像 Terraform、Pulumi，这类工具可以以代码的形式描述目标云资源状态，然后由工具引擎来执行代码，配置云资源环境。但使用这类工具，你首先需要去学习他们的基本操作，学习他们的语法，学习和云交互的各种 API...... 并且，随着基础设施变得越来越复杂，IaC 技术上手的门槛越来越高，使用的难度越要越大，需要学习的东西也越来越多。

此外，业务的规模可能发生变化，业务的预算也不尽相同，没有一套架构适用于所有应用程序。作为一名普通开发者，我没有充足的经验设计适合我业务场景的云架构选型，并且还要保证我的代码具有足够的可扩展性，能在我预算紧张或者业务规模扩大后，轻易地迁移到新的云平台或者新的云架构上。

不习惯

有一些用户友好的 PaaS 平台和新型编程语言，他们提供的能力的确能够让我的工作更轻松。但是他们要么只是简单地帮我托管容器，不能使用成本更低、启动速度更快的 FaaS 等解决方案，如果我使用他们提供的组件服务，还会导致我的应用程序与他们的平台紧耦合。要么有自己独特的编程方式，我需要去学习哪些代码会在本地执行，要部署到云上的代码需要写在哪里，以及怎么写。这种方式让我很难专注于业务逻辑，阻碍了我的创新。

难道就没有一种方式能够让我按照往常的思维方式编写代码，不需要学习新的技术，就能帮我轻松使用云丰富的能力吗？这正是 Pluto 想要尝试的事情，让开发者真正专注于编写业务代码，其他所有的事请交给 Pluto。

Pluto 理念

我们认为一款云的辅助工具不应该强迫开发者采用任何特定的方式编写应用程序，而应该是作为工作流的扩展集成到用户工作流程中，降低用户的上云负担。

但目前，各种云的技术与产品却在强迫开发者使用它所提供的特定方式编写应用程序，例如：将 FaaS 函数放到指定目录，或强行将编译时与运行时代码整合到开发者的编程界面，这都让开发者在编程时去区分哪些代码是云上执行的，哪些是云下执行的。这类“新的”编程方式与开发者以往的编程思维具有很大差异，极大地影响了用户的编程习惯。

因此，Pluto 目标是给开发者提供一个与往常编程一致的纯业务编程界面，让开发者真正专注于业务逻辑，编程过程中不需要关心基础设施的任何事情（当然，在需要时可以对基础设施进行配置）。同时，除编写代码外的所有事情，完全交给 Pluto 自动化完成，包括测试、编译、部署等。

如果你也有相似的痛苦经历，或者你对这个 idea💡 感兴趣，又或者你有场景正需要它，欢迎与我们联系，让我们一起做点有意思的事儿！