Practical Guide | Application Development under Serverless Architecture

Application development process of Serverless architecture

The application development process based on Serverless architecture will be simpler than that based on traditional architecture. For application development under the Serverless architecture, users usually only need to write code according to the specifications, build products, and deploy them online.

As shown in Figure 1, CNCF Serverless Whitepaper v1.0 points out that the life cycle of a function starts from writing code and providing specification metadata. A Builder entity will obtain the code and specification, compile and convert them into artifacts, and then deploy the artifacts on a cluster with controller entities. The controller entity is responsible for expanding the number of function instances based on event traffic and/or load on the instance.

As shown in Figure 2, the complete process of function creation and update is as follows.

1) When creating a function, provide its metadata as part of the function creation, and compile it to make it publishable. Next, start and disable functions. Function deployment should be able to support the following use cases.

• Event Streaming: In this case, there may always be events in the queue, but they may need to be processed by requesting pause/resume.

• Warm Startup: At any time, the function with the least instances can quickly start the received "first" event, because the function has been deployed and is ready to serve the event (rather than cold startup), where the function is deployed at the first call through the "incoming" event.

2) Users can publish a function, which will create a new version (a copy of the latest version). The published version may be marked or aliased.

3) Users may want to directly execute/call functions (bypass event sources or API gateways) for debugging and development. The user can specify call parameters, such as the required version, synchronous/asynchronous operation, detailed log level, etc.

4) The user may want to obtain function statistics (such as number of calls, average running time, average delay, number of failures, number of retries, etc.).

5) Users may want to retrieve log data, which can be filtered by severity level, time range, and content. Log data is at each function level. It includes events such as function creation/deletion, warning or debugging messages, and optional function Stdout or Stderr. It is preferable to have one log entry per call or associate the log entry with a specific call (to allow easier tracking of the function execution flow).

As shown in Figure 3, taking Alibaba Cloud Serverless products as an example, the process of developing serverless applications in a production environment is as follows:

Step 1: Select a familiar programming language according to the runtime provided by the FaaS supplier, and then conduct project development and testing;

Step 2: upload the code to the FaaS platform after completion;

Step 3: After the upload is completed, the functions uploaded to the FaaS platform are triggered by API/SDK or some cloud event sources;

Step 4: The FaaS platform will execute the corresponding functions according to the triggered concurrency and other elasticity;

Step 5: The final user pays according to the actual resource usage.

Comparison with ServerFul application development process

Next, we will compare the application development under the traditional architecture with the application development under the Serverless architecture through the case in the production environment.

Take a Web application as an example. As shown in Figure 4;

In general, some Web applications are based on the traditional three-tier C/S architecture. For example, a common e-commerce application uses Java on the server side and HTML/JavaScript on the client side; Under this architecture, the server is only an ECS, which carries a lot of business functions and business logic. For example, most of the logic in the system (authentication, page navigation, search, transaction, etc.) is implemented on the server.

When it is transformed into the Serverless application form, the architecture is shown in Figure 5.

Step 1: In the Serverless application mode, remove the authentication logic from the original application and replace it with a third-party BaaS service;

Step 2: Allow the client to directly access some data content, which is completely hosted by a third party. Here, some security configurations will be used to manage the client's access to the corresponding data.

Step 3: The first two points have implied a very important third point, that is, part of the previous server logic has been transferred to the client, such as maintaining user sessions, understanding the application's UX structure, obtaining data and rendering the user interface. The client has actually gradually evolved into a single page application;

Step 4: There are still some tasks that need to be kept on the server, such as heavy computing tasks or operations that need to access large amounts of data. Taking "search" as an example, the search function can be split from the continuously running server, implemented in FaaS, and receives requests and returns responses from the API gateway (explained in detail later). This server-side function can read product data from the same database as the client. The original search code can be modified slightly to implement this "search" function;

Step 5: The "purchase" function can also be rewritten as another FaaS function. For security reasons, it needs to be implemented on the server side rather than the client side. It is also exposed to external use by the API gateway.

The development and launch of applications under the traditional virtual machine architecture are shown in Figure 6.

After code development, developers need to make preparations before going online, including but not limited to evaluating resources, purchasing servers, installing operating systems, installing server software, etc. After the completion of code deployment, professional people or teams are also required to continuously monitor, operate and maintain servers and other resources, such as smooth server expansion when traffic suddenly increases, When the traffic drops suddenly, the server needs to be smoothed and shrunk.

However, under the Serverless architecture, the entire development mode has changed greatly.

In combination with the above e-commerce website, see Figure 7. In the above application development and online process, only the business logic in the function is actually concerned by the Serverless architecture developers. As for the authentication logic, API gateway, database and other products and services originally on the server side, they are all provided by cloud manufacturers.

