Author: Xiliu

background

When it comes to one of the hottest technologies of the moment, one concept inevitably comes up: Serverless. As a new application architecture, Serverless enables us to get rid of the tedious maintenance of infrastructure. We only need to upload code packages or images to get a flexible, highly available, o&M free and low-cost service.

Sounds very beautiful Serverless in the actual development process, but there are some pain points. For example, in the process of using Serverless, you must have the following problems:

  • Use the Custom Runtime/Container function to perform a one-click migration of SpringBoot, Python Flask, ThinkPHP, etc. During the startup process, you need to access other services in the cloud environment (such as database or registry). When an application fails to start, how to troubleshoot the cause?

  • The application uses a microservice architecture and involves multiple services. Can end-to-end testing be done quickly after native code development is complete?

  • Event-driven applications, triggered by event sources, have multiple links and long links. Can you quickly test the entire link locally?

  • …

Industry research report (Hacknoon Serverless Report [1]) also shows that debugging is the biggest obstacle to serverless implementation. At present, the industry has Serverless application debugging means, mainly in the local simulation cloud execution environment for local debugging; Applications running in remote environments rely mainly on logging. Since the real cloud environment cannot be simulated locally, the above problems cannot be solved by local debugging. Therefore, we have launched an innovative end-to-end cloud debugging function in the industry to solve the problem of Serverless application debugging.

The cloud alignment

The core idea of Serverless Devs’ end-to-end cloud coordination function [2] is to make the local development environment break through the limitations of the network and integrate with the cloud environment. Developers can start instances locally through end-to-end cloud tuning, and seamlessly connect with the cloud environment for rapid testing and problem debugging. End-to-end cloud integration can help developers:

  1. Code changes, real-time view results, debugging iteration of the shortest loop. For example, the service to be developed is dependent on other services. When the native code development is complete, it is a good idea to initiate end-to-end tests to see if the change breaks the caller service. In the traditional way, you need to deploy the code to the remote side and launch the test, which can be a lengthy process.

  2. Able to reuse local rich development and debugging tools, the highest efficiency. For example, investigating a test case failure in a remote environment used to be about logging. Wouldn’t it be nice to be able to import production traffic into an instance of your local environment and debug using a variety of ides on your local environment?

As shown in the following figure, the end-to-end cloud networking establishes a secure tunnel connection between the local development machine and the CLOUD application’S VPC environment. Traffic to cloud applications will be automatically forwarded to the local developer; In addition, the network traffic accessed by the local instance is automatically forwarded to the CLOUD application’s VPC. For example, if you use a local instance to access an RDS database instance on the cloud, you can only use the RDS instance to access the public network or purchase a VPN service to access an online VPC. With endcloud, RDS instances can be accessed directly from the Intranet without any configuration changes.

Enable end-to-end cloud interworking

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

  1. Create a secondary Service/Function based on your S.aml VPC configuration, and reserve an instance of the secondary Function. This helper function acts as a proxy service through which all incoming and outgoing traffic from the local instance passes.

  2. Start the proxy container instance of the local environment and establish a bidirectional TCP tunnel with the FC network proxy container instance in 1 through the channel service.

  3. Start the local function container instance, for example, if you are Custom Runtime directly running the SpringBoot application, start the SpringBoot local function container instance and 2 proxy container instance sharing network, The Springboot application can access online VPC resources from the Intranet.

  4. If the local Function container instance is successfully started, you can start debugging. Directly use S Proxied invoke or curl to call auxiliary Service/Function. Traffic will be sent back to the local Function container instance through proxy Service. Start the local IDE for breakpoint debugging of applications within the instance.

Disable end cloud interworking

Because an auxiliary function reserves one instance, you can manually clean up resources after debugging to avoid unnecessary costs.

  1. On the terminal on which the end-to-end cloud synch function is enabled, directly interrupt by CTRL + C

  2. Or on another terminal, run s Proxied cleanup in the same directory

Just use one of the methods 1 or 2 above, and run s Proxied cleanup several times if you are worried.

Even if you forget to clear the resources, if the local development machine is down or the network is disconnected, the channel session is automatically closed and the reserved resources are automatically cleared.

Examples of actual combat scenarios

Take ali Cloud function computing as an example: Xiao Wang is a business-driven company. In order to improve the efficiency of business iteration, the company’s technical architecture evolves to a comprehensive cloud ecosystem and reduces the management and operation and maintenance of infrastructure. The architecture is roughly as follows:

Wang migrates the most frequently iterated external projects to the Custom Runtime, where SpringBoot projects need to be able to use various VPC Intranet addresses to access downstream services (such as registries or other microservice interfaces). End cloud syncing [3] provided by Serverless Devs can come into play at this point, just in the directory where S.yAML (VPC configuration of the function defined in S.Yaml) resides:

$ s proxied setup
Copy the code

Using this command, you can establish a secure network channel with the cloud VPC and start the application instance locally. In this case, local instances can seamlessly access resources in the cloud VPC environment, such as registries, RDS, and Kafka, using Intranet addresses. This means that your application configuration can interact with resources locally and in the cloud without any changes.

At the same time, using the SpringBoot backend project directly corresponding to the custom domain name on the function computed FC, 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 backend that the front-end depends on is Backend and the corresponding self-defined domain name is backend.habc.com. At this time, you can open fronted.abc.com and perform operations with back-end requests. The traffic is automatically routed from online to the local SpringBoot instance. SpringBoot logs are displayed on the terminal in real time.

If the instance of a SpringBoot back-end project fails to be started locally, possible causes include incorrect VPC configuration calculated by functions or whitelist restrictions on downstream services. At this point, you can reproduce the same startup process locally as your cloud instance, which is extremely helpful in troubleshooting instance startup problems. As shown below:

From the startup process information of the local instance, we can clearly locate the reason that Nacos is inaccessible. We need to check whether the function is correctly configured with the VPC information of Nacos, or whether Nacos has whitelist restrictions, etc.

conclusion

Finally, we simply summarize the differences between local debugging and end-to-end cloud integration with a table:

Serverless is the default computing paradigm of cloud computing in the next ten years. Currently, debugging is one of the biggest challenges in Serverless. Compared with other vendors who only provide local debugging, Ali Cloud Function Computing innovatively proposes end-to-end cloud joint debugging and realizes good developer experience through tools. Greatly improve the development efficiency and happiness of Serverless application developers, life is too short, I use Serverless!

A link to the

[1] HacKnoon Serverless Report: hackernoon.com/top-5-serve…

[2] End cloud: github.com/devsapp/fc/…

[3] End cloud: help.aliyun.com/document_de…

reference

Spring Boot Serverless combat | Serverless application monitoring and debugging mp.weixin.qq.com/s/ToDSQXB1b…

Click here to skip to Serverless Devs~