一文搞懂SaaS困境、API经济与Serverless WebAssembly

2021年11月22日 阅读数:4
这篇文章主要向大家介绍一文搞懂SaaS困境、API经济与Serverless WebAssembly,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

​本文整理自 WasmEdge 在神州数码 『TECH数字中国2021技术年会』"武汉技术嘉年华" 的分享。前端

SaaS 的困境与 API 经济

SaaS 已经成为 deliver software 愈来愈重要的一种方法。可是中心化运营的 SaaS 产品怎么才能知足“千人千面”的定制化需求呢?这个问题在中美两国都有,可是中国的问题更严重一些。node

SaaS 公司广泛面临着一个问题,就是若是为用户定制化过多,SaaS 慢慢就不是一个产品公司了,而变成一个咨询公司。固然这个问题并非今天才有的。这个问题的解决方法其实也很简单,就是 API,因此就有 API  economy (API 经济)的说法。python

Postman 这家印度公司最近融了2.5亿美金,估值已是56亿美金。可能不少程序员会以为惊讶,由于 Postman 这个事其实并不复杂,就是为 SaaS 提供 API 测试和 API 管理的平台。这件事提及来技术含量并不大,可是 Postman 产品作得比较好,并且入行的时间比较早,因此取得了成功。这就是 API 经济,就是帮 SaaS 管理 API 这件事情,实际上是有很大需求的,并且今天有人作出了 Postman 这样五十几亿美金的公司。react

可是对于用户和开发者来讲,其实都是对 API 有 mixed feeling 的,由于每一个 SaaS 的 API 都不同,管理起来也比较复杂。有没有更好的方法呢?咱们来看另一家公司叫作 Zapier。git

Zapier 这家公司总共才融了不到200万美金,可是今天它的估值也是50亿美圆,每一年的收入11.4亿美圆。Zapier 就是作 API 自动化的,或者用今天比较流行的话来说就叫无代码平台。就是开发者不须要直接去管理API,也不须要直接为 API 应用专门起服务器。具体来讲,若是 SaaS 的用户要开发 SaaS 的应用程序,不须要起服务器,就也不须要去管理运维,而是直接用 Zapier 来管理 API。在 Zapier 创建一个 Zap,而后在那个 Zap 里面点击受权登陆 SaaS,就能够把 API 的功能给串起来,或者把 API 的功能给自动化。Zapier 让比较初级的开发者或者甚至没有代码能力的商务人员可以对 SaaS 进行定制化。程序员

解决 SaaS 定制化的问题中,API 是给程序员用的,低代码的解决方案是给商务人员用的,总的来讲这两个生意都能作得挺大的,这两家公司都在50亿美金的规模了。github

API 是什么

那么下面具体来说 API 究竟是什么?SaaS 的 API 为何会这么有用,为何会有这种低代码解决方案出现?web

API 的做用就是典型的网络隔离代码的做用。SaaS 是一个中心化运营的软件环境,因此说不能千人千面的为每个客户进行定制,不能为每一个客户改代码,那怎么办呢?可让用户本身改代码,把代码放在本身的服务器上,而后跟 SaaS 之间有某种交流的机制,这就叫 API。数据库

用户写了什么代码,要对 SaaS 进行什么样的定制,做为 SaaS 提供商来讲是不知道的,只有用户本身知道。因此用户写了以后放在本身的服务器上,不会放在 SaaS 的服务器上,而后跟 SaaS 的交互就是经过API、经过网络来进行交互,用网络把代码隔离开,这个是在云计算早期一个你们都用的方法。api

这个缺点是什么呢?缺点就在于用户本身要管理 服务器,这是一个开发也慢、deploy 也慢,安全性低,可靠性低,并且是一个很是昂贵的工做。

上图下面的这三张表就是飞书的应用上架流程,我下面会讲到它实际上是一个正面例子,不过为了要讲痛点,因此咱们如今把他当作负面例子来说。

飞书有一个核心功能,就是用户能够在飞书平台上定制本身的机器人,让机器人来处理一些事务。要搭建一个聊天机器人,标准的作法就是用飞书的 API。这个 API 的设置是用户去起一个服务器,用这个服务器监听飞书的 API 来的 event 的。若是有人在飞书里面和机器人对话了,就会产生一个事件,而后飞书经过 API 发回开发者的服务器上来,而后开发者的服务器就会按照写好的逻辑把回答经过 API 发回到飞书去,这个机器人对用户回答了一句话,整个过程就完成了。