At the same time, users do not need to pay attention to server level maintenance, nor do they need to invest in operation and maintenance resources for the peaks and troughs of traffic. Users also do not need to pay extra for idle resources. The pay as you go and elastic scalability of the Serverless architecture, as well as the low operation and maintenance/no operation and maintenance capabilities of the server, can reduce users' resource costs and labor costs, significantly improve the overall R&D efficiency, and greatly guarantee the performance, security, and stability of the project.

To sum up, the obvious difference between the Serverless architecture and the traditional architecture application development process is that the former allows developers to focus more on their own business logic, emphasizes Noserver's mind, and hands more professional things to more professional people, which is conducive to business innovation and efficiency improvement, and reduces the business launch and iteration cycle.

Challenges

Although the Serverless architecture has developed rapidly and is considered by more people as the real cloud computing, even at the Cloud Habitat Conference in 2020, Serverless was once again asserted that "it will lead the next decade of cloud computing". However, the Serverless architecture still faces many challenges.

UC Berkeley's article "Cloud Programming Simplified: A Berkeley View on Serverless Computing" in 19 years summarized the following five challenges for the Serverless architecture.

1）Abstraction Challenge

Resource Requirement: With the Serverless product, developers can specify the memory size and execution time of cloud functions, but cannot specify other resource requirements. This prevents those who want to control more specific resources, such as CPU, GPU, or other types of accelerators.

Data dependency: Today's cloud function platform does not understand the data dependency between cloud functions, let alone the amount of data that these functions may exchange. This may lead to suboptimal placement, resulting in inefficient communication patterns.

2）System Challenge

Ephemeral Storage: One way to provide temporary storage for Serverless applications is to use an optimized network stack to build distributed memory services to ensure microsecond latency.

Durable Storage: Like other applications, Serverless database applications are limited by the latency of the storage system and IOPS, requiring long-term data storage and variable state semantics of the file system.

Coordination Service: The sharing state between functions usually uses the producer consumer design pattern, which requires consumers to know immediately when the producers.

Minimize Startup Time: The startup time includes three parts: first, the time to schedule and start resources to run cloud functions, second, the time to download application software environments (such as operating systems and libraries) to run functional codes, and third, the time to execute application specific startup tasks, such as the time to load and initialize data structures and libraries. Resource scheduling and initialization may incur significant latency and overhead due to the creation of an isolated execution environment and the configuration of the customer's VPC and IAM policies.

3）Networking Challenge

Cloud functionality can incur significant overhead on popular communication primitives such as broadcast, aggregation, and shuffle.

4）Security Challenge

The Serverless architecture reallocates security responsibilities, transferring many of them from cloud users to cloud providers without fundamentally changing them. However, the Serverless architecture also has the inherent risk of application decomposing multi tenant resources.

5）Computer Architecture Challenge

The performance improvement of x86 microprocessors that dominate the cloud is slow.

Of course, the challenges faced by the Serverless architecture as described here are relatively abstract. As far as the actual situation of the current industry is concerned, these challenges are still widespread, which is also the direction of continuous efforts of many cloud manufacturers. From the perspective of serverless developers, combining the above challenges with several issues that developers are most concerned about, it can be concluded that the current challenges faced by the serverless architecture include but are not limited to cold start issues, vendor lock-in, and incomplete supporting resources.

1 Cold start problem

The so-called cold start problem refers to that the Serverless architecture may trigger the environment preparation (initialization of the workspace), download files, configure the environment, load code and configuration, and start the complete instance startup process when it scales elastically. As a result, the original request response that can be obtained in milliseconds or tens of milliseconds needs to be obtained in hundreds of milliseconds or seconds, thus affecting the business processing speed.

As mentioned above, everything has two sides. While the Serverless architecture has the advantage of elastic scaling, it also introduces a new problem compared with the ServerFul architecture: cold start. Under the Serverless architecture, after the developer submits the code, the platform will only persist it and will not prepare the execution environment for it. Therefore, when the function is triggered for the first time, there will be a relatively long process of preparing the environment. This process includes getting through the network environment and preparing the required files, codes and other resources.

This process from the preparation of the environment to the execution of the function is called the cold start of the function. Because the Serverless architecture has elastic scalability, the Serverless service provider will increase or decrease the number of instances according to traffic fluctuations. Therefore, the platform may frequently prepare new environments, download function codes, and start instances to respond to emerging requests.

As shown in Figure 7, when a function in the FaaS platform of Serverless architecture is triggered, the FaaS platform will reuse the instance or start a new instance according to the specific situation.

