In the serverless era, this is the correct way to develop web applications

Just as the iPhone subverted Nokia, the emergence of Serverless has also brought a new and subversive cloud development architecture model. Before the advent of serverless, developers couldn’t imagine how quickly a web application could be deployed online in minutes. Recently, Amazon Cloud Technology Tech Talk specially invited Sun Hua, a senior serverless technology expert, to share “How to Construct Serverless Web Applications Efficiently and Minimally”. Sun Hua introduced the construction of serverless web applications from the perspective of Amazon Lambda, and described how to use the newly released Lambda Function URLs and Lambda Adapter to further simplify the development and debugging of serverless web applications and implement web applications in Lambda, Fargate and Lambda. Smooth migration between computing platforms such as EC2.

Application Development in the Serverless Era

In 2012, Iron Company first proposed the concept of Serverless. In 2014, Amazon Cloud Technology released Amazon Lambda for the first time to bring Serverless from concept to implementation, which also marked the beginning of the Serverless era. Sun Hua believes that Amazon Lambda, as a serverless computing service, mainly has the following four characteristics.

• No need to deploy management infrastructure: Serverless computing doesn’t mean there are no servers, it’s the fact that there is no need to manage deployment servers.

• Automatic expansion: No need to consider the issues of capacity expansion and capacity planning, the underlying services will automatically realize on-demand capacity expansion.

• Pay-as-you-go: Charge according to time and usage to avoid wasting idle computing resources.

• Highly reliable and secure: Developed based on a high-availability architecture, with high availability.

The advent of Amazon Lambda provides a minimalist model for application development and deployment. At present, Amazon Lambda has hundreds of thousands of users, and the peak invocation of users usually exceeds one million per second.

The Coca-Cola Company is one of Amazon Lambda’s users. During the epidemic, Coca-Cola quickly brought the prototype of the mobile pour application online in just one week through Amazon Lambda, realizing millisecond-level communication between mobile phones and beverage machines, and shortening the time from idea to delivery by 50%.

Babble is an online education service provider. During the epidemic, the number of online learning visits increased by 2-3 times. By migrating services to Amazon Lambda servers, Babble improved P95 performance by 250ms (nearly a 50% reduction) and reduced costs by a quarter by improving utilization.

Serverless Web Application Use Cases

Common application scenarios of serverless architecture include data processing, IT operation and maintenance automation, etc. Many users will also apply serverless to front-end web applications, including Flask, Django, Express.js, Rails and other applications. Serverless can render the corresponding web page to the client, and also supports the REST API that provides json to separate the front and back ends. The static React, Angular, and Vue front-ends call the back-end APIs through HTTP requests to obtain data and display them to customers. . In addition, mobile back-end applications often use Serverless to develop the back-end of small programs.

What are the characteristics of serverless web applications? First of all, in the most common way of developing web applications, the web application process runs in the server. At this time, the web application will listen to a port. Moreover, in Amazon Lambda, each request is processed by a separate computing instance, regardless of CPU or memory, it is dedicated to serving this request. The advantage of this method is that each request can be isolated, and no one request will crash, affecting the concurrent needs of other users.

Second, web applications running in Amazon Lambda need to be stateless applications. Because Amazon Lambda requests are randomly distributed to multiple computing instances, each computing instance caches data locally, and the next request coming in may not be allocated to the same instance. So, if you need shared state, you can store it in Redis or a database.

Third, in the computing environment of Amazon Lambda, after each invocation request is processed, the computing environment will be frozen until the next request. During this time, there is no CPU resource, and background tasks cannot run, so background processes cannot be run in Amazon Lambda.

The most common web application architecture based on front-end and back-end separation usually puts the front-end SPEA application on Amazon S3 for HTTP, Django, etc., and the front-end is accelerated by CDN. After the user downloads the front-end, the front-end will call the dynamic data of the back-end through API Gateway. API Gateway provides the corresponding HTTP entry and triggers the Lambda function to run the web application. Web applications can access the database or any backend.

New: Lambda Function URLs

Amazon Cloud Technologies often receives feedback from customers. Customers want to learn to run web applications on Amazon Lambda or run individual applications inside a Lambda Function. To process all the business logic corresponding to the URL in Lambda Function, only one HTTP entry needs to be exposed, and there is hardly any additional learning cost. Last month, Amazon Cloud Technology launched the built-in Function URLs port of Amazon Lambda, which can provide HTTPS Endpoint by configuring a Function URL in the Lambda function. This feature is currently only available on Amazon Global, and will be launched in China in the near future. Function URLs point to the latest version of Amazon Lambda, or an Amazon Lambda alias. An Amazon Lambda alias can point to 1-2 versions of Amazon Lambda, so grayscale release or blue-green deployment can be performed by pointing to the alias.

What is the difference between Lambda Function URLs and API Gateway?

First, Function URLs are a very simple built-in way to provide HTTP entry. It is an HTTP entry exposed on the public network. The entry method is HTTPS. The authentication method can be controlled by IAM or implemented on the public network. Function URLs do not provide Custom domain support, but provide CORS support, so cross-site requests can be made. For example, when the browser sends Option, Function URLs will actively return the corresponding result according to the configuration, without offending the Lambda function. However, Function URLs only have some simple functions, and some advanced functions cannot be implemented, such as using Usage Plans, WAF-based integration and providing Private Enedpoint internally, which currently cannot be implemented by Function URLs. So, if you want to use features like WAF, Usage Private, Private Enedpoint, etc., use API Gateway’s Rest API.

Secondly, the timeout period of Lambda Function URLs is the same as the timeout period of the function. For example, the function needs to run for a maximum of 15 minutes, and the Lambda Function URLs request can run for 15 minutes, while the timeout period of Rest API and HTTP API is only 29 minutes. -30s. In terms of Payload Size, Function URLs are the same as Amazon Lambda, both 6MB.

