云计算十年,下一站是API SaaS吗?

简介:

2015年是SaaS和PaaS都非常火爆的企业服务元年。2015年后,对于云服务而言,面对客户,将何去何从?带着客户的疑问和身为行业从业者的一些经验,我试图给出一点自己的想法。

观点的碰撞和对未来趋势的判断,从来不乏对错之争。我无意介入这份纷纷扰扰,无意争论对错,仅是表达自己所看到的。

以下故事不针对某个具体的企业,这是我们要一起背负的命题。

我所经历的企业服务

2000年,开启了我企业服务的职业生涯。

站在2016年,SaaS元年后,软件行业在天翻地覆地变化着,我接收到的客户信息依然如十年前:你们的软件服务交付了会减少成本和人力吗?

SaaS交付方式的朋友很理直气壮的说:一定会。因为,SaaS便宜;因为,SaaS按用户实际使用情况收费;因为,……

PaaS交付方式的朋友也会挺直腰杆说:会。PaaS更灵活,支撑基于业务定制还能节约成本。

自2011年9月再次以创业者的身份踏入企业服务领域,就开启了“满足客户需求”的旅程,辛苦、委屈和无奈。曾经部署过独立业务的SaaS,撤掉了;原因没钱烧。有朋友说SaaS服务很简单,开账号买账号就好了;我感受到的是听来的故事,没有亲自躬身干过就别妄言了。苦过,方知甜的滋味。

如果仅仅是没钱烧,我们会启动融资,会找朋友借钱或者其它的方式度过难关。相对于没钱烧,更深刻的问题是客户的反馈:你们的SaaS传递了什么价值?把曾经给他们定制开发的软件服务,以十分之一的价格出售,他们竟然被问及了传递了什么价值。这句话引发了我深深地思考。

问题一个个浮现出来:定制的结合了网站的引流,销售SaaS没有提供;定制的整合了OA的API接口,销售的请假、报销和业绩能够在同一个报表中,销售SaaS没有提供;……。这些没有提供的问题解决了,销售的SaaS就能贴合需求,好卖吗?显然不是。就连Salesforce也不是因为提供了各种整合才好卖的。

读《云攻略》后的思考与实践

读了Salesforce的创始人撰写的《云攻略》。

细读下去,发现的第一个问题:SaaS标准化就是一个误区,Salesforce从创建的第一天就开始追求不同行业客户的不同需求满足,根本没有赖在标准化的“被窝里”意淫;

第二个问题:SaaS业务是交付模式的变化,不是业务结构的变化,Salesforce是通过不断丰富自己的业务结构让一个襁褓里的婴儿长大的,他们的交付方式节约了客户的使用成本;

第三个问题:和第三方系统的对接,Salesforce是非常主张企业内部数据似水般流动的,在PaaS系统上市之前先完成了SF的API化保证了系统对接的友好。

思考的过程我们并没有停止对SaaS或PaaS业务的探索。2014年开始,逐渐通过API嵌入的方式提供了几个大型企业客户很好的体验。

如:SAP的考勤系统在满足“计件工时”的服务上是不友好的,一个35万人的机械加工类企业找到我们定制了计件工时的系统,我们并没有提供自己系统的独立管理入口等,而是结成到了SAP的软件中;

又如:对于一个教育培训连锁机构,他们的教师上课“考勤”通过很多方案没有解决,我们通过手机的方案解决后整合到了他们的Oracle薪酬系统中,并没有提供自己的独立管理入口;

再如:二维码生成的系统,我们提供了丰富的API保证和任何第三方开发语言的API对接,嵌入到了N个业务系统中。

云的下一站是API SaaS?

在业务实践中,我们探索了一条不是独立提供应用系统,而是将系统嵌入客户已有业务系统的方案。此时,有机构大规模报道了API SaaS。然后得知很多基于消息通讯的云RCS服务商获得了诸多投资。在我们准备找投资的时候,一个新的问题出现了:客户的付费模式无法支撑“按需付费”。

在中大型企业中的客户软件或者服务费用是预算制,如果没有纳入预算的费用是无法支付的。基于API的服务私有化部署,客户是高度认可和接纳的;一旦涉及到公有部署和按需收费,就没有客户可以按照此模式结算了。投资商对私有化部署是不认可的。

SaaS主要面向中小型客户,他们有足够的数量,这也是投资商喜欢的逻辑。在API化的应用面前,中小企业的接受度是极低的。首先,中小企业的采购环节很短,他们喜欢体验操作后直接下单购买,API的应用是无法直观体验的;即便是做了直观体验,在实际采购的时候,他们采购的操作层面的“定制”服务,这个成本(时间和资金)都不是中小企业愿意的。

