问题描述
询问是否有一些基础设施自动化技术可以比Terraform更好地实现可移植性。他们在很大程度上使用Terraform，因为它是一种与云厂商无关的技术（与Azure的ARM模板或AWS的CloudFormation相比）。然而，一年前，当他们从Azure迁移到AWS时，他们发现一个基本的扩展集和负载均衡器在Azure和AWS之间需要完全重写。类似地，他们在使用类似Ansible的工具时，也遇到了相同的问题。这些工具基本上都使用云提供商特定的扩展来创建云资源，这意味着虽然你仍然了解工具的使用，但是你的项目在在不同云环境中部署时必须进行重新编码。
用户还提到了一些差异，例如Azure使用资源组来封装所有资源，AWS使用安全组来定义网络边界，AWS负载均衡器需要单独的目标组/监听器，而Azure使用更简单的后端池概念，还有IAM的差异等。
尽管用户了解一个通用工具必须要理解许多不同之处，但他还是惊讶于没有公司或开源项目试图通过更高级的DSL或其他方式来简化/自动化这些转换过程。因此，用户认为自己可能忽略了一些内容。用户还指出，他们在大规模使用Kubernetes，并且理解在部署了集群并将所有应用程序移植到Kubernetes之后，大部分问题都得到了缓解。
解决方案
在基础设施自动化领域，”与云提供商无关”这一目标很难实现，因为不同云提供商的云服务设计存在较大差异。然而，有一些方法可以更好地处理在不同云环境中进行部署的问题。
利用工具和模块
无论选择使用Ansible还是Terraform，你都可以通过创建云提供商特定的Ansible Roles或Terraform Modules来实现跨云部署。就像你为不同操作系统或不同情景编写特定于其的Ansible角色一样，你可以为不同云提供商编写专用的角色或模块。
举个例子，假设你想要在Azure和AWS上部署一个类似的扩展集和负载均衡器。你可以为每个云提供商编写一个特定的Terraform模块，其中包含适用于该提供商的资源定义和配置。然后，你可以根据需要在你的部署脚本中选择要使用的模块。
使用Kubernetes
正如你提到的，Kubernetes可以帮助缓解跨云部署的问题。一旦你建立了Kubernetes集群，并将应用程序迁移到Kubernetes中，你就可以通过定义抽象的资源和服务来减少对云提供商特定功能的依赖。Kubernetes提供了一种统一的方式来定义和管理应用程序，不论它们在哪个云环境中运行。
然而，值得注意的是，Kubernetes自身也需要适应和学习成本。在引入Kubernetes之前，你需要确保团队对其有足够的了解，并准备好管理和维护Kubernetes集群。
高级DSL和抽象层
虽然目前可能没有完全通用的解决方案，但一些公司和开源项目正在努力开发更高级的DSL（领域特定语言）或抽象层，以简化跨云部署的过程。这些工具可能会在将来提供更好的解决方案，但目前仍然需要根据具体情况进行评估和选择。
尽管没有一个完美的解决方案，但通过合理地组织代码、利用现有工具和技术，以及积极关注行业趋势，你可以更好地管理和减少在不同云环境中部署时的挑战。
提示：在实际操作中，请根据你的具体情况和需求，选择适合你团队的最佳实践和工具。
结论
在基础设施自动化的领域，”与云提供商无关”是一个复杂的目标。然而，通过合理使用工具、模块和抽象层，以及考虑使用Kubernetes等技术，你可以更好地管理在不同云环境中部署的挑战。尽管当前可能没有完美的解决方案，但随着技术的发展和行业的变化，未来可能会有更好的解决方案出现。