如果我今天玩的是流行词宾果游戏，我真的想把云、Fabric、OpenFlow、API和Stack这些词排在一起——我肯定会在会议开始42秒的任何供应商简报中胜出。让我们面对现实吧，即使某个供应商的产品是专为壁橱布线或分支路由设计的，他们也都在试图找到某种方式将其连接到云列车上。我最基本的问题是，这行得通吗?我能否将设计点、价格结构和吸引力都直接针对大型企业的产品和技术，有效地重新定位到云市场，使客户和供应商不受影响?看，这方面的挑战在于，公共云是IT最纯粹的形式之一。IT运营是公共云的业务。没有什么能掩盖这种架构的罪恶——失败/中断是公开的，架构的资本支出和运营支出直接影响底线，借用史蒂夫·乔布斯的话说，你不能通过出售更多的糖水来掩盖糟糕的IT决策。我听到很多人谈论“云”(他们说它的方式我觉得必须大写),另一个让我震惊的是深刻的谈话我和兰迪偏见,首席技术官兰迪很直接的表述,“你不能建立一个有利可图的和具有价格竞争力的公共云与企业技术、供应商税收太陡峭了。”Randy还指出，云需要新的设计模式，即基于商用硬件、开源软件、用于编程访问的api、水平伸缩、自动化和多租户的简单系统。因此，我对这个问题进行了一些探讨，并意识到这些云部署的成本以多种方式体现出来，有些方式比其他方式更切实:——作为一个公共云提供商，你必须购买设备。(当然，像这样的供应商，随着云服务提供商开始接受越来越多的中小型商业应用，很容易就会出现一些需求方面的整合，所以这对受影响的供应商来说是一场关键的战斗。)问题是供应商必须为了利润而操作这些设备。所以他们付的钱越少，或者他们使用的设备越便宜，他们就越有利可图。I have seen some configurations cut the revenue potential of a public cloud in half by taking too much power, and then further reduce profitability by having per Socket/CPU taxes on software, grossly expensive networking gear chock full of features that add to the complexity of the network - yet aren't consistently manageable or capable of being automated, and have no programmatic APIs. - operational expenses add up, and the one many people hone in on is power draw and maintenance contracts. I have seen many vendors looking at power draw as, "We are 30% less power than Competitor X, so we can save you money." I will contend this is probably a bass-ackwards way of looking at it for a cloud provider - its about compute density.
资产购置成本
运营成本
- 如果我有3MW的空间，我将用尽可能多的服务器来填满它。
- 一个拥有良好内存块和双插槽CPU的优秀的SuperMicro服务器将消耗350-400W
- 最好的情况是，在没有其他基础设施的情况下，我可以在这个数据中心安装大约8571台服务器，或大约215个机柜雷竞技电脑网站
- 在同一个电网上，您放入该数据中心的其他所有内容都会降低您对最多857雷竞技电脑网站1台服务器的支持能力。如果每台服务器可以容纳40个VM-SMALL，在亚马逊的价格大约64美元/月每VM-SMALL，我可以赚2560美元每台服务器
因此，3MW的数雷竞技电脑网站据中心每月的最大收入潜力为21,941,760美元。但这是你真正开始改变的地方——你投入的每一个交换机、路由器、负载均衡器和防火墙都减少了你所支持的服务器数量。你每消费350W，每月就会减少2560美元的潜在收入。整合成本我最近看到的常见问题是:
您正在考虑使用的设备是否可以由您的云管理系统管理——它是否绑定并集成?这些成本会很快超过其他所有成本——如果系统拥有定义良好、遵循的本地或远程api，并且版本控制或预先集成到您使用的任何云管理软件/框架中，那么您可能已经有了一个良好的开端。如果可用的最佳方法是CLI，并且希望您编写PERL并进行一些屏幕抓取，以提供vlan和段并添加路由条目，那么您可能需要继续查找。
所有这些都是一个主题的变体，顺便说一下，许多云管理公司似乎都是基于这样一个前提:他们可以提供裸机服务器，如果他们在其周围放置漂亮的ui，他们就可以拥有一个整洁的新服务。他们把东西安装好并运行起来，它在一两个柜子里工作得很好。然后他们开始扩展-然后他们遇到了网络。很多人忘记了网络设计的原因,和许多客户不舒适的改变他们的网络批发,而且几乎从不是一个网络存在的每一个端口可以跟其他端口wirespeed, L2,没有层次结构和支持成千上万的港口。(我不想讨论它是否可以构建，哪些供应商支持什么:它是可以构建的，但大多数现有网络不是这样构建的。)
- 一家供应商只支持1000个VLAN，但是他们希望用VLAN分隔客户，并为每个VM提供多个vnic。他们很快耗尽了vlan，无法将服务器填满。
- 一个云管理公司没有与他们的底层网络集成，所以他们永远不能升级他们的交换机。他们有一些容易纠正的问题，新代码已经可用了好几个月，但永远无法升级。中断引起的。
- 一个客户从一个厂商联盟那里购买了一个预配置的“罐装云”——为了收支平衡，他们必须以450美元/月的价格出售每个虚拟机。他们的竞争对手每月收费50美元，并且盈利——他们使用开源软件和低成本的硬件。
- 一个客户基于机架顶部的交换机构建了一个简单的云，但当他们不得不向外扩展时，却没有计划昂贵的L3聚合交换机成本，并推迟了扩张，直到他们有了成本成本。后来，当他们添加了聚合设备时，他们意识到他们没有为L3边界附近的寻址问题和VM移动性问题做好计划。
从这些故事,所以,我总和一些表格我齐心协力做成本比较,和从我看过许多公司建设公共云,如果你使用“云在一个可以”的方法从供应商销售产品,为企业客户设计和建造你可以让它工作,但是你将会失去在近期:
- 大多数情况下你会多付钱
- 您通常会得到一个非常复杂的系统，它没有以有意义的方式与任何云管理系统集成
- 由于低效率的电力消耗和HVAC处理，你将减少你可以推向市场的服务器数量
但是你们都看到了什么?有没有盈利的、不断增长的公共云的例子，它们不运行在开源软件、低成本的硬件上，或者有编程api和简单的系统?