Serverless架构用来描述那些显著或完全依赖于第三方应用或服务（“在云端”）的应用程序。这些程序经常是移动端APP或者是最近几年比较火热的单页Web应用。这些应用可以完全基于云的服务进行构建，比如AWS的S3和DynamoDB或者是阿里云的OSS和TableStore。
但是总是有一些独立的服务器逻辑代码需要运行，传统的部署方法是使用云服务器来进行进程的托管，但是FaaS (Functions as a Service)的出现改变了这种情况。FaaS能够让用户将自己服务器逻辑代码以Serverless的方式托管到云上，让用户以应用函数为单位对应用进行开发、运行、管理，无需基础设施层面的关心构建和维护工作。
Serverless架构于2014年进入大众视线，AWS、谷歌云、微软Azure和IBM Bluemix等云厂商提供服务。业界认为，Serverless化可大幅降低IT成本，将云的费用减少10%-90%。可口可乐架构师Patrick Brandt曾向外媒披露，向Serverless架构转移是主要出于降低IT运维费用并且提高服务部署效率。
2017年4月云栖大会 南京峰会，阿里云发布了函数计算产品。阿里云函数计算负责人不瞋认为，从云计算整体发展趋势而言，Serverless的出现是意料之中。云计算的第一阶段是基础设施即服务，用户能够使用和调动大规模的计算资源；接下来需要攻关的是如何高效利用资源、更加有效的降低成本，更加弹性的面对业务波动，这就是函数计算的用武之地。InfoQ对不瞋进行了专访，并将内容整理如下。
受访人简介
不瞋，函数计算研发经理。2010年加入阿里云，参与了阿里云飞天分布式系统的研发，历任批量计算的架构师，表格存储（NoSQL）研发经理，深度参与了阿里云系统研发和产品迭代的全过程。对大规模分布式计算，大规模数据存储和处理有非常深入的理解。现为阿里云函数计算产品研发负责人，致力于构建下一代弹性、高可用的无服务器计算平台。
什么是Serverless？什么是FaaS？
其实，广义的Serverless覆盖范围很大，很多云服务产品可以被视作Serverless化的。以存储服务的发展历程为例：最初常见是云服务器，此种情况对用户熟悉的原有开发方式的模拟，但是需要自行处理云服务器宕机带来的数据不可用问题，云磁盘上的数据也不便于分享；后来，对象存储（OSS），文件存储（NAS），表格存储（TableStore），消息服务（MNS）等都属于Serverless服务。这些服务不再有机器的概念，用户能够享受自动的扩容和负载平衡，性能水平扩展，通过API方便的读写数据，易于共享，并且按实际存储的数据量以及访问次数付费。此外，类似阿里云大数据计算服务（MaxCompute） 也是Serverless的，提供了MapReduce，和Streaming等多种计算框架，用户不需要管理计算资源。
Serverless是一个宽泛的概念，很多存储、计算和中间件服务都是Serverless的。而FaaS是Serverless的子集，也是实现整个应用Serverless化的核心服务。FaaS的关键特征是：事件驱动、细粒度调用、实时弹性伸缩，无需管理服务器等底层资源。在不瞋看来，FaaS兴起是对现有技术很好的补充，配合使用已有的云服务产品，即可以真正构建Serverless的应用。阿里云之所以研发FaaS产品-函数计算，也是观察到在存储和计算业务中，从server-base到Serverless的演变趋势和用户的需求。
Serverless与微服务是一脉相承的
微服务和Serverless是契合的，都强调系统的解耦。
将业务逻辑的实现拆分到Function的粒度再去实现，这种方法其实并不新奇；微服务本身是被越来越广泛使用的模式，并且已经有Netflix、Uber等公司的成功经验。用户完全可以把一个微服务实现为Function。阿里云函数计算设计的一个重要目标也是使之成为以微服务方式构建应用的最好平台。微服务式架构其实是很有挑战的，在拆成成百上千的服务之后，需要高度自动化的发布部署系统，管理各个微服务之间的依赖。从某种角度而言，Serverless和微服务是不同层面、但又互相促进的：微服务式是开发模式，Serverless是计算平台。
不瞋称其个人理解是，让Serverless这种计算平台变成支撑微服务开发模式的最好的平台。当越来越多公司熟悉并实践微服务的开发模式，那么迁移到Serverless就会更顺理成章，因为系统已经被解耦成了众多松耦合的微服务。
所以，Serverless和微服务的未来发展是相互借力的。一个有力的例子就是，大规模使用微服务的方式构建系统的公司，例如Netflix，也在广泛的使用AWS Lambda这类FaaS服务来构建Serverless应用。
但是，微服务化改造并非易事。将一个巨型单体应用以微服务的方式拆分解耦，继而改造为Serverless应用，是采用渐进的方式逐步替换还是完全重写？这是业界非常关心也经常讨论的问题，不瞋认为需要依据情况而定：有时直接重写更快；而在系统错综复杂的情况下，为了保险起见也可平滑过渡，一点点向微服务化演进。拆分微服务有三个考量，组织结构（参考康威定律），运维发布频率（比如将每周发布两次的服务与每两个月发布一次的服务进行拆分）和逻辑调用频度（将高频调用逻辑和低频调用逻辑分开，在Serverless架构下能够进一步降低成本）。以上三点需根据业务需求情况进行综合考量，没有普适性的优先级之分。
Serverless适用的两大场景
场景一：应用负载有显著的波峰波谷
Serverless化与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。
业界普遍共识是，当自有机器的利用率小于30%，使用Serverless后会有显著的效率提升。对于云厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个云厂商，如果其平台足够大，用户足够多，是不会有明显的波峰波谷的现象的。
场景二：典型用例-基于事件的数据处理
视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。
开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。
使用小tips：函数的执行本身是无状态的，如果要持久化数据则需使用OSS等存储服务。虽然用户可以使用本地的磁盘，但是需要假定这些数据在函数执行完成后就不再需要了。
Serverless会带来哪些冲击？
Serverless不等于没有运维，但是运维内容变了。
在Serverless出现之前，用户运维时要考虑机器挂了怎么办，连接数暴涨了怎么办等等。
用户用云，从某种意义上讲是为了提高效率，而效率又分为开发效率、运维效率和成本效率。Serverless之后，运维从事的更多是业务运维，摸清依赖关系，设定监控项进行健康报警。
运维不再负责机器运维，而是业务运维。比如函数A调用函数B，这样的依赖关系是否合理；从业务逻辑上去评估哪些关键路径需要报警，哪些是允许失败的。原来的机器运维需要关心配置问题、操作系统、Kernel升级和网络设定等。所以其实Serverless更加推动了DevOps，Ops工作被改变了，Serverless对开发人员也更加友好。
长远而讲，会冲击传统PaaS
如果Serverless平台可以解决通用问题，并且有吸引力，那确实会对传统的云计算有冲击；但是，这是个渐进的过程。Serverless可以部署在公有云、私有云和混合云上。（备注：目前阿里云推出的产品尚限于公有云。）
在不瞋看来，Cloud-Native应用是指基于各种云的服务构建的高可用、可伸缩的应用。例如通过函数计算实现控制流逻辑、整合对象存储、离线数据处理等云服务，就能快速搭建一个实时弹性伸缩、高可用的业务系统。因此Serverless是构建Cloud-Native应用的理想方式。
开发模式和职责的改变
未来，Serverless一旦流行开来，用户可以依托于云计算厂商提供的平台类服务，快速构建弹性高可用的系统，从而专注于业务逻辑的创新。
四问阿里云的函数计算
阿里云函数计算是不是一种跟风行为？
函数即服务（FaaS）并非阿里云首创，2014年10月hook.io推出了首个FaaS服务。同年AWS Lambda问世，2016年Google Cloud Functions 和 Microsoft Azure Functions相继商用化，具备开源版和商用版IBM Bluemix的OpenWhisk也提供类似的功能。Uber曾经演示过其私有云平台如何构建去模式化触发（Schemaless triggers），和云厂商的FaaS服务有异曲同工之妙的。
不瞋称，函数计算的推出其实是因为客户在使用过程中产生了这种需求，并且同时也确实契合了云的发展趋势。
阿里云做产品是由用户需求驱动，比如观察到用户在使用OSS对象存储时，通常需要由存储事件触发的数据处理。例如在音视频行业中，上传的视频文件通常会进行转码、鉴黄等处理。通过对这些需求的分析，然后去思考是否可以抽象为通用的技术解决方案。这是主要驱动力，当然同时也会观察业界的发展，不过本质上还是与所服务用户的需求相关。
从什么时候开始积累函数计算的技术能力？
函数计算的技术可以分成两个部分去看：
第一部分是服务的内核：包括资源动态的调度，用户函数的隔离运行，还有自动的负载均衡和流控，这是后台必须要具备的能力。
第二部分是服务的外延：当提供成计算服务供其他人去使用时，平台需要为用户提供优秀的debugging和tracing能力、函数依赖的管理、持续集成持续发布等功能。
对于内核部分的技术，包括资源的调度，程序运行的隔离等等，阿里云飞天计算平台有长期的积累。相对而言，外延部分比较新；业界也处于早期阶段，目前尚没有统一的厂商构建标准，还有很大的发展空间。打造好的服务外延的出发点是，怎么可以让用户基于函数计算构建复杂的Serverless应用，只有解决了这个本质问题，函数计算才能变成主流的通用计算服务。
除了函数计算技术本身，，函数计算的产品生态非常重要，函数计算本身是事件、消息和数据驱动的计算模式，还需要其他云服务与之协同配合应用于不同的场景中，比如OSS的多媒体数据写入和访问、LogService的日志、API Gateway的请求、消息服务的消息到达，这些都为函数计算的技术生态提供了协作关系。此外，对于数据处理方案，不瞋称用户也可以接入第三方的数据处理服务。
按需付费，如何面对“缺斤短两”的问题？
Serverless计算的一个核心优势是按需付费。因此关键的问题是，如何让用户能很容易预估费用？如何证明费用的真实性？
不瞋称，云服务的费用问题不是新问题，Serverless服务需要给用户提供简洁的，易于预估的费用模型，非常丰富的计量指标和细粒度的账单，让用户能够推敲验证。
此外，好的产品设计还需要考虑到如何帮用户规避错误。有时候用户实现的函数逻辑可能会有bug，导致突然间错误消耗大量资源，比如在具有巨大计算能力的云平台上写出了无限递归调用的函数；在这个方面，不瞋称阿里云也有考量，函数计算允许用户设置费用上限，并且提供丰富的监控和报警功能，帮助用户减少因为自身失误带来的资源过度使用的损失。
函数计算产品短期和长期的目标是什么？
阿里云的FaaS产品与业界相比的差异在哪里？坦白讲，目前还在发展的初期阶段，未来则会根据用户场景进行不断优化。目前使用函数计算的用户来自于电商、游戏、IoT等领域，用户的主要诉求是可以专注于业务逻辑开发，不再维护后端服务器；此外用户也非常看重按需付费，削峰填谷等特性。
短期主攻数个典型的用户场景，打造出尖锐的用户体验，自下向上的积累理解和经验。阿里云的函数计算目前还只支持Node.js，在多语言支持上有待提高。还有一种做法是去语言化，定一个与语言无关的http交互协议。但是后者的使用门槛稍微高一些：前者是写一个Function，而后者却需要用户实现一个mini web server。
在此基础上，从云发展的宏观角度思考，自上而下地制定中长期目标。持续改进服务的内核和外延能力，让平台变成构建复杂应用的核心计算平台。
还有，如何拓展技术的边界，计算场景是否可以发生在不同的计算环境中，不同的计算介质如FPGA、GPU、边缘节点、端设备。其中边缘节点计算需求在工控领域中尤为突出，比如如何收集偏远地区风力发电站的数据以实现智能化？在恶劣环境下，网络传输并不总是可靠且成本很高，这时就需要在本地对数据进行处理，然后再将提炼的数据传到云端。为什么这种情况函数计算适合？因为它已经脱离了机器概念，抽象出了统一的计算模型去支撑云端和边缘计算。
基于Serverless写的程序，是不需要考虑如何部署、管控和重度运维。用户可以自己在远端的办公室进行调控，比如将某些计算任务部署到边缘节点上，实现和云端类似的监控，在网络良好时，再进行数据的传输。而且在本地对噪声数据进行处理提炼，能有效的降低传输到云端的数据量，大幅降低成本。
Serverless未来光明，但挑战犹在
比起微服务、DevOps，Serverless的落地和流行将更快。
使用函数计算构建Serverless架构，以很高的开发效率去构建一个系统，并且这个系统天然就是实时可伸缩的。对于用户而言，良好落地Serverless的要点主要在于架构设计，用户需要首先理解Serverless，然后从现有的业务中提炼出业务逻辑。即Serverless流行起来难度不在于开发门槛，而在于思维和架构的转变。如果熟知微服务，对Serverless的理解会更加方便。
正如前文所说，Serverless让微服务的实现更轻松，更适应基于微服务的松耦合系统设计。但是反观微服务化和DevOps改造实施起来比较重，技术门槛不低。而Serverless很轻，和微服务的目标趋同，但是发布、运维等环节的云服务化更彻底；用户只需设定资源和发布部署等规则，因此Serverless会更加容易落地。
不过，Serverless对于用户而言，还是很新的概念。纵然DevOps、微服务等已经被广泛认知了，但是全面落地尚且遥远，怎么看待Serverless的推进呢？任何新的概念的落地，本质上都是要和具体业务去结合，去真正解决具体问题。这要取决于，一开发人员对技术的理解度，二是用户在实施中的渐进与积累，三是企业对按需付费的强烈意愿。
没有什么业务需求是空穴来风，也没有什么技术发展是一蹴而就。
本文转自d1net（转载）