Serverless debugging big killer device-cloud joint debugging

Background

Speaking of the current hottest technology, it is inevitable to discuss a concept: Serverless. As a new application architecture, Serverless frees us from the hassle of maintaining infrastructure. Simply uploading code packages or images can provide an elastic, highly available, O&M free, and low-cost service.

In the actual implementation and development process of Serverless, which sounds beautiful, there are indeed some pain points. For example, when using Serverless, you must have the following problems:

• Using a function to calculate the Custom Runtime/Container, you want to one-click migrate applications with various language frameworks such as SpringBoot, Python Flask, and ThinkPHP. During the instance startup process, you need to access other services in the cloud environment (such as databases or registry). If the application fails to start, how can you troubleshoot the cause?

• The application adopts a microservice architecture that involves multiple services. Can end-to-end testing be performed quickly after local code development is completed?

• For event driven applications, through event source trigger functions, with multiple links and long links, can the entire link be quickly tested locally?

• ……

The industry research report also reflects that debugging is the biggest obstacle to the implementation of serverless. Currently, the existing serverless application debugging methods in the industry mainly simulate the cloud execution environment for local debugging; Applications running in remote environments rely mainly on logging. Due to the inability to simulate a real cloud environment locally, local debugging cannot solve the above problems. Therefore, we have introduced an industry-innovative end-to-end cloud debugging function to solve the problem of serverless application debugging.

End Cloud Joint Debugging

The core idea of serverless Devs' cloud end joint debugging function is to enable the local development environment to break through the limitations of the network and integrate with the cloud environment. Developers can launch instances locally through end-to-end cloud debugging, seamlessly connect with the cloud environment, and quickly conduct testing and problem debugging. End cloud joint debugging can help developers:

1. Change the code, view the results in real time, and debug the shortest closed-loop iteration. For example, if the service to be developed is dependent on other services, it is best to initiate end-to-end testing after the local code development is completed to see if there are any changes to the break caller service. If you use the traditional method, you need to deploy the code to the remote end to initiate testing, which is a lengthy process.

2. Be able to reuse rich local development and debugging tools, with the highest efficiency. For example, investigating test cases that failed in a remote environment used to rely solely on logs. Is it great to be able to import production traffic to an instance in a local environment and use various IDEs in the local environment for debugging?

As shown in the figure below, end-to-end cloud joint debugging establishes a secure tunnel connection between the local development machine and the VPC environment of cloud applications. The traffic accessing cloud applications will be automatically forwarded to the local development machine; At the same time, the external access network traffic of the local instance is also automatically forwarded to the VPC environment of the cloud application. For example, when accessing RDS database instances in the cloud from a local instance, developers in traditional ways can only release public network access to RDS instances or purchase VPN services to achieve local access to online VPC if they conduct debugging and development locally. Using end cloud joint debugging does not require any configuration changes, and RDS instances can be accessed directly through the intranet.

Enable end-to-end cloud joint debugging

The user simply executes s proxied setup in the directory of s.yaml. This command does the following:

1. Create an auxiliary Service/Function based on your s.yaml vpc configuration and other information, and reserve an instance of the auxiliary function. The purpose of this auxiliary function is to act as a proxy service through which all incoming and outgoing traffic from the local instance passes.

2. Start the proxy container instance in the local environment, and establish a two-way communication TCP tunnel with the FC network proxy container instance in 1 through the channel service.

3. Start a local function container instance. For example, if you are running the SpringBoot application directly from the Custom Runtime, start the local function container instance of SpringBoot and the proxy container instance in 2 to share the network. The springboot application can already access online VPC resources through the intranet.

"After the local function container instance is successfully started, debugging can begin. Directly use the proxied invoke or curl custom domain name to invoke the auxiliary Service/Function. The traffic will be routed back to the local function container instance through the proxy service, and the local IDE can be enabled to perform breakpoint debugging on applications within the instance.".

Close end cloud joint debugging

Because there will be one auxiliary function reserved for one instance, after debugging, you can manually clean up resources to avoid unnecessary costs

1. At the terminal where cloud joint debugging is enabled, direct CTRL+C interrupt

2. Or, on another terminal, execute s proxied cleanup in the same directory

Use one of the methods 1 or 2 above. If you are not confident, you can execute the proxied cleanup multiple times

Even if you forget to clean up, if the local development machine is shut down or disconnected, the channel session will be automatically closed, and the reserved resources will also be automatically cleaned up.

Examples of actual combat scenarios

Take Alibaba Cloud Function Computing as an example: Xiaowang is the development of a business driven company. In order to improve the efficiency of business iteration, the company has evolved its technical architecture towards comprehensive cloud computing, and reduced the management and operation and maintenance of basic facilities. The architecture is roughly as follows:

Xiaowang will migrate the most frequently iterated external front and rear end separated projects to the Custom Runtime for function computing with one click. In this case, the SpringBoot project needs to be able to access downstream services (such as a registry or other microservice interfaces) using various VPC intranet addresses. At this time, the end-to-end cloud joint debugging provided by Serverless Devs can come in handy, You only need to execute in the directory where s.yaml (the VPC configuration for functions defined in s.yaml) is located:

$ s proxied setup

This command will establish a secure network channel with the cloud VPC environment and start the application instance locally. At this point, local instances can seamlessly access resources within the cloud VPC environment, such as using intranet addresses to access the registry, RDS, Kafka, and so on. This means that your application configuration does not require any changes and can interact with resources within the local and cloud environments.

At the same time, directly use this SpringBoot backend project to calculate the custom domain name on the FC, and the traffic will be routed to the local application instance. For example, the function name of your front-end project deployed to FC is frontend, and the corresponding custom domain name is frontend.abc.com. The function name of the front-end dependent back-end service deployed on FC is backend, and the corresponding custom domain name is backend.abc.com. At this time, you directly open fronted.abc.com in your browser and perform operations with back-end requests. The traffic is automatically routed from the online to the local SpringBoot instance. At the same time, the logs of SpringBoot are displayed in real-time on the terminal, and even you can use breakpoints to debug the traffic from the online.

Assume that the local startup of the instance of the SpringBoot backend project fails. Possible reasons include incorrect VPC configuration for function calculation, and whitelist restrictions on the corresponding downstream services. At this point, you can reproduce the same startup process as the cloud environment instance locally, which is extremely helpful for troubleshooting instance startup issues. As shown in the following figure:

From the startup process information of the local instance, we can clearly locate the reason that Nacos is not accessible. We need to check whether the function correctly configures the VPC information where Nacos is located, or whether Nacos has whitelist restrictions.

Summary

Finally, we briefly use a table to summarize the differences between local debugging and end cloud joint debugging:

Serverless is the default computing paradigm for cloud computing in the next decade. Currently, debugging is one of the biggest challenges for Serverless. Compared with other friends' ability to only provide local debugging, Alibaba Cloud Function Computing innovatively proposes end cloud joint debugging, and implements a good developer experience through tools, which greatly improves the development efficiency and happiness of developers of serverless applications. Life is short. I use Serverless!