为了要干这件事情,须要开发者本身起个服务器。要求不少,服务器须要在大陆,须要在工信部备过案,须要有 https,须要有 SSL certificate,飞书同时须要应用开发者可以管理本身的内容,不能有黄色内容和反动内容,须要 99.9% 以上的时间是可用的,当飞书用户与机器人对话的时候,机器人能立马要回应。若是把这些东西所有加起来,实际上是运营的工做不少,其实开发的工做很少。

下面这几个图讲的就是咱们当时就为了在飞书里面加一个春节的时候发贺卡的机器人,这须要通过的 check list 是好几十项,要好几我的干好几天才能完成。因此 API 这东西听起来是颇有用的,也颇有价值,但是其实用起来仍是挺困难的,这就是为何会有无代码这样的平台出现。

有没有一种更好地使用 API 的方式?

怎么解决 API 今天的问题呢?其实在 SaaS 跟 PaaS 之间的这条线其实一直都是模糊的,SaaS 是 software as a service,PaaS是 platform as a service。从 Salesforce 开始,SaaS 公司其实一直想作 PaaS 的,就是说把 API 作成一个开发者的平台。但咱们来看看真正的 PaaS 平台,好比说腾讯云、Heroku、字节的轻服务,其实都是以 API 与托管代码的形式共存的。我要作一个平台,让你们可以在个人平台上进行扩展,可以加本身的业务逻辑,须要的不只是 API,须要的仍是在平台上要可以直接运行客户本身的代码。

SaaS 为何要用 API 来隔离网络,由于他不想让用户把本身的代码放到中心化运营的 SaaS 上面去。可是在 PaaS 平台里面,这种作法常常是反过来的,就是让用户直接把代码上传到平台上来,而后在平台上运行用户的代码。举刚刚那个聊天机器人的例子,那就变成了开发者不须要本身起个 API server 去监遵从飞书来的 events 和信息,只须要给飞书上传一个函数,这个函数的输入就是用户对机器人说的话,这是个字符串。函数的输出就是机器人要回答的话,也是一个字符串。我把这个函数上传上去以后,不用购买任何服务器,就可以运行起来。并且,由于是在 SaaS 这个环境里面运行的,这样域名就不须要认证、99.9% 的可用性,这些都是有保证的。显然这是一个更简单的作法,就是在平台上直接运行用户的代码来实现定制化。

在 PaaS 平台里这样的传统作法是什么?就是用 Docker。在平台里面用户上传了一段代码、上传了一个函数,这个函数在平台上是不能被信任的,平台不能直接去运行这个函数,因此它就起一个 Docker instance,而后在 Docker 里面去运行用户的代码。这个就是所谓 Serverless 的概念,这是目前 PaaS 平台里面经常使用的一种方法。

如今在云计算这个行业里面, serverless 是一个很是大的趋势。

再借用我上面举的那个例子,用一个函数来作飞书机器人的,我就只管业务逻辑了,就不用再管 infrastructure 逻辑了,只是把函数上传上来就能够了。从容器到函数这一步是咱们如今正在走的这一步。固然在这一步里面,今天大部分人实际上就是所谓的 Function as a service,就是函数即服务,这种函数的方法仍是用容器,可是咱们下面会讲到还有其余更好的方法。

总结一下观点,今天的 SaaS 虽然是用 API 来作的,是用 API 来实现扩展的,可是若是说咱们须要更轻更快更安全,跨平台的扩展方法,咱们实际上是能够用嵌入式的函数,咱们就让用户上传一段函数给一个平台,而后让这个函数去定制 SaaS 的行为和 SaaS 里面的业务逻辑

SaaS 里的嵌入式函数用 Docker 合适吗?

下面就要问个问题,Docker 真的合适吗?作嵌入式的函数、作 Function as a service,今天主流的作法是用 Docker 来作。用户把函数代码上传上来了,而后放在 Docker 里面运行,而后经过这个函数运行的结果来定制这个 PaaS 平台或者 SaaS 平台的行为。可是 Docker 干这件事情真的合适吗?

Solomon Hykes 是 Docker 的 CTO 和 Co-founder。他说 If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. 这是他在2019年说的话。若是说 Webassembly 这种容器在2008年就存在的话,咱们就不须要 Docker 了。做为 Docker 的发明人说这样的话,天然在社区里面引发了很大的反响。

在云原生的行业里,咱们在用 Docker 作嵌入式函数的隔离,可是 Docker 真的合适吗?像 Webassembly 这样的新标准会不会是一个更好的选择呢?

