阿里云智能技术战略架构师陈绪：透视2019云计算酣战

本文作者是阿里云智能技术战略架构师陈绪。

2019年3月21日阿里云北京峰会落下帷幕，阿里云智能总裁张建锋阐释了阿里云战略加速的“四级火箭”：达摩院加持的云、数据智能的云、最佳实践的云和被集成的云，在业界引起巨大反响。作为“企业级基础设施专场 - CIO核心能力：云上构建亿级规模的IT基础设施”的出品人，我有幸主持了该专场，也做了一个10分钟的开场演讲，很高兴结合大会的组织过程，把我对2019年云计算发展的思考和大家做一个分享。

企业级基础设施专场 - CIO核心能力：云上构建亿级规模的IT基础设施

感谢许呙兢同学的信任和重托，我和专场架构师张强及另一位出品人孟蓁一起，操持了议题的甄选和确定。
国内公共云的营收，目前很大一部分还来自IaaS基础设施，首先这说明中国的云计算发展阶段还处于早期，对于弹性、效率等价值的认可还有很大的挖掘空间。
业界有一个说法：当下挣钱的东西都不前沿，当下前沿的东西都不挣钱。而企业基础设施的技术和产品既要挣钱，又要前沿，那么主题应该怎么安排呢？
应该说，同学们要发布产品和介绍技术的积极性还是很高的。初期review之后，经过话题整合，很快我们就确立了8个演讲。

• 何诚同学的“飞天基础设施智能运维创新和实践”
• 胡晓博同学的“基于ECS构建稳定、高业务弹性、低成本的企业应用实践解析”
• Alex Chen同学的“普惠数据智能经济 下一代云上存储创新”
• NetApp总监王熙明先生的“DT时代的企业混合云存储架构探讨”
• 谭礼铨同学的“构建安全、智能、开放的下一代企业级网络”
• 潘岳同学的“异构计算为企业上云提供核动力”
• 张子轩同学和周剑同学的“实现规模化、自动化的云上IT管理”
• 章君同学的“云上护航服务 保障云上尖峰时刻”

主线非常清晰，就是从IDC、弹性计算、存储、存储生态、网络、GPU异构、OpenAPI、云上护航等维度展示阿里云技术设施的亿级能力，逻辑是从下往上逐层展示我们的最新技术和产品，提升客户的兴趣！特别感谢王熙明先生带来NetApp对混合云存储的思考，我也受益良多。

为何要我开场

我本意是找一位美女同学来开场和主持。许呙兢同学指出，我在业界小有名气，如果请我开场，会吸引更多目标人群报名参会；同时，许呙兢对业界媒体大咖“狒哥”的主持风格大为赞赏，就是每个演讲完毕后由主持人做一个简要的点评，帮助听众理解，希望我也能沿袭。

作为出品人，当然要以专场的价值作为第一价值，我就积极接受了开场和主持的任务。

那么，我想既然要开场，那么有两个事情要说清楚，第一是本专场演讲的安排逻辑，第二还得送一碟开胃小菜，就是本文要将的2019年云计算发展趋势。

一般来说，趋势得凑足十条，不能多也不能少。于是我拍拍脑袋想了14条，发在内部钉群，征集部门同学们的反馈，结果就沉淀了以下十条，希望引起大家的共鸣。

2020年前后，中国会出现盈亏平衡的公共云

我认为，公共云的盈亏平衡点对于公司的长远发展是至关重要的。2015年7 月 24 日，全球电商巨头亚马逊发布了 2015 年第二季度财报，一直以来因为亏损而出名的亚马逊终于盈利了。该季度AWS 贡献了 18.24 亿美元净营收，同比增长 81%；AWS 运营利润也从上年同期的 7700 万美元增加到 3.91 亿美元。

财报发布后，亚马逊股价在盘后大涨近20%。之后，AWS的营收和盈利都一骑红尘，快速增长。也正是在这个时间阶段，阿里云的“骗子”成了“神”。不久后，央视在2016年3月7日《走近科学》栏目播出了一部专题片“王博士的计算梦”。

注意，这个论断中的多个关键词：

