MuleSoft 副总裁 James:API 战争不可避免

  • 崔康

2013 年 12 月 10 日

话题:SOA语言 & 开发架构

MuleSoft 公司工程副总裁 James Donelan 最近预言:一场 API 战争即将来临。云端提供商和新一波配备有 API 的开发人员将导致大规模的技术颠覆。而 API 就是这场变革所使用的弹药。

James 首先引用了另一位专家的观点,Antony Falco 最近描述了这些配备有 API 的开发人员将如何从根本上改变企业 IT。所有的一切,从银行系统到支付平台、从航空公司系统到电子商务平台、从汽车系统到医疗设备,很快将会有开发人员利用 API 访问它们,这会让我们的世界发生重大变革。

这种 API 的使用的大量增加会对产品开发、竞争以及我们进行软件工程的方法产生什么样的影响?James 认为可以从几个方面来分析这个趋势。

首先是微 SaaS API 和可插拔特征(Micro-SaaS APIs & Pluggable Feature),James 认为,SaaS(软件即服务) 是我们所见过的发展速度最快的软件产业。在这个预期将增长到 1200 亿美元的市场中,现今已有超过 2100 家 SaaS 公司。到 2015 年,预计 85% 的新软件将采取 SaaS。

如今,SaaS 公司通常通过云端提供一个完整的产品或者广泛的功能层,像 CRM(客户关系管理) 或者计费。然而,随着越来越多的公司注重建立 API,我们将看到一种新型的 SaaS 公司的出现,这些公司注重他们做得很好的微功能部件。试想一下这种公司的存在,一个只侧重于为实现高速转移支付的 API 的付款公司,一个提供能实时通知你所在地区处于开放状态的酒店客房的 API 的旅游公司,或者一个有提供低成本的汽车保险政策的 API 的保险公司,它可以实时调低溢价,根据连接到汽车的设备捕捉到的你的良好驾驶行为的信息。这些微功能部件可以非常出色地完成一些非常具体的工作,其他的开发人员将希望将其合并到他们自己的产品当中,用以构建更好的应用程序。这也会刺激某些其他事物的发展——颠覆性的应用程序。

James 认为,随着 API 使用的激增,一种构建应用程序的全新的商业模式正在脱颖而出。在这种商业模式下,公司和开发人员通过公共或私人 API 选择微功能部件,这些微功能部件可以相对轻松地被整合或丢弃。

亚马逊网络服务系统(AWS)已经提供新的服务器,利用云存储并把大规模搜索整合到应用程序中,和这同样容易,API 将使得开发人员构建新的应用程序的过程变得简单,既在企业内部又在云端。得到新的应用程序不仅会变得容易,而且会更便宜、更快。我们将会看到一大堆微创业公司的形成,他们能在数天或数周在网络上部署新的应用程序,而不再是数月或数年。这些公司会通过 MVP(最有价值专家) 使他们的产品理念在创纪录的短时间内得以成形,并能够以最小的投资测试市场对其的反响。他们将导致永无休止的新竞争。

已经拥有了很多 IP(知识产权)和技术的公司会假设他们有超过竞争对手的巨大优势,包括那些与他们竞争的创业公司。但这会是一个谬误,在一个由 API 驱动的世界中所有此种“已经存在的 IP 优势”会迅速地蒸发消失。一个创业公司可以只是不费力地从其他供应商那里插入或换出功能部件,就可以光速一样做出一款功能丰富的产品,且其还可以更快地适应市场变化。这样看来,这些创业公司就具有了明显优势。

因此,没有适当的 API 战略的公司会感到痛苦并很快落后。要想在这个新世界中取得成功,你该如何武装自己?James 认为,公司将需要把他们现有的平台转变成为启用 API 的平台,并对其开发人员开放。

许多公司会采取的方法是,只在其现有系统加上 API。然而,仅仅在一个现有系统上开放 API 并叫它完成任务是不够的。公司将会不得不改造和重做这些 API 之下的通信。当把你的通过一个 API 实现其功能的产品推向外部市场,许多现在不明显或不可见的潜在问题——安全性、版本控制、延迟、可扩展性、QoS(服务质量) 等问题会出现。

