在每天发送超过15亿条信息、每月与超过10亿消费者互动的过程中，Braze公司使用了大量的云基础设施。但是Braze的业务是不可预测的，因此对计算资源的需求可能会随着必须转换的数据量大幅波动，以支持客户的个性化通信需求。
Braze公司DevOps和安全主管Sal Poliandro III说：“有时候我们可能有100台服务器在运行，也有的时候可能有1000台。” Braze曾经根据一系列指标来扩展其云基础设施，而这些指标最终支持形成了有根据的最佳猜测。然后，Braze发现了亚马逊的无服务器计算平台Lambda。
现在，这个过程完全自动化了。算法确定他们需要多少容量，然后启动一个功能，该功能可以触及其基础设施合作伙伴并立即进行扩展。“过去我们常常根据峰值负荷进行扩展。而有了无服务器技术，我们就不必担心这一点了，” ”Poliandro说。对于一个典型的开发团队，他估计该过程至少比手动配置服务器快了10倍。
Braze只是越来越多追逐这个云领域、甚至是IT领域最热门趋势的公司之一。无服务器计算——下面包含功能即服务等子集——通过摆脱配置基础设施、同时要大幅削减成本的这些苦差事，来吸引开发者和首席信息官的注意力。
有些人认为，无服务器将最终成为大多数软件构建的一种方式。风险投资公司Mayfield Fund管理合伙人Navin Chaddha说：“这种底层技术将为重新定义完整的应用堆栈、软件编写方式、应用程序构建方式创造机会。”
狂热者们可能会领先一步。毕竟，无服务器计算还没有走出孵化阶段。但令人兴奋的是，早期采用者的反馈令人鼓舞。
Cloudability对1500个组织的云使用情况进行了分析，发现2017年第四季度无服务器平台的使用量增长了7倍多，不过基数还比较小。RightScale报告称，无服务器技术是2017年1000名受访的IT专业人员认为增长最快的扩展云服务，采用率从12%增长到21%。
不仅是初创公司，还有大量网站。AWS Lambda及相关无服务器服务总经理Tim Wagner表示，Lambda增长最快的用户群中包括CapitalOne、Hearst和Financial Industry Regulatory Authority等大型企业。
事实上，一些企业已经开始将无服务器技术推向主流甚至是前沿计算领域。例如，抵押贷款融资公司Federal National Mortgage Association(Fannie Mae)正在将其风险分析模拟从自己的服务器转移到Lambda，创造了所谓的金融行业第一个无服务器高性能计算平台。
那些尚未加入的软件开发人员正在争先恐后地追赶上来，那些瞄准下一代关键技术的大型科技公司也在关注这些热门趋势。例如下周在旧金山举行的Google Cloud Next大会上，无服务器将成为19个分会场主题之一。
“无服务器计算不仅将从根本上改变后端计算的经济性，也将成为分布式计算未来的核心，”微软首席执行官Satya Nadella在去年的微软Build大会上这样表示。
为你免除烦恼
简而言之，无服务器技术无需在每次运行程序时设置服务器和软件。相反，各种功能会根据事件自动执行，无论是由人还是由程序触发。
“无服务器”这个词实际上有些用词不当，因为仍然是需要服务器来执行功能的。但是，与设置虚拟服务器或使用软件模拟的计算机所花费数小时或数天相比，该过程可以在几毫秒内完成。因此，无服务器应用可以以非常低的成本几乎无限扩展，因为客户只在使用该功能时付费，而无需在服务器空间时间内付费。
相比之下，部署传统集成应用的过程需要分配基础设施，如CPU、内存和存储，以及一套平台软件。即使应用仅偶尔使用，这些资源仍然必须保持随时可用。过度配置会增加成本、浪费容量并导致“服务器无序扩张”——在这种情况下IT部门要为很少使用或者被遗忘了的云实例支付费用。
在无服务器的场景中，开发人员将应用构建为小块代码(或者功能)的集合，这些代码或功能以协调的方式即时调配。这意味着没有浪费、低开销、快速可扩展来满足容量需求。
移动计算最近推动着人们对无服务器领域的关注，因为许多移动应用非常适合无服务器设计。例如一位智能手机用户查找当地天气预报，或者某个足球场的方向，这些查询可以封装并保存在云中，以便在必要时进行调用。程序只是将参数(例如人的位置和目的地)传递给服务器，服务器返回单个目标结果。
无服务器技术还在一些更为日常的场景发挥着作用。例如，当用户使用新照片更新在线个人资料时，无服务器功能可以自动将照片复制到其他地方。或者，将Excel文件上载到数据库的用户可以触发无服务器功能，将文件转换为JavaScript Object Notation格式，以便存储在数据湖中。
无服务器减轻了Braze等公司在规划不可预测的使用场景时经常遇到的麻烦。这使得无服务器成为新闻组织的一个很好的模式，因为他们看到，当有重要赛事或者有球队进入季后赛时球迷活动激增导致流量峰值的出现，很多新闻组织只会简单地分配资源来应对高峰期，为那些未被使用的资源支付费用。
十年变迁
无服务器这一概念并不新鲜。谷歌的App Engine在2008年就具有了计量收费的功能。但直到2014年亚马逊推出Lambda，这一概念才开始流行起来。其他云服务提供商纷纷效仿，包括拥有Cloud Functions的谷歌、有Azure云功能的微软、以及有OpenWhisk的IBM。在此期间，商业和开源的产品及服务这一庞大生态系统已经蓬勃发展起来，其中也包括内部部署的选项。
无服务器应用的分布式特性是最有趣的特点之一。无服务器代码不一定比传统代码运行得更快，但它可以分布在网络上以便并行执行。例如，谷歌的BigQuery分析数据仓库将查询分成几个部分，并在服务器可用的任何地方处理这些查询。
这意味着相比单线程引擎处理来说，这么做的处理速度要快上几个数量。分布式引擎在使用资源的方式上也可以更加灵活和具有可扩展性，因为它可以在任何地方触发功能。水平扩展是自动的、弹性的并且由提供者管理的。
Google Cloud开发人员Kelsey Hightower表示：“计算机的最终目标就像计算器：我希望能够拥有一个非常简单的界面，计算机应该给我一个答案。我们会一直做下去，直到最终的体验变成‘这是我的应用，为我运行的应用。’”
那为什么这项技术还没有风靡世界呢?嗯，首先，它仍然处于早期阶段。“大多数客户都将无服务器技术用于非常具体的解决方案中，例如事件处理和数据采集，大规模部署还没有真正开始，”New Relic公司战略架构高级主管Lee Atchison说道。
另一个原因是无服务器模型的结构是有局限性的，目前是限制于一组有限的应用中。“我认为很少有公司会把赌注全部压在无服务器上，你的IT部门可以采取混搭的方式，” Red Hat产品管理高级总监Rich Sharples这样表示。无服务器是一种很好的快速执行简单任务的方式，但缺乏统一化的、微服务平台提供的一些关键控制功能。
Gartner技术和服务提供商集团研究主管Craig Lowery更为乐观一些。“人们不理解无服务器技术，所以将其归类成一个利基市场。”Gartner研究了五家公司，这五家公司都在沿着无服务器学习曲线向上攀升，并发现一旦他们放弃了开发软件的传统规范，所有公司都会成为颠覆者。“一旦他们放下以前那些期望，他们就能够实现这些好处。”
AWS首席执行官Andy Jassy去年表示，假如今年创建亚马逊公司的话，那么就会建立在无服务器平台上——他们对这项技术的快速采用感到惊讶，即使在大型企业中也是如此。
“我们有很多企业客户，我们原本认为他们不会是第一批采用Lambda的企业客户，”AWS首席信息安全官办公室主任Mark Ryland上周在纽约举行的AWS峰会上表示。“但是因为他们正在做重大的应用重建，他们说，‘我为什么要选择容器?我可以构建一个功能正常的应用。’”
无状态和事件驱动
无服务器计算有两个显着特征，既有强大的吸引力，又面临着更广泛采用的障碍。
首先，无服务器功能是无状态的，这意味着没有用于交互的上下文。它们不存储历史记录，因此仅使用随附的信息处理每个请求。“每次都像一块白板，但非常高效，因为你不需要应对重重的复杂应用逻辑，” Wikibon分析师James Kobielus说。
另一个显着特征是无服务器是事件驱动的，意味着会对用户或程序生成的动作做出响应，事件可能包括查询明尼阿波利斯当前温度的请求、搜索引擎查询或数据库记录更新。
事件驱动的应用是非常高效的，因为在不使用的时候不会消耗资源。这种应用编程简单，易于扩展。“你可以设置应用，这样如果有事件进来，那么功能运行起来。如果有一百万个时间进来，你就可以应对一百万个，”Lowery说。但是，并非每个应用都可以被提炼为一系列无状态事件。
综合起来，这些让无服务器计算成为某些请求的理想平台，例如查看美国明尼阿波利斯的热或冷。然而，对于其他例如管理购物车或制作账单来说，并不是那么好用。
Kobelius说：“有人点击‘购买’，整套数据库和运行时功能做定价，最终确定订单，并发送确认。所有必须以严格的方式发生，带有状态和事务流”，这使得它无法与无服务器执行相匹配。
目前尚不清楚是否会有新的工具和扩展程序让无服务器技术在更为传统的应用中变得可行。无状态应用可以扩展或改进以展示有状态的行为，就像容器一样，轻量级虚拟机可以抽象消除底层基础架构的差异。容器也是无状态的，但商业和开源扩展让容器可以用于上下文敏感的应用中。
微软的目标是消除功能即服务和平台即服务之间的界限，让开发人员能够混合搭配各种不同的平台。特别是，微软强调所谓的“虚拟Kubelets”，这个在12月推出的技术能够使容器运行各种功能或完整的应用，但有了微计费和自动基础设施配置，无服务器提供了很多企业客户想要的灵活性。AWS在11月底推出了Fargate，可以在不管理服务器或服务器集群的情况下运行容器。
微软Azure容器项目管理负责人Gabe Monroy在去年12月的KubeCon + CloudNativeCon北美会议上表示：“这实际是最好的无服务器，如果基础设施消失，我们将在基础设施领域开展工作。”
Wikibon的Kobielus甚至认为，区块链这种去中心化的数字记账技术对数据库密集型场景中的无状态来说是一种补充。他说：“你可以随时回滚一个完整叙述，关于谁在什么样的联合框架中调用了什么。”
因此，无服务器的拥护者认为，这项技术有广阔的前景，特别是对于那些有着“提升和转变”心态的企业，他们试图将旧应用转移到一种新模式上，并积极拥抱构建和运行这些应用的新方法。
例如就在几年前，房利美(Fannie Mae)公司运行蒙特卡洛(Monte Carlo)模拟分析其抵押贷款组合的风险。现在，他们正在运行所谓的第一个在金融行业中使用无服务器的高性能计算平台。在大约2000万抵押贷款的模拟中，该系统的工作速度比以前快了4倍多。
“我们认为没有任何固有的技术限制可以阻止任何主要工作负载在Lambda上的使用，”AWS的Gilbert表示，他有趣地称Fannie Mae将无服务器当做“云中的超级计算机”。他说：“无服务器将是最简单、最简单的，对许多客户来说是主流计算的首选方式。”
开发者的爱
无服务器模型有一个优点，不容易被提炼为投资回报指标：开发人员喜欢这项技术。无服务器架构使他们摆脱了基础架构部署的负担，他们只需要编写代码就行了。
Braze的Poliandro说“无服务器技术让我们的应用和运营工程师能够以对他们更有意义的方式思考他们的责任。他们可以更快地部署，不必担心周围的基础设施。”
但是，在无服务器平台上构建应用，需要对开发人员如何考虑执行任何的方式进行重大改变。“选择Lambda意味着要为代码进行重写，”Ryland坦言。
无服务器架构的粉丝说，这种局限性不在于技术，而在于开发集成应用已有60年的历史。 Gartner的Lowery说：“无服务器技术挑战了软件应该如何开发的一些假设和已有的模式。客户看到其中有很多价值，但他们不得不学习一种全新的编程方式。”
针对无状态、以事件驱动的环境进行开发，并不一定比开发单一程序更容易。无服务器架构“将复杂性从应用转移到连接中，”Atchison说。“这不是万能的解决方案，也有自身的问题，也要解决这些问题。”
微软建议，开发人员要熟悉基于事件的异步模式的编程，并学习使用功能协调器(如Durable Functions编程模型和Logic Apps连接器)，创建长时间运行的操作和状态管理。
但是倡导者们说，这些好处值得陡峭的学习曲线，所需要的不仅仅是更多工具，还有更具创造性的软件开发方法。
“大多数应用所做的，绝大多数都可以呈现为无服务器功能，”Kobielus说。容器有助于将功能封装并作为服务提供给用户，它们可以独立扩展。”
传统应用仍然可以通过修改以利用某些无服务器功能。本质上由事件驱动的各种功能是可以与主应用分开封装的。
例如，“随时在数据库或文件系统中创建数据，这是一个事件，”Lowery说。“这意味着你可以将其设置为独立于主程序执行其他操作。这样做让应用生命周期更长，”因为应用可以通过使用应用程序编程接口进行扩展，或者挂接到其他应用中。
企业组织可以调整各个组成部分以便受益于无服务器执行，并分阶段迁移，而不是从头开始重写现有应用。“将新的应用功能作为微服务，将用户界面组件从业务逻辑和数据访问层拆分，并将现有的微服务转换并拆分为无服务器功能，”Simform技术顾问Rohit Akiwatkar这样说道，Simform是一家移动和物联网服务公司，已经围绕服务器做了广泛发布。“随着时间的推移，功能的数量将会增加，开发团队的敏捷性和速度将会提高。”
最佳时机
现在是CIO加入无服务器阵营的时候了吗? Lowery认为是的。“我告诉CIO们，这项技术不会消失，这不是一种流行时尚。企业应该开始让员工熟悉这项技术。”
Simform的Akiwatkar建议采取三个步骤：了解使用无服务器架构的最佳实践;确定高ROI的应用;在低风险环境中尝试无服务器功能。
所有这些让现在成为开发者采用无服务器技术的最佳时机。从容器、微服务到现在的无服务器计算，过去五年在应用的构建和部署方面引入的创新数量比过去20年的总和还多。
在一个极度缺乏人才的经济体中，对下一个重要事件保持谦逊可能是吸引最优秀人才的唯一途径。 “你必须有一个长期采用这项技术的计划，否则你将无法获得所需的人才。开发人员会对这项技术充满期待，”Lowery说。
对于那些仍在努力应对如DevOps等无穷无尽创新(例如云、容器和微服务)的组织来说，无服务器计算似乎又是一个令人头痛的问题。 但在这个所有公司都想成为软件公司的商业世界中，没有跟上这个最新趋势可能会让你犯下存在感减少的错误。
