码迷,mamicode.com
首页 > 其他好文 > 详细

聊聊PAAS

时间:2018-09-27 01:36:41      阅读:148      评论:0      收藏:0      [点我收藏+]

标签:资源隔离   证明   项目   强一致   大量   不可   中国公司   直接   管人   

在2016年,SaaS公司走大客户方向,已成为行业的基本共识。大客户方向就难免会遇到不断变化的定制需求,是否一定需要PaaS?在过去很长一段时间里,国内关于PaaS的讨论,都主要集中在商业圈和投资圈,相信大家仍觉得谈的不透彻。

 

技术分享图片

 

在本文中,我们将结合企业级市场现状和PaaS的技术挑战,深度解析到底何谓“PaaS”

 

本文内容来源于,崔牛会创始人崔强与PaaS实际操盘手——美洽总裁兼CTO李令辉的访谈。

 

崔强:我一直想找人从技术角度给大家讲PaaS, 能不能跟大家先讲讲你的背景?

 

李令辉:我自己亲身参与过三次PaaS的构建,第一次是在豆瓣,我在platform team做架构师,当时豆瓣内部就打造了国内互联网比较早投入生产环境的App Engine基础设施DAE。

 

第二次是在滴滴,我作为首席架构师和技术委员会主席,带领滴滴基础架构团队打造PaaS的通用中间件,来应对业务的高速发展,提高业务研发的效率,统一解决复杂、艰难的业务技术问题。

 

第三次是一年多以前在美洽,带领团队从零开始做了一个比前两次都更复杂和强大的PaaS, 现在已经上线了。所以讲这个话题,我还是有一定实操经验的。

 

崔强:不同PaaS之间的能力确实差异性很大,令辉想从哪里开始谈这个话题?

 

李令辉:在从技术角度讲PaaS之前,我想先讲讲对企业级市场的宏观理解。

 

前不久iPhoneX发布之后,苹果首席设计师Jony Ive接受《纽约客》主编采访时,说了一段话,我很认同。里面谈到了iPhone为什么会诞生这个重要的问题。Ive说是因为苹果受不了当时使用的那些手机,认为它们都枯燥无味并且粗制滥造。

 

想想在诺基亚,摩托罗拉,阿尔卡特,西门子等等繁盛一时的功能机时代,相当长的一段时间内,诺基亚每年的研发费用都数倍于苹果。

 

为什么苹果这个毫无手机行业经验的外来人,把手机行业带入了一个新的篇章?因为只有苹果看到了未来,没有被现有成果所限制,直接去追求代表未来的更先进产品。

 

今天大家看到Salesforce市值700亿美金,SAP1400亿,Oracle2000亿,数字之下,不明觉厉,也带动了中国SaaS的创业热潮。

 

这里隐藏着一个巨大而又被忽略的风险是,这些公司会不会是上一个时代的诺基亚?这个行业里会不会诞生苹果一样的公司?

 

有些国内公司对SOS(Salesforce、Oracle、SAP)是在复制追赶;而事实上,类似Ive描述的,这个市场需要的是“受不了它们的枯燥无味并且粗制滥造”的公司。

 

当然,在产品技术上要做出比SOS强一个时代的PaaS及SaaS体验,成本上达到一个数量级的降低,在中国乃至全球市场取代SOS,这很难。

 

但事实上,之前大家觉得去IOE(IBM、Oracle、EMC)也很难,阿里还是做到了,之前大家觉得去思科、爱立信很难,华为还是做到了。我们相信在这个新时代,在应用软件领域,也一定会有中国公司脱颖而出,引领世界。

 

崔强:你的这个目标很大胆,能不能具体讲讲SOS有哪些让你觉得“无法忍受”,或者说不够先进的地方?

 

李令辉:SAP的生产型ERP和Oracle的数据库不在我说的范围内,我指的是SaaS及应用软件部分。

 

你能看到Oracle的SaaS大部分是收购而来的,产品的迭代速度极慢,另外各收购产品之间不是原生就打通的,要分别集成,数据整合,产品一致性和灵活性都有一定问题,云产品的服务器不在国内,访问速度比较慢。

 

SAP的云化刚开始,但SAP的思路并不是很现代,东西越做越贵,HANA是一个完全基于强大硬件的内存解决方案。在大流量下,单位成本的高昂几乎是不可接受的,中国互联网企业都在去IOE,SAP比IOE合起来还贵,效率明显低下。

 

