我们有一个由 .NET 前端和 SQL 后端组成的 Web 应用程序。我们还有一个使用 WebAPI 连接到 .NET 前端的移动应用程序。目前，我们的应用程序托管在美国的物理服务器上。我们有来自世界各地的多个客户，他们通过 Web 浏览器和移动设备登录该应用程序。
我们有不少客户询问两种方案：
“该应用程序可以在美国以外的国家托管吗？”（出于安全/ NSA 的考虑）
“我们可以自己托管应用程序吗？”（针对大型企业客户）
我们使用 Github 对前端代码进行变更管理。部署网站代码相当容易，因为我们已经构建了一个同步实用程序，允许我们从 Git 存储库更新生产服务器。但是，从我们的测试服务器更新 SQL 生产服务器更像是一项手动任务（架构、存储过程等）。我知道有软件（redgate 等）允许使用 SQL 进行类似的变更管理，但这不是我的问题。
考虑到一些客户希望能够将他们的数据单独托管在一个位置（出于安全原因），而其他客户希望将他们的数据托管在一个、多个或所有位置，共享，以便连接到最近的服务器，那么大多数公司如何处理从多个地理位置托管应用程序的问题。作为补充细节，我们经常（每天）更改代码，因此将代码和 SQL 更改推送到多个隔离的主机环境并确保所有内容同步有点麻烦。
如上所述，我们目前托管在数据场中的物理服务器上。使用 AWS、Azure 等是否会让这项任务变得更容易？
答案1
我认为你这里真正面临的两个问题：
- 地理位置
您希望将应用程序部署在多个位置，这时 Azure 或 AWS 等云提供商将为您提供帮助，您可以在多个区域部署应用程序，而无需在多个区域驻留。您可以使用内置的负载平衡工具在单个区域实现故障转移，也可以使用 Azure 流量管理器等工具跨多个区域。您可以根据流量和负载平衡配置文件将用户分配到单个区域或多个区域。
- 部署
您的第二个问题是能否部署您的应用程序，特别是当您将在多个区域中拥有大量实例时。这实际上不是云问题，而是工具和流程问题。如果您要扩展到多个区域和多个区域中的多个实例，那么在流程的任何部分进行手动部署都不再有效。您需要能够安全快速地部署到所有区域（或部分区域），并且知道它们都将是相同的，特别是在进行负载平衡时。实现此目标的唯一方法是查看您的流程以消除复杂性，或使用工具为您处理它。有手动 SQL 部署的解决方案，您提到了 Redgate，但还有其他解决方案，Visual Studio 甚至有一个数据库版本控制工具。