As shown in Figure 8, when there are idle instances that meet the reuse requirements, the FaaS platform will be used preferentially. This process is the so-called hot start process. Otherwise, the FaaS platform will start a new instance to respond to the request at this time, which is the corresponding cold start process.

This automatic zero management level scaling of the Serverless architecture will continue until there are enough code instances to handle all workloads.

Among them, "Starting a New Instance" includes several steps such as initializing the workspace, downloading files and configuring the environment, loading code and dependencies, and starting a function instance. Compared with the hot start in milliseconds or tens of milliseconds, the extra steps of cold start may take hundreds of milliseconds or even seconds. This kind of situation occurs when a new instance starts in production, which affects the business response speed. It is usually the impact of the cold start that everyone is concerned about, as shown in Figure 9.

To sum up, it is not difficult to analyze and summarize the common scenarios of cold start problems.

First Start of Function: The first start of a function after deployment, usually because there is no existing instance, is prone to cold start.

Concurrency of requests: A new request is received before a request is completed. At this time, the FaaS platform will start a new instance to respond to the new request, resulting in a cold start problem.

Too long interval between two triggers: The interval between two triggers of a function exceeds the threshold value of the instance release time, which also causes the cold start problem of the function. At present, the cold start challenge faced by the Serverless architecture is severe, but it is not fatal, because various cloud manufacturers are trying to introduce solutions to the cold start problem, including but not limited to instance preheating, instance reservation, resource pooling, single instance multi concurrency, etc.

2 Manufacturer lock

The so-called vendor lock-in refers to the different forms of Serverless architecture developed by different vendors, including product form, function dimension, event data structure, etc. Once a vendor's Serverless architecture is used, it usually means that the FaaS part and the corresponding supporting back-end infrastructure also need to use the vendor's, and it will be difficult to carry out multi cloud deployment, project cross cloud vendor migration, etc, The cost is extremely high.

As we all know, functions are triggered by events, so the data structure agreed between the FaaS platform and the supporting infrastructure services often determines the function processing logic. If the event structures agreed by triggers of the same type from each manufacturer are different, huge costs will be incurred in multi cloud deployment and project migration across cloud manufacturers.

When developers develop a function and implement it in the Serverless architecture provided by different cloud vendors, the code logic and product capabilities involved are different, even the business logic and operation and maintenance tools are completely different.

Therefore, if you want to conduct business migration and multi cloud deployment across vendors, enterprises will face high compatibility costs, business logic transformation costs, multi product learning costs, data migration risks, etc.

Because there is no complete and unified specification that is followed by all cloud manufacturers at present, the serverless architectures of different manufacturers are heavily bound with their own products and business logic, and it is very difficult for developers to perform cross cloud disaster tolerance and cross cloud migration. At present, the serious problem of cloud manufacturers' locking of Serverless architecture is also one of the problems that developers complain most and worry most.

Of course, as far as this issue is concerned, CNCF and other organizations and teams are trying to improve and deal with it in a more standardized and scientific way at the upper level.

3 Incomplete supporting resources

The so-called supporting resources are not perfect, which means that one of the core ideas of the Serverless architecture is to entrust more and more professional things to cloud manufacturers. However, in the actual process, cloud manufacturers will not be able to do more "things that should be done in the Serverless architecture" due to some problems such as demand priority and their own business quality, which leads to many difficulties for developers in developing projects and O&M applications based on the Serverless architecture, Complaining constantly.

In the process of rapid development of Serverless architecture, various manufacturers are also striving to improve their supporting resources and facilities. However, the Serverless architecture still has many supporting resources that are not perfect, which does not allow developers to more smoothly complete the development of Serverless applications and more easily operate and maintain Serverless applications, mainly in the following aspects.

1) Supporting developer tools are complex and diverse, and lack of functions

On the one hand, there is a shortage of developer tool chains in the market, which makes development and deployment difficult, thus increasing costs; On the other hand, the lack of relevant tool chains further improves the experience of Serverless at the experience level. The lack of high-quality tool chains makes it more difficult for serverless developers who are worried about being bound by manufacturers to unbind with manufacturers.

In 2020, the first Cloud Native User Survey Report released by the Academy clearly pointed out that before using the Serverless architecture, 49% of users considered the deployment cost, 26% of users considered the manufacturer's binding, and 24% of users considered the perfection of relevant toolsets.

The fact behind these data is that developers have a strong demand for improving the tool chain. As far as the current situation is concerned, there is no absolutely unified and consistent Serverless developer tool. Each manufacturer has its own developer tool, and the use form and behavior are different. This has led to serious challenges for developers in research before development, debugging during development, and operation and maintenance after deployment.

