大家觉得这种部署方式怎么样？

[Jianzs]

问一下各位 V 友，你们平常会有把应用部署到云上的需求么？都是怎么部署的呢？

这里想讨论的应用不仅仅是一份应用代码，我们都知道，一个应用可能会依赖很多后端服务，比如 LangChain 应用会用数据库来保存会话历史，用向量数据库存储知识库的 Embedding 。

然后，我发现将这样的依赖多个服务的综合应用（或者叫多应用？）部署到云上挺麻烦的，目前大致有两种方式：IaC 、手动。但是这两种方式，我分析下来有下面这几个问题。或许这也是 LangSmith、Modal、LaptonAI 之类的 AI Infra 产品出现的原因？

1. 极易出错：两种方式本质都是手动逐个创建细粒度的服务实例，容易出现配置遗漏、错误等问题，而这些问题在部署过程中很难被发现，只有在应用运行时才会暴露出来。
2. 需要云背景知识：不管是通过 CDK 代码定义服务实例，还是通过控制台手动创建服务实例，都需要开发者对 AWS 的服务有深入的了解，包括应用直接依赖的 DynamoDB 、S3 等服务，以及间接依赖的 IAM 等服务。
3. 权限配置繁琐：出于安全的考虑，我们通常以最小权限原则来配置各个资源服务实例的权限，如果由开发者通过 CDK 或者控制台手动管理这些权限，那必定是一个非常繁琐的配置过程，并且在修改业务代码后，也非常容易忘记更新权限配置。
4. 依赖管理：在将 LangChain 应用发布成 AWS Lambda 函数实例时，我们需要在打包时将应用依赖的 SDK 一并打包进来，而这个过程需要开发者手动管理，一方面容易遗漏依赖库，另一方面如果本地设备的操作系统、CPU 架构与 AWS 平台不一致，那打包过程就会更加麻烦。

区别于 AI Infra ，我从另一个角度出发来尝试解决这些问题：能不能直接从应用代码中直接推导出应用的基础设施资源需求，然后自动在 AWS 等云平台上创建相应的资源实例，通过这种方式来简化资源创建和应用部署的流程。

基于这个想法，我做了一个研发工具，叫做 Pluto 。基于 Pluto 实现的 LangChain 应用长下面这个样子，就和普通 Python 应用一样，但是，只需要执行 pluto deploy，Pluto 就能在 AWS 平台上自动创建 API Gateway 、Lambda 资源实例，并且配置好 API Gateway 到 Lambda 的路由、触发器、权限等。

import os

from pluto_client import Router, HttpRequest, HttpResponse
from langchain_core.pydantic_v1 import SecretStr
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_template("tell me a short joke about {topic}")
model = ChatOpenAI(
    model="gpt-3.5-turbo",
    api_key=SecretStr(os.environ["OPENAI_API_KEY"]),
)
output_parser = StrOutputParser()

def handler(req: HttpRequest) -> HttpResponse:
    chain = prompt | model | output_parser
    topic = req.query.get("topic", "ice cream")
    joke = chain.invoke({"topic": topic})
    return HttpResponse(status_code=200, body=joke)

router = Router("pluto")
router.get("/", handler)

你觉得这种方式可以让云更好用么？你会喜欢么？

最后最后，走过路过的大佬，求个 star🌟 👉 https://github.com/pluto-lang/pluto

[ShineyWang]

CI CD 没有吗?
自动发布 一键脚本部署还有什么问题吗?

[guanzhangzhang]

你是否需要 CICD 和 terraform

[Jianzs]

@ShineyWang CI/CD 的确很方便，我也非常认可这种方式，后续我也会做 GitOps 实践。

其实你提到的这些方式，前提是自己原本就有云的背景知识，就会部署，然后把这些经验沉淀成流水线或者脚本，但是这个脚本只针对单独的某个项目。所以，个人认为这种方式没法惠及更多能力没有那么强的开发者。

我这项目背后其实就是先解析出应用对云的依赖，然后生成一份 IaC 代码，然后自动执行。

https://pluto-lang.vercel.app/zh-CN/blogs/240515-develop-ai-app-in-new-paradigm 这篇文章比这个帖子更详细一些，大佬可以看看，欢迎交流

