为什么说产品化是私有IaaS的唯一出路？

主题简介：

大家好，今天我跟大家分享的题目是《产品化是私有IaaS的唯一出路》。在分享之前，先简单自我介绍一下。

我06年加入Intel开源技术中心，从事XEN内核开发，是世界最早一批硬件虚拟化工程师。2010年到硅谷加入CloudStack，是CloudStack早期核心开发人员，经历了CloudStack从初创到被收购的整个过程，所以从业经历可以说一直在2B这个行业。去年回国创业，创立开源IaaS项目ZStack。

刚回国创业时，跟很多投资人和2B的前辈聊，说ZStack是一家做产品的公司。得到的大部分反馈是说做产品的观点已经落伍了，现在做服务才是2B的出路。所以曾经一段时间我感到很困惑，觉得国内对2B创业的看法跟硅谷不太一样，因为在硅谷创业，绝大部分人是选择做产品公司，很少一部分才会去做服务型公司。

创业公司应该做产品还是服务，这个其实在硅谷是个热门话题。总的来说，倾向于做产品的创业公司更多。这个跟产品公司和服务公司的成长曲线有关，简单来说可以从5个方面来对比。

第一是进入市场的时间。服务型公司要远远快于产品公司。因为服务型创业公司通常是创始团队基于本身已有的经验给客户提供解决方案，这些经验在过去是验证过的，能够很快出成果。而产品公司从0开始打磨一款产品，周期非常长，通常要半年到一年才能有一些概念性的原型推向市场，并且是没有经过验证的，要找到product market fit的周期很长。

第二是商业化的风险。服务型公司的商业化风险是比较低的，首先这类公司的经验得到过验证，往往在初期就能获客，甚至获得一些大客户，产生现金流。而且在提供服务的过程中可根据客户的反馈迅速调整方向。而产品公司由于打磨产品的时间很长，在产品打造过程中更多是由创始团队的经验和眼界来决定产品的形态，产品推向市场是否被市场接受还尚未可知，有着非常大的风险。一旦产品不受市场欢迎，掉头的代价也很高。

从这两个特点来看，服务型公司相对于产品公司，起步快、风险低，初期优势比较明显。

第三是扩展性。当服务型公司发展到一定阶段，由于商业模式的限制，为客户提供解决方案（往往是定制化的），对每个客户的cost也比较高，比较难规模化复制。而产品公司一旦产品找到product market fit，规模化复制成本很低，能够快速地扩张。

第四点和第五点是复用性和控制力，就一起说。复用性方面跟第三点扩展性类似，服务型公司基于客户需求提供解决方案，复用性是比较差的，很难说一个客户的经验可以完全、直接地复制到其他客户上。在控制性方面也比较差，因为服务的边界比较模糊，服务型公司需要尽力跟客户沟通，满足客户的各种需求，控制性比较差。产品公司的边界比较清晰，因为产品本身就定义了什么事可以做，什么事做不了，控制力比较好，并且产品本身可以复用。

基于这几点的比较，服务型公司是先易后难，产品公司的曲线是先难后易。在硅谷大部分公司选择的是后者，但国内大部分公司选择的是前者。回到我们所从事的私有云行业，我坚定地认为我们应该选择产品化的道路。这有几点考虑：

首先是处于一个愿景。我们认为IaaS未来会成为企业软件分发的入口，只有产品化的IaaS才可以做到这一点。

大家经常把IaaS比喻成数据中心操作系统。一个操作系统应该是高度标准化、产品化的。很难想象一个操作系统是通过服务的方式堆叠而成。只有标准化的IaaS，才能像操作系统一样大规模广泛部署，企业软件才能围绕标准化的IaaS开发，让IaaS成为分发入口。

在云计算的三个层次里面：IaaS/PaaS/SaaS，IaaS是跟硬件打交道的，提供资源。跟硬件打交道的部分是最容易标准化、产品化的，因为我们在跟机器打交道，而不是跟发散的业务打交道。如果从IaaS层就开始大量地定制，那么整个 IT系统就很难标准化，同时很难把一个企业的经验复制到其它企业。

我们说云计算的出现是要革传统IT基础设施的命。很大一点就是要依托IaaS层面的标准化、产品化，来解决IT基础设施层面长期碎片化、孤岛化的现象，让每个企业都能按照标准的方式去构建IT基础设施。而不是接着云计算的浪潮，把传统的IT集成重新做一遍，制造大量相互孤立又不兼容的IT基础设施。

要达到这个目的，IaaS层面必须首先标准化、产品化。

