我对于应该在哪个 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 真的会带来那么多好处吗？
您对此有什么经验？
最佳答案
这里是 Pulumi 开发人员，所以我绝对有偏见。我怀疑 SO 社区可能会发现您的问题违反了某些指导，但我希望我的答案能够保留:)
使用 Pulumi 的一个好处是您可以访问多个具有一致开发人员体验的提供商。您可能只使用 Azure，但您可能在某个时候开始将其与构建和发布 Docker 镜像、部署 Kubernetes 应用程序或 Datadog 仪表板等内容结合起来。所有这些都可以通过同一个程序或解决方案来完成。
现在，命令式 SDK 的最大区别在于所需状态配置的概念。 Pulumi 程序描述了资源图以及它们之间的依赖关系(什么)，而不是配置它们的步骤(如何)。当您拥有一个运行数月甚至数年的环境时，逐步发展单个定义、应用增量更改 (Pulumi) 以及编写一堆更新脚本/程序以使每个环境达到新状态 (SDK) 之间存在很大差异)。
如何维护可能相似但仍然不同的多个环境？ (生产、登台、测试、开发)您如何确保为夜间测试创建的短期基础设施反射(reflect)了生产的现实？当 SDK 程序在中间失败时会发生什么 - 您可以重试再次运行它还是会创建重复的资源/因另一个错误而失败？如何简单地了解 git 中随时间变化的情况？并发控制？更改历史记录？
以上所有内容都已融入 Pulumi 中，需要使用云 SDK 进行手动考虑。
关于azure - 与使用 Azure .NET SDK 相比，Pulumi 有那么神奇吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62203605/