我可以将asp.net应用程序移动到云中吗？

Question

我们公司正在考虑迁移到云。 我们是否仍然能够满足我们当前的所有要求（如下）。 我们希望能够在不增加成本的情况下将来轻松扩展。

• 5个正在运行的ASP.net 4.0网站（使用sql数据库，请参见下文）
• SQL Server 2008 Express（与此有关的8个数据库）
• 2个计划程序服务正在运行（通过电子邮件发送夜间报告，例如数据库中的新订单）
• MongoDB和Memcached也安装在服务器上

当前，出于安全原因，网站位于与数据库服务器不同的服务器上。

我们正在考虑将Windows Azure和Amazon Web Services（AWS）作为提供程序，哪个最适合我们的要求？

我们还需要考虑其他因素吗？

Answer 1

回复：SQL数据库：在Windows Azure上，它将映射到SQL Azure。 费用高达$ 5 /月（最多100 MB实例）-一直到150 GB-超出了Federations的费用。

回复：5个正在运行的ASP.net 4.0网站：这些网站自然映射到Windows Azure Web角色。 “小型”实例的价格为$ 0.12 /小时/实例，通常需要两个实例（在某些情况下避免单点故障）。 根据您的负载，您也许可以将所有5个站点放在同一实例上。 如果您的网站使用率很低，请考虑$ 0.05 /小时/实例“超小型”实例。

回复：出于安全原因 ， 当前网站与数据库服务器位于单独的服务器上：当然这也是可行的。

Re：2 Scheduler服务正在运行：运行Windows Services没问题。

回复：通过电子邮件发送夜间报告，例如db中的新订单：虽然没有直接引入Windows Azure，但没有做任何问题，但是有许多简单的方法可以做到这一点（甚至是免费的，例如通过SendGrid ）。

回复：我们希望能够在将来轻松扩展而又不增加成本：您需要对实际成本进行数学计算，但是Windows Azure肯定可以扩展。

回复：MongoDB和Memcache也安装在服务器上：它们都可以在Azure上运行。 查看https://github.com/mongodb/mongo for MongoDB。 此外，还可以使用Azure缓存服务（由您管理）。

回复：我们正在考虑将Azure和Amazon作为提供程序，这将最适合我们的要求：这些功能在功能上非常相似（功能和成本），但有一些明显的区别。

1. Windows Azure是平台即服务，这意味着您无需担心虚拟机，而只需担心应用程序。 换句话说，您将（基本上）压缩的应用程序包上传到云中以执行。 使用Amazon，您将自己处理虚拟机。 在Azure中，您可以获得为您管理的Windows Server 2008副本，但是如果需要，还可以对其进行管理。 如果您的应用程序是旧的凌乱的安装，并且并不是真正干净的（尽管无论如何可能都不是一个好的高价值云候选者），那么这将没有太多优势。
2. Windows Azure有一个非常好的模拟器-Visual Studio中的F5可以与存储系统和VM以及更受欢迎的功能一起使用。

回复：还有其他需要考虑的因素吗？ 对于任何云应用程序，您都需要准备好进行横向扩展（而不是向上扩展），处理瞬态重试（您可能需要重试对云服务-任何云服务的操作）。 这样的好处是更好（和更具成本效益）的可伸缩性和更高的可靠性（当您在节点上运行时，没有单点故障）。 确保了解VM上何时/何处存储是持久存储还是临时存储。 还有更多考虑因素，但这是主要考虑因素。

您可能需要检查Windows Azure定价计算器 。

祝好运！ 欢迎来到云端。

Answer 2

除了扩展问题和2台物理服务器之外，您可以将此功能移至托管环境中，从技术上讲，您将身处“云”中。 这可以是专用服务器或VPS（虚拟专用服务器），如果您很小，甚至可以是共享服务器。

这些可以随着时间的推移而增长...您只需要升级与提供商的联系即可。

您还可以将托管服务器与托管服务器一起使用，这基本上意味着您将硬件放在托管提供商机架中，并使用其电力和带宽。 它们根据带宽使用情况收费。

由于您使用的是SQL Express，因此请记住，每个数据库的大小限制为8gb。 因此，这将限制您的成长。 如果您不想重新设计任何东西，那将需要从Express升级到常规SQL。

Answer 3

您是否考虑过AppHarbour ？ 它具有Memcached ， MongoDB ， SQL Server 等 ，并且比Azure部署更快。 我喜欢 Azure，但是有很多学习过程，而且我发现与SQL Azure的连接非常差-这意味着需要重新设计DAL以使用类似SQL Transient Failure Library的东西=对于现有项目来说有点麻烦。

AppHarbour没有blob存储-因此，如果要上传文件，则将需要使用Azure Blob存储或Amazon S3或同等版本。

希望这可以帮助。

Answer 4

虽然不是专家，但由于Asp.net是Microsoft产品，因此应该更容易迁移到Azure，尽管据我所知，AWS并不难。 您可能要考虑的另一件事是成本。 上次我检查AWS的成本明显降低，除非您已经为MSDN订阅付费。

Answer 5

您总结的所有要求在Windows Azure中部署都不是什么问题。 您可以在互联网上找到许多有关如何执行此操作的信息。

请记住，如果要将服务部署到Windows azure，则需要对应用程序进行一些代码审查，以修复Web应用程序上的会话状态，输出缓存等。

由于您希望扩展它们，并且它们位于非粘性循环负载均衡器后面，因此，如果会话状态保存在计算机本身上，则会遇到问题。 例如，您需要将会话状态分配到SQL Azure或Windows Azure表存储。

在Azure中安装MongoB和Memcache并不是问题，您会找到很多有关如何做的信息，但需要一些信息来设置您的角色和脚本

Answer 6

encodingoutloud已经给出了非常详细的答案。 在将任何应用程序迁移到Azure（或实际上许多其他云提供商）时，我将添加两个非常重要的考虑因素。

当地状态
对于普通的Azure，他们保留随时关闭角色的任何一个实例以移动或升级它的权利。 这意味着您总是需要至少一个角色的两个实例，并且它们将透明地实现负载平衡。 如果您当前的网站当前正在单个服务器上运行，则它们可能依赖于会话状态或本地目录中的文件等。现在，有一些解决方法（例如，将会话状态放入SQL，使用cookie提供程序提供临时数据，使用共享驱动文件等），或者实际上绕过Azure的许多好处并使用其“虚拟服务器”概念，这意味着您无法获得规模收益等。但是，严重依赖本地状态的站点可能会面临挑战迁移到云端。

时区
所有Azure服务器都在UTC时间运行。 如果您习惯于在单个时区为用户提供服务的专用服务器上运行，则很有可能使用诸如DateTime.Now（）之类的东西，而这些东西实际上并不符合用户的需求。

我没有将以上任何内容视为Azure的局限性，我发现它们在迫使您从一开始就构建全局和可扩展解决方案时非常有用。 但是，在移植现有应用程序时，即使存在变通办法，上面的内容也很难适应。

就像在其他地方提到的那样，Azure有一个学习曲线，而且由于某种原因，文档（尽管如此）似乎并不多。 但是，一旦“了解它”，我就会发现Azure确实很棒，并且有许多微妙的功能将帮助您构建可伸缩的解决方案，例如整个队列基础结构，blob存储和表存储。 在某些方面，选择过多会阻碍学习。

祝好运！