咱们来看看 Shopify 的故事。Shopify 是电商行业最大的 SaaS 之一了,Shopify 用 SaaS 的方法在北美市场上挑战电商巨头AWS。Shopify 今天的流量比亚马逊要大了,已是北美第一的电商了。这是 Shopify 的 CTO 说的话,Shopify is an API first company。

补充一下 Shopify 的背景,Shopify 就是开店的平台。若是用亚马逊的话,开的店都必须在亚马逊的平台上。Shopify 提供了一个 SaaS 工具,让用户能够开本身的独立电商店,而后就能够创建本身的品牌,全部的东西均可以在 shopify 上定制。

因此说 Shopify 是一个 API first company,由于 shopify 的用户、开发者是跟 shopify 的 API 进行交互。但是在 API 里面有不少事情是作不了的。

Shopify 在2019年作了一件事情。好比我开了一个店,可是这个店里面有一些逻辑是须要在用户购买的时候发生的,好比一个折扣的逻辑。每一个店家有本身的折扣逻辑,好比买三送1、买三包邮、买三打折。店家有千人千面的折扣逻辑,那怎么把不一样的折扣逻辑作到一个 SaaS 的平台里,让用户能够定制呢?

第一种方法就是作模板化。模板化问题就在于选择是有限的,若是真的有几千几万个模板,用户要找到他真正须要的模板可能还挺难的。Shopify 之前一直是在用模板这个作法。或者也能够用 API,可是这个体验不好。就是在用户购买的那一瞬间,Shopify 产生一个 Event,发到店家的 Server上面去,而后让店家计算这个折扣应该是什么,而后店家把结果返回给 shopify,而后再让用户继续往下走付款的流程。但是这是一个不好的用户体验。由于在网络的一来一往至少就要一秒钟左右,而在用户去付款的过程当中,每一毫秒都很重要。有研究代表,每延迟10毫秒,用户不买的可能性就会增大不少。因此用 API 这种办法其实不行的。

那只剩下一种方法,把这段逻辑以代码的形式嵌入在购物车里面,也就是说让商家上传通常代码,而后在 Shopify 的平台里运行。在用户结算购物车的时候,运行这段代码,根据购物车的内容去运行这段代码决定它的价格是什么。这段代码能够在 Docker 里面运行,但若是在 Docker 里面运行的话,仍然面临一个问题:Docker 的启动时间很慢。

在 Docker 里面引进一段函数,实际上是一个效率很是低的事,要起 Docker,就要起 Docker 里面的操做系统,而后再起 nodejs 或者起 python ,取决于这个函数用什么语言写的,而后运行一个20行的函数,运行完了以后再把 Docker 关掉,99% 的时间花在setup inferstructure上面,而只有大概1%的时间在真正运行这段代码。

因此 Shopify 想了一种新的方法。Shopify 当时专门写了篇文章《Making commerce Extensible with WebAssembly》,在业界有挺大的反响。Shopify 就用 WebAssembly Runtime 来干这件事。经过这个 workflow 图能够看到, Shopify Cloud 就是 Shopify  这个 SaaS 平台。用户进来一个 web request,它去 call 了开发者/商户商户提供的一段 WebAssembly 代码去计算折扣和其余定制逻辑。

Shopify 里面如今这样的应用场景愈来愈多,由于跟 API 相比,这种优点是很是明显的,对于开发者来讲,须要管理的东西大大减小,并且性能有了大幅提高,占用资源也大大降低了。而相比于 Docker 来讲,WebAssembly 的资源占用率也只有 Docker 的1%,而且没有冷启动时间。最大的电商 SaaS Shopify 有了这个落地的实践,用 WebAssembly  在 SaaS 里面做为提供扩展的一种方式,如今变得愈来愈流行。

在这儿不少人极可能有这个问题,就是 WebAssembly 真的能取代 Docker 吗?这听起来是两个不一样的东西,WebAssembly是从浏览器里面来的技术,Docker 一开始就是一个开发者工具。

但若是仔细看的话,Docker 与 WebAssembly 之间是有不少类似之处的。好比说它们都能提供在运行时的隔离,是可移植的,事实上 WebAssembly 的可移植性比 Docker 要好不少,Docker 还取决于下面的 CPU,若是基于 RAM 64 的 Docker 镜像在 X86 的机器上是运行不起来。可是WebAssembly 是 bytecode,因此 WebAssembly 下面全部的 CPU、GPU 之类的都被抽象了,因此 WebAssembly 是真的能够跨平台,这有点像JVM。而后都是比较容易部署的, Docker 能把程序打包成一个镜像,而后就部署了。WebAssembly 也是一样的,可以把程序打包成一个 bytecode application,而后全部的部署与依赖都在这个Application里面。把字节码应用直接把复制过来就能够部署了。因此从某种角度上讲,WebAssembly 和 Docker 在最重要的feature上面是很是相像的。