互联网的技术方向是用廉价的硬件+全新的分布式技术来解决这类问题,数据量越大,技术成本就摊得越薄,效率就越高。

 

其实这三家里面,产品体验最好的当属Salesforce,但是由于所处时代的限制,在今天看来,它有很多地方也无法忍受。

 

比如依赖于昂贵的Oracle数据库,因为数据库底层的限制,OLAP方面的能力不是很强,因为使用的技术都不是互联网时代出现的针对大流量大数据的技术,所以遇到ToC的使用场景,单位成本非常高昂。

 

因为限制只能使用Apex语言做二次开发,导致对开发者限制很多,无论是学习还是开发门槛都相对较高,并且Salesforce坚持不提供私有化服务,导致在一些领域无法推广。Salesforce的服务器也不在中国,访问速度也较慢。

 

另外,中国市场有自己的特殊性。

 

例如世界领先的电商渗透率,移动设备渗透率,未来的物联网渗透率,4G/5G,移动支付的普及率,小程序等连接线上线下的平台强大性,企业对人工智能的开放程度,互联网转型的急切心态,等等。

 

SOS等国外大厂调整产品,满足国内客户需求的速度也是难以忍受的,这方面我们会做的更好。

 

微软现任CEO萨提亚·纳德拉(Satya Nadella) 上任时就对全体员工说“我们这个行业不尊重传统,只尊重创新。”

 

21世纪的科技巨头和繁荣的开源社区创造了很多先进优雅的技术,我们的起点在2016年,世界已经和20世纪大不同,社会的每一个环节都被改变,这么多年里,快速发展的互联网行业从根本上改变了IT行业的基础和格局,我们依托于这些伟大的创新,站在巨人的肩膀上,当然有机会做出一个新的PaaS平台,比SOS更先进,成本更低。

 

崔强:接下来咱们谈谈技术干货,这也是崔牛会的读者们最期望的部分。能不能聚焦于PaaS的技术部分,给大家展开讲讲。

 

李令辉:好,在10月18号 Qcon 2017 全球软件开发大会上,面对CTO, 架构师,工程师,我做了一次关于美洽PaaS平台的演讲。崔牛会的读者不都是技术人员,所以接下来我会尽量用通俗易懂的方式,讲讲这件事。

 

PaaS是Platform as a service,通俗的说是Platform的云化。所以我想先谈谈Platform,再来谈谈PaaS,这是一脉相承,但并不相同的两个概念。

 

可以看到,很多大名鼎鼎的软件都支持充分的自定义,微软Office系列支持VBA,PeopleSoft支持PeopleCode,Unix上每个著名软件的配置文件语法都可以写本书来讲。

 

你可以把它们的这个能力抽象成code execution platform/computing platform。来到了云计算时代,计算能力在云端而不是本地,就有了PaaS,将Platform的能力,以Service的形式提供在云端。

 

其实从工业化时代开始,各行业都开始通过做一个靠谱的Platform来降低创新和迭代的成本,将不变的东西自动化,将不断变化的东西抽象成编程语言来提供灵活性,以此降低创新的成本和风险,这就是规模生产的工业化Platform的概念。

 

上世纪90年代,国外企业级软件里就能看到强大的API和可编程性,每个强大的软件都带着一个强大的Platform,例如当时的PeopleSoft、 Siebel CRM都发明了自己的编程语言,在二三十年前就很强大了。Salesforce 和Workday的PaaS不是凭空而生的,是一路沿袭过来的。

 

而中国直到现在,并没有足够好的PaaS供应方出现。为什么呢?因为做Platform难度很大,PaaS就更难了。

 

再说说as a service, 它就相当于从买车到租车或者滴滴打车的变化。

 

如果自己买车,首先要付一大笔钱,还要自己负责年检,保养,保险,考票,交罚单,加油,洗车等等事情,但as a service,租车或滴滴打车,就不用那么复杂,并同样能达到从A点到B点的目的。

 

当然作为服务提供方,租车公司或者滴滴打车做了很多工作把业务复杂度给消化了,直接呈现给客户一个简单易用的服务。

 

所以不管IaaS, PaaS, SaaS 相比传统的基础设施,platform, 软件,都是消化了特别多的复杂工作,提供一个简单易用的服务给客户。这种商业模式,无疑是正确的方向。

 

