Today’s Serverless can be said to be a potential new technology direction, especially in the current cloud upsurge, Serverless because of its free operation and maintenance, automatic expansion, support for a variety of programming languages and other advantages, for the front-end, is a great tool to improve service development, maintenance efficiency can also try the full stack development direction, but also because of its new, There are also some challenges in the implementation of team development and the combination of team development flow. This article will share IMWEB team’s practice plan for Serverless

I. Evolution and thinking of IMWEB team Serverless R&D mode

In the past one or two years, our team tried to use Serverless in a number of service projects. Serverless of Tencent Cloud provides one-stop service. By using this service, the front-end can independently complete the development of interface services, and the front-end individuals can develop to the full stack, so as to alleviate the problem of manpower shortage in the background of the team.

In the process of developing Serverless cloud functions, we also encountered some challenges in cloud function development compared to traditional services.

(1) Features of cloud function development

The development flow model of traditional front-end projects is relatively mature. The code is managed through Git and the deployment process of the project is standardized through CI. The whole workflow can be viewed and rolled back, and the deployment is also automated.

Let’s look at the characteristics of cloud function development. There are three bases for cloud function development:

  1. Cloud function independent account and permission management;

  2. Create, update, and deploy on a function basis;

  3. Create gateway APIS associated with functions so that cloud functions can be accessed through gateway apis;

These are the three basics for developing cloud functions:

Cloud functions can be created and updated in two ways:

  1. Tencent cloud official website cloud function console, visual operation interface, click the button to create, update;

  2. Through CLI creation, SERVERLESS provides SDK, calling SDK can complete custom creation, update operations, its advantages for flexible writing, but also easy to make engineering.

Considering team collaboration, the second approach, through the invocation of the SDK, is more suitable for customization as a team specification because of its flexibility.

In summary, we can see three features of cloud function development:

  1. Because it has a cloud function account independent of git account, the code of cloud function lacks the ability to view historical code versions and code modification records like Git.

  2. Because there are multiple ways to create and update functions, there is a risk of overwriting each other’s cloud functions when multiple people collaborate.

  3. Provide cloud function gateway, can help quickly configure access to cloud functions, without the operation and maintenance students to help do domain name pointing, machine application, etc.

(2) Problems of cloud function development in teamwork

In the early stage, when the team explored and tried cloud function development, compared with the development flow of traditional projects, there were more steps in cloud function development, and some shortcomings were exposed.

  1. High cost of entry

First of all, there are not small learning costs, such as cloud function configuration files, cloud function official website interface learning costs. In actual use, due to the cloud function gateway API link is too long, domain name restrictions, etc., need to configure nginx, use a specific domain name to access the cloud function gateway API, because most front-end deployment of nginx, This leads to nginx learning costs.

  1. Debugging cloud functions is inefficient

Because the cloud function is deployed in the cloud, Serverless has its unique environment, such as context and event, which is different from the request body of NODE service. It is difficult to simulate serverless request completely locally. As a result, when the development wants to debug and locate problems, The code can only be deployed to Serverless first, where you have to wait for deployment, which takes longer because Serverless is external.

  1. Development flow confusion

  1. Since cloud functions are directly deployed in the cloud, there is no traditional machine for environment differentiation, which is not friendly for team collaboration to ensure deployment quality.

  2. As mentioned above, often because you want your own business domain name to access the service interface, and the cloud function gateway API is relatively long and lack of semantic links, usually you want to configure Nginx to access the cloud function through the custom domain name, not only the cost problem but also the risk of easy configuration error problem.

  1. It is difficult to manage and has quality problems

Due to the independent account management of cloud functions without Git management, code records cannot be tracked. Even if anyone with permission creates a function with the same name for deployment, the function will be overwritten inexplicably. Similarly, the CLOUD function gateway API can also be arbitrarily changed to point to other cloud functions.

To sum up, the challenges encountered in team SCF development are as follows:

