Implementation and case analysis of serverless architecture

Evolution of Internet Software Architecture

Let's first briefly review the evolution of Internet software architecture. Single machine deployment: In a single machine deployment, all businesses and databases are deployed on a single host.

The advantage of this architecture is that development, deployment, and operation and maintenance are very simple. The disadvantage is that once encountering excessive traffic or machine failure, the entire system will be paralyzed, even losing business data, resulting in huge business losses.

Clustered deployment

For the above architecture issues, a common solution is to adopt a horizontal expansion approach for clustered deployment. Introduce SLB traffic gateway routing for load balancing.

Clustered deployment is essentially a single architecture. Developers need to pay extra attention during project development, such as using cookies for authentication. Sessions cannot be stored locally, and Redis needs to be introduced for separate storage. Clustered deployment can solve the problem of sudden traffic increases or machine failures through rapid horizontal expansion.

Microservice splitting

With the development of business and the expansion of team size, the tightly coupled approach of single architecture will bring more and more problems, and the flexibility and scalability of the architecture will become a major challenge hindering business development. Micro service architecture emerged as the times require.

Compared to single architecture, microservice architecture is far more complex and has derived many new technologies, such as API gateways, service registration, service discovery, and RPC communication.

Serverless architecture

From a single architecture to a microservice architecture, from stand-alone deployment to clustered deployment, the Internet software architecture is becoming increasingly complex, and companies need to invest a lot of effort and cost in upgrading and maintaining underlying technologies. The following figure shows the Serverless architecture, which is different from the single architecture in that the corresponding components are replaced with Serverless cloud products.

The essence of technological evolution is to better serve the business. Traditional development methods make enterprises spend more effort polishing the underlying technical details. The Serverless architecture is to enable developers to focus on business implementation and create greater business value.

The advantages of the Serverless architecture are obvious:

● Not focusing on underlying infrastructure, focusing on business value creation

● Automatic elasticity, calmly facing sudden increase in traffic

● Billing by resource usage to avoid idle and wasteful resources Serverless architecture discussion Let's take a look at the execution process of FaaS first. The blue part is manually managed by users, requiring only code delivery. Other startup, operation, and maintenance tasks are performed on the FaaS platform.

However, this architecture can cause some problems:

● Code fragmentation, unable to uniformly manage and deploy

● The local environment and online environment are inconsistent and cannot handle dependency compatibility issues

● Difficulty in local debugging and online debugging

● FaaS manufacturers have restrictions on code packages and cannot deploy large code packages

● Lack of unified standards leads to vendor lockdown issues

Serverless Devs addresses the above issues. Serverless Devs can help developers better develop and manage Serverless applications. It has the following characteristics:

● No vendor lock, Serverless Devs helps developers deploy applications to various vendors

● Open source, no black holes in code logic

● Functionally pluggable, Serverless Devs is provided in the form of components, allowing developers to quickly develop their own tool suite based on their needs

● Project lifecycle management capabilities. Serverless Devs is a tool for users to perform full lifecycle management such as project initialization, creation, development, debugging, and deployment. Simplifying Serverless application development. If the Serverless architecture can help developers develop applications, then Serverless Devs is helping Serverless developers better develop Serverless applications!

Serverless Architecture Practice

The practice on the official website of Serverless Devs can be seen from the above introduction that the Serverless Devs developer tool does not provide services, and the implementation of the services is provided by components, while the components themselves are scattered in different GitHub repositories.

The official website of Serverless Devs has the following appeals:

● Documents from GitHub sources in different warehouses are displayed in one interface

● Component developers focus on component documentation, which is automatically synchronized to the official website in real time

● Once components are changed, the official website can automatically deploy and build the overall scheme as follows:

The developer updates the document in GitHub and triggers the Http Serverless function configured by the webhook. Note here: Due to the variable number of components' documents and the unstable GitHub network, it is very easy to cause a timeout if all work is processed in the Http function. Therefore, all processing logic is placed in asynchronous calls, and the results of the processing are delivered to channels such as staples or emails after execution.

Alibaba Cloud Functional Computing Console Practice Alibaba Cloud Functional Computing FC Console is the first stop for users to use functional computing products, and the user experience of the console is crucial.

There are several architectural issues:

● The backend adopts a centralized deployment mode, resulting in very high user access delays overseas

● Require users to manually build monitoring, logging, grayscale, and other capabilities, resulting in high operation and maintenance costs

● Low research and development efficiency, requiring coordination and communication between the front and rear ends during the development process, and high collaboration costs. The overall solution is as follows:

On the left is Alibaba Cloud's common gateway, responsible for unifying authentication and security logic, and pulling out the BFF (Back for Front) layer. The characteristics of this part are as follows:

● The overall BFF is deployed on Alibaba Cloud functional computing FC, and developers do not need to manually operate and maintain it

● The BFF layer is in the charge of front-end engineers, who better penetrate the business and provide an excellent user experience

● Backend engineers focus on providing underlying stability and atomic capabilities, and deliver them to BFF through SDK

BFF implemented through Serverless not only brings great flexibility to the business, but also has a qualitative change for the group of front-end engineers: from the previous technical perspective to a more focused focus on business value and user experience improvement.

CD Construction Practice

The conventional self built CD cluster solution uses Jenkins or Tekton frameworks to orchestrate business logic, and the resource level uses K8s deployment to achieve elastic scaling. If you need to implement a simple cloud based construction CD solution, using the above architecture is slightly complex. The CI/CD business scenario has the following characteristics: ● Execution is triggered by events ● Traffic cannot be predicted in advance ● It requires a long time of running in the background and is insensitive to latency ● Due to network latency and other issues, it is necessary to design a failure retry mechanism These characteristics are completely tailored for Serverless. The implementation scheme also uses asynchronous functions to guide all processes of the build into asynchronous functions for processing. The entire orchestration logic is performed through Serverless Devs, perfectly achieving a stable performance CD build cluster. The underlying CD capabilities of Alibaba Cloud Functional Computing Application Center are fully based on the above principles for practice, and you can experience them yourself.

Asynchronous function

There are many scenarios where asynchronous functions are used in practice. Here is a brief introduction to asynchronous functions.

In summary, asynchronous functions have four characteristics:

1. Can operate for long periods, ranging from two hours to one day

2. Automatic termination can be set, time can be adjusted freely, and resources can be saved

3. The trigger results can be distributed to various event cashing centers

4. There are three opportunities to automatically retry in the event of a failure