具体到PaaS,这件事对企业信息化至关重要。

 

它能从根本上降低试错成本,任何行业创新都源自大量的试错,如果成本很高,就会减少可能成功的机会,而PaaS是提高试错效率的有效手段。如果没有PaaS,企业信息化这个行业的井喷发展期就很难到来。

 

用个通俗的比喻来说,在没有PaaS的世界里,客户想吃个西红柿炒蛋,就要自己去造燃气灶和油烟机。

 

大部分企业客户需要的仅仅是实现业务需求(就像想吃西红柿炒蛋),而不是如何管理资源,如何处理身份认证,如何管理倒排索引等等(就像造燃气灶和油烟机)。

 

由于通用编程语言过于基础,程序员需要把大量的精力花在对计算机资源的控制,去解决大量重复出现的问题,把至少80%的精力花在了原本要解决的核心问题之外,而一个合适PaaS的价值就在于,将解决方案提供者的视野限定在了业务需求范围内,把此领域中反复出现的问题事先解决好,不去浪费当事人的精力。

 

崔强:SaaS公司想做大客户,PaaS是必须要有的吗?

 

李令辉:你去看SAP、Oracle、Microsoft Dynamic 365、Salesforce、 Workday、ServiceNow都具有PaaS能力。

 

中国市场里,满足大客户高度复杂定制化需求的最常见方法是外包,这种商业模式价高、质低且不可持续,其次是找标准软件商提供定制服务。

 

因为这种服务是非标准的,所以无法保证质量,成本也极高。而第三条路,就是提供PaaS,依靠后续的实施和开发来满足需求和应对变化。

 

这里可以谈一下ToC和ToB的本质差别。

 

ToC产品解决的是一个确定的问题域,是一个比较具象、比较聚焦的需求场景。

 

但是这一套逻辑在ToB领域里完全不适用,在企业信息化中,最终使用者由企业中各层级的不同角色、职能,在不同的业务场景下管理需求,即使是一个行业,也分为大中小型规模,即使是同一个公司,也分为早中晚不同时期的管理模式。

 

可以说,永远不可能凭借想象来穷举所有遇到的需求,需求是无穷无尽的。

 

一套好的系统,必须能够跟随企业的发展和变化,充分灵活和可塑,所以才有了PaaS的概念,我们需要把提供的服务拆解到更底层的维度,才能经得住时间的考验。

 

大家都知道IaaS, PaaS, SaaS这三层的关系,理论上一个强大的PaaS层,是能支撑各种SaaS需求的。在我看来,一个强大通用的PaaS,从技术上可以拆分成三个维度:高性能PaaS, 度PaaS, 开发者PaaS。

 

论技术难度,做好一个高性能PaaS,相当于一个大型互联网公司的基础架构部或中间件团队的工作内容,需要丰富的经验和大量的研发投入。

 

做好一个复杂度PaaS, 相当于创造一套数据库+一套编程语言+若干个强大好用的中间件。上一个时代里,IBM、Microsoft、Oracle三家公司都做过类似的,艰难繁复的工作。

 

而一个开发者PaaS, 要解决的是开发者工具支持的完整度,开发、调试、部署、安全、文档、数据隔离的问题。这需要提供一个基于云的开发、调试、部署工具,大致相当于一套App Engine的工作,可以类比GAE、Heroku,或者BAE。

 

我们做PaaS的公司,要同时去挑战这三件事的难度,更可怕的是还要同时挑战这三件事的完整度,这意味着巨大的工作量。要知道Salesforce做PaaS平台的有近4000位工程师,每年的人力成本就接近10亿美金。

 

崔强:能不能给我们具体讲讲这三种PaaS的技术挑战?

 

李令辉:我们内部评判PaaS总共有50多条标准,按照高性能,复杂度,开发者三个维度来拆开分析下吧。

 

先说高性能PaaS,这块的难度相当于:百亿美金互联网公司的基础架构部。

 

这是互联网ToC公司的强项,FLAG,BAT都是其中的佼佼者。

 

主要挑战在于如何最大程度的发掘机器的潜能,如何利用分布式集群的能力,如何保证系统的SLA承诺,如何水平扩展,如何控制单位成本,如何实现集群的自愈和监控,如何有效的控制平摊下来的人力维护成本,又如何不断优化架构,提升检索,读写IO的能力。

 

