平台型 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
  }
}

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