中国的云计算是个快速发展的行业，业内里的玩家很拼，也吸引了很多人临渊慕鱼。我在曾经和很多人聊过如何设计、采购、投资或者监管云计算，现在将我的观点通过网文分享给大家。——成本篇，
要做好云计算必须的成本主要分六大类，说完这六大类成本，我们再聊聊谁有成本优势，谁该如何发力。
云计算六大成本要素
1、硬件成本
硬件成本主要就是采购服务器、交换机及其零部件的成本。土豪大厂还会采购硬件负载均衡和硬件存储，科研大厂还会自研整柜服务器。这里小厂商只能用常规价买服务器，大厂商一次采购上万台服务器，能把供应商的利润压榨到低于余额宝收益。
我一直说Intel是云计算行业最大赢家，每个云计算大会Intel都会慷慨赞助，因为只要你的技术选型不太偏门，都离不开Intel的硬件。
2、机柜成本
机柜成本简单说就是电力成本，电力是实打实的资源，不是摔一把钞票到地上就能买到电力，IDC的不间断供电要求是等同于ICU病房的。小型云厂商基本都是一个13安电机柜每月花四五千块钱;大型云厂商都是自营无利润IDC、整柜服务器、高效散热系统，虽然节能效率有夸大吹嘘的成分，但成本是远低于小型云厂商的。
3、网络成本
网络成本包含IP和带宽，租一小段IP不贵，但是以现在IP(v4)地址的稀缺状态，有钱也可能买不到几万个IP。带宽是云计算运营的硬成本，大厂商的集采压价优势同样明显，而且大厂商还可以拉很多对等互联网络节省资费。此外还有DDOS问题、IP段被污染问题、ICP备案问题等等，也在提高网络成本。
4、闲置成本
巨大的采购体量必然会造成极大的资源闲。假设我一次采购上架200柜服务器，那就要售出5万台虚拟机才能充分利用硬件。硬件从上架之时就在不停的折旧，但虚拟机能卖多快却不好预估。而你可以随时上线200个机柜，那就代表机柜和网络也留了很多富余。
理论上来说，大厂商规模大，富余闲置的百分比会小一些，小厂商规模有限，富余闲置的百分比会大一些。但以前从未有过需要“机柜+带宽+服务器”一起做规划预估的情况，大厂商的资源估算人员未必估的够准确，往往会“饥一顿、饱一顿”，不是资源紧绷到过度超卖，就是资源像大水漫灌一样的浪费;而对小厂商来说，客户固定估算简单，就算资源不足也不会成为大新闻。所以，闲置成本这一块各有千秋，说不清楚谁的成本更低。
5、人力成本
作为云计算从业人员，感谢这个行业给我们带来了高薪。对公司来说，高薪招揽技术人才可以提高公司核心竞争力，极大加快产品上线速度。如果工资翻倍挖个技术人员，让某个项目提前半年上线，或者多花了200万雇个5人小组，但融资金额多了3000万，从公司角度是包赚不赔的。
说技术人员的具体薪水有点泄密，我们八卦一下某些销售人员也能惊掉外行的下巴。一个智商和沟通能力都正常，无任何特殊社会资源，公司商机正常分配的商务客服级销售人员，他们的底薪和提成是其他软件行业销售的2-5倍。别说你不信，刚确认这个消息的时候，我也郁郁寡欢了好几天。
那些自负盈亏、没有VC资金支持的老一代厂商都在尝试转云，但他们的员工待遇太低了，在抢人大战中没有任何胜算，这一点，从很多传统IT公司出来的技术人员体验最深。
6、市场成本
云计算企业的品宣和会务的成本可能比传销公司还高。以某最火runtime环境为例，据知情人士透露该行业的初创公司50%的成本用在品宣了。每年到开各种技术会议的时候，机票酒店都会涨价，大量二手售卖会议赠品，也是一片繁华景象。
无论是初创公司还是大公司的云计算分舵，都不愿意这样烧钱，但你不烧钱市场就会忽略你的存在。上文说到一些普通销售靠公司分配商机，也和强大的市场引流(烧钱)能力有很大关系，只要产品过硬，多参会总是不亏的。
成本综合评估
综上所述，前三条成本，大厂商相对小厂商占据了绝对优势，但大厂商之间的成本区别并不大，因为硬件降价折扣是有底线，全国能拿到低价服务器、机柜和带宽的厂商，肯定超过十家了。企业客户是理性选择供应商，并不会盲目黏在一个平台不走，而各厂的技术差距早晚是能追平的，后入场的大玩家一样有插足分羹的机会。
小厂商的机会集中在如何避免同大厂商在前三条上正面PK，少丢分或不丢分，然后在后三条上发力破局。首先，天使和A轮的小厂商，创始人大都是业内知名人士。BCD轮的小厂商，抢人姿势超级凶残，烧点工资快速刷出产品线和销售额，VC也会很开心。小厂商可以保持灵活的身姿、手握精兵团队，而大厂商因为决策链太长，庸才冗吏太多，后三条很容易丢分。
小厂的出路在哪里
小厂商并非毫无胜算，他们甚至有机会活的比过去更好。因为大厂商在完成培育市场、教育客户的工作，小厂商当下可选的策略非常多，我做个简要描述。
1、小厂商可以做私有云，硬件机柜和带宽成本让客户来承担。
2、小厂商有自身灵活性，售前阶段技术总监亲自出马很容易吹死大厂商的普通职员，出了故障CTO挂帅快速解决故障;而大厂员工吹牛怕是过不了法务这一关、没高层和
3、小厂商可以做特定领域的公有云，其短板不明显还能发挥其他长处。以某云存储为例，因其巨大的磁盘采购量磁盘价格已经很低了，其技术选型尽量廉价通用，又找回来一部分硬件成本。云存储习惯做CDN源站不需要BGP带宽，网络成本也很低。
4、小厂商可以直接用大厂商的资源，比如一些PaaS和SaaS厂商的海外节点，可能就是租的两云群网络的虚拟机。
5、小厂商可以卖股份给大厂商或者大客户，或者和IDC组成利益共同体。因为大厂商也知道自己神经末梢太长，陈腐组织太多了，急需新鲜血液补充。
6、小厂商相对大厂来说足够中立，客户可能和大厂云的兄弟部门是直接竞争关系
个月以前，我与一些人讨论过关于公共云服务成本与传统专用基础设施价格比较的话题。为给你提供一些见解，我们来跟踪一下一个企业中的两个开发团队 — 并比较他们构建类似服务的方式。
如何剑走偏锋的做出自己的特色
这两个团队被要求为一家全球化企业开发一个新的服务，该企业目前为全球数百万消费者提供服务。要开发的这项新服务需要满足以下基本需求：
能够随时扩展以满足弹性需求
具备应对数据中心故障的弹性
确保数据安全以及数据受到保护
为排错提供深入的调试功能
项目必须能迅速分发
服务构建和维护的性价比要高
就新服务来说，这看起来是非常标准的需求 — 从本质上看传统专用基础设备上没有什么东西可以超越公共云了。
1 — 扩展以满足客户需求
当说到可扩展性时，这个新服务需要去满足客户变化无常的需求。我们构建的服务不可以拒绝任何请求，以防让公司遭受损失或者声誉受到影响。
传统团队
使用的是专用基础设施，架构体系的计算能力需要与峰值数据需求相匹配。对于负载变化无常的服务来说，大量昂贵的计算能力在低利用率时被浪费掉。
这是一种很浪费的方法 — 并且大量的资本支出会侵蚀掉你的利润。另外，这些未充分利用的庞大的服务器资源的维护也是一项很大的运营成本。这是一项你无法忽略的成本 — 我不得不再强调一下，为支持一个单一服务去维护一机柜的服务器是多么的浪费时间和金钱。
云团队
使用的是基于云的自动伸缩解决方案，应用会按需要进行自动扩展和收缩。也就是说你只需要支付你所消费的计算资源的费用。
一个架构良好的基于云的应用可以实现无缝地伸缩 — 并且还是自动进行的。开发团队只需要定义好自动伸缩的资源组即可，即当你的应用 CPU 利用率达到某个高位、或者每秒有多大请求数时启动多少实例，并且你可以根据你的意愿去定制这些规则。
2 — 应对故障的弹性
当说到弹性时，将托管服务的基础设施放在同一个房间里并不是一个好的选择。如果你的应用托管在一个单一的数据中心 — （不是如果）发生某些失败时（LCTT 译注：指坍塌、地震、洪灾等），你的所有的东西都被埋了。
传统团队
满足这种基本需求的标准解决方案是，为实现局部弹性建立至少两个服务器 — 在地理上冗余的数据中心之间实施秒级复制。
开发团队需要一个负载均衡解决方案，以便于在发生饱和或者故障等事件时将流量转向到另一个节点 — 并且还要确保镜像节点之间，整个栈是持续完全同步的。
云团队
在 AWS 全球 50 个地区中，他们都提供多个可用区。每个区域由多个容错数据中心组成 — 通过自动故障切换功能，AWS 可以将服务无缝地转移到该地区的其它区中。
在一个 CloudFormation 模板中定义你的基础设施即代码，确保你的基础设施在自动伸缩事件中跨区保持一致 — 而对于流量的流向管理，AWS 负载均衡服务仅需要做很少的配置即可。
3 — 安全和数据保护
安全是一个组织中任何一个系统的基本要求。我想你肯定不想成为那些不幸遭遇安全问题的公司之一的。
传统团队
为保证运行他们服务的基础服务器安全，他们不得不持续投入成本。这意味着将需要投资一个团队，以监视和识别安全威胁，并用来自不同数据源的跨多个供应商解决方案打上补丁。
云团队
使用公共云并不能免除来自安全方面的责任。云团队仍然需要提高警惕，但是并不需要去担心为底层基础设施打补丁的问题。AWS 将积极地对付各种零日漏洞 — 最近的一次是 Spectre 和 Meltdown。
利用来自 AWS 的身份管理和加密安全服务，可以让云团队专注于他们的应用 — 而不是无差别的安全管理。使用 CloudTrail 对 API 到 AWS 服务的调用做全面审计，可以实现透明地监视。
4 — 监视和日志
任何基础设施和部署为服务的应用都需要严密监视实时数据。团队应该有一个可以访问的仪表板，当超过指标阈值时仪表板会显示警报，并能够在排错时提供与事件相关的日志。
传统团队
对于传统基础设施，将不得不在跨不同供应商和“雪花状”的解决方案上配置监视和报告解决方案。配置这些“见鬼的”解决方案将花费你大量的时间和精力 — 并且能够正确地实现你的目的是相当困难的。
对于大多数部署在专用基础设施上的应用来说，为了搞清楚你的应用为什么崩溃，你可以通过搜索保存在你的服务器文件系统上的日志文件来找到答案。为此你的团队需要通过 SSH 进入服务器，导航到日志文件所在的目录，然后浪费大量的时间，通过 grep 在成百上千的日志文件中寻找。如果你在一个横跨 60 台服务器上部署的应用中这么做 — 我能负责任地告诉你，这是一个极差的解决方案。
云团队
利用原生的 AWS 服务，如 CloudWatch 和 CloudTrail，来做云应用程序的监视是非常容易。不需要很多的配置，开发团队就可以监视部署的服务上的各种指标 — 问题的排除过程也不再是个恶梦了。
对于传统的基础设施，团队需要构建自己的解决方案，配置他们的 REST API 或者服务去推送日志到一个聚合器。而得到这个“开箱即用”的解决方案将对生产力有极大的提升。
5 — 加速开发进程
现在的商业环境中，快速上市的能力越来越重要。由于实施的延误所失去的机会成本，可能成为影响最终利润的一个主要因素。
传统团队
对于大多数组织，他们需要在新项目所需要的硬件采购、配置和部署上花费很长的时间 — 并且由于预测能力差，提前获得的额外的性能将造成大量的浪费。
而且还有可能的是，传统的开发团队在无数的“筒仓”中穿梭以及在移交创建的服务上花费数月的时间。项目的每一步都会在数据库、系统、安全、以及网络管理方面需要一个独立工作。
云团队
而云团队开发新特性时，拥有大量的随时可投入生产系统的服务套件供你使用。这是开发者的天堂。每个 AWS 服务一般都有非常好的文档并且可以通过你选择的语言以编程的方式去访问。
使用新的云架构，例如无服务器，开发团队可以在最小化冲突的前提下构建和部署一个可扩展的解决方案。比如，只需要几天时间就可以建立一个 Imgur 的无服务器克隆，它具有图像识别的特性，内置一个产品级的监视/日志解决方案，并且它的弹性极好。
如何建立一个 Imgur 的无服务器克隆
如何建立一个 Imgur 的无服务器克隆
如果必须要我亲自去设计弹性和可伸缩性，我可以向你保证，我会陷在这个项目的开发里 — 而且最终的产品将远不如目前的这个好。
从我实践的情况来看，使用无服务器架构的交付时间远小于在大多数公司中提供硬件所花费的时间。我只是简单地将一系列 AWS 服务与 Lambda 功能 — 以及 ta-da 耦合到一起而已！我只专注于开发解决方案，而无差别的可伸缩性和弹性是由 AWS 为我处理的。
关于云计算成本的结论
就弹性而言，云计算团队的按需扩展是当之无愧的赢家 — 因为他们仅为需要的计算能力埋单。而不需要为维护和底层的物理基础设施打补丁付出相应的资源。
云计算也为开发团队提供一个可使用多个可用区的弹性架构、为每个服务构建的安全特性、持续的日志和监视工具、随用随付的服务、以及低成本的加速分发实践。
大多数情况下，云计算的成本要远低于为你的应用运行所需要的购买、支持、维护和设计的按需基础架构的成本 — 并且云计算的麻烦事更少。
通过利用云计算，我们可以更少的先期投入而使业务快速开展。整体而言，当你开发和部署业务服务时，云计算的经济性可以让你的工作更赞。
也有一些云计算比传统基础设施更昂贵的例子，一些情况是在周末忘记关闭运行的一些极其昂贵的测试机器。
Dropbox 在决定推出自己的基础设施并减少对 AWS 服务的依赖之后，在两年的时间内节省近 7500 万美元的费用，Dropbox…——www.geekwire.com
即便如此，这样的案例仍然是非常少见的。更不用说当初 Dropbox 也是从 AWS 上开始它的业务的 — 并且当它的业务达到一个临界点时，才决定离开这个平台。即便到现在，他们也已经进入到云计算的领域了，并且还在 AWS 和 GCP 上保留了 40% 的基础设施。
将云服务与基于单一“成本”指标（LCTT 译注：此处的“成本”仅指物理基础设施的购置成本）的传统基础设施比较的想法是极其幼稚的 — 公然无视云为开发团队和你的业务带来的一些主要的优势。
在极少数的情况下，云服务比传统基础设施产生更多的绝对成本 — 但它在开发团队的生产力、速度和创新方面仍然贡献着更好的价值。
客户才不在乎你的数据中心呢
客户才不在乎你的数据中心呢
客户才不在乎你的数据中心呢