同时 WebAssembly 又比 Docker 轻和快不少,这是咱们在2021年初在IEEE Software上面发表了一篇学术论文,那时候咱们的开源项目叫 SSVM,如今叫 WasmEdge。因此你们看一个比较重要的点是这幅图的最后。那就是说在启动时间,WebAssembly 比 Docker 或者 Docker+Node.js 是快了100倍以上。

WebAssembly 是一个比 Docker 抽象层次更高的 runtime,或者说容器。咱们把容器分红三种,一种就是VM,第二种就是Docker这样的容器,第三种是 high level language VM WebAssembly,VM 在模拟一个计算机,容器在模拟一个操做系统,而WebAssembly这样的 VM 是在模拟操做系统里面的一个process。

咱们的开源项目是CNCF里面第一个云原生的 WebAssembly 项目,叫WasmEdge,这个项目在 github上面,欢迎你们来围观。

WasmEdge 源代码:https://github.com/WasmEdge/WasmEdge

 

WasmEdge 的重要场景固然有不少,好比说有Cloud-native Microservices ,微服务;在公有云里面的 Serverless runtime,而后最后一个固然很重要的是在应用和 SaaS 里面的嵌入式的 Serverless runtime。

同时 WasmEdge runtime 全面支持了 JavaScript。你们对 WebAssembly 的一个“诟病”,就在于 WebAssembly 前端的语言须要是编译性的语言,好比说 Rust、 C++、C、Swift 这样的语言比较好。但是 Python JavaScript 的支持就比较差,但在云原生这个行业里面,其实 JavaScript 挺重要的,咱们作了不少努力,让 WasmEdge 可以比较全面地支持JavaScript。而后甚至可以在JavaScript里面支持几乎全部C native 或者 Rust native 的 API。就是 C Native 或者 Rust Native 的 API 可以 import 到 JavaScript 里来。

好比说咱们这里的一个例子是用 JavaScript 做为AI推理,是用到下面的GPU 和 Tensorflow library,可以达到的performance 跟你用 C++ 写Tensorflow 的 performance 是差很少的。

如何用 Serverless 的方式扩展 SaaS

因此咱们刚刚讲到了 SaaS 的可扩展性和用嵌入式函数来扩展SaaS。具体作法其实主要有两种,一种就是刚刚咱们讲的在SaaS内部直接支持 PaaS 风格的 SDK 与嵌入式函数,就是改造 SaaS 内部的 infrastructure。让用户除了 API 以外,还可以用嵌入式函数跟 SaaS 进行互动。SaaS平 台自己提供一个让用户上传函数的地方,这就是 Shopify 干的事。

由于不少 SaaS 内部采用的是微服务或者采用的是 Kubernetes 来管理 SaaS 内部的各类服务与服务的集群,因此在这种架构下面,咱们能够把 WebAssembly 加进来。在 SaaS 平台内部进行改造,让 SaaS 内部的微服务,有的微服务用Docker容器,有的微服务用 WebAssembly,特别是用户上传的函数作成一个微服务,就用 WebAssembly 容器,而后可以带来性能的提升和经过嵌入式函数给用户带来更自由的可扩展的好处。

这上面咱们也作了不少工做,好比说咱们跟 dapr 有比较深的合做,而后咱们跟几个基于 kubernetes 的 service mesh有比较深的合做,若是你们有兴趣的话,但愿你们来找咱们一块儿讨论。

这个方法的难点在于须要 SaaS 的开发者与运营商配合,须要在SaaS软件内部的结构进行一些改动。

第二个作法,就是说对 SaaS 进行无缝对接。SaaS 仍然是提供 API,可是咱们提供一个第三方的服务,把 SaaS API 用嵌入式函数给联系起来,这其实就是 Zapier 的作法,咱们用第三方 Serverless 服务连接 SaaS,具体怎么作呢?

首先来解释一下为何要这么作。SaaS 仍然是有 API,可是对于开发者来讲它不用关心 infrastructure了。开发者不用为了拓展 API 专门买服务器来监听这个 API 的消息。只须要上传代码给一个第三方的服务就行了。这个第三方的服务会帮开发者设置一切底层的内容。这叫 Serverless。

同时一个 Serverless 能够链接好几个 SaaS,能够把好几个 API 给串起来,而不是一个服务器监听一个SaaS。