2020年前后。2019年是没戏的，原因可以从各公共云公司的财报中看到体现。我们内部的同学和我说：十年的努力，让我们对成本已经控制到极致，我们都不盈利，别人怎么可能盈利。

中国。上文已经说过AWS已经在全球第一个盈利。

公共云。其实在中国做云公司盈利说难也难，说简单也简单。我就知道有些小公司，人数不多，一年接几个小单子，账面上就是盈利的。但问题是，这些订单都是通过以前的关系得来，不具备扩大的潜力。所以，一时的盈亏平衡是没有意义的，长期地从盈亏平衡开始的快速盈利才是关键。

在IT行业，特别是赢家通吃的领域，有一个证明过多次的现象。第一名盈利，第二名不盈利，第三名及之后全都亏钱。2018年年底，中国有几个云计算公司大打口水仗，都说自己是第N名，完全是没有任何意义的PR行为。

还有一种手法，就是采用财务手法来调节收入。报表可能这么显示，近几年的财务报表都是微盈利。由于没有看到详细的报表，可以猜测很大一部分收入是来自私有云订单或者硬件的销售，短期内覆盖了公共云的亏损。

我所说的“盈亏平衡的公共云”，指的是真正从IaaS、PaaS等领域获得盈利，这样才有长远发展的价值，而非短期对投资者的一种迎合。我坚持认可公共云领域的马太效应，就是强者恒强，大者恒大。

如果发展顺利，出现盈亏平衡的中国公共云厂商的时间节点是2020年，如果慢一点，大概率是2021年。只有出现不可阻挡的优势，才会有公司退出这个领域，美国前几年就出现过多家公司退出公共云领域。

通过开放API管理混合云会更受大客户欢迎

本文的发展趋势条目是早就准备好的，我也没有参加张建锋总裁的主题演讲资料准备，但是我高兴地发现，上午主会场的演讲为这一条做了一个铺垫。因为本条和作为一级火箭的“被集成”是相辅相成的。“被集成”是公司战略，那么战术上如何被集成？手段是通过OpenAPI。

前几天技术战略部的一位同学和我分享了英特尔中国研究院院长宋继强博士的一张演讲照片，图中显示的“统一的异构计算软件开发接口”OneAPI和这里说的OpenAPI也是一脉相承。

2018年中，阿里云OpenAPI的开发工作开始加速。这说明，我们的“被集成”不是突然提出的，而是经过了长时间的内部酝酿。

为什么要有OpenAPI？因为阿里云提供的首先是资源，包括计算、存储、网络等等，我们也提供官方的后台控制管理界面。要控制一台机器，十台机器都是简单的，但是要通过官方后台控制成百上前台机器就比较麻烦。

同时，GC6和GC7的大客户，往往拥有很强的技术研发团队，对自己的业务也非常清楚。他们更希望开发自己的控制台，并灵活地调用各种阿里云提供的资源。没有OpenAPI，这种开发就无法进行。

当年淘宝的聚石塔，也是为商家提供了API，方便商家定制自己的后台，从而获得了较大成功。大客户一旦感受到API带来的方便，就无法离开。

更进一步，AWS一直在致力于提供优秀、统一、高效的API，帮助大客户更好地使用资源。当很多国外客户和合作伙伴进入中国的时候，他们缺省就认为阿里云会有系统的OpenAPI可以调用。

我曾经谈到过公共云是终局，但是混合云是必经的历史阶段，现在正处于这个历史阶段，所以要满足混合云的需求，也必须提供OpenAPI，更好地实现阿里云的“被集成”。

客户倾向于用云存储灾备技术保障数据可靠性

承接上一条的混合云，用户对混合云很感兴趣，主要是因为弹性。弹性是云的基本特征，没有弹性的云其实不是真正的云。私有云要获得弹性，手段就是构建混合云。

同时，混合云还可以带来数据的高可靠性。2018年，中国市场出现过多次因为存储不稳定带来的灾难事故，而且某些极端情况下数据完全丢失无法恢复。事件发生之后，客户对数据可靠性的需求和投资的意愿都有很大提升。

阿里云存储的可靠性是11个9，在提供3AZ的环境下，可靠性达到12个9。要保证用户的数据绝对不丢失怎么办？我不认为请客户自己买一块移动硬盘来定期备份数据会是云计算的未来发展方向，我认为：客户倾向于用云存储灾备技术保障数据可靠性。

