0

自从 MS在这里声称您可以在不更改代码的情况下进行迁移以来，我一直致力于提升和转移应用程序以使用 Azure 文件存储。然而，在实践中，这似乎并不那么容易。我尝试将文件存储挂载为驱动器号，但我发现虽然用户可以在他们的计算机上手动执行此操作，但 Web 应用程序无权执行该操作。所以我最终使用了他们的云 API，这似乎工作正常，但需要几天时间和大量测试来升级我们现有的应用程序以使用它。

我们遇到的另一个问题是，为了提供 url，我们必须创建一个SAS 或共享访问签名，这确实提供了额外的安全性，但也需要进行更多代码更改，以便在应用程序需要向最终用户提供链接的任何地方添加它。我还遇到了链接不起作用的另一个问题，这可能与缓存问题有关，现在似乎已通过此 hack修复。

我想相信他们声称您可以在不更改代码的情况下进行迁移，只需更改您的配置值以指向新的文件夹位置或其他内容，但我的经验是，这要么是彻头彻尾的谎言，要么在不更改代码的情况下使其工作，这是必需的大量的技术挖掘表明继续沿着这条路努力是不值得的。

所以我向任何 Azure 大师或任何人提出问题，Azure 怎么可能声称你可以“在不更改代码的情况下进行迁移”？这似乎是一个谎言，会给客户带来意想不到的挑战，并给客户设定不切实际的期望。

谢谢你的帮助！

4

1 回答 1

2

微软声称“这是简单的提升和移位迁移”（通常理解为提升物理虚拟机并用虚拟机替换它）是正确的。如果您刚刚这样做，那将很容易。但是您不会利用 PaaS 的优势。

Lift and Shift 传统上意味着将所需的基础设施物理地重新定位到不同的位置。通常情况下，当一家公司在他们自己的建筑物中用完空间时，他们会将机架、路由器和服务器提升并转移到一个有空间的新数据中心。

但是，对于云模型，您无法将它们物理地提升到虚拟空间中，因此目的是尽可能地替换同类。ie - 用类似的虚拟机替换所有服务器。

您所做的是云应用程序现代化工作或重新架构。这确实需要更多的工作，需要对平台和代码更改有更深入的了解，但也会获得更大的收益。TechTarget 有一篇关于两者好处的简单文章。因为您误解了提升和移位的含义而称其为谎言有点粗略。

进行任何类型的迁移时的一般经验法则 - 尽可能少地进行更改。所以在你的情况下，首先是纯粹的提升和转变。让它稳定。然后进行云现代化工作。

于 2017-08-01T16:20:01.700 回答