无服务器计算可以降低公有云中的应用成本，但企业需要正确的技能才能获得这些，且收获其他收益。
无服务器计算允许组织在更细的颗粒度上构建和部署云应用。与使用单体代码构建的传统应用相比，无服务器应用将工作负载分解为离散功能，它们仅在由某个事件调用或触发时才会运行。
尽管名字被定义为“无服务器”计算，但无服务器计算并不能完全排除服务器的使用。相反，它仅在功能加载并运行时才使用服务器。这最大限度地减少了资源的使用，从而能够在公有云中节省资金。
主要的公有云提供商现在都提供某种形式的无服务器计算，如Amazon Web Services(AWS)Lambda、Microsoft Azure Functions和Google Cloud Functions。下面让我们来仔细看看无服务器计算以及如何充分利用这一新兴技术。
开发人员和管理员需要哪些技能才能使用无服务器计算?
无服务器计算代表了构建和管理应用的完全不同的方式，因此开发人员和云管理员都应该进行调整，以充分利用此技术。
开发人员面临的主要变化是无服务器应用的结构。传统的单体应用通常是通过变量进行数据交换。向微服务的转变推动了这一思想的演进，将软件分解成功能组件，可以独立扩展并使用API来交换数据。无服务器计算更是将其带到极致; 它将软件功能分解为单独的离散功能，企业只在需要时才进行调用。这意味着核心应用可以小得多，并且使用更小和更便宜的云计算实例。
无服务器计算也会影响云管理员。例如，管理员必须监督几十个甚至更多的功能的可用性和性能。这意味着，对于每个功能来说，他们都需要监控性能，排除故障，跟踪使用情况和成本，然后将这些成本纳入到更高层应用的成本中。管理员可以使用其公有云提供商的监控功能，例如Azure Functions的“监视器(Monitor)”页签，来分析和评估每个功能。
管理员还必须实现与开发人员共享持续管理信息的机制。这将允许持续地开发无服务器应用程序来优化性能和成本。
哪些应用最适合无服务器?
无服务器计算最适合于具有轻资源需求，最小化依赖关系，并且不需要延长时间来运行的小型无状态的功能。该功能应该尽快地启动，运行和退出。具有更多资源或时间要求的任务更适合于常规的VM或容器部署。
功能通常对资源，并发和部署规模有所限制，因为云提供商需要快速启动实例，并提供资源来加载和执行功能的代码。例如，AWS Lambda目前允许使用512 MB的临时磁盘容量，1,024个文件描述符，1,024个组合的总进程或线程，以及最大执行时间为300秒。
无服务器应用有助于在公有云中节省资金吗?
与公有云中按需分配的虚拟机实例相比，无服务器计算的一个优点是节省成本——取决于应用的设计。节省的数量取决于每个应用的性质，进行架构和部署的事件驱动的功能数量，以及用户如何调用这些功能。如果大部分应用在事件发生之前都保持空闲状态，那么组织就能够降低成本。
然而，与公有云中的按需分配的虚拟机实例相比，业务并不一定能体会到任何节省。除了那些适用的免费层次之外，其他每个功能的调用都需要花钱。基于功能的应用的成本大致是每个功能的成本之和。每个功能的成本基本上是调用次数乘以每次调用的成本。
然而，假设无服务器应用由50或100个不同的功能组成，它为数十甚至几十万的企业移动用户群提供服务。这将在公有云计费周期的过程中累计起惊人数量的功能调用。这样的应用，相比于设计成更传统的架构而言，设计成无服务器程序可能会花费更多。问题的一部分是不确定性;大多数开发人员不知道功能被调用的频度——这让成本分析变得很困难。
为了预测无服务器应用的成本，请仔细评估功能利用率和用户的基本规模大小。思考应用设计的变化将如何影响这些运营成本。如果开发人员改变应用的设计以减轻某些功能的大量使用，就可能会降低成本。
还有哪些最佳实践?
无服务器计算的概念很引人注目，但开发人员和管理员在采用前应仔细评估一些重要的考量因素：
性能：考虑功能延迟和性能的影响。由于功能在每次执行之前都需要加载，因此会造成响应时间的延迟，虽然很小但不可避免。延迟也可能随着流量需求的变化而变化。这些因素可能会降低其对延迟敏感型应用的吸引力。
复杂性：功能会让应用设计，性能监控和故障排除变得复杂;管理员必须监视几十甚至几百个单独的功能。考虑采用比现有的更细颗粒度的管理工具和策略。
快速，紧密和无状态：功能的快速，特设性质使其适用于无状态的软件设计。如果在功能之间处理或传递状态，则需要将状态分配给数据而不是功能。但是，功能之间传递的消息的大小通常会受到严格限制。
应对失败：功能通常依赖于其他功能，存储，后端应用和网络可用性——所有这些都可能会发生故障。设计功能来处理错误，在后续运行中完成未完成的任务，并确保功能尽可能得完善健壮。
便携性：公有云供应商之间的功能通常不可移植。AWS Lambda功能在Azure或Google中不起作用，反之亦然。这可能会导致供应商锁定并使多云规划变得复杂。