NetApp的王熙明总监介绍了备份和灾备的区别。备份是一个有很长历史的名词，就是在另一个媒介上把数据拷贝一份，如果原来的数据丢失，拷贝回来即可。而灾备就是一个云计算的名词了，灾备是指将你的私有云的数据和代码在云上完整地备一份，一旦本地私有云出问题，无论是数据丢失或者是虚机崩溃，公共云上能够立刻拉起计算的环境，并接管对客户的服务，让最终用户感觉不到私有云出了问题。所以这里的存储不仅是对数据的备份，而且还有对整个计算环境的备份和实时拉起的能力。

阿里云的混合云存储团队，经过2年的艰苦工作，研发了HDR（Hybrid Disaster Recovery）解决方案。具体技术就不一一赘述了，我这里强调一点，HDR方案不仅是灾备方案，而且也能解决客户的搬站问题。简单而言，使用HDR的一半功能，将客户的私有云可以迁移到公共云上；接着使用另一半功能，客户私有云和阿里云公共云构成灾备解决方案。迁移上云只是灾备技术的一个子集。

中国出现第一家真正全面云化的大型公司

什么叫全面云化，我觉得有两个关键指标：一是公司的核心业务都要放到云上，很多的公司，特别是金融和电信公司，外围和中间层都是用了虚拟化、云原生等云计算技术，但是核心交易系统还是跑在传统大机上，这个就不是全面云化；二是公司内部只能有一朵云，这意味着所有的资源是统一调度和管理的，有多朵云的不是真正全面云化。
每个成功的互联网公司都有自己的技术发展历程，在业务快速发展的过程中，都是怎么有效怎么来，怎么快怎么来。这就导致基础设施的架构设计不太优雅，或者说不符合现代云计算操作系统的要求。将原有的业务迁移上云，需要时间和详细的分析规划，同时不能影响现有业务。打铁还需自身硬，公共云公司将自己的业务全部上云，会最有说服力。

正如张建锋总裁指出的，现在阿里巴巴集团业务有60-70%是使用阿里云的资源，在未来1-2年内，将100%使用阿里云的资源。一旦成功，这将会成为一个历史性的分水岭。因为据我所知，很多云计算公司内部有多朵完全隔离的云，而且整合也是遥遥无期，没有日程表。全面云化，说起来简单，做起来难。

自建预算大幅削减的企业成为上公共云的主力军

对于云计算能帮助企业节省成本的文章我写过一些，最近我不停地看到这种趋势落到了实处。为了完成数字化转型，从而享受数字经济带来的技术和成本红利，是敦促企业上云的第一动力。

云计算，已经不是一个上亦或不上的问题，而是一个早上或者晚上的问题。不跟上云时代的步伐，就会被时代抛弃。

2019年经济形势严峻，很多公司都开始考虑将线下的计算集群和自建的云计算放到公共云上来。很多客户停止了自建，原因是成本高企，在慢慢消化原来自建机器的同时，剩下的就是往公共云上放多少业务的问题。

2019年之前，这些客户更愿意自己拥有云资产。愿意考虑上云，说明客户遇到了问题，很大程度上是自建预算大幅削减的问题。即使是技术能力不错的公司，也会因为财务预算的原因选择上公共云，大家要积极做好承接的准备。

回顾中国的云计算历史，公共云爆发式增长的时期并没有过去，还有大批企业的传统IT没有上云，现在很多公司会直接跨越自建的阶段，直接使用公共云。

Kubernetes和Kata Containers会成为业界主流

Kubernetes是容器的管理和编排工具，已经成为云原生的代表项目广为认可。阿里云就是Kubernetes的所有者CNCF基金会的白金会员。
今天我们谈一下Kata Containers，最近有一则新闻，是Hyper公司的创始团队赵鹏、王旭等同学加入蚂蚁金服，Hyper也是Kata Container的主要贡献者。但是，我们今天谈到对于Kata Containers的认知和使用和这则新闻并没有直接联系。

