How Knative Enables Low‑Code Serverless Workflows for Complex Business Logic

Introduction

Microservices have evolved over many years, and while they bring benefits such as fine‑grained services and easier maintenance, they also introduce new complexities like service discovery, consistency, fault tolerance, distributed transactions, circuit breaking, and configuration management. As services become more granular, the overall business complexity shifts to the inter‑service call graph, making it harder to understand and maintain.

To address the additional complexity, service mesh solutions encapsulate many cross‑cutting concerns in sidecars, allowing developers to focus on business code. However, even with service mesh, developers still write a lot of boilerplate. This article investigates how Knative can further reduce code and simplify complex business logic.

Knative Overview

Knative is a Kubernetes‑based serverless framework released by Google in 2018 and now maintained by Google, Red Hat, IBM, Pivotal, and others. It abstracts common cloud‑native functions such as service deployment and traffic management on top of Kubernetes and Istio, so users do not need to manage Deployments, ReplicaSets, Pods, or Ingress directly. Knative consists of three main modules:

Build : Handles CI/CD pipelines (now delegated to Tekton).

Serving : Deploys and manages serverless applications.

Eventing : Provides event‑driven publish/subscribe capabilities.

Serving Components

Service : Represents an application, managing its lifecycle and related resources such as Route and Configuration.

Route : Controls traffic routing to specific Revisions.

Configuration : Stores the latest desired state; each change creates a new immutable Revision.

Revision : A snapshot of code and configuration at a point in time.

Eventing Components

Event Consumer : Implements the Addressable or Callable interface to receive events.

Event Source : Produces events (e.g., K8s API server, GitHub, Kafka, WebSocket).

CloudEvent : Standard format for event data.

Broker : Receives events and forwards them to Subscribers that match Trigger filters.

Trigger : Defines filtering rules and the subscriber for a Broker.

Event Registry : Collection of EventTypes.

Event Channel : Persistent layer for events.

Event Subscription : Subscribes consumers to events.

Workflow Construction on Knative

Knative Eventing offers two high‑level workflow resources:

Sequence : Executes steps sequentially.

Parallel : Executes multiple branches in parallel.

Although these resources simplify workflow definition, they are insufficient for production‑grade needs. To build a robust serverless workflow platform, iQIYI’s “iQIYI Channel” project wraps Knative Eventing and adds a drag‑and‑drop UI, CI/CD integration, and additional orchestration logic.

Workflow System Architecture

Workflow‑Dashboard : Front‑end UI for creating and visualizing workflows.

Workflow‑Api : Backend service that generates YAML definitions and applies them to the cluster.

Workflow‑Operator : Watches custom Workflow resources, parses the YAML, and creates/updates the corresponding Knative Eventing components.

Workflow‑Syncer : Monitors Workflow status and persists it to a database for the UI.

Creating a Workflow

Developer logs into the Workflow UI, drags components to define a workflow, and submits it to Workflow‑Api.

Workflow‑Api creates a Git repository, scaffolds the project structure, and generates the necessary YAML files.

Developer pulls the repository, implements business logic in the cmd directory (e.g., Go code in main.go), and pushes changes.

Workflow‑UI triggers a CI pipeline (GitLab‑CI) that builds Docker images with ko, replaces image references in the YAML, and applies the resources to the Kubernetes cluster.

Workflow‑Operator parses the custom FlowApp CRD (apiVersion apps.iqiyi.com/v1alpha1) and creates the required Knative Eventing components.

Workflow‑Syncer watches the resource status, stores it in a database, and updates the UI.

Monitoring and Alerting

Serverless workflow monitoring is achieved by instrumenting business services with Prometheus client libraries. Knative Eventing uses CloudEvents over HTTP, so HTTP metrics (status codes, latency, QPS) are exposed at /metrics. Rancher‑integrated Prometheus collects these metrics, and Grafana visualizes them. Alerts are sent via webhook to the company’s unified alerting platform.

Conclusion and Outlook

The iQIYI Channel Serverless Workflow platform aims to reduce repetitive coding and simplify complex business logic by providing a low‑code, visual workflow editor. Future work includes supporting more sophisticated workflow nodes (e.g., loops, conditionals), richer workflow‑level monitoring, multi‑language support (Java, Python), and synchronous execution models.

Source: iQIYI Product Technology Team