As Serverless and cloud functions have been concepted and implemented over the past two years, their value has gradually become apparent. In order to have a better understanding of cloud function, I will introduce the concept, value and understanding of cloud function with this literacy post.

First of all, let’s introduce the concept of cloud function:

Graph LR A[Serverless] --> B(Faas: Function as A Service) A --> C(Baas: Backend as A Service)

Serverless broadly refers to simply allowing customers to run applications directly, regardless of their underlying mechanisms. In a narrow sense, Serverless can be divided into the above two aspects. This time, WE mainly talk about Faas, which provides event-driven computing services. Developers manage application code in the form of snippets of functions that are triggered by events or HTTP requests. Compared to traditional applications, it is deployed in a more fine-grained functional manner, so that computing resources can be more finely scheduled and managed, and these operations are automated without the involvement of the developer.

Here is the value of cloud functions, which do not exist on cloud computing when services are not being requested. Once the request is issued, the scheduling platform instantiates a service at the millisecond level and completes the response. Once the request is processed, the scheduling service will automatically retrieve the instance. As long as the cost of cloud functions is calculated by the number of calls, resource usage and outbound traffic, etc., the operation and maintenance cost is very small in the business trough when the number of visits is low. For start-up companies, it can save most of the initial operation and maintenance costs, which is of great value.

So how do we understand cloud functions? Let’s start with this picture:

Graph of TD A [Faas controller] -- > | | B/event source configuration triggers A - > | | start instance C [function instance] -- > | | C trigger

For a Faas cloud function service, we need to configure a trigger and a function instance. We can start the function instance through the controller during debugging, but we still need to use the event source of the configured trigger to drive the function instance to execute. Here we take Tencent cloud function as an example, combined with the steps of creating cloud function, to understand the cloud function:

From the console’s cloud function Services portal, click on the function Services TAB on the left. You can see that there are two ways to create cloud functions, one is template creation, and the second is custom creation. Template creation is the basic project file that introduces the corresponding services, such as the KOA template file, which introduces a KOA project template that can be called by cloud functions after writing its own project. Let’s focus on custom creation:

In custom creation, you need to choose at the top whether it is an event function or a Web function. Here, event functions are the most basic function type. Web functions are closer to the native Web development parameter format than event functions. For example, you can start your own KOA service by using koA-BodyParser to parse parameters into your own cloud function service. Most importantly, it supports both the development of Web services through cloud functions and one-click migration of native Web frameworks to the cloud. You must create an executable file, scf_bootstrap, to start the Web Server, and then package and deploy it along with the code file to complete the Web function creation.

Since the argument format is mentioned here, let’s see what the convention argument format is for the cloud function if it is an event function. Select event function, deployment mode select code deployment, this time does not involve docker image deployment. The running environment is node12. The commit method chooses the simplest online edit, and you can see that the execution method is the main_handler method we exported in the file.

In the main_handler method, we pass in the event and context. The event is the event referred to in the event function and is the actual input parameter to the function. Context contains some auxiliary information about the context in which the function is running. So that’s a brief introduction to our function example.

Further down is the function configuration. If we get some errors while running the function, we should check whether the maximum memory or maximum elapsed time Settings are too small.

Moving on to triggers:

Options can be seen in the timing trigger, COS trigger, Ckafka trigger, API gateway trigger and so on. Let’s start with API gateway triggers, which are the most commonly used triggers. Because Faas does not support HTTP, it also needs to provide Web APIS through the API Gateway. If we select a Web function in the function type, then the trigger here locks to an API gateway trigger. COS trigger is an object storage trigger. When a user uplows a static file, it is stored in the file storage service. It will then automatically trigger our cloud function. For interface services such as video transcoding, which consume computing resources and have a large gap between peak and valley visits, cloud functions can save costs. Timing triggers are obviously similar to routine tasks to perform cloud functions. Ckafka triggering is the cloud function execution triggered by message queues.

This concludes the two blocks of Faas: function instances and triggers.

Reference: 1. “Front-end Serverless For full Stack Serverless Architecture Combat” Yang Kai 2. Tencent Cloud Document

More exciting articles please pay attention to: