Serverless App Engine (SAE) is an application-oriented, serverless Platform-as-a-Service (PaaS) that frees you from managing Infrastructure-as-a-Service (IaaS). It provides on-demand, pay-as-you-go resources and simplifies the cloud migration of applications built with technology stacks such as microservices, Java, and PHP. This topic describes how to use SAE and provides tutorials to help you quickly get started with SAE.
Background information
For more information, see What is Serverless App Engine?.
SAE workflow
The following figure shows the workflow for using SAE.
Before you deploy an SAE application for the first time, plan the VPC, vSwitch, and namespaces. Namespaces help you distinguish between environments, such as test, staging, and production.
For more information, see Preparations.
Deploy an application in the SAE console.
For more information, see Application deployment. In addition to deploying applications in the console, SAE supports deployment using various methods, such as Jenkins, IDE plug-ins, Maven plug-ins, Terraform, OpenAPI, Alibaba Cloud DevOps, and the kubectl-sae tool.
NoteIf you are deploying an application to SAE for the first time, create an application in the SAE console.
Access the SAE application in one of the following ways.
Method 1: Bind a Network Load Balancer (NLB) instance for access. One port can be bound to a single application. For more information, see Bind an NLB instance to an application for service access.
Method 2: Configure gateway routing for access. One port can be bound to multiple applications. For more information, see Use an Ingress to forward external traffic based on gateway routing rules.
Method 3: Bind an EIP for access. One instance can be bound to a single EIP. For more information, see Configure public access for SAE instances and the ability to access the internet using EIPs.
Configure advanced features for the SAE application.
Examples include enterprise-level access control, elastic scaling for cost reduction and efficiency improvement, enhanced Java microservices, high availability, and storage.
Deployment
SAE supports deploying applications from code packages and deploying applications from images.
Startup command and parameters
Image deployment
You can write the startup command and related parameters directly in the Dockerfile. You can also override the startup command when you create the application.
Package deployment
You can configure parameters for the application startup command. For example, for Java, the default startup command format is
Java[-Options] -jar jarfile[arg...]. You can customize the[-Options]and[arg...]parameters.
Database whitelist
Unlike ECS instances, SAE applications run in containers, and their IP addresses may change after each deployment. However, the CIDR block of the vSwitch that is bound to the application remains unchanged. Therefore, you can add the CIDR block of the vSwitch to the database whitelist. For more information, see Access Alibaba Cloud databases from applications.
CI/CD
In addition to console-based and API-based deployment, SAE is integrated with multiple continuous integration and continuous delivery (CI/CD) tools, such as Alibaba Cloud DevOps and Jenkins. You can use these tools to automatically deploy applications after code is committed. For more information, see Overview of application hosting.
Upgrade and rollback
SAE supports a variety of release policies, such as single-batch release, phased release, canary release, and rollback to historical versions. For more information, see Upgrade and roll back an application.
Permission configuration
SAE supports fine-grained access control. You can configure permissions based on namespaces, applications, and read and write operations. The permission assistant simplifies the configuration process. For more information, see SAE permission assistant.
Other
Network
After you deploy an application to SAE, you may have different network access requirements. For more information, see Concepts and capabilities related to SAE networks.
Basic concepts of Alibaba Cloud networks
Virtual private cloud (VPC): A VPC is a custom private network that you create on Alibaba Cloud. VPCs are logically isolated from each other.
NoteBy default, access from VPCs to the internet is denied.
vSwitch: A vSwitch is a basic network device that connects different cloud resources in a VPC. A vSwitch corresponds to a physical data center. When you create a cloud resource in a VPC, you must specify a vSwitch for it to connect to.
Elastic IP address (EIP): An EIP can be bound to only a single resource, such as an ECS or SAE instance. After you bind an EIP to a resource, the resource can access and be accessed by other services over the internet.
NAT Gateway: The source network address translation (SNAT) feature of a NAT Gateway allows resources in a VPC to access the internet. An Internet NAT gateway can be used for all resources in a VPC, whereas an EIP can be used for only a single resource in a VPC.
Main scenarios and methods for SAE network access
After you deploy an application to SAE, you may have the following network access requirements. The following figure illustrates the concept.
Access SAE applications from the internet (inbound traffic)
You can use one of the following methods to enable access.
SAE Service: Access the application through an SAE service. You can implement this using a public NLB or a public CLB.
SAE Ingress: Access the application through an SAE Ingress (gateway route). You can implement this using a public API Gateway, a public ALB, or a public MSE cloud-native gateway. This lets you route traffic to different SAE applications based on different domain names and paths.
SAE EIP: Bind an EIP to each instance of an SAE application. This allows the instance to both access and be accessed from the internet.
Access the internet from SAE applications (outbound traffic)
You can use one of the following methods to enable access.
NAT Gateway: Configure an Internet NAT gateway for the VPC associated with the SAE application. Then, all related SAE applications can access the internet.
SAE EIP: Bind an EIP to each instance of an SAE application. This allows the instance to both access and be accessed from the internet.
Enable mutual access between microservice applications using a service registry
For more information, see Service registration and discovery based on Nacos and other service registries.
Enable mutual access between applications over the internal network
In serverless mode, a new internal IP address is generated for each deployment. Therefore, direct access between applications based on instance IP addresses is not supported. You can use one of the following methods to enable access.
SAE Service: Access the application through an SAE service. You can implement this using a private NLB or a private CLB.
SAE Ingress: Access the application through an SAE Ingress (gateway route). You can implement this using a private API Gateway, a private ALB, or a private MSE cloud-native gateway. This lets you route traffic to different SAE applications based on different domain names and paths.
Access ECS instances, ApsaraDB RDS, and Tair (Redis OSS-compatible) from SAE applications in the same VPC
SAE is based on Alibaba Cloud VPC networks. Therefore, you do not need to perform extra configurations to access other resources in the same VPC, such as ECS instances, ApsaraDB RDS, and Tair (Redis OSS-compatible). Conversely, other Alibaba Cloud resources in the same VPC can also access SAE.
Make sure that the security group and product whitelist are configured correctly. If you encounter issues, you can follow the troubleshooting steps in the FAQs.
Comparison of SAE network access methods
Differences between an SAE Service and an SAE Ingress (gateway route)
An SAE Ingress (gateway route) can route traffic to different applications based on domain names and paths, as shown in the following figure. A Service cannot do this. We recommend that you use an Ingress when possible. You can use a Service for scenarios that require the Layer 4 TCP protocol or when you cannot access the service using a domain name.
Differences between an SAE Service and a Kubernetes ServiceName
Kubernetes services have two modes. One is based on LoadBalancer, which corresponds to an SAE Service and can be implemented using an NLB or a CLB. The other is based on ClusterIP. SAE does not directly provide ClusterIP. Instead, it provides an accessible domain name, which is the Kubernetes ServiceName. The main differences are as follows.
Comparison item | Service | Kubernetes ServiceName |
Billing | Free of charge | |
Scenarios | For accessing applications from the Internet or a private network. | Suitable only for mutual access between SAE applications. |
O&M | Supports configuring related monitoring and alerts, and collecting access logs to SLS. This provides fine-grained troubleshooting capabilities. | Does not provide independent monitoring, alerting, or access log capabilities. You need to configure alerts and logs on the application side. |
Differences between ALB-based and CLB-based gateway routing
Application Load Balancer (ALB) is a load balancing service from Alibaba Cloud that is designed for application layer load scenarios, such as HTTP, HTTPS, and QUIC. For gateway routing scenarios, we recommend that you use an ALB. For more information, see Introduction to the Server Load Balancer (SLB) product family.
Differences between NAT gateway-based and EIP-based internet access
The following figure shows an example of EIP-based internet access where each instance is bound to an EIP. If there are not enough EIPs, instance creation fails and the instance cannot provide services.
The main differences between the NAT and EIP modes are as follows.
Comparison item | NAT | EIP |
Effective scope | A NAT gateway can be controlled at the VPC or vSwitch level. It provides a proxy service for all instances without public IP addresses in a VPC or vSwitch to access the internet. You need to configure only one NAT gateway for a VPC or vSwitch to enable all its instances to access the internet. | An EIP is at the instance level. For example, 10 instances require 10 EIPs. After an EIP is bound to an instance, the instance can both access and be accessed from the internet. |
Static public IP address | Yes. | No. After a new instance is successfully bound to an EIP, SAE destroys the original instance and unbinds the original EIP. Therefore, make sure that the number of EIPs is at least the number of instances plus one. EIPs are dynamic and are allocated from an IP pool. |
Typical scenarios | The application scales automatically. New instances need to access the internet by default and require a static IP address. This scenario is suitable for 95% of users. | The EIP can be variable. This is suitable for scenarios that require direct connection to instances, such as online meetings. You also need to control the lifecycle of each instance in a fine-grained manner. |
Billing | For more information about billing, see NAT Gateway billing. | For more information about billing, see EIP billing. When the number of instances does not exceed 20, EIPs are more cost-effective. |
Enhanced microservices
As a best practice product for serverless microservices architecture, SAE provides many enhancements for microservices capabilities.
Service registry
For more information, see Service registration and discovery based on Nacos and other service registries.
Configuration center
We recommend that you use the Nacos service registry of MSE. It provides the features of both a microservice registry and a configuration center. You can also use the distributed configuration management (ACM) feature that comes with SAE.
Microservices development
IDE-based automatic deployment
Compared with repackaging and deploying each time, one-click deployment from an IDE can greatly reduce your deployment time and improve development efficiency.
For more information, see Use Alibaba Cloud Toolkit to automatically deploy a microservice to SAE.
Interconnection between on-premises and cloud applications
After you adopt a microservices model, the number of your applications increases. In extreme cases, local development and joint debugging require starting all related microservice applications. To address this pain point, you can use the interconnection capability provided by the Alibaba Cloud Toolkit plug-in. For example, you can connect your local consumer directly to a provider deployed in SAE. This way, you do not need to start the provider locally, which greatly reduces development and debugging costs.
For more information, see Use Cloud Toolkit to implement interconnection between on-premises and cloud applications (IntelliJ IDEA).
Service administration
Service list
For applications that use the built-in Nacos, SAE provides basic service list query capabilities. If you use a self-managed registry or an MSE registry, you can log on to the corresponding console to query services. You do not need to view them in the SAE console.
For more information, see View the service list.
Graceful shutdown
Because the consumer client has a cache, it cannot promptly receive the offline notification from the microservice provider. Therefore, you usually need to remove the provider instance from the service registry and wait for the consumer's cache to refresh. To address this issue, SAE integrates with the graceful shutdown feature of Microservices Engine (MSE) to productize this process.
For more information, see Configure graceful start and shutdown.
Graceful start
A microservice provider can be called by a consumer as soon as it is registered with the service registry. However, the provider may still need further initialization, such as initializing the database connection pool. Therefore, for microservice applications with high traffic, we recommend that you enable the graceful start feature.
For more information, see Configure graceful start and shutdown.
Microservice canary release
SAE not only supports application lifecycle management but also provides canary release capabilities for microservice applications.
For more information, see Manage canary release rules and Perform a phased release for an application.
Throttling and degradation
For both microservice and monolithic applications, a sudden traffic burst, such as in a flash sale scenario, can cause the application to crash. If it is a microservice application, this may also cause an avalanche effect. Therefore, you must take protective measures. SAE integrates the traffic protection feature of Microservices Engine (MSE), which lets you easily configure and manage throttling and degradation rules.
For more information, see Traffic protection.
Application monitoring
In a microservices architecture, without a supporting monitoring system, it is difficult to discover and diagnose problems. SAE integrates with Application Real-Time Monitoring Service (ARMS). It provides dashboards, JVM monitoring, slow call monitoring, trace analysis, and alerting capabilities to lower the barrier for enterprises to implement a microservices architecture.
For more information, see Application Monitoring.
Multiple languages
PHP runtime support
SAE supports the following deployment methods:
Image: any PHP architecture application.
PHP ZIP package: any online application with a PHP-FPM and Nginx architecture.
SAE provides a default PHP runtime environment.
Static file hosting
Using NAS and OSS, SAE supports independent hosting of static files. It provides persistent storage for code, templates, and uploaded files during runtime, and enables file sharing across instances.
Remote debugging
The different features of SAE enable various debugging capabilities in SAE.
PHP remote debugging
SAE has a built-in Xdebug plug-in that enables remote debugging.
File download
SAE lets you log on to instances using Webshell and download files using SAE or OSS features. For more information, see Upload and download files using Webshell.
File upload
SAE facilitates code development and debugging using NAS and OSS.
Logs
SAE integrates with SLS and Kafka for log collection. The real-time log feature of SAE supports viewing 500 lines of log information. If you have higher viewing requirements, we recommend that you use the file log collection feature. SAE collects business file logs (log paths in containers) and container standard output (stdout) logs and sends them to SLS or Kafka. This lets you view an unlimited number of log lines and aggregate and analyze logs on your own, which facilitates business log integration.
File logs
SAE integrates with SLS for log collection, which you need to enable only in the SAE console. Unlike with ECS where you had to manually maintain a list of machines for collection, with SAE, after you configure the collection directory or file, SAE automatically connects with SLS for log collection during each deployment or scale-out. You can search for logs by keyword in the SLS console. For more information, see Configure log collection to Simple Log Service.
Log sources support wildcard characters. For example, /tmp/log/*.log indicates the collection of all files that end with log in the /tmp/log directory and its subdirectories.
In cases where it is inconvenient to use SLS for collection or a RAM user cannot view SLS logs, you can choose to import logs to Kafka. Based on this, you can deliver data from Kafka to other persistent databases, such as Elasticsearch, according to your business scenarios. This facilitates centralized log management and analysis. For more information, see Configure log collection to Kafka.
You can also set Logtail startup parameters using environment variables. For more information, see Configure environment variables to improve the collection performance of Logtail.
Real-time logs
SAE automatically collects stdout logs, retains the latest 500 entries, and lets you view them in the SAE console. For more information, see View real-time logs.
If you want to collect stdout content to SLS as well, you can first output the content to a file and then configure file collection. The parameters are shown in the following figure.
Storage
SAE comes with 20 GB of system disk storage. To read from and write to external storage, we recommend that you use NAS and OSS. Diagnosing SAE applications involves two methods: routine checks and log uploads. For log uploads, you can use not only OSS but also the built-in one-click upload and download feature in SAE.
For log scenarios, we recommend that you use SLS instead of NAS or OSS. For more information, see Configure log collection to Simple Log Service.
NAS
SAE supports NAS storage, which solves the problems of data persistence for application instances and data distribution between instances. NAS storage can be accessed only when it is mounted to an ECS instance or SAE application. For more information, see Configure NAS storage.
OSS
OSS provides convenient tools and a console for visual management of buckets. OSS is suitable for read-intensive scenarios, such as mounting configuration files or frontend static files. After you configure OSS storage when deploying an application in the SAE console, you can access the data through the OSS console. For more information, see Configure OSS storage.
You cannot use the ossfs tool in log writing scenarios. For more information, see ossfs 1.0.
Upload and download files
If you want to download files from SAE to your local machine, you can use the file upload and download feature built into Webshell. For more information, see Upload and download files using Webshell.
In addition to using NAS or OSS storage, you can also use the ossutil tool. For information about how to use Alibaba Cloud OSS for log upload and download, see Diagnose applications through routine checks.
Monitoring and alerts
SAE has built-in infrastructure monitoring and ARMS business monitoring for Java and PHP. The alert management system provides reliable alert convergence, notifications, automatic escalation, and other features to help you quickly detect and resolve business alerts.
Infrastructure monitoring
Infrastructure monitoring includes CPU, Load, MEM, disk, network, and TCP connections. For more information, see Infrastructure monitoring. The built-in infrastructure monitoring is provided by Alibaba CloudMonitor. You can also log on to the CloudMonitor console to configure custom dashboards.
Application monitoring
SAE Professional Edition applications integrate ARMS Pro application monitoring features. After you enable application monitoring, no extra fees are incurred, and the feature monitors your application in real time. For more information, see Professional Edition application monitoring.
SAE Standard Edition applications integrate ARMS Basic Edition monitoring. After you enable application monitoring, you can use this feature for free. However, an option to enable ARMS Pro monitoring features is also provided. After activation, extra fees are incurred, and you must view the data in ARMS. For more information, see Standard Edition application monitoring.
Alert settings
SAE supports setting alerts for each of the preceding metrics. For more information, see Alert management system.
High availability
After you deploy an application in SAE, you can use the health check feature for graceful start and shutdown of traffic. This feature lets you check whether application instances and business operations are normal so that you can locate problems when exceptions occur. At the same time, SAE supports deploying applications across multiple vSwitches to handle data center-level failures and supports using AHAS to implement throttling and degradation for Java applications. These features comprehensively ensure application availability.
Multi-vSwitch deployment
To handle data center-level failures, we recommend that you configure multiple vSwitches for production-level SAE applications. You can configure multiple vSwitches when you create an application or add vSwitches after the application is created. When you create a vSwitch, we recommend that you allocate a sufficient number of IP addresses (more than 100 is recommended). If the number of IP addresses is insufficient, application creation or elastic scaling may fail. For more information, see Switch vSwitches.
Using multiple vSwitches, SAE can help businesses automatically scale resources across multiple zones. You do not need to monitor the distribution of resources because SAE ensures the overall availability of resources. For example, in the event of a single point of failure or a zone failure, SAE migrates the failed instances to healthy nodes or other zones in seconds.
Select multiple vSwitches during creation.
Add a vSwitch after creation.
NoteWhen you add a vSwitch, make sure to synchronize the database whitelist configuration. For more information, see Access Alibaba Cloud databases from applications.
Graceful start and shutdown
When you deploy an application in SAE, it generally goes through a process of scaling out first and then scaling in. However, there are two major business pain points for graceful start and shutdown of traffic.
Whether the newly scaled-out instances are ready to handle traffic.
How to gracefully destroy old instances.
SAE is based on Kubernetes and provides two health check methods: liveness probes (Liveness configuration) and readiness probes (Readiness configuration). To address these two pain points, SAE supports the configuration of a readiness probe. The readiness probe periodically checks whether an instance is ready. After a new instance is ready, SAE directs traffic to it. If the check fails, SAE does not direct traffic to it. Before old instances are destroyed, they are first removed from the traffic flow. You can also configure a shutdown script and a waiting time before the instances are destroyed. For more information, see Configure health check.
The liveness probe also periodically checks whether an instance has started. If the check fails, SAE automatically restarts the container. This feature is useful for automated O&M in exceptional scenarios, but it may cause the context of the failure to be lost, making it impossible to investigate the cause. You can decide whether to configure a liveness probe based on your actual scenario.
In addition to configuring readiness or liveness probes, microservice scenarios also require you to configure graceful shutdown for microservices to solve the problem of caching in the service registry. For more information, see Configure graceful start and shutdown. In a production environment, using features such as automatic elastic scaling and rollback upgrades may cause services to be unavailable for a short time and cause business monitoring to report many errors. To address these pain points, SAE supports the configuration of graceful start for microservices. For more information, see Configure graceful start and shutdown.
Throttling and degradation
For high-traffic scenarios, SAE integrates the traffic protection feature of Microservices Engine (MSE) to easily configure and manage throttling and degradation rules, which ensures application availability. For more information, see Traffic protection.
Elasticity (cost reduction and efficiency improvement)
SAE supports elastic policies such as manual scaling, scheduled scaling, metric-based scaling, hybrid scaling, and scheduled start and stop. Elasticity is a typical feature of cloud-native architectures and applications that can help you reduce infrastructure costs and improve O&M efficiency.
Manual scaling
Manual scaling is suitable for manual O&M scenarios. Compared with the relatively complex and slow scaling process of ECS, SAE scaling is based on container images and is faster. For more information, see Manual scaling.
Scheduled scaling
Scheduled scaling is suitable for scenarios where traffic is predictable. For example, the catering and education industries have clear business peaks in the morning and evening each day. Therefore, you can configure different numbers of instances to run at different times to make server resources match the actual service traffic as closely as possible. For more information, see Configure an Auto Scaling policy.
Metric-based scaling
Metric-based scaling is suitable for scenarios where traffic is relatively unpredictable. It currently supports metrics such as CPU, MEM, TCP connections, QPS, and RT. For more information, see Configure an Auto Scaling policy.
Hybrid Elasticity
Hybrid scaling is suitable for scenarios with both burst traffic and scheduled scaling requirements, such as the internet, education, and catering industries. It allows for fine-grained adjustment of the number of instances for known time periods.
For example, on weekdays, the maximum number of elastic instances is configured as max and the minimum is min. However, if you do not need to maintain min instances on weekends, you can configure a different number of instances for weekends to reduce the value of min. For more information, see Configure an Auto Scaling policy.
Scheduled start and stop
The scheduled start and stop feature lets you start and stop applications in a namespace in batches at scheduled times. For example, you can schedule the start and stop of all applications in a development or test environment. Assume that you need to use a development and test environment only from 08:00 to 20:00 each day, and it remains idle for the rest of the time. You can configure scheduled start and stop in SAE to reduce costs. For more information, see Create a scheduled start and stop rule.
Practical tutorials
SAE provides best practices for various business requirements. This topic covers elasticity, networking, storage, and application access to Alibaba Cloud databases. Other best practices include images, application acceleration, and JVM parameter configuration. For more information about common scenarios, see Best practices.