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

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

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

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

极易出错：两种方式本质都是手动逐个创建细粒度的服务实例，容易出现配置遗漏、错误等问题，而这些问题在部署过程中很难被发现，只有在应用运行时才会暴露出来。
需要云背景知识：不管是通过 CDK 代码定义服务实例，还是通过控制台手动创建服务实例，都需要开发者对 AWS 的服务有深入的了解，包括应用直接依赖的 DynamoDB 、S3 等服务，以及间接依赖的 IAM 等服务。
权限配置繁琐：出于安全的考虑，我们通常以最小权限原则来配置各个资源服务实例的权限，如果由开发者通过 CDK 或者控制台手动管理这些权限，那必定是一个非常繁琐的配置过程，并且在修改业务代码后，也非常容易忘记更新权限配置。
依赖管理：在将 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

Jianzs

188 天前

@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 代码进行修改。