What is Serverless

Serverless, an application mode of cloud computing. It’s not that we don’t have servers, but that we don’t have to worry about servers.

Why not worry about the server?

Serverless has two concepts: BaaS (Backend as a Service) and FaaS (Functions as a Service).

1. BaaS, cloud services provide basic services in the form of API, such as cloud data/file storage (e.g. Parse and Firebase), message push (e.g. Aurora push and Getui), application data analysis, etc. There are applications.

2. FaaS, the business logic written by the user, is submitted to the cloud in the form of code (note that it is submitted, not deployed). The FaaS framework provided by the cloud service provider will manage them, register them as a series of events, and trigger the automatic execution. (I loosely interpret FaaS as a Web server similar to Tomcat, as long as we pack up the site and throw it in, someone visiting it will return pages).

This pattern can be seen, for the user, the basic service can be directly called; Its own unique business logic, submission can run directly in the cloud, there is no need to have a server concept.

BaaS and FaaS are the basic characteristics of a Serverless application. An application that complies with these two basic characteristics can be called a Serverless application.

What are the advantages of Serverless?

1. It allows us to focus on the business because we don’t have to worry about any hosts, operating systems, databases, or even web servers like Tomcat, we can focus on the business.

We can only write the core business code, such as loading resources, configuration and other auxiliary functions are no longer. Actually, this can be quite inconvenient sometimes. Configuration is essential for a complete program. Based on the application characteristics of Serverless, I estimate that a system will rarely adopt the Serverless architecture completely, but will adopt the core code in Serverless and the related auxiliary functions in a hybrid mode of other architectures.

3. FaaS that scale Serverless horizontally starts a new process for each event and API request, instead of threads, so no memory or other resources are shared. The maximum number of processes depends only on the FaaS framework.

4. Saving money Since there is no need to maintain a virtual machine or cloud server, users only have to pay for the execution time of the code; The code is triggered by an event, and the lifetime of each request is short (too long to use Serverless), so the direct cost savings are significant. If it’s a virtual machine, cloud hosting, space rental, even in the dead of night, no one accesses the system, we have to pay for that part of the time.

The indirect cost savings are even greater:

The granularity of horizontal Scaling is refined from the original cloud host to the process, eliminating the need to purchase idle cloud hosts to offset configuration inaccuracies in auto-scaling. The increased agility of the business also reduces operating costs. We no longer need operating personnel proficient in operating system configuration and management, which not only saves labor costs, but also saves the time from development to launch of the application.

Disadvantages of Serverless

1. Slow startup speed FaaS are not always in standby state like virtual machines, so it takes extra time to load code; At the same time, Serverless applications usually run in the multi-tenant environment of public cloud, and the startup delay is also affected by system load. Therefore, it is difficult to ensure that applications can be run within the specified time. This is unacceptable for real-time systems.

2. It is too expensive to start one process per request for high-concurrency applications.

Serverless applications cannot reside in memory and run for a limited time. Serverless is not an option if your application cannot do the work in a few minutes, for example AWS Lambda gives a maximum running time of 5 minutes for a process, after which the process will be forced to terminate. This presents a programming challenge.

4. The inability to share state between Serverless calls makes writing complex programs extremely difficult.

5. The code needs to be rewritten using the FaaS framework provided by cloud service providers, such as AWS Lambda. On the one hand, the workload is increased; on the other hand, the framework of each cloud service provider may be different, so it is inconvenient to transplant; Moreover, running these frameworks may require the use of services specified by the cloud service provider, which is too tightly bound to the cloud service provider.

The above are some inherent limitations of the Serverless architecture. They are due to the characteristics of the Serverless architecture and are difficult to be resolved with the passage of time and improvement of technology. In addition, as a new technology, Serverless also faces many shortcomings, such as difficulties in integration testing, Vendor Lock-in, debugging monitoring, and version control, all of which will become obstacles to the adoption of Serverless architecture.

Because of these limitations, the Serverless architecture will not be the architecture of choice for complex applications. Instead, it should be the future of back-end applets.

4. Serverless Application Scenarios Example:

1. Low-frequency request scenario

In the Internet of Things industry, low-frequency request scenarios are often involved due to the small amount of data transmitted by iot devices and the fixed time interval. For example, iot applications only run once per minute for 50ms, which means that the CPU usage is 0.1%/ hour, which means that there are actually 1000 identical applications sharing computing resources. In the Serverless architecture, users can purchase 100ms of resources per minute to meet their computing requirements. In this way, the efficiency problem can be effectively solved and the cost can be reduced.

2. Traffic burst scenario

Mobile Internet applications often face burst traffic scenarios, such as: The typical traffic situation for mobile applications is QPS 20, but there is a QPS 200 traffic every five minutes for 10 seconds (10 times the normal traffic). With traditional architectures, enterprises must expand the hardware capacity of QPS 200 to handle peak traffic, even though peak time is only 4% of the total uptime. In the Serverless architecture, users can make use of the elastic expansion feature to quickly build new computing capacity to meet current requirements. When the service peak, resources can be automatically released, effectively saving costs

Cloud applications have a large number of small program scenarios, such as recognizing a picture, encoding and decoding an audio/video, returning a small piece of data to the IOT device request, and notifying customer service personnel of work orders submitted by customers via email, etc. These event-based applets are relatively complex to implement in a traditional architecture, where you often need to run 80% of the supporting business for 20% of the core business. Serverless solves these problems perfectly and can be a complementary architecture for complex applications. We can split the stateless, event-triggered business into Serverless applications, making the whole architecture more concise and efficient.

Comparison with other cloud computing models In the past, cloud computing has IaaS (basic as a service, such as VM, virtual machine, or storage space?). PaaS (Platform as a service, such as Ali Cloud, has its own operating system.) The three models of SaaS (software as a service, suite of software, such as online CRM, ERP) Serverless subdivides granularity into functions.

Many people think of Serverless as a type of PaaS, or a particular form of PaaS. Or is Serverless a fine-grained form of PaaS? I may have a wrong understanding of PaaS, why PaaS is close to virtual machines.

Serverless is not directly related to microservices, but they have some similarities, such as the need for business separation, emphasis on statelessness, agility, etc. Serverless is in many ways more granular and demanding than microservices. For example, microservices split services on the boundary of services, and Serverless split services on the boundary of functions. Microservices can have memory state sharing across invocations, and Serverless requires that invocations be completely stateless. In addition, Serverless relies on BaaS to provide third-party dependencies, while microservices are free to choose third-party dependency sources, such as traditional middleware stacks built locally (such as local MySql and message buses).

Serverless is a software design architecture, and the container is the bearer of the software architecture. However, I feel that the FaaS framework manages our submitted code and executes it, and has the function of a container.

Another comparison:

Currently, cloud service providers provide computing resource services to users in three architectures, including VIRTUAL Machine (VM) architecture, Container architecture, and Function (Serverless) architecture. Its main pairs are shown in the following figure:

Related articles

Serverless, the future of back-end applets

Serverless Architecture: Replace servers with services

Future technology Trends you need to know – How will Serverless change future architecture?

Cloud computing