Third, there is no additional fee for using Lambda Function URLs, but there is a corresponding fee for using Rest API and HTTP API.

Many users require web applications to have corresponding custom domain names to access websites. At this time, you can add a custom domain name through CDN, for example, add your own domain name to CloudFront, and combine with Amazon WAF to protect the corresponding integrated applications. Because Function URLs only provide the HTTPS entry, when the CDN returns to the origin, it returns to the origin site through HTTPS. The Host Header cannot be sent back to the origin site, and the user-defined domain name that the user actually visits cannot be obtained. If the domain name is fixed, you can learn it through configuration in the application, but if the domain name is not fixed, you need to determine which tenant is doing the corresponding processing based on the second-level domain name. In this case, you can take advantage of the capabilities of the CloudFront Function. CloudFront Function can obtain the domain name on the user request side, add it to another header, and then send the header back to the origin site. In the application of the origin site, the real domain name accessed by the user can be obtained through this header.

If a single-function web application is deployed based on Lambda Function URLs, and the dynamic request proxy is done through CloudFront, and the static resources are placed in Amazon S3, the following architecture will be unified, and API Gateway will not be needed.

New Tool: Lambda Adapter

Lambda Function URLs provide you with a very simple way to get HTTP entry, but the development method of Amazon Lambda is based on an event-driven approach, which converts events from event sources into json objects. For developers who are familiar with web application development, there will be additional learning costs. The general approach is to write a Handler function in the application, perform a layer of conversion, and convert json into the format required by the web application, but this method can further simplify.

The role of Lambda Adapter, a new tool launched by Amazon Cloud Technology, is to help users complete conversions. Use the Lambda Adapter to run web applications on Amazon Lambda without code modification. The Lambda Adapter obtains the corresponding json object from Amazon Lambda, converts it into an HTTP request, and sends it to the web application. After the web application processes it, it returns to the Lambda Adapter through the HTTP Response, and the Lambda Adapter converts it into the json Response format required by Lambda . In this way, no matter what language or web framework is used, web applications or HTTP APIs can be developed in this way, without modifying the code or adding any dependencies, and running on Amazon Lambda without the need for Using special tools, debugging APIs can be developed locally using familiar methods.

In addition, Lambda Adapter supports API Gateway’s Rest API and HTTP API as HTTP event sources. Regardless of the format, the Lambda Adapter can parse and convert it accordingly. At the same time, because the event format of Lambda Function URLs is exactly the same as that of API Gateway HTTP API V2, Lambda Adapter can access Lambda Function URLs without any modification. Users can run web applications or HTTP APIs on Lambda by combining Lambda Function URLs and Lambda Adapter. At the same time, because the web application may return Binary data such as pictures, and because json cannot directly store Binary data, the Binary data needs to be base64 encoded, and the Lambda Adapter will detect whether the returned data is Binary data, and automatically complete the base64 transcoding Work.

At the same time, Adapter supports packaging functions in the way of container images, and also supports packaging functions in the way of zip. When a user uses a container image to package a function, the resulting container image can run on Amazon Lambda, in a container environment, or even on a local computer. Therefore, Web applications can be easily run on different computing platforms, and can be smoothly migrated between different platforms without modification.

Constructing Serverless Web Applications in Practice

Through Lambda Function URLs and Lambda Adapter, you can easily build web applications through familiar APIs. But if I use the Lambda Adapter, can I run my existing web application on Amazon Lambda?

Amazon Cloud Technology tried it out with WooCommerce. WooCommerce is an e-commerce scenario, why try to run WooCommerce on Amazon Lambda? First of all, on the Buildwith website, among the 100 most visited websites, WooCommerce occupies the first share; secondly, WordPress is developed based on PHP, and PHP is used in the construction of web application websites, and about 70-80% of the websites are It is developed based on PHP and is widely used. Third, the PHP language needs to be re-initialized for each request entering, which is very compatible with the stateless computing environment of Amazon Lambda.

The Amazon Cloud Technology team adopted the following serverless WooCommerce architecture, running WordPress on Amazon Lambda.

The front part of the architecture uses Route53 and CloudFront as the CDN, uses Amazon Lambda to run the application, uses Lambda Function URLs instead of API Gateway as the entry point, and stores static resources through Amazon S3. Then, through the Docker image in the Lambda function, the process management services run by PHP Runtime, NGINX Server and PHP FPM are loaded, and the WordPress and WooCommerce codes are packaged. The backend uses the corresponding database, such as Redis, the latest V2 database to cache the data, and uses the EFS shared system to save the files uploaded by the user. Through this architecture, Amazon Cloud Technology has realized running WordPress on a serverless basis.

What is the actual performance of running a website on Serverless? If you want to achieve better performance on your WordPress website, you can make WordPress static and put static content on the front-end CDN website. If running a WooCommerce e-commerce website, users browse products, add products to shopping carts, submit orders, and pay. These are dynamic requests and need to go back to the back-end PHP application. For static applications, performance can be achieved from no request to the highest peak within 3 minutes, and more than 20,000 orders can be processed per minute for 1 hour. In terms of cost, the API needs to be called 10 times for each order processed, that is, the Lambda function needs to be called 10 million times to process 1 million orders. According to statistics, the cost of 10 million Lambda function invocations is only $300. Not only that, the API response time of the website is also very stable during the test process, the P99 delay is only 1-2s, and the P50 delay is only about 500ms.

At the end of the sharing, Sun Hua demonstrated the actual performance of the website running on Serverless, and provided relevant information on Serverless. Interested developers can scan the QR code below to obtain it.

The text and pictures in this article are from InfoQ