The author | changshuai

The threshold of the FaaS

Cloud services in the form of Serverless help developers to undertake a large number of complex capacity expansion and reduction, operation and maintenance, capacity planning, cloud product integration and other responsibilities, enabling developers to focus on business logic, improve the delivery speed (time-to-market), and continue to optimize costs. Function-as-a-service (FaaS), as the earliest and most widely used Serverless computing form on cloud, has attracted a large number of developers in a few years and gradually established the Serverless priority selection logic. However, migrating from traditional apps to FaaS presents a number of challenges to the developer experience:

1. The environment is not unified: the deliverables format defined by different manufacturers varies in compatibility and richness of the operating environment, requiring developers to adapt or even recompile;

2. Learning costs: the difference between packaging dependent libraries, building into compressed code packages, and familiar development deployments;

3. Service limitation: for example, code package is limited to 100 MB level, which forces the separation of deliverable code dependency and increases the difficulty of management and release;

4. Poor versioning of deliverables: non-standard formats, inconsistent best practices, and the responsibility of the developer;

5. Ecological immaturity: Lack of support and integration of popular open source tools such as CI/CD pipeline.

Containers, on the other hand, revolutionize portability and delivery agility. Ecological deposits around containers are so rich and mature that they are widely accepted for use, and application containerization is fast becoming the de facto standard for development and deployment. However, the container itself does not alleviate the challenges of operation and maintenance, scaling, idle costs, and cloud service integration.

Function computations support container mirroring

Ali Cloud FaaS function computing supports container images as function deliverables, and comprehensively upgrades developer experience by combining the excellent development, deployment and ecology of containers (before launching) with features of function computing itself, such as operation free, zero idle cost and cloud service integration (after launching) :

• Simplify application Serverless: no need to modify code or recompile binary, shared object (*.so), local debugging, keep development and online environment consistent;

• Greater function code restrictions: the maximum image support before decompression is 1 GB (compared to the maximum 50MB before decompression of code package), avoiding separation of code and dependencies, simplifying distribution and deployment;

• Container image hierarchical cache: incremental code upload and pull, improve development efficiency and reduce cold start delay;

• Mirror sharing and reuse: logic can be transplanted to reduce repeated development and construction;

• Mixed deployment: Serverfull (ECS, container ACK) and Serverless (FC, ASK, SAE) of the same application, mixed deployment of different applications or cut flow between different services of the same application, achieving the balance of consistent performance, rigid resource delivery, rapid expansion, and minimal operation and maintenance.

• CI/CD: Continuous build, integration testing, code upload, storage and standard version management, rich open source ecosystem CI/CD tools can be reused.

Typical Customer scenarios

1. Event-driven audio and video processing

FaaS is the preferred cloud for self-built audio and video services due to its large traffic fluctuation, high requirements on computing resource elasticity, monitoring of video upload events, and dependence on services such as workflow and queues. However, the software most commonly used in such scenarios, FFMPEG, often needs to be customized to meet different requirements. Compiled binaries rely on shared objects (*.so) and libraries such as glibc in the compile environment and are incompatible with the FaaS runtime environment and cannot run. Not only does recompilation bring extra work, but different dependencies and versions also pose challenges to business stability.

As shown in the figure below, the existing Dockerfile is used to transcode logic and related dependencies to maintain the existing installation mode and completely isolated container sandbox operating environment, which greatly reduces migration costs, stability risks and FaaS development and deployment learning costs.

2. Serverless AI/ML model prediction and inference serving

AI/ML inference prediction service can also enjoy the benefits of FaaS free operation and maintenance, automatic scaling and low cost. However, community-popular frameworks such as TensorFlow are shared and reused as container images by default. Not only is full version coverage officially available, but the community ecosystem based on the official mirror is also very active.

In the offline model training phase, container images are deployed in ECS or ACK/ASK GPU clusters. In the serving inference/prediction stage, cpus are often the more cost-effective choice. Serving is characterized as request-driven and needs to be able to respond quickly to burst traffic, release resources during trough cycles, or even shrink to zero to save costs. Such requirements are naturally what function computing excels at.

It is not easy to deploy an example of TensoflowFlow Serving on a function calculation without container mirroring support. TensorFlow’s own library size far exceeds the code package’s 50MB limit. Packing dependencies into NAS can get around this problem, but it makes getting started and migrating more difficult. Irregular dependencies and versioning also introduce stability risks to changes. While using the container image and functions to calculate the HTTP Server programming model, a simple few lines of Dockerfile can be run in FC Tensorflow Serving:

Function computing support for container mirroring helps AI/ML scenarios mix and deploy containers and functions smoothly, unifying CICD tools, processes, and best practices. The function calculates operation-free, high-concurrency, hundred-millisecond instance expansion and 100% resource utilization to further optimize the quality of service and cost.

3. The traditional Web HTTP application Serverless evolves