[7lQM1uTy635LOmbu]

软广，建议移送推广节点

[Jianzs]

@guanzhangzhang 我想把 pluto deploy 做到 CICD 里，让没有 IaC 背景的开发者，也能很简单的用上云。

理想一点，就是想实现提了很多年的一个概念，云是一台大电脑。想达成的体验就是，开发者只管敲码，执行一条命令，应用就跑到云上了，不用关心云的细节

[ZSeptember]

没太理解和 terraform ，pulumi 的区别是什么。

是提供一些预制的模板吗

[Mithril]

@Jianzs 前提是云服务厂商不收你钱，或者压根没人扫你服务。
不然一旦你哪里配置有问题，跑出了大量的费用；或者安全配置没搞好，被人刷爆/拖库。

那么这个责任是你的，还是开发者的，还是云服务厂商的？

这就是为什么 AI 医疗喊了那么多年，各种论文研究刷遍各种会议，但最终能落地的还是不多的原因。
它本质上是个责任问题，而不是技术问题。

想要改也很简单，自动生成 IaC 配置，但不会部署。或者将两步拆开，强制使用者 review 一遍 IaC 脚本。

[Jianzs]

@Mithril 有道理，感谢大佬！现在是基于 Pulumi 实现，后面打算支持 TF ，到时候导出 TF 代码，让开发者确认

[Jianzs]

@ZSeptember 开发者使用 Terraform 的话，需要维护业务代码、基础设施代码两套代码，有上手成本和维护开销。

我这里的话，是用户只需要编写业务代码，然后 Pluto 理解业务代码的资源需求，自动生成 IaC 代码，目标是让开发者不关心基础设施。

业务代码就像平常写的代码一样，这里不是基于模版来实现的，而是通过程序静态分析来实现的

[ZSeptember]

@Jianzs #9 想法确实还可以。但是在公司用起来可能很难。
1. 根据业务代码，准确性很难保证
2. 过于动态了
3. 很难精细化控制到底需要多少资源

当然最核心的是，现实中，业务部门和运维部门是分开的，很多资源都是要单独申请创建或者修改的，而不是会允许 CICD 里面自动就创建，修改了。

[Jianzs]

@ZSeptember #10 感谢大佬反馈

对于你最后提到的核心问题，深表赞同，所以这款工具的定位就是面向个人开发者的，对基础设施也有要求，云化需要做的比较好。

对于大佬前面提到的三个问题，我是这样解决的，可以交流一下：

1. 对于第一点，Pluto 生成的不是最终的 IaC 代码。比如 API Gateway 这类组件，其实用起来还需要 Route 、Trigger 、Stage 、Integration 之类的组件，我们把这些组件组合在一套 SDK 里，封装出一些方法，生成的代码是这套 SDK 方法的调用。一两句话说不清楚，可以看下这篇文档 https://pluto-lang.vercel.app/zh-CN/documentation/how-pluto-works

2. 对于第二点，目前的确灵活性不足，我只支持在全局作用域定义这类特殊变量，最近才支持了环境变量，只能说尽可能覆盖更多的编程行为。

3. 对于第三点，目标是：抽象之下支持完全可扩展性。会在 Router 这类构造器上提供一个 options 参数，通过这种方式对资源进行细粒度的配置。后续也想做插件体系，通过插件的形式对生成的 IaC 代码进行修改。

[ZSeptember]

@Jianzs #11 我觉得想法确实不错，面向个人开发者的话， 不想商业化的话，挺好的。
我做自己项目的时候也考虑过用一下 terraform ，pulumi ，但是后来发现学习这个的成本还不如手动点点点。
就是说，很多情况下，个人开发者，，不没有那么多资源，vm ，gateway ，估计都是一次性配置好了。用 lambda 多了，可能需要更多的自动化。

[Jianzs]

@ZSeptember #12 终于有人肯定啦，不考虑商业化

是这样的，很多个人开发者虚拟机一把梭哈，没有并发的压力，也就不太考虑 Serverless 这一套，所以现在是通过 AWS 的羊毛来吸引用户能上手试试，给点反馈

大佬下次有需求可以试用一下，劳驾点个 star 呗