FaaS+BaaS 的组合，构成了 Serverless 无服务器架构，免除了所有运维性操作，让企业和开发者可以更加专注于核心业务的开发，实现快速上线和迭代，把握业务发展的节奏。
由此可见，云函数是 Severless 架构中的算力部分，是实现 Severless 架构的基础计算资源。在 Severless 架构下的业务系统中，因业务功能、需求场景不同，所需的 BaaS 后端服务也可能各不相同，但业务逻辑都需要通过云函数来实现。
具体案例刚才也提到 Serverless 本身有很多很多的应用场景，这个问题在不同的 Serverless 的场景下，答案也是不同的。
如果业务需求是基于类似于 Express、koa 的应用框架来实现的，那么在设计上，基本没有任何区别。Serverless 云函数可以很好地支持这些应用框架，只是部署方式不同而已。
如果需求场景不需要任何应用框架，直接使用原生代码，在 Serverless 架构下进行设计时，需要以函数为粒度来考虑，将函数作为业务中的最小功能单元。
还有一个场景使用 Serverless 和不使用就有很大的不同——企业上云。
现在很多企业应用都做应用上云，上云其实是一件非常有技术门槛的事情。可能需要上云的代码只有几百行，但传统上云绝不是上传部署几百行代码那么简单（估计很多工程师看到 Kubernetes 那几本厚书的时候就已经快疯了）。这个过程需要专业的、有经验的工程师，花费大量的工作，才能把业务系统迁移到云上。
Serverless 下的体验就非常不同，因为无服务器架构，所以不需要关注虚机或者容器配置和治理工作，基本上只用上传代码就完成了上云。
Serverless 的未来演化从以往的历史来看，技术的演化还是存在一些一般规律的。
首先我预测 Serverless 生态一定会趋于繁荣。一个技术很有优势，相关的社区贡献，以及周边的支持就越强大，用的人就越多；用的人越多，这个技术就越火，类似于经济学里的有效市场理论。最近 Serverless 的发展很快，可能大家看到这篇内容的时候，我们的 Serverless DB 产品已经发布了，就是开发者连数据库的存在都不需要关注了。Serverless 的使用者会越来越多，同时生态里的贡献者也会更多，整个生态也会更加繁荣。
第二个方向是 Serverless 的标准化。当生态繁荣之后，对于标准化的需求就变得非常强烈了。国内外各家云都有了自己的 Serverless 解决方案，对开发者隐藏了底层基础设置。但是各家的接口、实现还是不一样。试想一下，开发者在国内云上用 Serverless 实现的代码，在做国际化的时候，要迁移到另一个云厂商，却发现完全无法平滑迁移是什么感受？公司内两个技术团队如何在 Serverless 的架构下复用功能和代码？如何能够用统一的标准或者框架来构建应用？Serverless 开发需要一些标准，或是某一种框架来适配各个云厂商之间的不同实现和接口，很可能是 Serverless 接下来的发展方向。
传送门：
GitHub: github.com/serverless
官网：serverless.com