准备将原有应用系统通过API化提供服务融资方案就此否决了。依然面向大客户,自己有收入就很好了。在今天我们交付的客户中,也在APP端集成了美洽的客服API,客户的客服中心、运营服务人员直接和他们的用户在APP端进行了业务的交流。

计算能力的支撑在API化以后遇到了问题。客户会将一个API系统“主动”嵌入到需求的系统中,然后服务器无法支撑了。第一次接到这种情况的电话,我就认为了Docker是解决这个问题的最优方案。后来和华为的Docker项目负责人俞小涛在一次会议上深入聊了这个问题,他分析后强烈建议合作。我们似乎找到了合适的解决用户私有化部署迁移到公有云的方案。不过由于部分原因这个合作还没有开始。

基本的假设是客户的私有化部署无法解决计算能力自动增量扩充的问题,我们将API应用的计算能力迁移到公有云,客户通过租赁公有云+应用的模式付费,数据通过备份方案或者存储方案部署到客户本地。根据客户获取计算能力的值收费。

没有了界面的支撑,在小企业和中小型企业销售方面确实遇到了巨大的阻力;也突然了API SaaS的优势:非常好的契合了用户的使用场景。将服务能力体现淋漓尽致的同时维护了企业服务各类角色的利益关系。

对于企业客户而言:满足需求和业务场景、省钱和在2-3年不落伍,这是对企业软件服务的基本需求。API化的应用服务很好地满足了这个特征。

API SaaS已经有了这个名词。这是好事儿!我在过去的两年逐渐体会到了API SaaS带来的巨大价值和优势,这是我们喜欢的领域。

在SaaS热度以后,是否就是API SaaS,我不知道。云的下一步在哪里?我坚信,做好自己现在的未来就在哪里。创业是一次修行!

本文转自d1net(转载)

相关文章
|
26天前
|
安全 API 云计算
云计算中使用API的5个坏习惯
云计算中使用API的5个坏习惯
云计算中使用API的5个坏习惯
|
3天前
|
消息中间件 运维 Java
java医院综合信息管理云HIS系统源码(前后端分离、SaaS模式、云计算)
云HIS系统分为两个大的系统:综合管理系统和业务系统 1、综合管理系统:由运营商、开发商和监管机构使用,用来进行运营管理、运维管理和综合监管。 2、业务系统:由基层医院使用,用来支撑医院各类业务运转。
19 1
|
6月前
|
存储 弹性计算 云计算
深入理解云计算:探索IaaS、PaaS和SaaS服务模型
云计算作为当代信息技术领域的关键驱动力,通过提供弹性计算资源和灵活的服务模型,极大地改变了企业和个人的计算方式。本文深入探讨了云计算的基础概念,着重介绍了三种主要的云计算服务模型:IaaS、PaaS和SaaS。
300 0
|
2月前
|
消息中间件 运维 前端开发
(云HIS)云医院管理系统源码 SaaS模式 B/S架构 基于云计算技术
v(云HIS)云医院管理系统源码 SaaS模式 B/S架构 基于云计算技术
50 0
|
2月前
|
人工智能 监控 安全
【Java】智慧工地SaaS平台源码:AI/云计算/物联网/智慧监管
【Java】智慧工地SaaS平台源码:AI/云计算/物联网/智慧监管
59 0
|
2月前
|
前端开发 JavaScript 项目管理
C#基于云计算SaaS模式的医学检验云LIS系统全套源码
C#基于云计算SaaS模式的医学检验云LIS系统全套源码
28 0
|
3月前
|
存储 中间件 开发工具
云计算的三个主要服务模型:IaaS、PaaS 和 SaaS
云计算的三个主要服务模型:IaaS、PaaS 和 SaaS
862 0
|
9月前
|
存储 机器学习/深度学习 容灾
IT知识百科:三大云计算模型IAAS、PAAS、SAAS
IT知识百科:三大云计算模型IAAS、PAAS、SAAS
1943 0
IT知识百科:三大云计算模型IAAS、PAAS、SAAS
|
11月前
|
消息中间件 运维 监控
基于 EventBridge API Destination 构建 SaaS 集成实践方案
本次新增集成中心(Integration Center)是负责 EventBridge 与外界系统对接的模块,通过抽象与配置快速获取第三方事件并将事件集成到第三方系统。并且优化现有 HTTP Sink 集成方案,为用户下游集成创造更多适配场景。
283 0
基于 EventBridge API Destination 构建 SaaS 集成实践方案
|
XML JSON 前端开发
聊聊 API 管理-开源版 Yapi 到 SaaS 版 Apifox
API 管理这个话题近些年听到的频次越来越多,这本质上是个 web 领域的发展有关,也和开发协作方式有关--前后端分离代替了全栈工程师 hold all 的局面,强调的更多的是 API 复用、分工和协作细化。
 聊聊 API 管理-开源版 Yapi 到 SaaS 版 Apifox