以美洽的做法举例:我们通过分布式系统和集群管理工具来管理容量,并至少保障99.95%的SLA可用性,运维和部署一并解决。

 

通过分布式系统,我们规避了昂贵的硬件,我们甚至也不使用的单机数据库,而是使用分布式数据库TiDB,具有在不牺牲业务特性和强一致性的事务保障的前提下的水平的扩展能力。

 

并且,我们整个架构还尽量使用多租户设计,更进一步的节省计算资源和存储成本。

 

这里要明确一点,大部分互联网公司的水平扩展技术是以牺牲某些技术特性或需要使用者做很多「work around」的工作来解决水平扩展性问题,而美洽的PaaS是提供不打折扣的类似于单机基础设施能力的。

 

我们使用的所有基础设施都是分布式的,比如分布式关系型数据库TiDB,比如分布式的缓存系统Memcached,比如分布式队列系统Kafka,分布式配置管理系统etcd,再通过将微服务化的无状态微服务容器化,通过Kubernetes和istio的能力,将所有的服务能力分布式化。

 

美洽提供了结合了传统单机系统一样的灵活性以及互联网公司常见的分布式高可用的基础技术平台。

 

我们的多租户技术依赖于集群和数据库的能力。通过集群编排系统,智能的做容量管理,自动升级,部署管理,部署隔离。

 

我认为高性能PaaS是一个基本能力,无论做哪个领域的SaaS,大的,小的,垂直的,客户对你的要求,在这方面都是一样的,系统稳定性,数据安全性,数据量的水平扩展能力,处理较大流量的并发能力等,这件事情是避免不了的,一个收入天花板太低的SaaS公司,根本无力覆盖这块技术投入的成本。

 

这一点被很多创业者和投资人忽视或者低估了。就好像银行再有资源也无法做一个像iPhone一样出色的硬件设备,一个再大的企业也无法为内部开发一个强大的操作系统一样。这是个成本问题,一定要覆盖更多的人和领域,高昂的成本才能平摊到可以接受的程度。

 

再说说复杂度PaaS,其难度相当于设计一套数据抽象系统,以及领域专用编程语言。这块是企业软件公司的强项,之前世界上最强的是Salesforce和SAP。

 

主要挑战是如何最大程度地提高解决复杂问题的能力,如何高效的应对业务变化,而且必须是不能阉割的解决方案,要能解决所有问题。一般业务人员讲给不懂技术的客户,总说类似乐高积木的系统,任意需求都可以拼搭出来,说的其实就是复杂度部分。

 

我讲讲复杂度PaaS这块我们是怎么做的。

 

首先,美洽PaaS中一切都是以服务形式提供的,这样的好处是将某件事情的复杂度控制在服务内部,服务之间隔离数据和逻辑,只以API形式协作,这样的好处是把问题域限制在一个较小的范围内,对人类脆弱的大脑比较友好,可以更好的完成每一个具体的服务。

 

并且大部分服务本身都是元数据驱动的多租户服务,它们都可以通过定义元数据的方式改变行为,特别是PaaS的核心,也就是存储服务,可以通过元数据定义出数据和数据之间的关系,数据以及数据间的映射还有级联关系。

 

企业级服务的核心就是数据的增删改查,以及级联操作。通过一个高度定制,可以元数据定义的分布式数据服务,来满足复杂的数据业务场景。我们把OLTP,OLAP,搜索引擎合三为一,用户可以一键式开启这些能力,无需开发。

 

企业级开发的权限需求也非常复杂,像我们的权限系统兼容RBAC和ABAC,权限控制可以精确到数据库的表级,列级,行级,甚至字段级。

 

对于复杂的业务场景,直接封装成可高度定制化的服务来单独提供,比如审批,工作流,报表等服务,全部可以通过元信息定义出期望的行为。

 

为了提高交付速度,连Web,iOS,Android三端也可以通过元信息生成界面,而无需开发。

 

为了满足个性化展示需求,三端也可以全部抛弃,客户完全可以基于API或者基础UI组件,来独立开发。

 

对于一些特别的需求,客户可以基于PaaS提供的API,基于自己擅长的编程语言,开发适合于自己需要的程序,以Plugin的方式部署,这样既提供了足够的灵活性(任意语言,任意行为),又保证了数据安全和资源隔离。

 

