Nedim的最近这篇帖子很好地总结了Aspire现在的样子。我想聊聊我们的下一步计划——更重要的是，我们为什么要这样构建它。

归根结底，Aspire 是一个平台，它为开发者提供一个易于理解的抽象，并为平台工程师和 DevOps 团队提供接入点。

让我解释一下我的意思。

平台架构师抽象出云服务提供商

在我看来，平台工程师抽象掉云提供商的具体实现。他们从 Azure、AWS 或 GCP 等云服务中提取原始能力，并为组织的其余部分策划一个既安全又成本可控，同时严格限制的云服务子集。他们执行政策规定，制定最佳实践，并管理不同环境之间的界限。

但要做好这件事，他们需要两样东西来做到。

1. 一种描述他们正在构建的环境的政策和规定、能力和局限的方法。
2. 这意味着让这些限制变得对实际构建应用程序的团队易于使用且理解的开发体验。

第一部分相对而言已经解决了一部分问题（尽管现有的工具功能较底层，功能不够完善）。有很多基础设施即代码的工具，比如 Terraform、Bicep、Pulumi 等，这些工具可以帮助平台团队定义他们的架构。

第二部分就是问题开始冒头的地方。

这就是Aspire想要填补的空缺。

开发人员不需要知道组织使用的 PostgreSQL 版本，它所在的子网，或是调整哪些配置。他们也不必学习如何编写 Terraform 来操作 Redis。

但他们确实需要描述他们的应用是什么：它由哪些部分组成，它连接到哪里，以及它依赖于什么。Aspire 让他们能够用自己熟悉的术语来描述这些内容，例如项目（project）、服务（service）、容器（container）、端点（endpoint）、引用（reference）。

同时，Aspire 为平台工程师提供了一个集成点。他们可以定义当有人调用 AddRedis() 或用 WithReference() 添加一个项目时会发生什么——这对应什么基础设施，如何配置，以及用哪些策略。

Aspire的核心在于，它是一座连接开发人员想法与平台工程师管理的平台的桥梁。

Aspire 并不是来替换您的基础架构工具套件。

我们并不想成为另一个像 Pulumi 或 Terraform 那样的工具。这些工具在描述基础设施方面非常擅长。Aspire 致力于描述应用程序及其依赖关系和连接——然后提供足够的连接点来将这些连接到你所需要的任何基础设施层。

Aspire 可以向这些工具提供输入。它可以生成特定环境的配置清单，并正确地将资源与秘钥和连接字符串关联。但它始终从应用开发者的视角出发。

这就是差别。

我们要去哪

现在，Aspire 正专注于改进本地开发流程——建模应用，启动依赖，以及简化服务发现和配置过程。

这只是个开始。

未来，Aspire会帮助你

• 定义“Redis”在开发、测试和生产环境中的含义
• 生成管道和部署基础设施
• 支持平台定义的“组件”或“集成”，这些封装了基础设施、默认配置、策略和集成
• 通过代码实现完整的应用建模，而不是使用 YAML

最后，我希望你能只描述一次你的应用程序，它就能呈现出这种形态：

• 你的本地开发设置
• 你的流水线设置
• 你的生产环境部署

这是我们正在构建的世界。

结尾

Aspire 是对更好抽象的一次押注。它不仅是为了更快地启动容器，也是为了帮助开发者清晰地表达他们的构建内容，以便平台工程师更好地运行。

我们正在努力缩小意图和实际操作之间的差距，从“我想添加Redis”到“这里就有生产就绪、合规、安全且可观察的Redis，适用于所有环境的Redis”。

虽然现在还早，但基础已经打好，我对接下来的发展感到很兴奋。