OpenFaaS Product Background, Business Scenario, Architecture Design and Implementation

In the early stage of cloud service architecture, the idea was to let developers ignore the building and management of backend applications. The backend infrastructure is provided as services (e.g., databases, message queues, authentication services) hosted by third parties.

When Amazon released AWS Lambda in 2014, it introduced a new system architecture where functions are executed on demand without the need for a continuously running server process. This model, known as Function-as-a-Service (FaaS), triggered by events, has since been adopted by other cloud providers such as Google Cloud (alpha), Microsoft Azure, IBM OpenWhisk, and Chinese providers including Alibaba Cloud FC, Baidu Cloud CFC, and Tencent Cloud SCF. Popular open‑source FaaS frameworks include OpenFaaS, Knative, and OpenWhisk.

The project’s business background is Baidu’s Aladdin search platform, which provides structured data for search results. Offline tasks generate high‑quality data, while online servers run on Baidu’s search machines. The original solution deployed all scripts on physical machines, leading to resource waste and cumbersome deployment processes.

To reduce machine budget and improve stability, the team evaluated open‑source FaaS projects for secondary development on a Baidu Smart Cloud BCC VM with a CCE Kubernetes cluster. After comparing Knative, OpenFaaS, and OpenWhisk, OpenFaaS was chosen because it aligns with the existing technology stack, uses Prometheus and Alertmanager for autoscaling, and supports event connectors similar to AWS Lambda.

OpenFaaS’s event‑connector mechanism (Cron, MQTT, etc.) enables scheduled tasks, HTTP triggers, and other integrations. The overall architecture consists of:

Gateway – routes external events to specific function instances, collects traffic metrics, and handles rate limiting and failover.

Autoscaling – adjusts the number of function pods based on traffic and resource thresholds using Prometheus.

Data collection – gathers traffic and resource usage data for scaling decisions.

Log collection – captures and persists logs from function instances.

Controller – implements Kubernetes CRD logic.

Task instance – runs the actual script code.

Deployment platform – builds, versions, publishes functions, and provides runtime logs and execution history.

Task types include:

Synchronous tasks – require immediate results and have the highest priority.

Scheduled tasks – run at predefined times (e.g., full‑index builds) using the Cron connector.

Asynchronous tasks – long‑running jobs that do not need immediate feedback.

Stability measures cover gateway high‑availability (active‑standby), rate limiting, asynchronous handling, and degradation configuration. Monitoring is based on Prometheus with Alertmanager notifications for instance restarts, resource over‑usage, or failures. Logs are exported via Filebeat for persistence and can be viewed in the deployment platform.

For DNS resolution stability, three BNS (Baidu Naming Service) solutions were considered; the final choice was to inject a BNS host environment variable (方案3) by modifying the faas‑neters source code, which resolved intermittent resolution failures.

Project outcomes include a standardized deployment workflow, detailed release records for quick rollback, isolated task instances to avoid cross‑impact, and significant resource savings—only 14% of original CPU and 8% of memory are used. Further savings are possible by co‑locating low‑frequency scheduled tasks.