企业应该选择无服务器计算吗？
无服务器计算 无服务器

> 
> 无服务器计算将服务器从规划中移除，使企业能够专注于应用功能。那么，企业是不是都应该选择无服务器计算呢？让我们来探究一下吧！
> 
> 
> 


![](/data/attachment/album/202207/01/113921u4sjl5cczwj3tjbu.jpg)


直至不久之前，几乎每个产品经理都会将他/她的工程资源，分成两个独立的团队 —— 开发团队和运维团队。开发团队通常参与编码、测试和构建应用功能，而运维团队负责应用程序的交付、部署和运行维护。


当开发团队构建电商应用时，运维团队会搭建好服务器来托管该应用。搭建服务器涉及到许多方面，其中包括：


* 选择合适的硬件和操作系统
* 应用所需的补丁集
* 搭建所需服务器环境，如 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](https://www.opensourceforu.com/author/krishna-mohan-koyya/) 选题：[lkxed](https://github.com/lkxed) 译者：[lkxed](https://github.com/lkxed) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
*Serverless computing removes the server from the equation and enables businesses to give undivided attention to the application functionality. Does that make serverless computing the automatic choice? Let’s find out.*

Until recently, almost every product manager organised his or her engineering resources into two separate teams — the development team and the operations team. The development team is usually involved in coding, testing and building the application functionality, whereas the operations team takes the responsibility of delivery, deployment, and operational maintenance of the application.

When a development team builds an e-commerce application, the operations team sets up the server to host that application. Setting up a server involves several aspects, which include:

- Choosing the appropriate hardware and operating system
- Applying the required set of patches
- Installing applicable server environments like JDK, Python, Tomcat, NodeJS, etc
- Deploying, configuring, and provisioning the actual application
- Opening and securing appropriate ports
- Setting up required database engines

… and the list just goes on.

Besides this, managers also break their heads on capacity planning. After all, any non-trivial application is expected to be 100 per cent available, reliable and scalable all the time. This requires optimal investment in the hardware. As we all know, shortage of hardware at crucial periods results in business loss, and on the other hand, redundant hardware hurts the bottomline. Capacity planning is crucial, irrespective of whether the application is targeted for the on-premises data centre or for cloud infrastructure.

By now, it is clear that businesses spend a lot of time not only in building the functionality but also in delivering it.

Serverless computing aims at offering a seamless way to deliver the functionality without worrying about the server setup and maintenance. In other words, a serverless computing platform offers a ready-to-use environment in such a way that the businesses build and deploy the applications as a set of smaller functions as quickly as possible. That is why this approach is referred to as Function as a Service (FaaS).

Remember that there is still a server in serverless computing, but it is taken care of by the FaaS vendors like AWS, Microsoft, and Google.

For example, AWS offers a serverless computing environment in the name of Lambda functions. Developers can choose to build the applications as a set of Lambda functions that can be written in NodeJS, Java, Python, and a few other languages. AWS offers a ready-to-use environment to deploy these functions. It also offers ready-to-use database servers, file servers, application gateways, authentication servers, etc.

Similarly, Microsoft Azure offers an environment to build and deploy Azure functions in languages like C#.

**Why serverless?**

There are two main factors driving the popularity of serverless computing.

*Ready-to-use environment:* Obviously, this is the topmost selling point in favour of serverless computing. Businesses need not procure/book hardware or instances in advance, or worry about licences and setting up and provisioning the server. And they need not bother about scaling up and down. All of this is taken care of by the FaaS vendor.

Optimal cost: Since FaaS vendors always charge the clients based on the utilisation of the environment (pay as you use model), businesses need not worry about upfront costs and wastage of resources. For example, AWS charges the clients based on the number of requests a Lambda function receives, number of queries run on a table, etc.

**Challenges with serverless computing**

Like with any other approach, serverless computing is also not the perfect approach that everyone can blindly follow. It has its own set of limitations. Here are a few of them.

**Vendor locking:** The first and most important problem associated with serverless computing is that functions like Lambda or Azure are to be written using vendor-supplied APIs. For example, the functions that are written using an AWS Lambda API cannot be deployed into Google Cloud and vice versa. Hence, serverless computing forces businesses to commit to a vendor, for years. The success or failure of the application depends not only on the functionality but also on the ability of the vendor with respect to performance, etc.

*Programming language:* No serverless computing platform supports all the possible programming languages. Moreover, it may not support all the versions of a given programming language. The application development teams are constrained to choose only the languages that are offered. This may turn out to be very crucial in terms of the capabilities of the team.

*Optimal cost, really?:* It all depends on the usage of the resources. If your application is attracting a huge load, like millions of requests per second, the bill that you foot might be exorbitant. At such a scale, having your own server on-premises or on the cloud might work cheaper. It doesn’t mean that applications with Web-scale are not suitable for serverless computing. It all boils down to the way you architect around the platform and the deal you sign with the vendor.

*Ecosystem:* No application is written for an isolated environment. It requires other components like data stores, databases, security engines, gateways, messaging servers, queues, cache, etc. Every platform offers its own set of such tools. For instance, AWS offers Dynamo DB as one of the NoSQL solutions. Obviously, other vendors offer their own NoSQL solutions. The teams are thus forced to architect the applications based on the chosen platform. Though most of the commercial FaaS vendors offer one or another component for a particular requirement, not every component may be best-in-class.

**What about containers?**

Many of us migrated to containerised deployment models in the last decade, since they offer a lightweight alternative to the costly machines, physical or virtual. With orchestration tools like Kubernetes, we love to deploy containerised applications and meet Web-scale requirements. Containers offer a certain degree of isolation from the underlying environment, which makes deployment relatively easy. However, we still need investments in hardware (on-premises or cloud), licences, networking, provisioning, etc, which demands forward planning, applicable technical skills, and careful monitoring. Serverless computing frees us even from these responsibilities, albeit with its own set of pros and cons.

**Road ahead**

We are in the days of continuous development, continuous integration, and continuous deployment. Every business is facing competition. Time to market (TTM) plays a significant role in gaining and retaining customers. In this backdrop, businesses love to spend more time churning out the functionality as quickly as possible rather than struggling with the nitty-gritty of deployment and maintenance. Serverless computing has the potential to meet these demands. Big players are committing huge investments to make FaaS as seamless and as affordable as possible. The future looks bright for serverless computing.