Preface: 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
Look again at the characteristics of cloud function development, cloud function development three basic
1. Independent account and permission management of cloud functions
2. Create, update, and deploy functions
3. Create a gateway API and function association so that cloud functions can be accessed through the gateway API
These are the three basics of 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 and update
2. Through CLI creation, SERVERLESS provides SDK, calling SDK can complete custom creation, update operations, its advantage is 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. There are multiple ways to create and update functions, leading to the risk of overwriting each other’s cloud functions when multiple people collaborate
3. The cloud function gateway can help quickly configure access to cloud functions, without the need for operation and maintenance students to help with 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 getting started
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
2) Low efficiency in debugging cloud functions
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
3) 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, it is 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, which is not only the cost problem but also the risk problem of easy configuration error
4) Management difficulties and 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, and unified norms to ensure unified workflow, so as to improve development efficiency and ensure quality
2. Optimize the cloud function development experience, use tools to automate repetitive and redundant operations, 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) Unified 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, development of learning cost, the cost account to fit
2) Manage cloud functions based on GIT
As for the independent management mode of 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 in the test environment is restricted to Intranet access to ensure service security
4) Unified cloud function rule configuration
Develop naming conventions for cloud function names, corresponding gateway service API names and environment namespace, so that the namespace, function name and gateway service API can be matched one by one. The first can be derived from the second. For example, if you know the function name, what is its access API and what is the corresponding environment 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) Hands-on development is faster
After using CLI tools to assist, compared with the team’s previous development mode, it can get started to develop in 2 minutes through CLI
2) The debugging experience is consistent with traditional service development
By the way of isomorphism + construction, the traditional service development experience is retained. The tool encapsulation shields the cloud function file, and the developer can develop the same as before
3) One-click positioning and debugging of cloud functions
The real operating environment of cloud function is relatively complex. If there is a problem related to the debugging of cloud function environment, the real debugging of cloud function is needed, and the debugging can be completed locally. The tool encapsulates a series of operations, such as real-time debugging, monitoring file changes, real-time deployment, and one-click positioning and debugging of cloud function
4) Optimize the deployment time of cloud functions
Cloud function is deployed on the Internet, 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
Iii. Use of IMFLOW
Imflow built-in command
🏆 issue 7 | all things can be Serverless technology projects