关于无服务器架构,可以忽略的三种常见观点

F5生态系统 | 2019年1月03日

无服务器架构正日益受到云计算领域的青睐。过去一年中,至少有三分之一(33%)的组织部署了无服务器应用。(来源:Digital Ocean 2018年第2季度开发者调查)在参与CNCF 2018年调查的受访者中,38%表示目前正在使用无服务器技术,另有26%计划在未来12个月内采用该技术。

这一新兴的云选项不仅发展迅速,还经常被误解,甚至被赋予近乎神奇的能力,仿佛既能降低成本、缩短价值实现时间,还能把早餐送到床边。

更令人困惑的是,功能即服务(FaaS)常常与无服务器计算混为一谈。两者并不相同,这也导致人们对一般企业如何利用这项颇具吸引力的新技术产生其他误解。

今天,我们将澄清过去6个月里客户和会议参与者反复提到的3个常见误区。只有了解这项技术是什么、不是什么,才能判断它是否值得花时间探索。

首先,我们来厘清无服务器计算与FaaS之间的区别。

误区:Serverless === FaaS

Serverless是一种系统、一种平台,也是一种框架。更准确地说,它是一种即时弹性执行环境。Serverless旨在通过在某种隔离环境中按需执行某些内容,消除运维开销和阻碍。这种隔离环境通常是容器,但也有使用虚拟机和WebAssembly的产品。为简洁起见,下文将使用“容器”统称这三种环境。

无服务器架构是事件驱动的。这意味着,资源预置和处理由某种触发器启动,例如收到API请求或时间到达14:07。触发事件可以自动生成,也可以由交互操作产生,例如点击Web应用表单中的按钮。在无服务器模型中,事件会触发执行“容器”中存在的某个对象that exists in a "container"。

NETOPS 注意事项:F5 iRule熟悉相关知识的读者可以将无服务器事件与iRule事件联系起来,例如“HTTP_REQUEST”和“HTTP_RESPONSE”。两者的模型大致相同:发生事件时,执行一些代码。遗憾的是,大多数无服务器框架不支持TCL,但通常支持node.js和Python。

“容器”通常会在收到请求时从存储库加载(冷启动),也可能已处于待命状态(热启动)。“容器”中的内容会执行,并向触发其运行的系统返回响应。

无服务器架构背后的商业模式通常是仅按所消耗的资源付费,计费范围仅限于“容器”执行期间。其运维模式旨在免除环境运维工作,让人们专注于构建“某种东西”。

这就是无服务器。函数即服务是无服务器的一种特定应用,它将“某种东西”定义为“一个函数”。

FaaS让我们能够将始于微服务的应用分解推进到最终形态,即函数。

了解无服务器计算与函数即服务之间的区别,是澄清下一个误区的关键。

误区:必须重构

由于FaaS与Serverless经常被混为一谈,市场上许多人误以为,要利用Serverless的优势,就必须将应用重构为多个组成函数。

Serverless无需重构应用,也无需在函数层面设计新应用。Serverless同样可以执行包含任何类型应用、进程、守护进程或函数的“容器”。只要将其打包到“容器”中并且可以调用,就能在Serverless环境中执行。

我也见过一些成功案例,它们利用Serverless扩展(现代化改造)现有应用架构。注册、订单履行及其他非关键路径流程的批处理和带外处理,可以采用Serverless模式实现,而无需彻底重构传统应用。已经为此采用外部API集成的应用会更容易适配Serverless。成熟的客户端-服务器应用几乎肯定需要进行一些修改才能利用Serverless,但工作量远小于彻底重构。

仅偶尔执行的流程(由不定期或不可预测的特定事件触发)也可能非常适合采用Serverless。与让“容器”持续运行相比,定期启动“容器”来执行任务的成本效益要高得多。这一点对公有云和本地部署的Serverless都适用。

这就引出了第三个误区,重点在于部署位置。

误区:无服务器架构无法部署在本地

我听过各地的IT从业者和评论人士提出这种说法。这显然是错误的,就像认为无法在本地运行“云”一样。实际上完全可以,而且根据《Developer Economics State of the Developer Nation》,相当一部分组织已经在这样做。

规模更大、使用更频繁的应用也能受益于高效扩展:只需为应用中承受高负载的特定部分所需的额外资源付费,也更容易识别并优化这些部分。这项优势可能是目前17%的无服务器计算采用者选择在自有数据中心运行解决方案的主要原因。

本地部署无服务器架构带来的成本效益提升并不局限于可扩展性。对于使用频率不高的应用,复用相同资源并在这些应用之间共享资源也能带来显著价值。无服务器架构还可利用其核心的事件驱动特性,为应用和运维功能附加增值能力。在尚未认识到无服务器架构的优势远不止消除开发人员日常工作中的运维阻力之前,不应轻易否定其本地部署价值。这无疑是一项优势,但并非唯一优势,也绝非组织尝试在本地部署无服务器架构的唯一原因。

事实上,无服务器架构可以在本地部署,而且已经有了实际应用。上述CNCF调查深入分析了广受欢迎的“可安装”无服务器平台:

还有更多,而且随着这项技术加速发展,必将涌现出更多相关项目。

随着各组织不断试验、探索和评估无服务器技术与函数即服务(FaaS),以确定其是否适用于新的云原生应用和现代化改造,这两项技术的采用率都在快速增长。识别并摒弃常见误解,是判断这些技术是否适合贵组织应用的重要第一步。

分享

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

SOAS 2025:目标不一致,结果难出色
F5生态系统 | 2025/05/13

SOAS 2025:目标不一致,结果难出色

AI部署缺乏协调会导致效率低下。了解如何协调安全、自动化和部署策略,充分释放AI潜力。

AI应用的应用交付与安全:驾驭现代AI架构
F5生态系统 | 2024/08/22

AI应用的应用交付与安全:驾驭现代AI架构

了解生成式AI应用和API安全如何塑造现代应用交付与安全。

借助多云网络简化超级云
F5生态系统 | 2023/09/13

借助多云网络简化超级云

超级云不只是一个流行词。它代表着一种简化愿景,以多云网络为起点,支持跨云提供商的混合IT。

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素
F5生态系统 | 2023/03/15

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素

多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联,为解决当今混合IT面临的挑战提供支持,因而备受业界关注。

运营演进的必要性
F5生态系统 | 2022/01/11

运营演进的必要性

在数字化成为默认模式的世界中,运维仍然过度依赖人工方式,需要不断演进,才能支持自适应应用。这一演进要求整个IT体系进行重大变革,并具备由AI赋能的自适应能力,以保持可用性、优化性能并保障安全。

多云并非简单使用多个云:让跨云衔接更轻松
F5生态系统 | 2021/10/07

多云并非简单使用多个云:让跨云衔接更轻松

随着企业转向互联云战略,工作负载的管理和保护变得日益复杂。了解F5如何满足市场对多云网络新方法的需求。