mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
94 lines
7.6 KiB
Markdown
94 lines
7.6 KiB
Markdown
[#]: subject: "Should Businesses Opt for Serverless Computing?"
|
||
[#]: via: "https://www.opensourceforu.com/2021/12/should-businesses-opt-for-serverless-computing/"
|
||
[#]: author: "Krishna Mohan Koyya https://www.opensourceforu.com/author/krishna-mohan-koyya/"
|
||
[#]: collector: "lkxed"
|
||
[#]: translator: "lkxed"
|
||
[#]: reviewer: "wxy"
|
||
[#]: publisher: "wxy"
|
||
[#]: url: "https://linux.cn/article-14781-1.html"
|
||
|
||
企业应该选择无服务器计算吗？
|
||
======
|
||
|
||
> 无服务器计算将服务器从规划中移除，使企业能够专注于应用功能。那么，企业是不是都应该选择无服务器计算呢？让我们来探究一下吧！
|
||
|
||
|
||
|
||
直至不久之前，几乎每个产品经理都会将他/她的工程资源，分成两个独立的团队 —— 开发团队和运维团队。开发团队通常参与编码、测试和构建应用功能，而运维团队负责应用程序的交付、部署和运行维护。
|
||
|
||
当开发团队构建电商应用时，运维团队会搭建好服务器来托管该应用。搭建服务器涉及到许多方面，其中包括：
|
||
|
||
* 选择合适的硬件和操作系统
|
||
* 应用所需的补丁集
|
||
* 搭建所需服务器环境，如 JDK、Python、Tomcat、NodeJS 等
|
||
* 部署、配置和提供实际的应用
|
||
* 打开并固定合适的端口
|
||
* 搭建所需的数据库引擎
|
||
|
||
……这个名单还在继续。
|
||
|
||
除此之外，管理人员还对容量规划感到头疼。毕竟，任何重要应用都应始终保持 100% 可用、可靠且可扩展。这需要对硬件进行最佳投资。众所周知，在一些关键时期，硬件短缺会导致业务损失，而硬件冗余又会损害利润。因此，无论应用是针对本地数据中心，还是针对云基础架构，容量规划都是至关重要的。到目前为止，很明显，企业不仅在功能构建上投入了大量的精力，还在功能交付上也花费了大量的时间。
|
||
|
||
<ruby>无服务器计算<rt>Serverless computing</rt></ruby>旨在提供一种无缝的方式来交付功能，而无需担心服务器的设置和维护。换句话说，无服务器计算平台提供了一个“<ruby>即用型<rt>ready-to-use</rt></ruby>”环境，企业可以尽快将应用程序构建和部署为一些较小的功能。这就是为什么这种方法被称为“<ruby>功能即服务<rt>Function as a Service</rt></ruby>”（FaaS）。
|
||
|
||
请记住，无服务器计算中仍然存在服务器，但它由 AWS、微软和谷歌等 FaaS 供应商负责。
|
||
|
||
例如，AWS 以 “Lambda 函数”的形式提供了一个无服务器计算环境。开发人员可以选择将应用程序构建为一组 Lambda 函数，这些函数可以用 NodeJS、Java、Python 和其他一些语言编写。AWS 提供了一个现成的环境来部署这些函数。它还提供了即用型数据库服务器、文件服务器、应用程序网关和身份验证服务器等。
|
||
|
||
同样，微软 Azure 也提供了一个环境，它可以用 C# 等语言构建和部署 Azure 函数。
|
||
|
||
### 为什么选择无服务器？
|
||
|
||
有两个主要因素推动了无服务器计算的普及。
|
||
|
||
#### 1、即用型环境
|
||
|
||
显然，这是无服务器计算的最大卖点。企业无需提前采购/预订硬件或实例，也无需操心许可证，以及设置和配置服务器。他们不需要为扩大和缩小规模而烦恼。所有这些都由 FaaS 供应商负责。
|
||
|
||
#### 2、最优成本
|
||
|
||
由于 FaaS 供应商总是根据环境的利用率向客户收费（按使用付费模式），因此企业无需担心前期成本和资源浪费。例如，AWS 根据 Lambda 函数接收的请求数量、在数据表上运行的查询数量等指标来向客户端收费。
|
||
|
||
### 无服务器计算的挑战
|
||
|
||
与任何其他方法一样，无服务器计算也不是每个人都可以盲目遵循的完美方法。它本身也有一系列限制。以下是其中的几个。
|
||
|
||
#### 1、供应商锁定
|
||
|
||
当使用无服务器计算时，第一个也是最重要的问题就是，Lambda 或 Azure 等函数将使用供应商提供的 API 来编写。例如，使用 AWS Lambda API 编写的函数无法部署到 Google Cloud 中，反之亦然。因此，无服务器计算迫使企业在许多年内，只能使用同一家供应商。并且，应用的成功或失败不仅取决于它的功能，还取决于供应商在性能等方面的能力。
|
||
|
||
#### 2、编程语言
|
||
|
||
没有哪家无服务器计算平台支持所有的编程语言。此外，对于它支持的编程语言，它也可能不支持其所有版本。这样一来，应用开发团队只能选择供应商提供的语言。就团队的能力而言，这可能是非常关键的。
|
||
|
||
#### 3、最优成本，真的吗？
|
||
|
||
其实也不一定，这一切都取决于资源的使用情况。如果你的应用正在承受巨大的负载，例如每秒数百万个请求，那么你所支付的费用可能会过高。在这样的规模下，在本地或云端拥有自己的服务器可能会更便宜。这并不意味着具有 Web 规模的应用不适合用无服务器计算。归根结底，它还是取决于你的平台的构建方式，以及你与供应商签署的协议。
|
||
|
||
#### 4、生态系统
|
||
|
||
没有哪个应用是为了一个孤立的环境而编写的。它总是需要其他组件，如数据存储、数据库、安全引擎、网关、消息服务器、队列、缓存等。每个平台都提供自己的一组此类工具。例如，AWS 提供了 Dynamo DB 作为其 NoSQL 解决方案之一。显然，其他供应商也提供了自己的 NoSQL 解决方案。因此，团队又会被迫地基于所选平台来构建应用程序。尽管大多数商业 FaaS 供应商都为特定需求提供了多个组件，但并非每个组件都可能是同类型中最佳的。
|
||
|
||
### 为什么不考虑容器呢？
|
||
|
||
在过去十年中，我们中的许多人都迁移到了容器化部署模型，因为它们为昂贵的物理机或虚拟机提供了一种轻量级的替代方案。有了 Kubernetes 等编排工具后，我们乐于部署容器化应用，同时也满足了 Web 规模的要求。容器提供了与底层环境一定程度的隔离，这使得部署相对容易。但是，我们仍然需要在硬件（本地或云）、许可证、网络、配置等方面进行投资，这需要具有前瞻性的规划、合适的技术能力和仔细的监控。无服务器计算，尽管它也有自己的优点和缺点，但它让我们把这些责任也摆脱了。
|
||
|
||
### 展望未来
|
||
|
||
我们正处于持续开发、持续集成和持续部署的时代。每个企业都面临着竞争。产品<ruby>上市时间<rt>Time to market</rt></ruby>（TTM）在吸引客户、留住客户这两个方面，发挥着重要作用。在这种背景下，企业喜欢花更多时间来尽可能快地推出功能，而不是在部署和维护的细节上苦苦挣扎。无服务器计算有可能满足这些需求。大玩家们正在投入巨额资金，以使 FaaS 尽可能地无缝且经济。无服务器计算的未来看起来是一片光明。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://www.opensourceforu.com/2021/12/should-businesses-opt-for-serverless-computing/
|
||
|
||
作者：[Krishna Mohan Koyya][a]
|
||
选题：[lkxed][b]
|
||
译者：[lkxed](https://github.com/lkxed)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://www.opensourceforu.com/author/krishna-mohan-koyya/
|
||
[b]: https://github.com/lkxed
|
||
[1]: https://www.opensourceforu.com/wp-content/uploads/2021/10/Severless-Cloud-Computing-Featured-image-OSFY-Oct-2021.jpg
|