标签归档:Serverless

Serverless 不是银弹

Serverless 不是银弹

这张图相信大家在互联网上或多或少都看过,说的很显示,如果你想要好且快的东西,那就是一分钱一分货。如果你想要快且便宜的东西,那必然会变得丑一些。

图源:Facebook劍心日劇廣告娛樂情報

作为互联网从业者,一个打工人,相信我的读者们都能够想明白这个点。

不过,大家似乎在看待别人的产品,特别是一些大厂的产品时,并不能够认清这个事实

产品方出于产品推广和运营的需要,必然会在产品推广和实际介绍的时候,宣称自己可以做任何东西。但作为真正使用的用户,你必须明确的知道,任何产品都具有自己的问题,没有一个产品可以满足你的所有诉求

我们以互联网产业中最为常见的问题来说,现在大型厂商一般都会推出自己的传统主机计算业务和 Serverless 云服务。

主机计算服务可以提供独立的主机给你使用,但相应带来的问题是你需要自己构建一整套基础环境,并进行基础的环境运维。

Serverless 服务则可以为你提供更高的弹性和更简单的环境配置,但相应的,也会带来更高的价格。 Serverless 服务在实际使用过程中,同等业务量的售价是会更高的。

你们一定要清楚不同的技术的优势和劣势。如果一个技术只有优势没有劣势,那他只能是个骗子了。

当你搞清楚技术的优势和劣势以后,反而你会对于技术的使用更加的得心应手。你不会在一个可能很大的项目中使用很低廉的技术方案。也不会在一个长期小而美的技术中,应用一整套互联网架构。

每一个产品都有自己的优势和劣势,你理解了优势和劣势,再根据实际情况选择方案,才能够不给自己挖坑,不给自己的长期运转留问题。

平台型 Serverless 产品的必杀技:免鉴权调用API

平台型 Serverless 产品的必杀技:免鉴权调用API

我在2019年的文章中(别找了,被我删了)曾经介绍过,国内的 Serverless 产品可以分为两个大类:

  1. 大公司产品:包括腾讯云云开发、字节跳动微服务、阿里云的云开发产品、Google 的 Firebase
  2. 小公司产品:比如 LeanCloud、Bmob 等等

而前者的最佳发展路线我也曾经提到过,大公司的 Serverless 想要赢得时间的最佳方案,是通过内部资源的整合,将开发者彻底绑架在自己的平台战车之上

而这样的方案,现在已经在各家的方案中有所体现,比如腾讯云云开发和微信合作推出的「小程序·云开发」产品中的「云调用」能力、轻服务推出的免鉴权调用小程序 API 的能力。

在微信小程序中,你可以通过 cloud.openapi.templateMessage.send 来实现免鉴权调用公众号的模板消息 API ,将过去数百行的代码简化为一行代码实现,可以有效的提升开发者的开发效率。

如今,轻服务提供了类似的功能,你可以通过 inspirecloud.openapi.tt.sendTemplateMessage实现免鉴权调用推送模板消息。

我一直觉得,Serverless 这样的产品,是为小团队、创意者而生的。而这些人的特点是,对于技术的深度可能不那么在意,毕竟他们关注的是我要实现一个创意,解决一个问题,至于 Scale 的问题,是在后续才需要注意的。而对于大公司的产品来说,想要干掉小公司的产品,一个利器就是免鉴权调用平台 API

免鉴权调用平台 API 对于开发者而言是一杯毒酒,不喝,你可能会被竞争对手超越,最终失去用户而死;喝了,你就会因为 Serverless 这样的产品模式,最终被绑死在战车之上。随之而来的,便是伴随着产品用户规模的不断提升的,是这些 Serverless 基础设施的成本就会逐渐超过你使用传统的服务器模式的成本。

但回过头来说,你真的能拒绝这样的平台优势么?很难,即使作为我这样的前后端一把梭的开发者,也很难抵挡 Serverless 产品前期的低成本和快速迭代,对于大量无法独立完成大型后端开发的工程师来说,这是一个必须喝下去的毒酒。

希望你在选择技术方案的同时,不给自己挖坑。

平台型 Serverless 如何赋能中小开发者?

平台型 Serverless 如何赋能中小开发者?

1 月 7 日的推文中,我有提到,「大公司的 Serverless 想要赢得时间的最佳方案,是通过内部资源的整合,将开发者彻底绑架在自己的平台战车之上」,对于很多人来说,如何理解这种内部资源的整合和它带来的赋能开发者?今天就用小程序 · 云开发最近开放的一个新能力 —— 短信跳小程序为例来聊一聊。

短信跳小程序这个能力其实背后是另外三个能力的组合:

  1. 微信最近开放的 URL Scheme ,我已经在 1 月 9 日的推文中写到了。
  2. 云开发的网站托管能力
  3. 腾讯云自有的短信推送能力

云开发基于上述的两个能力,辅以一些很低的开发工作量,实现了短信跳小程序这个能力。

其中,云开发的网站托管能力和短信推送能力,便是平台型 Serverless 产品内部资源整合而来的。

同样是一个 Serverless 团队要做这样的功能,作为小公司的 Serverless 就会面临:

  1. 短信服务供应商的选择和沟通
  2. 短信签名的审核和提交
  3. 底层代码拉通

但大公司的平台内往往已经自有短信推送的渠道,平台型 Serverless 只需要将底层代码拉通,就可以完成产品能力的对接。

这一点相比于小团队的重新选择供应商等,流程和耗时要少的多,要踩的坑也少的多

平台型 Serverless 团队借助于这样的很多内部能力,就可以轻松实现各种各样的能力,让开发者可以以最低的成本在自己的业务系统中加入产品能力。实际发布给开发者使用的产品,也就变得更加的简单易用。

就短信触达用户而言,云开发将这个能力做到了极简,你需要做的仅仅是将模板代码上传到静态网站托管中,并部署一个配套的云函数,就可以用cloud.openapi.cloudbase.sendSms触达你的用户,剩下的无需你操心,就自动完成了相关的功能。

const cloud = require('wx-server-sdk')
cloud.init()
exports.main = async (event, context) => {
  try {
    const result = await cloud.openapi.cloudbase.sendSms({
        env: 'online-12345678910',
        content: '发布了新的能力',
        path: '/index.html',
        phoneNumberList: [
          "+8612345678910"
        ]
      })
    return result
  } catch (err) {
    return err
  }
}

作为一个云开发的用户,我很期待有更多的同类型功能出现。