How to use a plug-in to solve the problem of serverless grayscale publishing

Serverless grayscale publishing

What is Serverless?

Serverless, as its name implies, is serverless. It is a new way of providing computing that is "ready to use, fully functional, and ready to go". Users do not need to prefabricate or manage the server to run the code. They just need to deploy the code from the server to the serverless platform of each manufacturer; At the same time, it enjoys the advantages of Serverless pay-as-you-go, high flexibility, low operation and maintenance costs, event-driven, cost reduction and efficiency improvement.

What is Serverless grayscale publishing?

Grayscale publishing is also called Canary Deployment. In the past, miners would put a canary into the mine before going down. If the canary did not die of hypoxia and gas poisoning in the mine, the miners would go down to work. It can be said that the canary protected the lives of workers.

Similarly, in the process of software development, there is also a canary, that is, Gray release: developers will first open the newly developed functions to some users. When the new functions can run smoothly among these users and the feedback is positive, they will open the new functions to all users. The canary release is a process of never releasing, and then gradually transiting to the official release.

So how to publish grayscale functions deployed on the Serverless platform?

The following will take Alibaba Cloud FC as an example to introduce to you.

Grayscale publishing has a process and two methods:

One process

Serverless grayscale publishing is realized by configuring an alias. The alias can configure the traffic proportion of grayscale version and main version. When calling the function, the configured alias can be used to send the traffic to the corresponding version in proportion.

The process of configuring grayscale publishing is as follows:

• A new version is released in Service.

• Create or update the alias, configure the alias to associate the new version with the stable version, and the new version is the grayscale version.

• Associate a trigger to an alias.

• Associate a Custom Domain with an alias. When aliases are used in the calling function, the traffic will be sent to the new version and stable version according to the configuration proportion.

There are two traditional approaches

Alibaba Cloud console web interface:

Release version

Make Alias

associate triggers

Associated custom domain name

Using Serverless Devs cli

Release version

s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"

Create alias and set grayscale

s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20

associate triggers

Console configuration required

Associated custom domain name

Console configuration required

You can see that each step in the grayscale publishing process using the console or Serverless Devs requires the user to operate it personally. And it is easy to make mistakes due to various configurations. In addition to these drawbacks, another problem that customers are troubled by is that it is very inconvenient to use the grayscale publishing strategy.

There are five common grayscale publishing strategies:

1. CanaryStep: grayscale publishing, first specify the flow in grayscale, and then the remaining flow in grayscale after the specified time interval.

2. LinearStep: release in batches, with fixed flow for each batch, and start the next batch after a specified time interval.

3. CanaryPlans: customize the grayscale batch, set the grayscale flow and interval time for each batch, and conduct grayscale according to the set flow after the specified interval.

4. CanaryWeight: manual grayscale, directly set the corresponding weight for the grayscale version.

5. FullWeight: full release, full release to a certain version.

Among these grayscale strategies, the first three items need to configure the interval time. However, users can not configure the interval time through automatic programs on the console or using the Serverless Devs tool. They have to remind users to manually carry out the next grayscale process through alarm clocks and other methods. This experience is very unfriendly. Next, we introduce a plug-in that can help you publish the grayscale function with one click: FC-Canary.

Grayscale publishing based on Serverless Devs plug-in FC-Canary

In order to solve the above problems, the plug-in FC-Canary based on Serverless Devs came into being. This plug-in can help you realize the grayscale publishing ability of functions through Serverless Devs tools and FC components, effectively solve the problems of complicated parameter configuration, the need for personal operation of developers and the lack of available strategies during grayscale publishing.

(Content configuration and precautions - partial screenshots)

Refer to: https://github.com/devsapp/fc-canary 。

Advantages of FC-Canary

1. FC-Canary supports ultra-simple configuration

The user can start the grayscale publishing function by adding 5 lines of code in s.yaml at the minimum.

2. FC-Control configuration guidance is simple and clear:

3. FC-Canary supports multiple grayscale strategies

Grayscale publishing: first specify the traffic in grayscale, and then the remaining traffic in grayscale after the specified time interval.

At this time, the traffic change is: 20% to the new version, and 100% to the new version after 10 minutes

Manual grayscale. When specifying, set the corresponding weight of the grayscale version directly.

At this time, 10% of the traffic flows to the new version and 90% to the stable version

Customize the grayscale, and configure the grayscale change in an array.

At this time, the traffic change is: 10% to the new version ->(5 minutes later) 30% to the new version ->(10 minutes later) 100% to the new version

Release in batches, and continue to accumulate the gray scale until 100% traffic reaches the new version.

Traffic change: 40% to the new version ->(10 minutes later) 80% to the new version ->(10 minutes later) 100% to the new version

Full release, 100% traffic to the new version

The FC-Canary plug-in supports five grayscale strategies. Users can experience one-click grayscale publishing by selecting the desired strategy and performing simple configuration.

4. FC-Canary grayscale stage prompt is clear

The plug-in will show every milestone in the form of log, giving developers enough confidence.