从本质上来说,Salesforce的force.com和Heroku,它们分别代表了不同的思路和世界观,虽然后续Salesforce收购了Heroku,将其变成了给自己扩展功能的底层设施,但毕竟是两个独立的平台。我们的思路是一开始就将这两者合二为一,更加一致和强大。

 

最后说说开发者PaaS,难度相当于开发App Engine的大致难度(比如GAE),这是技术型平台公司的强项,最强的是微软,谷歌。

 

这部分的挑战是:要建立清晰明确的世界观,要服务好里面的所有玩家,要有完整的工具链条和文档建设,要从架构上支持开发者,要做好社区建设。

 

要保证对开发者友好,易用,强大,而且不断进步,尽量降低门槛,让大家容易上手,还可以不断精进,快速解决问题,提高收入。

 

以美洽PaaS为例,我们会推出完整的编程工具,辅助完成元数据的编写和查看,提供调试工具、部署工具,以及沙盒环境,帮助开发者快速开发,提高效率,并且提供在线监控平台协助开发者了解自己程序的运行状况,把整个系统状态尽量和客户保持透明。

 

我们会提供一个让开发者更高效的在线开发环境,也会尽量保持和普通虚拟机类似的开发体验来让开发者低成本的迁移自己的经验和知识。

 

高性能PaaS, 复杂度PaaS和开发者PaaS,这三个PaaS不能割裂来看,用小米雷总的话说,铁人三项,少一项都会有问题。

 

目前看要同时做好这三方面事情的难度和挑战还是很大的,需要很强的想象力和架构能力。

 

其中很多地方是反互联网技术常识的,互联网ToC公司,因为业务发展和变化太快,大部分时候不会也无法做特别长久的设计,而ToB业务,因为别人要依赖于这个PaaS而存在,所以一开始就要是个至少完整正确的设计。

 

架构也好,设计也好不是为了解决计算机的问题,而是为了解决使用者的问题,人类的脑容量不适合处理特别复杂,变量特别多的东西。所以,一个事先考虑的很清楚,强大优雅,简单清晰的世界观就非常重要。

 

崔强:高性能PaaS, 复杂度PaaS和开发者PaaS,这三方面按照难度,如何排序呢?

 

李令辉:这三方面,第一难的是高性能PaaS,第二是开发者PaaS,第三是复杂度PaaS。但其实最难的,是如何将三者整合,同时呈现。

 

为什么这么说呢?说到复杂度,过去几十年的企业级玩家,用小型机,或者单机实现的功能都是非常复杂的。

 

仅限于单机的技术,就不是特别有挑战的事情。将这些复杂度用某种易于理解和使用的方式呈现给开发者,就需要掌舵人很好的建立世界观,维护好这个思想世界里的一致和协调。

 

到了互联网时代的数据爆发期,单机解决不了问题了,就要考虑如何在分布式环境下同时解决存储和逻辑的问题,这也是过去二十年里,互联网巨头们一直在努力的领域。

 

这里面用到的技术和理论还是很新很难的,互联网公司往往为了使用这些能力,放弃了很多业务上的便捷,但在企业级这些又无法放弃,所以三者结合的难度又大大高于其中任何一种。

 

以美洽的做法举例:我们通过分布式系统和集群管理工具来管理容量,并至少保障99.95%的SLA可用性,运维和部署一并解决。

 

通过分布式系统,我们规避了昂贵的硬件,我们甚至也不使用的单机数据库,而是使用分布式数据库TiDB,具有在不牺牲业务特性和强一致性的事务保障的前提下的水平的扩展能力。

 

这里要明确一点,大部分互联网公司的水平扩展技术是以牺牲某些技术特性或需要使用者做很多「work around」的工作来解决水平扩展性问题,而美洽的PaaS是提供不打折扣的类似于单机基础设施能力的。

 

美洽利用最新的技术手段提供了结合了传统单机系统一样的灵活性以及互联网公司常见的分布式高可用的基础技术平台。

 

崔强:要做出比SOS更先进的PaaS产品,你觉得应该要有什么样的用人策略?

 

李令辉:就像攀登珠峰有南坡、北坡两条路,国内PaaS公司也有不同的路径。

 

有的技术带头人软件行业背景强擅长复杂度PaaS, 有的技术带头人互联网行业背景强擅长高性能PaaS,这就看哪个打入到对方领域,更容易了。

 

