我即将开始开发一个负载/流量细节非常不确定的项目。当它发布时，负载肯定会非常低，可以通过单个桌面四码机轻松处理。
问题是（在一段仅限邀请的时期之后）该产品将会受到强烈的宣传，因此我预计会有相当大的流量/负载峰值。
我对云提供商的了解还不够多，而且我主要倾向于 Amazon 或 Azure，因为这两家公司的可信度很高，而没有像我应该与其他公司一样对它们进行检查（即我认为 Rackspace 也是一家云服务提供商）。
我想要
创建一个普通的 Asp.net MVC Web 应用程序，可以在内部单机低成本服务器上运行。它将运行 Web 服务器以及数据库（关系数据库，也可能是文档数据库）和全文搜索（不是 SQL FTS，而是像 Lucene 或 Sphinx 这样的高速独立产品）。但在最初的仅限邀请期之后，我想将此应用程序移至云端，以使其更适合流量/负载需求。
据我所知，亚马逊提供了一种虚拟机托管，我知道您可以将其设置为普通服务器，但在负载能力方面可能具有灵活的资源。我不确定这是否也可以在 Azure 上完成。
问题
- 您在将应用程序迁移到云方面有什么经验？您选择了哪一种？为什么？
- 您建议我在设计/开发解决方案时应该考虑什么，以使过渡尽可能轻松。
- 根据您的经验，迁移到云（财务方面）更好，还是自己购买自己的服务器和负载平衡应用程序更好，从长远来看也许可以省钱？
I'm about to start development on a project with very uncertain load/traffic specifics. When it will be released there will certainly be very low load that can easily be handled by a single desktop quad code machine.
The problem is that there will be (after some invite-only period) a strong publicity for the product so I expect considerable traffic/load peaks.
I haven't read enough about cloud providers and I'm mostly leaning toward Amazon or Azure for the credibility these two companies have without checking them out as I should with others (ie. Rackspace that I suppose is also a cloud service provider).
What I want
I would like to create a normal Asp.net MVC web application that can be run on in-house single machine low-cost server. It would run web server along with database (relational and maybe also document) and fulltext search (not SQL FTS but rather high speed separate product like Lucene or Sphinx). But after initial invite-only period I'd like to move this app to the cloud to make it more traffic/load demand-friendly.
As much as I know Amazon offers a sort of virtual machine hosting which I understand you setup as a normal server but has possible flexible resources in terms of load power. I'm not sure if that can be accomplished on Azure as well.
Questions
- What is your experience with application transition to cloud and which one did you choose and why?
- What would you recommend I should think about when designing/developing the solution to make the transition as painless as possible.
- Based on your experience is it better to move to the cloud (financial wise) or is it better to buy your own servers and load balance application yourself and maybe save money on the long run?
发布评论
评论（4）
“云”是一个非常模糊的术语。不过，我认为这是一个非常好的问题。
基本上，IaaS 云托管不会神奇地使您的应用程序扩展。它实际上是一个虚拟专用服务器，合同/取消期限非常短。
对于可扩展性来说，神奇之处不在于托管，而在于应用程序代码本身的水平可扩展性。这与所有分布式计算挑战有关。例如，添加更多应用程序服务器并不总是那么容易：您必须确保不在服务器应用程序中保留任何用户状态（而是在数据库中，
static可能是邪恶的）、缓存可能会出现问题，因为如果您使用循环策略等，本地缓存可能会使情况变得更糟。您实际上不需要做任何不同的事情来托管在 EC2 或 Azure 上 - 基本上。但当然，当事情发展时，事情就不那么容易了。
例如，EC2 实例存储相当有限。然而，EBS 上的附加存储无法提供可比较的性能特征，并且可能比磁盘更滞后。这里的要点是，EBS确实能够神奇地扩展，而且它可能更像是 PaaS，而不是 IaaS；但它不是一个简单的硬盘，因此它的行为也不像硬盘。我不知道Azure块存储。一般来说，无论额外的抽象层做什么，都会带来它们自己的问题。
典型的云提供商比通常的“全方位 VPS 提供商”更昂贵，但根据我的经验，它们也更加可靠和专业。 EC2 有免费套餐（但很小），Azure 为您免费提供 3 个月的小型实例。
正确地进行计算是相当棘手的；例如，如果您出于某种原因必须关闭服务，那么最好现在就取消，而不是再支付一年的费用 - 您可能希望将此风险纳入您的计算中。另一方面，如果您注册 6 或 12 个月，而不是按小时付费，那么 EC2 和 Azure 都会便宜得多。
您可能想查看免费的 Azure 计划，因为无需任何费用就可以开始摆弄，这真是太好了。云提供商的一大优势是您可以非常轻松地垂直扩展：购买 16 核、64GB RAM 服务器机器确实很昂贵，但如果您的网站流量如此之大，升级您的计划就不会如此。这不是一个大问题。
"Cloud" is such a vague term. Still, I think this is a very good question.
Basically, IaaS cloud hosting does not magically make your application scale. It's really a virtual private server with very short contract / cancellation periods.
For scalability, the magic lies not so much in the hosting, but in the horizontal scalability of the application code itself. This is related to all the distributed computing challenges. For example, adding more application servers is not always easy: you must be sure that you don't persist any user state in the server application (but rather in a database,
staticcan be evil), caching can be problematic because local caches can make the situation worse if you're using a round-robin strategy, etc.You don't really have to do anything different just to host on EC2 or Azure -- basically. But of course, it's not that easy when things grow.
For instance, EC2 instance storage is rather limited. Additional storage on EBS, however, does not provide comparable performance characteristics and can be a bit more laggy than a disk. The point here is that EBS does magically scale, and it's probably more PaaS than IaaS; but it's not a simple hard disk and it does, consequently, not behave like a hard drive. I don't know about Azure block storage. In general, expect additional abstraction layers to introduce problems of their own, no matter what they do.
Typical cloud providers are more expensive than the usual 'round-the-corner VPS providers, but they are, to my experience, also much more reliable and professional. EC2 has a free tier (but it's quite small), Azure gives you a small instance for free for 3 months.
Doing the calculation right is rather tricky; for example, if you have to shut down your service for whatever reason, it's nice to be able to cancel now rather than pay another year - you might want to put this risk into your calculation. On the other hand, both EC2 and Azure will be considerably cheaper if you sign up for 6 or 12 months, rather than paying by the hour.
You might want to check out the free Azure plan, because it's nice to start fiddling around without any cost. A big advantage of cloud providers is that you can scale vertically very easily: buying a 16 core, 64GB RAM server machine is really expensive, but if there's so much traffic on your site, upgrading your plan won't be such a big issue.
因为有人还没有提到它......
AppHarbor 太棒了。您可以在几分钟内推送东西。部署轻而易举。并且为此设置您的项目也更加容易。它甚至不需要对您的解决方案进行任何重大更改即可适应。
对于全文搜索，您可能会考虑类似 Websolr 。
As someone hasn't mention it yet...
AppHarbor has been amazing. You can push stuff in a matter of minutes. Deployment is a breeze. And setting up your project for it is easier as well. And it doesn't even require any major changes in your solution to fit in.
For the full-text search, you might consider something like Websolr.
这在很大程度上取决于您的应用程序正在做什么（例如，是否存在可以从在不同实例上运行中受益的可分离组件，而不是带有前端的简单 CRUD 应用程序）。需要考虑的一件事是，在云应用程序中通常没有传统的关系数据库。因此，您必须选择云或传统托管，或者计划对访问层进行两次编码。 Azure 确实有关系数据库 (SQL Azure)，尽管它们与 SQL Server 2008R2 并不相同。您必须根据您的具体情况研究云设置的优缺点。
就财务问题而言，在托管公司而不是云服务上获得一个帐户通常要便宜得多，因为您按月付费，而不是按小时付费（上次我检查了 Azure 24/7 运行的帐户）一个月的费用约为 40-50 美元，而您可以每月 15 美元获得托管服务）。当您必须运行多个服务器并且维护它们的成本超过云平台上的实例的成本时，云可以节省成本。
所以，抱歉，我们没有灵丹妙药的答案。了解可用的不同服务。考虑您的应用程序需要什么、价格是多少，然后从那里开始。
A lot of this depends on what your app is doing (e.g., are there separable components that might benefit from running on different instances, vs. a simple CRUD application with a front end). One thing to consider is that in a cloud application you normally don't have a traditional relational database. As such, you have to choose either cloud or traditional hosting, or plan on coding your access layer twice. Azure does have relational databases (SQL Azure), although they're not identical to SQL Server 2008R2. You're going to have to research the pros/cons of a cloud setup for your specific situation.
As far as financial concerns, it's usually a lot cheaper to just get an account with a hosting company instead of a cloud service, since you pay by the month, instead of the hour (last time I checked an account with Azure running 24/7 for a month would cost about $40-$50, while you can get hosting for $15 a month). The savings with the cloud come in when you have to run several servers, and the cost of maintaining them surpasses the cost of the instance on the cloud platform.
So, sorry, there's no silver bullet answer for you. Read up on the different services available. Consider what your application needs, what prices will be, and go from there.
我刚刚将基于 MVC 的应用程序从专用服务器迁移到 Azure。迁移 MSSQl 数据库时，我首先尝试导入 .bacpak 文件，但某些表因其大小而失败。然后，我使用了 SQL 数据库迁移向导，该向导对于小型表工作正常，但对于具有 BLOB 字段的表则失败。对于这些表，我必须使用临时中间表。过了一段时间，所有数据都传输完毕后，设置 Web 应用程序变得轻而易举，我们就开始投入生产了。起初，一切似乎都工作得很好，但几个小时后，当负载变重时，就会出现各种错误。我进入 Azure 门户，很容易看到
I have just migrated an MVC-based application from a dedicated server to Azure. When migrating the MSSQl-database, I first tried importing .bacpak files but some of the tables failed because of their size. I then used the SQL Database migratio wizard which worked fine for small tables but failed for tables with BLOB-fields. For these tables I had to use temporary intermediate tables. Then after a while after all the data was transferred setting up the Webapp was a breeze and we went in production. At first, everything seemed to work just fine, but after a couple of hours when the load got heavier, all kind of errors occurred. I went into the Azure portal and it was really easy to see the