我认为这是一个很好的问题,但任何人都会努力给你一个答案,因为你的结果总是会有所不同,并且来自该领域的人的回复会对他们的具体情况过于具体。
我,我们在Azure上运行一个真实世界的解决方案。事实上,如果您决定使用Azure,请考虑使用它来优化Azure的计算实例分配:http://www.paraleap.com :)
我可以告诉您,您希望预算至少有20%的额外计算时间,原因是不同的时候,当你需要部署/重新部署/并重新部署一个环境到暂存区域(每小时增加一个额外的花费)时,只有在云中发现其他东西时,它在dev结构中工作时不起作用。在您的应用程序的最初不稳定时间尤其如此。如果您有一个大型QA团队将您的Azure-QA环境暴露出来,或者您将要为客户进行beta测试并且他们正在测试您的Azure-Prod环境,那并不重要。您需要经常为他们安静地重新部署。另外,正如我已经提到的,计划根据需求调整您的实例数 - 希望自动或按计划进行调整。如果您要编写自己的监控来执行此操作,请为此添加/ bunch /开发成本,存储成本和交易成本。外包这个仍然会花费一点点,因为性能指标需要至少保存一次,并且至少需要重新加载一次。这将使计算实例成本轻松地节省多达50-80%,具体取决于需求变化的多少。
存储成本 - 这些应该很容易,如果你知道你的使用模式和目标模式,估计......问题是,如果你与前关系型数据库的工作,现在将使用表存储,计划有3-你认为你的关系数据库有4倍的大小。通过表格存储,您可以更多地反转ALOT。 3-4倍,甚至可能太小的乘数 - 你的结果可能会有所不同。
交易成本。我发现在这些方面,我的估计进一步提高了。从关系世界来看,我并没有完全准备好我需要做的非规范化的程度。非规范化不仅会导致更高的存储成本,还会导致更多的调用(更多调用)到存储 - 从而导致更高的事务计数。
不幸的是,我的应用程序的性质,我不能很好地用交易模式。如果您可以使用事务处理,其中一堆内容存储在一个表中的一个PartitionKey中,并使用一个事务进行提交 - 那么成本要低得多。所以,不管你认为你的交易成本是多少 - 要乘以10左右才能达到悲观的一面。
我发现,转移成本是最简单的规划,可能是因为这些都是接口的一部分,并且更好的定义前期。你的旅费可能会改变。
最后,诊断数据 - 您将要保存一些跟踪/性能计数器/等。信息。不要忘记计划。它有点不规范,可以占用大量空间。
SQL Azure的是伟大的,因为它没有被交易成本,如果同一个数据中心内没有转移成本费 - 但空间和存储数据的成本是非常有限的。所以,我经常使用它来查询,但小数据项。
希望这有助于
怎么样的定价是很难搞清楚?主要成本通常是“您运行多少个虚拟机几个小时?”和“你将消耗多少带宽?” – smarx 2010-11-30 14:28:01