首先无服务器这个概念并不代表该技术的实际状态。因为还有一台服务器，但你只是不需要购买，管理或维护它。你将所有服务器管理外包给其他人，在你的云基础架构中添加抽象级别。对于开发人员来说，这意味着最终推动了服务器后台配置的能力和创建应用程序之间更加友好。对于企业来说，带来了更快的应用上市时间，以及专注于开发和部署的应用程序，而不是如何管理服务器的后台配置。基本上，无服务器方法是由业务驱动的，第三方处理你的技术问题，而用户自己专注于交付。
现在，你可能会想：“我们已经将我们的基础架构放在了云中，并且不拥有任何硬件。那么，这跟无服务器计算有什么不同呢？”
使用传统的云模式（通常称为Cloud 1.0），只需将存储和网络移动到云中，但仍需通过虚拟机（VM）远程访问和监控它。无服务器的方法将它带到了另一个级别。程序员选择编写代码的环境（Node.js.Python，C＃等），并上传代码文件，然后由系统自动部署。通过使用供应商自己的生态系统，你可以轻松描述这些服务如何通信以及他们可以访问数据的位置。这是一种近乎NoOps的方法，大多数Ops都是外包给供应商的。
图：应用程序部署如何随着云发展而变化
为了更深入地了解它如何工作，以及它带来的好处，我们首先描述一下无服务器架构的一些定义特征。
无服务器的特征
Function-as-a-Service
无服务器计算的另一个名称是功能即服务（FaaS），指的是开发人员将代码组装到称为功能的构建块中的方式。这与微服务非常相似，在这种微服务中，一个大型代码块被分割成小的，可管理的元素，可以分别并行地进行缩放和更新。然而，FaaS通过进一步分解来将其提升到一个新的水平。
图：微服务与无服务器：相同的概念，不同的实现
事件驱动的编程
你显然不希望家里安装的摄像头记录你的街道24/7发生的一切。这就是为什么当我们不在家时，我们使用激活的摄像头来检测可疑行为。无服务器架构的工作原理类似：就像运动传感器一样，它只在特定的预编程事件触发时才起作用。无服务器是无状态的，这意味着它只执行一个任务，不存储或重用请求。
可伸缩服务
无服务器方法非常灵活，是扩展应用程序的理想选择。FaaS供应商将你的每个功能都分别放在不同的容器中运行。这使你可以无限制地自动调整它们。这是无服务器和传统云之间的另一个区别。在这里你不必购买预订的资源量，你可以尽可能地灵活。
每次调用帐单
在传统的云模式中，你需要服务器随时准备处理请求。不管实际使用的CPU时间和内存如何，持续的服务器可用性都会导致每月大量的后端成本。或者，无服务器供应商允许你为每个请求支付一小部分的费用，这意味着你的成本仅取决于你本月的流量。
AWS Lambda，微软Azure Functions，Google Cloud Functions和IBM Bluemix OpenWhisk等功能即服务供应商提供了类似的解决方案。谈到定价，他们在预算上很容易：高达100万的请求是免费的，给你一个很好的起点。差异主要在于社区支持和支持语言的可用性，这使得选择更具个性化。
无服务器计算的优点
在工程方面，无服务器的好处是显而易见的。这是一种简化的开发方法，消除了复杂的层面，简化了工程设计。但是商业方面呢？你如何说服利益相关者，证明FaaS是未来方向？
比传统云便宜
正如我们所提到的，FaaS允许你为每个请求支付一小部分的费用。如果你是一家创业公司，那么你几乎可以免费创建一个MVP，并且轻松进入市场，而不需要处理大量的账单以获得最小的流量。
可扩展
每个人都想要构建下一个优步，但是你会冒险调配基础设施以防万一？无服务器，你不必做出选择，但你仍然可以为任何增长量做好准备。
降低人力资源成本
就像你不必花费数百或数千美元购买硬件一样，你可以停止为工程师付费来维护它。
能够专注于用户体验
允许公司投入更多时间和资源来开发和改进面向客户的功能。
无服务器计算的缺点
供应商锁定
当你让供应商控制你的运维时，你必须按照他们的规则来玩。如果你已将应用程序设置到Lambda上，将应用程序移植到Azure也不是一件容易的事情。同样的问题涉及编程语言：现在只有Node.js和Python开发人员可以自由选择现有的无服务器选项。
学习曲线
尽管有全面的文档和社区资源，你可能很快就会发现FaaS工具的学习曲线非常陡峭。此外，为了平滑的迁移到无服务器，你可能希望将你的“庞然大物”分为微服务，这是另一个需要解决的复杂任务。这就是为什么最好从无服务器工具经验丰富的专业人士那里获得帮助。
不适合长期任务
Lambda给你五分钟执行任务，如果花费更长时间，你将不得不调用另一个函数。无服务器非常适用于发送电子邮件等短实时或接近实时的流程。但长时间操作（如上传视频文件）需要额外的FaaS功能，或者更适合“服务器”的架构。
无服务器架构用例
目前，大多数技术采用者都是初创公司，他们寻求平滑扩展和降低入口障碍的可能性。无服务器也是一种完美的方法，适用于不连续运行，但具有安静时段和高峰流量的应用程序。
物联网应用
无服务器方法的实时响应特性非常适合物联网用例。上面已经提到的激活摄像头，以及对天气，温度或健康状况变化作出反应的应用程序，对于无服务器用例而言是完美的，它不会让你的服务全天候闲置。
虚拟助理和聊天机器人
希望得到即时响应，这就是无服务器数据处理速度更快的原因。随着你的应用程序从一百个增加到几千个用户，你的处理时间也应该保持不变，FaaS可以自动处理。
图像丰富的应用
为了保持良好的用户体验，开发人员必须为不同的屏幕尺寸提供多个版本的相同图像，从台式机到平板电脑和智能手机。这显著减少了加载时间。然而，来自AWS和Google的工具将自动优化你的图像以满足任何需求，使其成为适合图像大量应用的完美解决方案。
敏捷和持续集成管道
仅当某个事件被触发时才运行代码的想法完全符合敏捷或持续集成原则。将代码分离成函数还有助于纠正错误和发送更新。无服务器是实现最大自动化和快速部署过程的整体友好方式。
无服务器架构选型
随着各种无服务器平台的发展，选型时需要注意哪些重要事项？该如何斟酌无服务器平台的重要功能和监控的注意事项。
开源无服务器架构
OpenFaaS，Kubeless，Fn，OpenWhisk等等，它们都是目前热门的无服务架构解决方案。大多数开源产品都在Kubernetes上运行。它们可以运行在云中的Kubernetes服务（KaaS）或你的内部Kubernetes集群上。如果部署在内部的集群上，运行无服务器的平台，看上去会不会有点矛盾？
所有这些开源项目仍处于早期阶段。目前还没有特别明显的区分出哪个解决方案最受欢迎。
对这些开源平台的运行时（runtime）支持，包含广泛的流行语言以及构建自定义运行时的能力。每个功能通常部署为Docker容器。只要该容器符合接口要求，它就会运行。
对于所有这些无服务器平台，可观察性至关重要，因为它们在已经非常复杂的平台Kubernetes之上增加了另一层复杂性。无服务器平台和Kubernetes的顺利运行对托管功能的顺利运行至关重要。其中一些项目已经考虑了可观察性，并提供了Prometheus度量端点。Fn还包括Zipkin和Jaeger的Open Tracing实现。
云提供商的无服务器架构
AWS Lambda，Google Cloud Functions，微软Azure Function Apps，最近IBM已经通过托管版本的OpenWhisk进入了这个领域。其中AWS Lambda时间最长，是最成熟的产品；它已经在运行亚马逊Alexa服务的重要部分。
所有这些托管产品都提供了与云中托管的功能相同的基本功能，在不使用它们时不需要任何费用，并且在执行时按微秒计费。所有平台都提供一个Web用户界面和CLI工具来管理这些功能。可以将触发功能引入云平台的其他服务，AWS拥有目前最丰富的可用服务。
所有平台都提供基本的监控和日志汇总功能。AWS Lambda是利用X-Ray提供可观察性的领导者，它提供跨各种AWS服务的端到端跟踪。Google的Stackdriver追踪功能目前仅可用作预览版本，并且尚不支持自动追踪无服务器功能。微软Azure和IBM OpenWhisk不提供任何跟踪功能。
运行异构服务
有了如此多的无服务器平台可供选择，问题是哪一个最适合你的需求？好消息是你不必做出选择。无服务器项目提供了用于管理功能的通用工具和用于将事件映射到功能的事件网关。
管理工具
使用一个定义文件和一个命令行工具，可以将无服务器功能部署到这些提供程序支持的任何语言运行时的许多提供程序中。这种自动化水平使得从一个供应商到另一个供应商的功能不那么痛苦。但是，函数并不是真正的可移植的，因为目前没有任何函数入口点标准，返回数据或者在运行时可用的库。
事件网关
虽然每个云提供商都有自己的API网关，但它们通常不会为多种提供商解决方案提供多少便利。无服务器事件网关提供了供应商不可知的解决方案，既可以作为服务提供，也可以作为Docker镜像在你想要的位置运行。由于此API网关与任何供应商无关，因此可以接收来自任何提供商或外部来源的事件，并路由到任何其他提供商或外部目的地。
图：无服务器网关流程。
利用第三方网关可以用最少的配置交换无服务器端点。
例如，客户端通过HTTP调用事件网关，事件最初路由到AWS Lambda并进行处理。通过简单的配置更改，可以将相同的客户端呼叫路由到Google Cloud Functions进行处理；客户端不需要重新配置。
无服务器监控
观察无服务器框架及其运行功能的性能对于生产环境至关重要。商业产品的领先者是亚马逊与CloudWatch和X-Ray。对于开源，领导者是Fn，因为它已经包括Prometheus指标和Jaeger/Zipkin跟踪。
将开源无服务器平台部署到Kubernetes会创建大量Deployment，Pod和Container组件。
上面的例子显示了一个托管的函数OpenFaaS。大多数开源平台的当前实现技术是为每个函数使用单独的Docker镜像，从而导致在Kubernetes上单独部署。
无服务器功能容器。
凭借Instana对Kubernetes集群监控的支持，所有这些部署都会自动检测和监控。随着通过这些平台的追踪标准的发展，Instana将采用它们来提供全自动分布式追踪。
无服务器是未来吗？
走向无服务器不仅仅意味着技术变革，而且意味着业务变革。对于许多在传统基础设施上运行的公司而言，迁移将是痛苦的，并不具有成本效益。当你已经建立了工作流程时，采用FaaS工具来彻底摆脱服务器管理是很难证明的。另外，无服务器远非主流，尽管它朝着这个方向发展并且非常快。
作为一个非常有前途的方向，有许多产品并没有真正的标准。将应用程序碎片化为分散功能确实为CI/CD和计算资源效率提供了优势，但代价是更高的复杂性和与平台绑定的风险。
开源产品的开发仍处于早期阶段，可靠性不符合生产标准。例如，我尝试使用提供的helm文件将一些项目部署到Google Kubernetes Engine，却只有一个项目成功部署。
Gartner预测，在2017年的新兴技术炒作周期中，无服务器/FaaS将在未来2-5年内达到如机器学习，VR和物联网的生产力水平。该技术已经可用，而真正的挑战是确定可能用例的广度，并等待来自所有供应商的更大的编程语言和功能支持。