There are three main requirements for traditional Web monolithic application modernization: responsibility separation, reduction of o&M burden (resource planning, system upgrade, security patches, and other o&M burdens), and cost optimization. While it is a best practice to use functions with a single responsibility, responsibility splitting often takes longer to design and refactor. With the mirroring capabilities of function computing, individual applications can be easily migrated to FaaS services to meet the demands of o&M free, flexible horizontal scaling, and 100% cost efficiency.

Due to historical reasons or complexity of traditional Web applications, the running environment (container mirroring) and service logic are highly coupled and the decoupling cost is high. Sometimes the operating system and dependent library versions have to be upgraded and recompiled in an environment provided by the FaaS vendor for Serverless transformation. Migrating to a Serverless architecture has time costs and stability risks. Function computing’s support for container mirroring helps traditional containerized Web applications enjoy the value of Serverless more quickly without modification, focusing time and energy on business logic innovation and iteration rather than repeating boring environments, relying on versioning, upgrade maintenance, and capacity planning and scaling.

4. Mixed deployment across cloud vendors

The pace of clouds on the enterprise is accelerating, but due to the nature of the business, a hybrid of private and public clouds will be the norm for quite some time to come. Enterprises even need multi-cloud vendors to ensure migration, disaster recovery, and rigid delivery of resources. Container mirroring is the default choice for both on-cloud and off-cloud software deliverables.

The customized runtime of function calculation chooses the interaction mode of HTTP Server standard. The programming mode of function code is not bound to the vendor, which alleviates enterprises’ concerns about vendor-lockin. The functions that can run on the cloud, Under the cloud even other cloud vendors can also be deployed as separate HTTP Web applications to service requests. Container functions can run on container services of other cloud services or self-built IaaS services to implement multi-cloud disaster recovery and elastic resource protection.

Cold start best practice

• Container image address You are advised to use the VPC image address calculated in the same region as the function, for example, registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1, to obtain the optimal image pull delay and stability.

• Image minimization, using tools like Docker-Slim to save only necessary dependencies and code, avoiding additional delays caused by unwanted documents, data, or other files;

• In the case of resource availability and thread safety, using single-instance multi-concurrency can avoid unnecessary cold start and reduce cost.

• Container images are used together with reserved instances to eliminate cold starts.

DevOps/GitOps best practices

Support for container mirroring standardizes build steps and function deliverables, making it possible to reuse CI/CD tools. Function calculation is integrated with Aliyun cloud DevOps service, and CI/CD assembly line is introduced.

As shown in the figure below, when a new code is pushed into the master branch of the code repository (Github/Gitlab), the construction pipeline task is started. According to the Dockerfile specified in the code, the container image will be built and pushed to ali Cloud container image service. The final step in the pipeline completes an automated release by deploying the functions that release the new version.

In addition to the fully automated continuous integration delivery experience of Cloud DevOps, Ali Cloud container mirror service and self-built open source CICD pipeline can also automate function publishing in the way shown in the figure below. The standardization of functional computing publishing enables enterprises to continuously deliver multiple different services with a unified tool, reduces the learning cost of deployment tools for development operation and maintenance personnel, and improves the success rate and delivery speed (time-to-market) with automated deployment.

And Custom Runtime

Function Computing has introduced the Custom Runtime in 2019. What are the similarities and differences between the Custom Container and the existing runtime?

• The same programming model and function calculation system interaction: exactly the same HTTP Server protocol, the existing Custom Runtime functions can be directly transplanted to the environment compatible custom container environment, no need to modify the code;

• There are different scenarios and trade-offs between the two Runtime:

1. For non-containerized applications, you can continue to use custom Runtime;

2. If the tolerance of cold start delay is low, you are advised to use Custom Runtime to save image pull time.

3. You are advised to use Cutome-Container Runtime for asynchronous offline jobs that have been containerized.

4. The Custom Container Runtime is preferred for applications that use functions to calculate reserved instances and where the deployment environment and service logic are closely coupled.

The future planning

As containers become the standard way for application delivery and deployment, FaaS will integrate more closely with container ecology to help containerized applications Serverless at a lower cost, including integration of surrounding ecosystems such as declarative deployment, application abstraction similar to K8s, and cloud native observability software integration. Container-image-based pull acceleration allows function calculations to be both portable and quick to start.

Both container technology and Serverless are designed to help users deliver faster to the time-to-market and continuously optimize costs, eliminating waste generated by idle resources and increasing enterprise competitiveness.

Eventually cloud native two technology: Serverless and container technology will become more cohesive, development and deployment operations narrowing differences, almost don’t need to change the business logic that allows developers to choose the appropriate technical solutions for different workloads, with an open, standard, unified the cloud native technology, continuous innovation, to create more value for customers.

Course recommended

In order for more developers to enjoy the dividends brought by Serverless, this time, we gathered 10+ Technical experts in the field of Serverless from Alibaba to create the most suitable Serverless open course for developers to learn and use immediately. Easily embrace the new paradigm of cloud computing – Serverless.

Click to free courses: developer.aliyun.com/learning/ro…