同时这种方法对今天的 SaaS 是没有入侵性的,因此能够利用现有的API。

但它一个缺点就是没有很是深度的集成,好比说咱们刚刚讲的 Shopify 这个 case 用这种方法是作不了的,Shopify 那个case要作的事情不仅是要让开发变得容易,对反应时间也有很大的要求,因此说用 API 这 个作法其实作不了的,必须得要在它的平台内部嵌入函数。而咱们这里讲的仍是在平台外部嵌入函数,同时由于咱们是用 SaaS 现有的API,因此只有现有 API  能作的事情咱们才能作。若是说咱们要去改 SaaS 的 UI ,就是一个就比较困难的事情。这种方法也有优点和劣势。

咱们有一个内测的服务,用咱们的 WebAssembly runtime WasmEdge 把这样的服务给写出来了,这服务叫作Serverless Reactor。一个是Serverless,另外 Reactor 是个 reactative programming model,是反应式的。这个函数何时被调用(triger),是看 SaaS 的 API 会不会监听到事件。

http://reactor.secondstate.info/zh/

因此咱们来说两个例子。好比说咱们开发一个飞书或者 Slack 的聊天机器人,在咱们这个平台里面要怎么作呢?

第一是在 Reactor 里面建立一个 flow。这个 flow 有两个 connector (接口),第一个接口是配置飞书的 inbound connector,就是从这个 flow 登陆飞书,而后让飞书的 event 送到这个 flow来。而后再给这个 flow 配飞书的 outbound 的 connector,一样的过程 log in飞书,而后把这个flow的event flow产生的数据发回给飞书。这样就建立一个 flow。

第二个是开发一个函数,这个函数能够用 Rust 或者 JavaScript 语言开发。这函数的输入是一个字符串,就是一个 JSON message,也就是飞书的event,输出就是须要回复的消息。因此输入的是别人对机器人说的话,输出的是机器人要回复说的话,

第三是把函数开发好了,编译好了以后把它上传到 flow,这件事情就完成了。刚才在第一步建立一个 flow 的时候已经把 connector setup 好了。对于用户来讲不须要管理任何服务器,只须要写业务代码,也不须要知道飞书的 check list 是什么。开发者只须要知道进来的数据格式是什么,出去的数据格式是什么,业务逻辑是什么,在这个过程当中能够经过 WasmEdge 的 SDK链接数据库,网络,因此这就造成了一个闭环,让用户开发一个聊天机器人变得更容易。

第二个例子是连接两个SaaS服务。是 Liga AI 跟飞书联系起来。好比说在研发管理里面有ticket,有issues。若是一个issue 截止时间到了,它就应该给相应的飞书用户发一个通知,提醒用户时间快到了。

Liga AI是个深圳的公司,是作研发服务的SaaS,有点像中国的 JIRA.

咱们也是一样的 123,先是建个flow。但这个 flow 里面,inbound 事件是从 Liga 来的,因此在这个 flow 里要去登陆 Liga,让 Liga 的 event 送到这个 applications 里面来。同时给 flow 配的 outbound connector是飞书的,因此在配 outbound connector 的时候,登陆飞书,而后发出去的 message 送给飞书。

而后是开发这个函数,能够用 Rust 或者JavaScript,输入是 Liga 的 event,输出是飞书的 message。flow 设置好了,函数编译好了,最后就把函数上传到 flow 里面去,这个机器人就能够用了。

若是 Liga 里面产生了一个event,event 被这个函数收到了,这个函数看到这个 event 的时候就去给飞书发一个消息,而后发给 对应的飞书用户。这是咱们两个 use case 如今在这个内测的平台上如今就能够用了。

咱们这个平台如今尚未彻底公开使用,咱们也愿意把这个平台提供出来,给有兴趣的朋友可以内部测试使用。一个是往 SaaS 里面直接加嵌入函数,第二个是经过一个第三方平台链接 SaaS 的 API,经过嵌入的方式直接链接SaaS的API。这两个想法若是你们有什么想讨论的东西,欢迎你们你们来找咱们讨论。很是感谢。

 

关于 WasmEdge

 

WasmEdge 是轻量级、安全、高性能、实时的软件容器与运行环境。目前是 CNCF 沙箱项目。WasmEdge 被应用在 SaaS、云原生,service mesh、边缘计算、汽车等领域。

 ✨ GitHub:https://github.com/WasmEdge/WasmEdge

 💻 官网:https://wasmedge.org/

 👨‍💻‍ Slack 群:CNCF Slack 搜索 WasmEdge