×
Community Blog Serverless Debugging Big Killer: End-Cloud Debugging

Serverless Debugging Big Killer: End-Cloud Debugging

This article discusses end-cloud debugging, including the similarities and differences between local debugging and end-cloud debugging.

1

By Xiliu (Alibaba Cloud Function Compute Expert)

Background

Speaking of the hottest technology currently, Serverless is an inevitable topic of discussion. As a new application architecture, Serverless allows us to get rid of the tedious maintenance of infrastructure. You only need to upload code packages or images to obtain a flexible, highly available, O&M-free, and low-cost service.

Serverless has many advantages but also has some pain points in the development process. The following troubles exist when using Serverless:

  • When you want to translate applications with various language frameworks (such as Spring Boot, Python Flask, and ThinkPHP) using the function to compute Custom Runtime/Container, you need to access other services (such as databases or registries) in the cloud environment during instance startup. How can you troubleshoot the reason why the application cannot be started?
  • The application uses a microservices model and involves multiple services. Can users quickly perform end-to-end testing after local code development is complete?
  • There are many procedures and long links for event-driven applications that trigger functions through event sources. Can users quickly test the entire procedure locally?

Industry research reports (Hacknoon Serverless Report) show that debugging is the biggest obstacle to Serverless landing.

The existing Serverless application debugging methods in the industry mainly perform debugging in the local simulation cloud execution environment, while applications running in the remote environment rely on logs. The real cloud environment cannot be simulated locally, so local debugging fails to solve the preceding problems. The industry's innovative end-cloud debugging function was launched for this reason.

End-Cloud Debugging

The core idea of Serverless Devs end-cloud debugging is to enable the local development environment to break through network restrictions and integrate with the cloud environment. Developers can launch instances locally and connect to the cloud environment seamlessly through end-cloud debugging to perform testing and problem debugging. End-cloud debugging can help developers:

  1. Change the code, view the results in real-time, and debug the iteration with the shortest closed loop. For example, the service to be developed is dependent on other services. When the local code development is completed, it is best to start end-to-end testing to see if there is a break caller service. If the traditional method is adopted, the code needs to be deployed to the remote end. Then, the test can be initiated. The process is lengthy.
  2. The ability to reuse local rich development and debugging tools is the most efficient. For example, users can only rely on logs from the past to investigate test case failures in a remote environment. Is it great to import production traffic to instances in the local environment and use various IDEs in the local environment for debugging?

As shown in the following figure, end-cloud debugging establishes a secure tunnel connection between the local development machine and the VPC environment of the cloud application.

2

The traffic that accesses the cloud application is forwarded to the local development machine. At the same time, the network traffic accessed by the local instance is also forwarded to the VPC environment of the cloud application.

For example, if you use a local instance to access an ApsaraDB for RDS instance on the cloud, you can only access the ApsaraDB for RDS instance from the Internet or purchase a VPN service to access an online VPC. You can access the RDS instance in the intranet by end-cloud debugging without any configuration changes.

Enable End-Cloud Debugging

The user executes the s proxied setup in the s.yaml directory, and this command does the following:

  1. Create a secondary Service/Function based on the VPC configuration of s.yaml and reserve one instance for the secondary function. The role of this secondary function is a proxy service. All inbound and outbound traffic from the local instance will pass through this proxy service.
  2. Start the proxy container instance in the local environment, use the channel service, and establish a two-way communication TCP tunnel with the FC network proxy container instance in 1.
  3. Start a local function container instance. For example, if you run a Spring Boot application with Custom Runtime, the local function container instance that starts Spring Boot and the proxy container instance in 2 shares the network. The Spring Boot application can access online VPC resources over the internal network.
  4. If the local function container instance starts, you can start debugging. You can use the s proxied invoke or curl custom domain name to call the secondary Service/Function. Traffic will be returned to the local function container instance through the proxy service. Open the local IDE to perform breakpoint debugging on the application in the instance.

Disable End-Cloud Debugging

There will be a secondary function to reserve 1 instance. After debugging, you can manually clean up the resources to avoid unnecessary costs.

  • CTRL + C the interruption in the terminal that opens end-cloud debugging
  • Or in another terminal, execute the s proxied cleanup in the same directory

You can use one of the preceding methods (1 or 2). You can also execute the s proxied cleanup multiple times.

Even if you forget to clean up and the local development authority or network is disconnected, the channel session will be closed, and the reserved resources will be cleaned up.

Examples of Real-World Scenarios

Let's use Alibaba Cloud Function Compute (FC) and a real enterprise customer as an example. Mr. Wang is a developer of a business-driven company. The company's technical architecture has evolved to full cloud-native and reduced infrastructure management and O&M to improve business iteration efficiency. The following is the architecture:

3

Mr. Wang migrated the most frequently iterated projects that separated the front and backend to the Function Compute Custom Runtime with one click. Spring Boot projects need to be able to access downstream services (such as registration centers or other microservice interfaces) by using various VPC intranet addresses.

At this time, the end-cloud debugging provided by Serverless Devs can be used. You only need to execute it in the directory where s.yaml (the VPC configuration with functions defined in s.yaml) is located.

$ s proxied setup

The command establishes a secure network channel with the cloud VPC environment and starts the application instance locally. As such, the on-premises instance can seamlessly access resources in the cloud VPC environment, such as using the internal endpoint to access the registry, RDS, and Kafka. This means your application configuration does not need any changes to interact with resources within local and cloud environments.

At the same time, directly use the custom domain name corresponding to the Spring Boot backend project on the Function Compute FC, and traffic will be routed to the local application instance.

For example, the function name of your frontend project deployed to FC is a frontend, and its corresponding custom domain name is frontend.abc.com. The function name of the backend service that the frontend depends on and is deployed on FC is the backend, and the corresponding custom domain name is backend.abc.com.

At this time, you can open fronted.abc.com in the browser and perform operations with backend requests. Traffic is routed from online to the local Spring Boot instance. At the same time, Spring Boot logs are displayed in real-time on the terminal. You can use breakpoints to debug traffic online.

Let's assume the instance of the Spring Boot backend project fails to start locally. Possible causes include incorrect VPC configurations of the Function Compute and whitelist limits for the corresponding downstream services. At this point, you can reproduce the same startup process as the cloud environment instance locally, which is helpful in troubleshooting problems with instance startup. As shown in the following figure:

4

With the information from the startup process of the local instance, the cause of Nacos access failure can be identified. We need to check whether the function has correctly configured the VPC where Nacos is located or whether Nacos has whitelist restrictions.

Summary

Finally, we use a table to summarize the differences between local debugging and end-cloud debugging.

5

Serverless is the default computing paradigm for cloud computing for the next ten years. Currently, debugging is one of the biggest challenges in Serverless. Compared with other businesses that only provide local debugging capabilities, Alibaba Cloud Function Compute (FC) proposed end-cloud debugging and achieved a good developer experience through tools, improving the development efficiency and happiness of developers of Serverless applications.

Related Links

  1. Hacknoon Serverless Report: https://hackernoon.com/top-5-serverless-trends-in-2020-wd1m3t8g
  2. Serverless Devs End-Cloud Debugging: https://github.com/devsapp/fc/blob/main/docs/en/command/proxied.md
  3. Serverless Devs FC: https://github.com/devsapp/fc/blob/main/readme_en.md
0 0 0
Share on

Alibaba Cloud Serverless

49 posts | 6 followers

You may also like

Comments

Alibaba Cloud Serverless

49 posts | 6 followers

Related Products