2015年，英特尔宣布Clear Containers开源项目，并于2017年底和Hyper的runV合并，新项目称为Kata Containers，与Open Container Initiative（OCI）规范以及Kubernetes的容器运行时接口（CRI）完全兼容。顺便说一下，2019年1月发布的Kata Containers 1.5版本已经支持了AWS发布的Firecracker虚拟机管理程序。

什么是Kata Containers？四个字：安全容器。Docker容器很好，但是不能解决安全问题。安全问题的解决之道是利用CPU硬件的虚拟化功能。Kata Containers将容器的敏捷性和VT硬件虚拟化带来的安全性完美地结合在一起。

公共云的规模效应带来无可辩驳的成本优势

我看到很多专家从各种维度讲解私有云比公共云便宜，这里就不一一分析了。其实我是很疑惑的，因为这个逻辑上不通，因为大规模使用云计算而带来的成本摊销，是云计算提升IT效率的重要手段之一。如果规模化没有带来更高层次SLA上的价格优势，就从根本上否定了云计算的价值。

首先，这些专家往往没有计算自建的私有云所带来的人员、维护等多项费用。而公共云的使用是一揽子付费，付款之后，电费、空间、机房等费用都包含在内了。

此外，计算的灵活性也是一个问题。平均每天需要10台物理机进行计算的客户不会因为一年365天中有一天要用100台机器的规模而采购100台物理机。既要享受100台的峰值计算力，又要不多买一台机器的私有云，是做不到的。要使用云，要为云带来的弹性和效率买单。

开源生态成为云厂商维护开发者关系的手段

从1995年开始我接触Linux并长期在开源社区活动，深刻体会到开源和开发者关系之间的血肉联系。我也多次谈到，自主研发和开源并不矛盾，这就意味着云厂商可以更好地使用开源生态这个杀手锏来加强和开发者之间的连接。

前微软CEO鲍尔默曾经在微软大会上喊出“Developer、Developer、Developer”的口号，他认识到获得开发者支持是微软成功的关键。云平台的成功标志也是能否获得广泛的开发者支持。

我在英特尔期间于2015年4月发起创立的中国开源黑客松（半年一次）已经坚持到第九届，开发者以代码会友，解决网友见面问题。这种活动会成为中国的主流。我更倾向于加入技术联盟，以代码说话是开源生态的基本交流方式。我于2007接手的、从2006年发起的中国Linux内核开发者大会将在2019年第一次来到杭州，希望为大家带来Linux内核顶尖大师的讲座和交流机会。

目前很多公司的开发者关系，还停留在口号上，没有落到实处。开源产生以来，涌现出很多优秀的开源项目，这些项目成为了业界事实上的标准。帮助更多的开源项目在云平台上取得成功，是撬动开发者的重要手段。成功的重要标志就是能否带来实际的经济收益。开发者关系和开源生态给开发者带来的不仅仅是名气，而是要给开发者带来实实在在的盈利。只有云平台自己挣钱，其他参与方都只挣经验不挣钱的生态是不健康、不可持续的生态。

云端GPU计算在业务中应用的广度和深度将成为未来十年衡量企业竞争力的新标尺

2018年12月25日，斯坦福大学发布最新的DAWNbench深度学习推理榜单，阿里云获得了图像识别性能及成本双料冠军，打破了基于亚马逊AWS计算平台保持的长达8个月的纪录。这是该榜单首次出现中国科技公司。

对，这是中国公司第一次上榜，我相信绝不是最后一次。这只是拉开了云端GPU计算强势登陆云计算市场的帷幕。

算力不仅指CPU的计算能力，也包括GPU的计算能力，特别是在公有云中的计算能力。

随着人工智能的兴起和进入大规模实用阶段，GPU的算力将成为企业竞争的基本指标。如何更好地使用云端GPU快速经济地满足业务对计算的需求，是一个值得考虑的问题。

城市大脑的关键技术能力是对高清摄像头产生的海量视频进行高速处理，能处理上千路甚至上万路视频的GPU能力会非常必要。作为现代的科技企业，特别是人工智能相关的企业，用好云端GPU，宜早不宜晚。

多家中小云厂商登录科创板，但长远发展靠技术