5. FC-Canary supports nail group robot reminder

Configure the nail robot to receive relevant reminders in the group, such as:

FC-Canary Best Practices

Use the FC-Canary plug-in to publish the functions of nodejs 12 in grayscale.

Code warehouse: https://github.com/devsapp/fc-canary/tree/main/example/singleFunc-http

Initialize configuration

Code configuration

Yaml configuration

We adopt the grayscale strategy of canaryWeight: after the grayscale release, 50% of the traffic will go to the new version, and 50% of the traffic will go to the old version.

Make the first release

Execute release

Enter: s deploy -- use local in terminal

View results

You can see in the log output from the command line:

Because this is the first release, there is no historical version in the project, so even if the grayscale release strategy is configured, the FC-Canary plug-in will also publish in full, that is, the traffic will be sent to version 1.

Modify the code and release it for the second time

Before the second release, let's modify the code to throw errors.

Execute release

Enter: s deploy -- use local in terminal

result

You can see in the command line output log:

For the second release, the grayscale release strategy is applied, that is, 50% of the traffic is sent to version 1, and 50% of the traffic is sent to version 2.

test

Get the domain output in the log, access the domain 100 times, and then view the console monitoring disk.

You can see that the function has been called 100 times, the wrong function has 49 times, and the correct function has 100 - 49=51 times. Both the correct and wrong functions account for about 50% of the total number of calls.

Analysis: Function version 1 is the correct function, and function version 2 is the wrong function. Our grayscale configuration is 50% to version 1 and 50% to version 2, so the wrong function and the correct function should account for 50% respectively during the call process. The results in the figure conform to our assumptions, which proves that our grayscale strategy is successful.

Summary: We can find that compared with using the console for grayscale publishing, using the FC-Canary plug-in saves users the trouble of manually creating versions, publishing aliases, associating triggers, and managing custom domain names. It is very convenient to use.

Relationship between Serverless Devs components and plug-ins

What are the components?

According to the description in Serverless Devs Model v0.0.1, the component Component: is a piece of code developed and released by Package Developer that conforms to the specification of Serverless Package Model. Usually, this code will be referenced in the application and loaded in the Serverless Devs developer tool, and some actions will be performed according to the predetermined rules. For example, deploy the user's code to the Serverless platform; Build and package the Serverless application; Debug the Serverless application.

for instance:

If you want to use Serverless Devs to manage Alibaba Cloud function computing resources, you need to declare Alibaba Cloud FC components in the yaml configuration file, and then you can use the capabilities of Alibaba Cloud FC components.

FC components can provide the ability to manage Alibaba Cloud function computing resources, including: management services, functions, versions, aliases and other functions.

Component address: https://github.com/devsapp/fc

What is a plug-in?

As a supplement to components, plug-ins provide atomic functions of components.

for instance:

Use the function deployment function of FC component deploy to publish the deployed function in grayscale after deployment.

Using the function deployment function of FC component deploy, you can use the layer-fc plug-in before deployment to reduce the time spent uploading code during deployment: that is, layer-fc allows the function to directly use the dependencies in the public dependency library (remote), so that it is no longer necessary to upload these remote dependencies during deployment.

What is the relationship between components and plug-ins?

In the Serverless Devs Model, components occupy the core position and plug-ins are auxiliary. That is to say, the purpose of plug-ins is to improve the capabilities of components and provide them with some optional atomic functions.

Serverless Devs manages the life cycle of components and plug-ins. If it is a pre plug-in, it will be executed before the component is executed. On the contrary, the post plug-in will complete some finishing work after the component.

A component can use multiple plug-ins at the same time. The execution order of component plug-ins is:

Plugins are executed in yaml order. The execution result of the previous plug-in is the input parameter of the next plug-in

The output of the last pre plug-in is used as the input parameter of the component

The output of the component is used as the input parameter of the first post plug-in

Related concepts:

FC function is the unit of system scheduling and operation, which is composed of function code and function configuration. FC functions must be subordinate to services. All functions under the same service share some of the same settings, such as service authorization and log configuration. For related operations of functions, see Managing Functions. Function calculation supports two function types: event function and HTTP function. For the difference between them, see Function Type

Service can be compared with microservice (with version and alias), and multiple functions can form a service unit together. Before creating a function, you must first create a service. All functions under the same service share some of the same settings, such as service authorization and log configuration.

The function of a trigger is to trigger the execution of a function. Function calculation provides an event-driven calculation model. Function execution can be triggered through the function calculation console or SDK, or by other event sources. You can create a trigger in the specified function. The trigger describes a set of rules. When an event meets these rules, the event source will trigger the associated function.

Custom Domain is the ability of function calculation to bind domain names for Web applications.

Version is a snapshot of the service, including the service configuration, function code and function configuration within the service, excluding triggers. When the version is published, the function calculation will generate a snapshot for the service, and automatically assign a version number to it for subsequent use.

Alias, combined with version, helps function computing realize continuous integration and release in the software development life cycle.