我认为应该选择的是全互联网背景的人才,我们认为从高性能PaaS打到复杂度PaaS更容易。

 

软件行业和互联网行业两种人才的能力特点和认知都相差甚远,做产品、架构、写代码的方式也差异极大。

 

大部分软件行业的人才,虽然应对复杂需求的能力ok,但这只是必要能力,不足以破局,如何应用最新的互联网技术和思想,去突破性的解决问题才是关键。

 

互联网技术在过去二十年里获得了突飞猛进的发展,诞生了很多革命性的技术手段,这些技术合理地应用到ToB领域,是可以带来突破性的功能/成本/体验优势的,这也是我们看到的巨大机会。

 

其实从这个角度来看,SOS的团队也是相对陈旧落后的,他们也在革新和换血。

 

崔强:你认为,对于做PaaS的厂商来说,应该有什么样的商业化策略?

 

李令辉:从商业策略上来说,我认为最重要的是发展生态伙伴。

 

你去看SOS这种体量的公司,它们没有一家是单纯靠直销做大的。Salesforce负责中国业务的员工应该不超过十个,每年就能做到两个亿的收入,销售效率极高。

 

而国内厂商,现状都是靠大量的直销团队,来拉动销售收入,不管人均单产高低,毕竟短期可以让投资人看到增长的可能性。

 

现在国内厂商在生态伙伴这方面,基本没有真正开始,有也只是一些帮着走货的小批发商,很少有类似埃森哲,汉得信息这种体量的,能帮助客户做定制化解决方案的合作伙伴。

 

事实上,如果你去搜索2016中国方案商500强,会发现,中国最多的企业IT预算是在方案商这里的。

 

那为什么国内现在的云厂商都没打入这些方案商市场?就是因为没有强大的PaaS及公司品牌,方案商的实施人员根本无法施展。

 

做PaaS, 做生态,作为一个范式转换的新兴事物,被市场全面接受并普及是需要一个过程的,我们应该要有充分的耐心。

 

AWS是2006年推向市场的,Netflix是2008年才开始和AWS合作,7年后的2015年才全部迁移到AWS上面。iPhone诞生于2007年,但到了2013年,智能手机的出货量才超过功能机的出货量。

 

很多合作伙伴觉得不能依赖其他第三方平台,这种想法是可以理解的,其实这是一个行业成熟度的问题,想象一下全世界范围内为汽车生产变速箱,发动机的厂商寥寥无几,生产CPU的厂商也一只手就数的过来,大家选择公有云,其实也就那么几个大厂出品。

 

因为不同事情需要不同的人,不同的经营策略,不同的管理方式,一个企业什么都做的方式在现代工业文明里越来越少见。任何一个事情要做好都需要巨大的投入,如果没有一个足够大的规模去平摊掉成本,这个巨大投入就没有人负担的起。

 

崔强:好,接下来进入崔牛会的读者提问时间,关于PaaS, 我们收集到很多周边问题。

 

比如有人认为PaaS是需求累积到一定程度倒逼出来的,不可能凭空做出来一个PaaS。

 

还有人认为PaaS投入巨大,只有Salesforce , Oracle, SAP 这种巨头才能玩得起,市场上又有很多小公司声称自己开发出来了PaaS。

 

这些到底如何鉴别,是真是假,是否强大?

 

李令辉:这些问题确实很高频,我也经常被问到。

 

“PaaS是需求累积到一定程度倒逼出来的”这个说法是相当经不起推敲的,需求是无限的,而人的生命是有限的,以有限追无限,是不可能成功的。

 

PaaS的设计是来自于对某一领域可能有的需求的总结和抽象,不需要穷举。

 

在我看来,PaaS更类似于编程语言和操作系统,在发明编程语言的时候,计算机科学家根本无法想象出今天的无数种应用场景。

 

如何判断一个编程语言的强大性?科学的方法是判断它是否图灵完备,这更像是一种数学证明方法,而不是穷举所有的编程需求。

 

至于说“PaaS只是巨头的游戏,小公司没法参与”,这个观点也站不住脚。

 

在我看来这是典型的因果倒置,是做了PaaS的公司,才成了大公司。Salesforce从创业开始就在做PaaS, 用他们的话说是要做商业的操作系统,那时候的Salesforce可是完完全全的小公司。

 

