无服务器应用成主流 零运维代码运行付费

　　无服务器火起来了，包括AWS、Google Cloud、Azure在内的云厂商都在该技术上投入了不少精力，而这也是开发人员的春天，其编好的代码上传到云，无需配置或管理服务器即可运行代码，按照所编好的被管理代码计算时间付费。如果说DevOps（开发运维一体化）是敏捷协作的代表，那么无服务器计算强调的则是NoOps。

无服务器应用成主流 零运维代码运行付费（图片来自Thinkstock）

　　什么是NoOps？当然不是完全放弃运维，而是要突出自动化运维，避免更多的人工干预，与无服务器计算的思路有着异曲同工之妙。既然无法摆脱“显性”的基础设施，干脆就把应用程序从原有的框架中取出来。在一定程度上，算是改变了软件的开发和部署模式，对于开发者来说最直观的影响就是付费。事实上，随着虚拟机转向容器和微服务，这也为无服务器计算概念的推广奠定了基础，带来了更加细分化的需求。

　　根据CNCF的一项数据，无服务器应用正呈现高速增长态势，有38%的企业客户在使用这种技术，较此前提升7%，其中32%的企业采用托管类无服务器平台，6%的企业采用安装类的无服务器平台，另有26%的企业表示要在未来12-18个月内使用该技术。相比之下，未采用无服务器技术的客户比例减少了4%。

　　原有整体交付的方式可以被拆分为单独功能或代码实现，即一段完整的业务流不仅能够体现为一段视频或一幅图片，也可以是一行代码，这些代码形成的片段均可实现完整功能。借助无服务器计算，系统能够自行编排代码片段。应用程序会直接在服务器上运行，几乎所有的管理工作交由服务商来负责，使用者无需进行预置、扩展、维护等操作，即可运行数据库、存储或软件程序。

　　通常理解，无服务器架构包括了FaaS（函数即服务）和BaaS（后端即服务），当然无服务器并不是真的放弃了服务器，只是说客户不用再将过多的精力放在物理机上，对平台的控制力和通用性都要有改进。这种概念在普及的过程中，以AWS为代表的Lambda起到了推动作用，由此也引伸出了FaaS的概念。与已有的体系结构有所区别，无服务器是运行在无状态计算容器内部的，后者可短暂触发事件并由第三方管理，比如AWS。

　　顾名思义，函数即服务就是函数可以当作一个功能，开发者写进配置文件后交给服务器即可运行，这个函数是封装在容器中的，自定义输入函数执行出结果，同时FaaS也不需要对特定框架或库编码。其好处是，编写成本大幅降低了，开发者为执行代码过程中消耗的资源付费就行了。对于业务来说，可以更关注业务本身，不用花费太多注意力在底层资源。

　　无论是虚拟机还是容器，都可以看作是通过代码实现的方案，本质上与无服务器计算并不冲突。操作过程中，开发人员无需考虑选择什么容器，只要安心编写代码，由服务商将片段加以整合管理，节省了软件创建时的付出，让双方做各自擅长的事情，效率更高。在弹性基础架构中，开发者能够将应用“切成”小块通过高度扩展的方式部署。从某种程度上来说，无服务器计算为资源使用提供了新模式，其定位更像是介于IaaS和PaaS之间。

　　计费方面，开发者不用像原来那样为了数分钟或数小时的应用实例支付整套费用，而是只需支付某一段函数运行的几毫秒，这种方式是更精准的按需付费。按照这个逻辑，无服务器计算平台在云端似乎更适用于由众多微服务“拼接”而成的应用。无论是基础设施管理还是应用构建，均节省了不少“无用功”。

　　举个零售门店的例子，以往要想在五分钟内对1万个门店的1万个商品进行预测，动用集群计算的成本会非常高，而Lambda每使用5GB内存的启动价格大约是1美分/次。也就说，其背后把成本的压力给到了亚马逊，方案商则可以把算法集成到容器里，并且做了大量的优化，让整个预测过程在200-300秒内就能完成。

　　目前，涉足无服务器计算的不仅包括亚马逊（AWS Lambda）、微软（Azure Functions）、谷歌（Cloud Functions）、IBM（OpenWhisk）这样的巨头公司，还有Iron.io这样的垂直公司。这些服务各有特色，例如OpenWhisk主打开源，Azure Functions结合了微软IoT、SaaS方案，Iron.io则是希望构建主流公有云和私有云的全平台兼容，确保高度可移植性。

　　无服务器应用的春天来了，开发者有更多的选择可以让代码更有价值，当然背后也离不开云厂商的帮助，只有这样才能改变代码交付、业务实现的方式。