从美国回来后，我深刻地感觉到在云计算领域，我们有弯道超车的机会。因为欧美的2B领域虽然非常发达，可也有有大量的传统IT的历史包袱，要实现云化的阻力还是蛮大的。但国内不一样，去IOE的浪潮已经给我们带来重构整个IT基础设施的机会，如果我们能够依托标准化的产品，快速实现云化，就能在IT基础设施领域超越欧美，实现弯道超车。

很可惜的是，目前国内大部分私有云、私有IaaS，仍然走的是系统集成的老路，云计算厂商慢慢成为了新一代的系统集成商，并没有产品化的基础设施出现。

这跟我们长期的系统集成惯性有关系。大部分客户的IT运维水平偏低，又长期依赖于集成商，在做IT设施云化时，传统系统集成的思维仍然很浓重。中国有很多优秀的服务型公司，例如神州数码，但却缺乏像微软、VMWare这样的标准化产品的公司。这是我们的缺陷，也是我们的机遇。

IaaS产品可以产品化，是我们应该抓住的机遇。但IaaS产品化也存在很多难点：

首先是IaaS产品的涵盖面太广，它覆盖计算、网络、存储、租户管理几个大部分。每个部分都是一个非常深的领域，需要IaaS提供商有非常强的整合能力。这种整合能力通过服务的方式去做是相对比较容易的，简单的说，就是技术解决不了的问题，可以通过铺人，以人工的方法去解决。

但产品化强调的是高度自动化，甚至是完全自动化，无人工干预。这就对厂商技术能力要求非常高，在这个领域没有数年甚至10年的的耕耘，很难做出标准化的IaaS产品。

产品化的第二个难点是用户教育问题。前面说了，国内的2B客户是长期被集成商服务，定制化的氛围非常浓。客户自己提出的一些需求，其实本身并不需要，或者说在云计算时代并不适合。例如云计算本身提倡一个自服务的思想，但很多客户受传统IT思维影响，要求把各种传统IT审批的功能都做到云计算产品里去，这个跟自服务本身就是冲突的。但厂商在集成的过程中，为了迎合客户，或者受自身水平限制，很难对客户做出正确引导，转而做大量集成的工作，致使产品化的IaaS很难出现。

最后在技术方面，IaaS产品本身是一个大型的分布式的集成系统，需要把用户数据中心各种异构的物理资源都管理起来，让产品化的门槛非常之高。典型的有部署难、升级难、运维难几个问题。

大家如果对IaaS产品有过接触，就会知道，往往部署一个IaaS产品需要熟练的技术团队花费数周或者上月的时间，一旦部署起来，升级几乎变成了不可完成的任务，在运维的过程中也是小毛病天天有，大毛病偶然发生。

但是否因为存在这么多难题，我们就放弃产品化的路线，转而走传统的服务型方式，以铺人的问题解决这些问题？答案是否定的。

前面讲到，我们坚信IaaS将来一定会成为企业软件的入口，未来的企业软件不再会以操作系统为中心设计，而是以IaaS为中心设计，直接在IaaS平台上分发。用户也不再需要先装操作系统，再手动安装各种软件，而是直接用预装好企业软件的镜像在IaaS 上批量创建虚机集群，实现企业软件部署的完全自动化。

所以，为了这个梦想，我们从一开始就坚定地走产品化的路线，基于过去长期在这个领域的经验，我们在技术上做出了几点努力：

首先要解决部署难的问题。一个产品化的软件，一定是用户可直接从官网下载，并根据官方的手册，直接部署试用的，这个过程应该是半个小时甚至更短的时间就能完成。

为此，我们采用了“进程内微服务架构”、“Anisble无缝集成”等多种技术，让用户可以通过API或者UI，在5分钟内能自己构建部署一套私有云环境。并且能够根据手册完成一些典型云场景的搭建。通过产品化，我们赋予了用户自己构架IaaS环境的能力。

其次是解决升级的问题。ZStack是唯一提供一键、5分钟在线升级的产品。我们每一个半月就会迭代一个新的版本，用户可直接下载新版本一键升级，升级过程不影响业务系统。升级功能是产品化的一个标志，不能升级的产品一定是项目制的。大家用的国外很多成熟的2B产品，都是提供升级能力的。只有这样，用户才能在第一时间获取bug修复，以及新功能的迭代。

最后就是运维难的问题。以服务提供的项目型IaaS中，运维是最大的问题。因为大量的工作，在部署阶段需要通过厂商的人员手工完成。当项目一旦交付给用户后，出现的任何问题用户都无法解决，需要厂商协助。归根到底，是因为没有实现产品化，没有实现完全的自动化。