崔强:有一种说法是“PaaS会有一个侧重,比如侧重CRM的,侧重HR的,很难有一个PaaS能各方面都很强大。”造成这种区别的内在原因是什么呢?

 

李令辉:在我看来这种说法有一定道理但是又有点似是而非,这里说的是复杂度PaaS的那一部分。

 

我之前做了一个类比,这个领域类似于数据抽象系统+一门编程语言,数据库会对哪方面的业务有所侧重么?编程语言会明显倾向于解决某种业务么?

 

要知道从数据库的角度来看,都是CRUD,编程语言的角度来看,都是读写IO,参数处理,一点点计算而已。从这个角度来看,什么业务并没有太大差别。

 

但是这种提法并不是一点道理也没有,因为PaaS都是在易用性和强大性之间做权衡,为了更快的交付,PaaS一定会对具体要做的业务做很多接近的功能支撑,如果一个公司的在商业策略上倾斜于一个领域,当然在这个领域的功能支持上会增大投入,所以肯定会在交付上能力上有所区别。

 

但是这件事并不是必然的,而是和投入水平相关。通用的编程平台很多,根本不会有人质疑它们的通用性。

 

崔强:有人问PaaS那么重要,为什么Salesforce的PaaS收入还不到总收入的10%?

 

李令辉:PaaS直接售卖的不多,更多是打包成SaaS后去售卖的,但是透过现象看本质,你会发现,如果没有PaaS来平摊成本,效率是很低的。

 

另外,对Salesforce而言,最重要的护城河是它的生态,单靠Salesforce一家公司直营,是不可能满足如此数量众多的客户需求的。而吸引如此众多的合作伙伴的前提,无疑是PaaS。

 

就好像QQ其实长期都不是腾讯的盈利主力,网游才是,但是QQ的存在,现在是微信,是保证腾讯能够源源不断的获得网游用户的竞争力所在。你不能说这个不直接赚大钱,就不是公司的核心。

 

崔强:有一种观点说,凡是到一定规模的客户,难免会自己开发CRM。你们怎么解决客户的这个问题?

 

李令辉:过去确实有不少中国企业倾向于什么事都自己干,这在以前技术人力成本较低的情况下还好。

 

企业客户第一次做CRM开发时大多会低估难度,找个外包团队或在自己技术团队里找几个人就开始干了,做出一个能用的,就先凑合着用。

 

在今天还带着这个惯性来做的,肯定得不偿失。专业的人做专业的事情,一个公司不可能有精力把内部系统做的和外部系统一样好,现代社会肯定是用分工去提高效率的。

 

刚才提到的例子,过去大多数公司都自己买车,但是现在大家都改成租车了,因为自己养车成本高,效率低,就算每个公司都有车的时代,也没有哪个公司非要自己造车造发动机吧,你可以理解中国企业非要自己干内部信息系统的行为基本就等同于为了用车,非要自己造车。

 

随着时代发展,大家越来越在乎成本和效率,没有人会自己养车了,都会选择租车,在企业服务市场,大家都会选择租用SaaS,而不是现在自己买机器,自己雇程序员,项目经理,产品经理,开发一个“用的人比做的人多不了多少”的系统。

 

算笔简单的帐,一个相对来说比较复杂的CRM系统20个人来做一点也不多,大约4-6个移动端,2-3个前端,6-10个后端,1个项目经理,2-3个测试,1-2个产品经理,1-2个UE,这些人一年的所有成本大约500-1000万,如果一个团队经过多次迭代,三年才把CRM做到及格,就需要1500-3000万。

 

每家公司在自己的领域都要征服星辰大海,但肯定不是每家公司都征服同一片海嘛。

 

任何行业的发展都会逐步走向更精密的分工及合作,企业信息化领域也不例外。

 

美国的亚马逊,苹果,特斯拉,思科采购了Salesforce, 国内的金山软件,TalkingData, 神策采购了Salesforce。这些公司都有很强的软件研发能力,但在非核心的业务系统上,还是会采购专业的第三方服务。

 

国内现在是供应方产品技术能力比较弱,假以时日,这种现状肯定会改变的。

 

聊聊PAAS

标签:资源隔离   证明   项目   强一致   大量   不可   中国公司   直接   管人   

原文地址:https://www.cnblogs.com/tqyysm/p/9710879.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!