与使用 Azure .NET SDK 相比，Pulumi 有那么神奇吗？

Question

我对在哪个 SE 网站提出这个问题感到困惑，所以如果它应该在其他地方，请帮助我。

我一直在研究基础架构即代码解决方案。

不太喜欢 Terraform。智能感知的缺乏使得难以辨认比程序员已经习惯的更难。

我一直在考虑 ARM 模板。我喜欢我们在门户中创建资源时提供的模板，但它似乎不太可读且之后更难维护。

然后我发现了 Pulumi 并喜欢与 Terraform 相比他们的想法。在我看来，它们的方法也像上述选项一样是声明性的，但我们可以使用体面的编程语言来完成工作。

for 循环是必须的。

酷，我喜欢！但既然我们喜欢使用 C#（或其他替代方案），那我们为什么不使用 SDK 将我们的基础设施作为代码来管理呢？

Pulumi has compared themselves with cloud SKDs 将他们的解决方案定位为更安全，提倡如果我们自己使用云 SDK，那么我们的解决方案就不会那么可靠。

我想知道这在多大程度上是真的？

去年，我编写了一些使用 Azure 服务总线队列/主题的库。有几个可以并行运行的集成测试，我需要通过创建新队列/主题来隔离它们，并使用Microsoft.Azure.ServiceBus.Management.ManagementClient 来执行此操作。

看起来我真的不需要学习任何东西。

现在进入正题。不放弃 Pulumi 我认为很棒的创新：

与使用 Azure SDK 相比，Pulumi 真的会增加那么多好处吗？

您对此有何体验？

Answer 1

这里是 Pulumi 开发人员，所以我肯定有偏见。我怀疑 SO 社区可能会发现您的问题违反了某些指导，但我希望我的回答能够继续存在:)

使用 Pulumi 的一个好处是您可以访问多个具有一致开发者体验的提供商。您可能只使用 Azure，但您可能会在某个时候开始将它与构建和发布 Docker 映像、部署 Kubernetes 应用程序或 Datadog 仪表板等内容结合起来。所有这些都可以通过同一个程序或解决方案完成。

现在，命令式 SDK 的最大区别在于期望状态配置的概念。 Pulumi 程序描述了资源图和它们之间的依赖关系（什么），而不是提供它们的步骤（如何）。当您拥有一个可以使用数月和数年的环境时，使用小步骤发展单个定义和应用增量更改（Pulumi）与编写一堆更新脚本/程序以将每个环境带入新状态（SDK）之间存在很大差异)。

您如何维护多个可能相似但仍然不同的环境？ （生产 vs 登台 vs 测试 vs 开发）你如何确保你为夜间测试创建的短期基础设施反映了生产的现实？当 SDK 程序在中间失败时会发生什么 - 您可以重试再次运行它还是会创建重复的资源/失败并出现另一个错误？你如何简单地了解 git 中随时间的变化？并发控制？更改历史记录？

以上所有内容都已集成到 Pulumi 中，需要使用云 SDK 手动考虑。