In addition, the vast majority of Serverless developer tools are more resource orchestration and deployment tools than development tools and operation and maintenance tools, especially in debugging, the consistency between online and offline environments cannot be guaranteed; During operation and maintenance, the business cannot be debugged quickly, and it cannot be ensured that the error can be more easily checked; There is no unified and complete solution to the positioning problem, which leads to the high cost of learning and using the Serverless architecture for developers.

2) Supporting help documents and learning resources are not perfect, and learning costs are too high

As far as the current situation is concerned, the learning resources of the Serverless architecture are relatively scarce. There are no perfect learning resources and reference cases from the perspectives of text, video, experiments, or cases, tutorials, and best practices provided by manufacturers. It is precisely because Serverless has few learning resources and few development experience cases that developers find it difficult to find suitable learning resources in the learning stage. In the development process, they often encounter unknown errors, which seriously blocks the mental construction of the Serverless architecture on the developer side.

Of course, the above aspects are only part of the performance of the Serverless architecture in terms of supporting resources and facilities. In addition, how does the Serverless architecture integrate more closely with traditional frameworks; How to easily migrate traditional businesses to the Serverless architecture; How to monitor and alarm the Serverless architecture; How to manage serverless applications and serverless resources; What is the scientific release of Serverless architecture and the best practice of O&M? These issues also need to be studied and explored.

Today, although there are still many challenges to be faced with the Serverless architecture, everyone is trying to help users deploy business code to the Serverless architecture more simply and quickly through better experience. For example, the open-source Serverless Devs from Alibaba Cloud's Serverless team is a serverless application lifecycle management tool without vendor lock.

As shown in the figure, Serverless Devs can participate in the whole process of project creation, development, debugging, deployment and O&M, taking Alibaba Cloud function computing components as an example.

Figure 10 Schematic Diagram of Serverless Application for Full Life Cycle Management of Serverless Devs Project

• In the project creation phase, the project can be initially created through the developer tool or application center.

• During project development, the correctness of local development can be verified through local development, debugging and other capabilities.

• In the project debugging phase, the final debugging of the project can be carried out through local debugging, remote calling, log query and other capabilities.

• In the project deployment phase, you can first build a complete deployment package through dependency installation, project construction and other processes, and then deploy the project.

• In the later stage of operation and maintenance, you can check the project health through index query, locate problems through log query, and publish versions, aliases, grayscale through project publishing and other capabilities.

In addition, there is also strong support at the level of learning resources. Figure 11 shows a large number of Serverless courses provided by Alibaba Cloud developer community. （ 👉 2021 technical atlas)

Figure 11 A large number of Serverless courses provided by Alibaba Cloud developer community

Later, we also prepared a series of courses such as "Serverless Practical Strategy", and welcome your continuous attention.

4 Other challenges

The Serverless architecture is very popular now, and all manufacturers are making greater efforts to improve their own Serverless products and promote the ecological and mental construction of Serverless. But objectively speaking, the challenges exposed by the Serverless architecture are not only those described above.

1) Will the Serverless architecture face greater challenges in some security aspects?

The more professional things are handed over to more professional people, so that the Serverless architecture has greater security guarantees. However, because of the extreme flexibility of the Serverless architecture, developers have more concerns, "If someone maliciously attacks my business, will the extreme flexibility and pay as you go of the Serverless architecture cause me huge losses quickly?" This is different from the "inability to provide services" shown by traditional virtual machines, but it is more worrying for developers.

Although many manufacturers are solving this problem through the whitelist and blacklist functions of the API gateway, the upper limit configuration of instance resources for function computing and other related functions, many developers still have concerns.

2) Errors occur - difficult to perceive and troubleshoot?

Because the Serverless architecture has a more "black box" visual sense than the traditional virtual machine architecture, there are often some imperceptible errors when developing applications under the Serverless architecture.

For example, some inexperienced Serverless application developers may face serious cycle triggering problems when using object storage triggers. Specifically, "the client uploads images to the object storage, and the object storage trigger function performs image compression operations, and then writes the result image back to the object storage. If the trigger conditions here are not set clearly, it may cause cycle triggering compression and write back operations.". In addition to the described errors that are difficult to perceive, the Serverless architecture also faces the challenge of difficult troubleshooting. It is common for users to develop and debug business logic locally. After deploying the code online, accidental errors occur. At this time, because the user cannot log in to the machine for debugging, and the instance may be released after triggering, challenges such as difficulty in locating the problem and tracing the source occur.

To sum up, like the advantages of the Serverless architecture, although many of the challenges faced by the Serverless architecture have been illustrated in the previous article, some of the challenges have already been solved. We will also introduce how to solve them in this series of articles. Although the Serverless architecture faces many challenges, these challenges will also bring new opportunities to more organizations and teams!