相信很多朋友都开通了科创板的账户，其实就是在沪市账户上开通科创板的交易权限。顾名思义，科创板是为了鼓励科技创新而设立的股票交易板块，规则和主板、中小板、科创板、新三板等有很多不同。我这里讲一下科创板的的差异化IPO条件对云厂商的影响，简单来水，从大方向的指引、财务盈利指标等方面，科创板将所有阻碍中小云厂商IPO的障碍全部移除了。

1. 2019年1月30日证监会发布的《科创板首次公开发行股票注册管理办法（试行）》指出：“科创板重点支援新一代资讯技术、高端装备、新材料、新能源、节能环保以及生物医药等高新技术产业和战略性新兴产业，推动互联网、大数据、云计算、人工智能和制造业深度融合。” 

这是直接点名鼓励云计算公司申请IPO上市。

2. 2019年3月1日上交所发布的《上海证券交易所科创板股票上市规则》指出：

   “2.1.2 发行人申请在本所科创板上市，市值及财务指标应当至少符合下列标准中的一项：

（一）预计市值不低于人民币10亿元，最近两年净利润均为正且累计净利润不低于人民币5000万元，或者预计市值不低于人民币10亿元，最近一年净利润为正且营业收入不低于人民币1亿元；

（二）预计市值不低于人民币15亿元，最近一年营业收入不低于人民币2亿元，且最近三年累计研发投入占最近三年累计营业收入的比例不低于15%；

（三）预计市值不低于人民币20亿元，最近一年营业收入不低于人民币3亿元，且最近三年经营活动产生的现金流量净额累计不低于人民币1亿元；

（四）预计市值不低于人民币30亿元，且最近一年营业收入不低于人民币3亿元；

（五）预计市值不低于人民币40亿元，主要业务或产品需经国家有关部门批准，市场空间大，目前已取得阶段性成果。医药行业企业需至少有一项核心产品获准开展二期临床试验，其他符合科创板定位的企业需具备明显的技术优势并满足相应条件。”

注意，二到五都删除了盈利要求。这是比照当年美国的纳斯达克，那里孕育了微软、英特尔等新一代IT巨头，而当时是没法要求这些公司盈利的。

可以看到第四、五条简直就是为国内中型云计算厂商度身定制的。

3.各地政府对科创板IPO企业的财务激励

为鼓励本地企业赴科创板上市，很多省市出台多项补贴政策。补贴最高的达到2000万元，补贴最低的省市也有100-200万元。上海市徐汇区可给予落地项目建设单位不超过项目总投资50%，且每年最高不超过2000万元的补贴。
真金白银的补贴会极大提升云计算公司上市的积极性。

4.2019年3月1日上交所发布的《上海证券交易所科创板股票上市规则》指出：

“2.4.5 上市公司核心技术人员减持本公司首发前股份的，应当遵守下列规定：

（一）自公司股票上市之日起12个月内和离职后6个月内不得转让本公司首发前股份；

（二）自所持首发前股份限售期满之日起4年内，每年转让的首发前股份不得超过上市时所持公司首发前股份总数的25%，减持比例可以累积使用；

（三）法律法规、本规则以及本所业务规则对核心技术人员股份转让的其他规定。”

注意：核心技术人员股份锁定期，由3年调整为1年，期满后每年可以减持25%的首发前股份。这意味着，科创板上市后云计算公司的核心人员在1年之后，就可以开始部分抛售公司股票套现退场。这也是大力鼓励云计算公司上市，毕竟1年后无论盈利与否，员工都可以卖出股票了。

我的判断是，2019年会有不止1家中小云计算厂商登录科创板，以获得继续发展的资金支持。但是这里想强调的是：云计算的竞争将会是一场持久战，是一场靠技术硬碰硬的战争，希望上市的公司们能够沉下心来，真心以客户第一的价值观，赢得市场。这既是对客户负责，对公司自己负责，也是对整个中国云计算产业的健康发展负责。

从另外一个角度来看，科创板采用的是注册制，同时前五个交易日不设涨跌幅，之后每天涨跌幅是20%。这就是意味着，在财务透明的同时，投资者会有更大的投票权，这也能极大降低“割一把韭菜就走”的冲动。

---

本文作者：阿里云头条

阅读原文

本文为云栖社区原创内容，未经允许不得转载。