Ii. IMFLOW one-stop Serverless development solution breaking and landing

Summarize some problems encountered by the above cloud functions in team collaboration and propose corresponding solutions:

  1. Formulate norms to ensure unified collaboration, unified norms to ensure unified workflow, improve development efficiency and ensure quality;

  2. Optimize the cloud function development experience, automate redundant operations through tools, and filter out some development learning costs through encapsulation;

  3. Develop CI and CD according to the characteristics of cloud functions to ensure the unification of the process and improve the deployment efficiency; Unified gateway rules to reduce cloud function gateway API learning and operation.

(1) Formulate norms to improve collaboration efficiency

1) cloud account management For independent function of cloud account, apply for alone every development before the overhand development needs, but also opened a variety of privileges, get along while, slow down for a day or two, aiming at this problem, consider using a public account for cloud function management team, tools use public account for cloud function deployment, update, Free from the development of learning costs, account costs.

2) Based on the independent management mode of GIT management cloud functions for cloud functions, in order to track cloud functions only, the original GIT management project code is retained, and a series of specifications are formulated to uniquely associate GIT projects with cloud functions to ensure that cloud functions are unique and not overwritten.

3) Namespace isolation function environment To provide the development flow of cloud functions, according to the characteristics of cloud functions, the concept of cloud function namespace is used to isolate cloud functions, and the gateway service of the test environment is restricted to Intranet access to ensure service security.

4) environmental namespace isolation function Cloud the function name, corresponding to the gateway service API, environmental namespace naming conventions, in order to achieve a namespace, the function name, gateway service API can be one to one correspondence, through one is derived and the other, such as know the function name, know what is its access API, the corresponding environment what is namespace.

(2) Self-developed CLI tool IMFLOW to improve SCF research and development efficiency

After the first specification, the IMWEB team developed its own CLI to help implement the specification.

Tool — IMFLOW, provide SCF team development flow practice plan, improve SCF research and development efficiency by means of tools; Such as account creation, permission application, cloud function creation, cloud function debugging, cloud function gateway API association, function isolation, etc., can be completed by entering commands through CLI tools.

1) Faster hands-on development after using CLI tools to assist, compared with the team’s previous development mode, it can get hands-on development in 2 minutes through CLI.

2) The debugging experience is consistent with the traditional service development, and the traditional service development experience is retained through isomorphism + construction. The tool is encapsulated and shielded from cloud function files, so that developers can develop the same as before.

3) a key location debug function of cloud cloud function of real running environment is relatively complex, if met problems involving functions of cloud environment debugging, need real debug function of cloud, at this point the local can complete debugging, tool encapsulates a series of operations, according to the facts when debugging, monitoring file changes, etc., real-time deployment, a key to realize positioning debugging function.

4) Optimize the deployment time of cloud function The deployment time of cloud function is external network deployment, and the deployment time of cloud function affects the release time of cloud function, and even affects the debugging efficiency of cloud function during local real-time debugging of cloud function. In order to optimize the deployment time of cloud function, By taking advantage of the layer function of cloud function, the node_module of the project is less likely to change, and the size of the code package will affect the deployment time, the cloud function project deployment is split. When node_modules does not change, there is no need to deploy node_modules. This reduces deployment time.

After the deployment optimization, check the deployment time of the project. Most of the time is 35 seconds to complete the function deployment.

(3) Quality assurance

In terms of quality assurance, mainly through the deployment process CI | CD specification, make standard of gateway service to isolate cloud function and decrease the cost of the gateway configuration.

Restrict the gateway service of the test environment to Intranet access.

In addition, in order to ensure the stable operation of cloud functions and avoid the failure of accessing cloud functions due to the cold start of cloud functions, a layer of STKE disaster recovery is made for cloud functions. Through the code isomorphism, a set of code is constructed and packaged by using tools to achieve both serverless and STKE deployment. Cooperate with the gateway to implement degraded Dr For cloud functions.