我在这里遇到有关哪个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）有很大的不同。 ）。
您如何维护可能相似但仍不同的多个环境？ （生产vs阶段vs测试vs开发）您如何确保为夜间测试创建的短暂基础反映了生产的实际情况？当SDK程序在中间失败时会发生什么-您可以再次尝试运行它还是会创建重复的资源/失败并出现另一个错误？您如何获得git随时间变化的简单概述？并发控制？更改历史记录？
以上所有东西都放入Pulumi中，需要使用云SDK进行手动考虑。