我们提倡完全自动化，所有的操作、配置完全由API交付，不存在手工环节。用户可以完全通过界面和API就能实现IaaS的自动化运维。例如添加新的计算节点、存储节点，用户只需要在UI上操作，或者调用API，就能全自动地完成，无需厂商协助。

这所有的努力，最终目的是提供一个产品化的IaaS，能够被成千上万家客户所使用，而不是通过服务的方式，只能让一小部分客户使用。当产品化的IaaS被部署到成千上万的用户的机房，就形成了入口能力，就可以基于这样的IaaS提供企业软件分发的渠道，让用户的业务软件能够全自动化地分发和升级，这样用户就获得了从基础设置到上层业务系统的全自动化的一个闭环，从而避免构建碎片化的IT基础设施。

中国的2B市场才起步，跟欧美相比，仍有着巨大的发展潜力。只有走上了标准化、产品化的道路，我们才能超车，并在未来将我们的技术输出到欧美。产品是没有国界的，标准化的产品可以输出到世界任何地方，但服务很难跨国界，要跨国定制服务就更难了。这也是为什么我说产品化才是私有IaaS的唯一出路。

Q1：ZStack如何去响应客户定制化问题？

A1：这是个好问题，也是国内产品化的过程中无法回避的问题。我们的观点是跟集成商、服务商合作。国内其实是存在有大量有经验的服务商的，他们也希望进入私有云这个行业，但缺乏标准的产品为他们降低提供服务的门槛。

ZStack提供的标准IaaS产品就可以为集成商解决这个问题。通过跟集成商合作，解决客户在现阶段要求的定制化需求。

Q2：ZStack如何提升自身产品的厚度，如何规划后续的产品线？

A2：我们还是会专注在IaaS这个领域。前面说了，IaaS相当于数据中心操作系统，要把它做到高度产品化，其实还有非常多的问题要解决，也需要很多时间。对于IaaS之上的一些产品部分，我们选择跟这些领域的厂商一起合作，推出解决方案，更多的是把ZStack打包到这些厂商中的产品中去，形成完整解决方案。

Q3：一键升级只适用部分场景，如OS版本升级恐怕避免不了数据迁移？

A3：这要分为两个层面。第一是管控面的升级，第二是数据面的升级。管控面的升级就是IaaS本身的升级，这个ZStack通过一键升级已经解决了，不论是管理一台物理机，还是一万台物理机，管控面都是一键升级的。数据面的升级就是你提到的操作系统升级。相对于管控面，数据面的升级不频繁，通常的安全升级都可以通过包升级的方式解决。

当涉及到重大问题，需要对操作系统内核升级的时候也有两个方法可以解决。一是通过将物理机设置到维护模式，虚机迁移走，然后对操作系统进行冷升级。二是通过内核热补丁的方式，对操作系统进不停机升级。因为最早就是在Intel OTC从事虚拟机内核开发，我们团队里面也有不少10年前就在这个领域工作的牛人，所以这个问题我们也是可以解决的。明年ZStack会发布自己的发行版，里面就会支持这些技术。

Q4：现在SDN比较火，ZStack有无集成SDN计划？

A4：对于SDN方面，如果是比较简单的用户场景，我们有自己的软件解决方案。2010年，我在CloudStack做的第一件事就是跟Nicira的工程师基于Openvswitch为godaddy提供SDN方案，那个时候它都还没被VMware收购。

对于需求复杂的SDN场景，特别是要接入硬件SDN方案的，我们有完整的网络插件体系，从2层到7层都是插件式的，可以通过插件的方式在不修改已有代码的基础上实现无缝集成。

Q5：ZStack大规模部署方案思路是怎样的？是否存在管理数据库、消息队列等瓶颈？比如千台宿主机规模。

A5：不存在。我们单管理节点的核定规模是 10万台物理主机、百万级虚拟机、同时响应数万并发API。具体实现的技术细节可参考我们官网blog里的技术文章，这里我可以跟大家share一个客户测试的ZStack并发能力的数据，750个并发没有测试ZStack，因为只给了我们4个计算节点，而计算节点资源不足。

Q6：针对某些行业对资源强管控需求，有无对应资源审批开通机制？

A6：这个我们没有，这方面的定制需求我们有合作伙伴做，合作伙伴提供的BOSS系统，整个解决方案是有的。

Q7：ZStack着重解决IaaS层问题，您对PaaS层服务怎么看？比如DB、Big Data、Container等。

A7：这些我们都跟合作伙伴一起做的，正好你提的这三个方面我们都有完整的解决方案。这个也是因为ZStack的轻量级的特性，合作伙伴集成起来非常容易而且可控。

原文发布时间为：2016-12-26

本文来自云栖社区合作伙伴DBAplus