为了竞争,公司将必须更进一步、钻研得更深、重构其基础框架,使其达到同那些从头开始的创业公司一样的最终状态。他们需要与创业公司一样使其产品有同样的灵活性,这将使他们能插入同类最佳供应商的 API,这样做是必要的。如果不这样,他们简直没有资格竞争。

James 表示,这种改造工作有一个名字——API 重构。它将是你的公司和工程团队必须主动去做的,重塑 API 并改进平台的底层基础,以便使其更容易地与 API 整合。

公司现在就需要开始把这些 API 战略落到实处,并开始行动,此举宜早不宜迟。从让你的开发团队认为 API 地位第一开始。开始设想你的平台会是什么样子吧,你现在就不受任何限制地从头开始设计,并让其足够灵活能够轻松地插入第三方 API,尤其是在那些不提供任何差异化的产品价值的领域里。

其实,API 的快速发展有其背后的意义。Alex Handy 曾经撰文谈到了从 SOA 到 API 的发展过程和历史意义:

八年前,企业级软件开发行业流行词不是一个词,而是三个词:“服务”“导向”“架构”。SOA 承诺了一个前景——第三方提供企业服务,用户可以很容易从内部使用企业服务。这个目标是将遗留系统转为网络可访问的 API。非常遗憾的是现在再没有人这样提议了,因为这将减少企业很多困惑。正当企业观望 Web Service 标准发展的时候,RESTful Web API 出现了。Web API 带来了 SOA 一直以来未能带给用户的前景。

那么现在这些 SOA 公司处境如何呢?许多 SOA 公司被收购了,也还有一些公司残留,正在进行重构、调整。MuleSoft 就是其中之一。在 SOA 盛行的时代,MuleSoft 提供的全是企业服务总线。但是现在 SOA 的时代已经过去了,这家公司在过去的两年不得不重新进行价值定位以谋求发展。

MuleSoft 的创始人、战略产品总裁 Ross Mason 表示:“我们所做的是停留在了核心竞争力的地方,然后发现产业在朝着那个方向发展。”现在 MuleSoft 的重心放在移动和 SaaS 集成,而这些业务已经占到 MuleSoft 全部业务的 60%。

为什么现在不同了呢?首先,SOA 关注的事情是错误的,它仅仅关注如何公开数据,但没有思考人们应该怎样使用这些数据。市场迫使供应商去思考用户想从平台上获得什么。市场迫使供应商去为用户思考,但是 SOA 并没有做到这一点。”

我们为传统 SOA 提供单个统一的平台,然后应用程序——特别是 SaaS 集成——是这个平台的重要组成部分。API 发布和管理驱动着最大的利益。越来越多的人认为这是一种更好的托管系统的方式。我认为现在的局面源自潮流的驱动——SaaS 潮流和移动潮流——正是它们驱使人们换一种思路来理解基础设施。过去的四年,人们追寻降低成本的办法。现在,他们该想想‘十年以后我们的业务会变成什么样子?’正是这些控制了 CIO 的收购行为。传统的中间间还没有跟上步伐。

另一家致力于 API 管理和支配的公司是 WSO2。WSO2 的高级技术主管 Senaka Fernando 提到 WSO2 已转换认知——从将 API 和托管服务作为两个服务转换为将其视为一个统一的管理服务,该公司已因此不断成长。

我们认识到 SOA 管理和 API 管理并非两个不相干的事情。他们是一件事情,而且我们需要实现它们的整合。过去,你将你的系统托管,然后在上面跑一些东西,现在你可以在上面实施一些“政策”。另一方面,为了保障员工的利益,你可以跟踪这些服务背后的信息。所有被跟踪的信息都会记到一个注册表中。把这个技术放到产品生产的大背景中,你会想知道‘谁在用我的服务?’我们的产品就允许你追踪了解哪些人在使用这些 API。

SOA语言 & 开发架构