19.3 Serverless and event-driven workloads

Key Concepts: Serverless and Event-Driven

Serverless and event-driven approaches focus on reacting to events with small, loosely-coupled units of compute rather than long-running services you manage directly.

On OpenShift, this typically means:

• You don’t manage servers or pods directly for these components.
• Workloads scale to zero when idle (where applicable).
• Functions or services are invoked by events (HTTP, messages, timers, cloud events).
• Billing/consumption and resource usage are closely tied to actual activity.

In the Kubernetes/OpenShift ecosystem, this space is largely represented by Knative and tools built on top of it.

Types of Serverless Models on OpenShift

There are several patterns relevant for OpenShift:

1. Request-driven serverless (Knative Serving):
• HTTP/HTTPS-triggered workloads.
• Scale based on inbound requests; can scale to zero.
• Suitable for APIs, webhooks, microservices with spiky or unpredictable traffic.
2. Event-driven serverless (Knative Eventing and friends):
• Functions/services triggered by arbitrary events: messages, timers, storage events, etc.
• Uses a pub/sub model and CloudEvents for interoperability.
• Suitable for asynchronous processing, pipelines, data ingestion, and automation.
3. Function-as-a-Service (FaaS) abstractions on top of Knative:
• Higher-level “functions” frameworks (e.g., OpenShift Serverless Functions, KNative functions frameworks).
• Developers focus on a single function or small handler; build and deployment are automated.

These models can coexist in a single cluster and interoperate with traditional long-running deployments.

OpenShift Serverless: Core Building Blocks

OpenShift provides a commercial distribution of Knative under the umbrella of OpenShift Serverless. It typically consists of:

• Knative Serving: For HTTP-based serverless services.
• Knative Eventing: For event routing and processing.
• Optional function frameworks: To simplify code-level function development.

You interact with these components via:

• Custom resources (Service, Route, Broker, Trigger, etc.).
• CLI tools (e.g., kn in addition to oc).
• The OpenShift Web Console’s serverless views (when installed).

Knative Serving: Serverless Services on OpenShift

Knative Serving provides:

• Serverless Services:
• A Service (Knative Service, not a Kubernetes Service) describes a serverless app.
• Knative manages revisions, traffic splitting, and scaling.
• Revisions:
• Every new code or configuration change creates a new immutable Revision.
• Enables quick rollbacks and traffic canarying:
• Route 10% of traffic to a new revision, 90% to stable.
• Gradually increase allocation as confidence grows.
• Autoscaling and Scale-to-Zero:
• Uses an activator/proxy and scaling controller to adjust pod counts.
• Scale based on concurrency (requests per pod) and RPS.
• When idle for a configurable period, can scale down to 0:
• First request after cold start incurs some latency.
• Routing and URLs:
• Automatically creates externally accessible endpoints using OpenShift’s routing/ingress.
• Integrates with TLS, DNS, and custom domains configured at the cluster level.

When to Use Knative Serving vs Traditional Deployments

Use Knative Serving when:

• Load is highly bursty or intermittent.
• You want automatic scale-to-zero for cost/efficiency.
• You need fine-grained traffic control between revisions (progressive rollout).
• You are building lightweight APIs, webhooks, or endpoints that react to requests.

Prefer standard Deployments/DeploymentConfigs when:

• The workload must always be warm and low-latency.
• Start-up times are large and cold starts are unacceptable.
• You need stateful, long-running services that do not fit request-driven patterns.

Event-Driven Architectures with Knative Eventing

Knative Eventing focuses on producing, routing, transforming, and consuming events in a decoupled way.

Key primitives:

• Event Sources:
• Produce events from external systems (e.g., message brokers, Git events, timers).
• Write events to a sink: a Knative Service, Broker, Channel, or other HTTP endpoint.
• Brokers and Triggers:
• Broker: A central event mesh for a namespace; receives events and stores them in a backing channel/broker implementation.
• Trigger: Subscribes to a Broker, filters events (e.g., by CloudEvent attributes like type or source), and forwards them to a subscriber (e.g., a Knative Service).
• Enables a “pub/sub with filtering” pattern:
• Producers send events to a Broker.
• Multiple Triggers route events to different services based on content.
• Channels and Subscriptions:
• Channel: An abstraction for point-to-point or fan-out messaging using a backend (e.g., Kafka, in-memory).
• Subscription: Connects a Channel to a sink/service, optionally with reply-based chaining.
• Useful for building custom topologies or integrating specific messaging systems.
• CloudEvents:
• Events are normalized using the CloudEvents specification.
• Standard attributes (id, source, type, subject, time) simplify routing and interoperability.

Typical Event-Driven Patterns on OpenShift

Some common patterns using Knative Eventing:

1. Webhook Fan-Out:
• A single external webhook (e.g., Git, payment system) sends events to a Broker.
• Multiple Triggers deliver different events to different services:
• Build pipeline starter
• Notification service
• Audit logger
2. Async Processing Queue:
• A front-end API (possibly Knative Serving) immediately returns to the user.
• It emits an event to a Channel or Broker.
• Back-end worker services consume events and perform heavy processing.
3. Event-Based Workflows:
• Events from multiple systems (storage, message queues, databases) are combined.
• Steps of business logic are implemented as small serverless services.
• Each step emits a new event consumed by the next step.
4. Policy/Compliance Hooks:
• Cluster events (e.g., image scanned, policy violation) are fed into a Broker.
• Specific Triggers direct relevant events to policy engines, notifiers, or auditors.

Serverless on OpenShift: Tooling and Developer Experience

OpenShift enhances the raw Knative experience with:

• Operator-based installation and lifecycle:
• OpenShift Serverless Operator to install and configure Knative components.
• Integration with OpenShift networking, monitoring, and logging.
• CLI Support:
• kn CLI to create/update Service, Broker, Trigger, etc.
• oc and the web console for cluster-level management and troubleshooting.
• Function Frameworks and Templates:
• Quickstarts for writing small functions in various languages.
• Standardized build and deployment pipelines from source to Knative Service.
• UI Integration:
• Topology views showing serverless services and event flows.
• Visual representations of Brokers, Triggers, and their relationships.

This is designed to reduce friction compared to managing raw Kubernetes or hand-crafted CI/CD logic for similar workloads.

Design Considerations and Trade-Offs

When deciding whether to use serverless/event-driven approaches on OpenShift, consider:

Performance and Cold Starts

• Cold start: When a service scaled to 0 receives a new request, a pod must be started.
• Adds latency that may be noticeable for latency-sensitive workloads.
• Mitigations:
• Tune scale-to-zero and min-scale parameters.
• Use faster-starting runtimes (e.g., lightweight JVMs, native binaries, small containers).
• Keep a small baseline of warm pods for critical services.

Resource Economics

• Scale-to-zero and per-request scaling can:
• Improve resource utilization for intermittent workloads.
• Reduce the need to manage capacity for rarely used services.
• But high, consistent load might be equally well served (or simpler) with standard Deployments.

Observability and Debugging

Event-driven systems can be more complex to debug because:

• Control flow is implicit in event streams, not explicit in a single call stack.
• Multiple services can be triggered by the same event.

Effective practices:

• Consistent logging with correlation IDs in CloudEvents attributes.
• Use OpenShift’s monitoring and tracing stack to visualize event flows.
• Structured event schemas and documentation.

Reliability and Ordering

• Events may be:
• At-least-once, at-most-once, or exactly-once depending on backend.
• Ordered or unordered depending on channel implementation.

Design workflows to:

• Tolerate duplicates (idempotent handlers).
• Not depend on strict ordering unless your event backend guarantees it.

Security

Serverless components must adhere to cluster security controls:

• Configure RBAC and scopes for event sources that access APIs or external systems.
• Restrict who can create Broker, Trigger, and Service resources.
• Ensure secure ingress (TLS) for public-facing serverless services.
• Include event payload validation and authentication where needed.

Serverless and Event-Driven in Future OpenShift Ecosystem

Serverless/event-driven architectures intersect with several future-looking areas in the OpenShift ecosystem:

• Integration with CI/CD and GitOps:
• Events (Git push, image publish, test results) trigger pipelines and deployments.
• GitOps tools can drive configuration of Brokers/Triggers as code.
• Data and AI Platforms:
• Event-driven ingestion pipelines feeding data lakes or feature stores.
• Functions triggered on new data or model events (e.g., model retrain, drift detection).
• Hybrid and Multi-Cloud:
• CloudEvents provide a common language for events across environments.
• OpenShift clusters in different locations can participate in a larger event mesh.
• Edge and IoT:
• Edge clusters running OpenShift can use serverless for intermittently used logic.
• Events from devices are aggregated and processed through Knative-based pipelines.

Practical Usage Scenarios

On OpenShift, expect to encounter serverless and event-driven workloads in scenarios such as:

• Webhooks and API callbacks: Implementing small endpoints that respond to external systems without running full-time services.
• Event-driven microservices: Decomposing large services into smaller functions/services triggered by business events.
• Image and artifact processing: Trigger functions on new files in storage, new container images, or published artifacts.
• Automation and operations: Responding automatically to cluster events, security scans, or alerts by running small corrective actions.

Understanding these patterns prepares you to:

• Select appropriate models (serverless vs traditional).
• Compose event-driven pipelines using Knative on OpenShift.
• Integrate future ecosystem tools that build on events and functions as first-class primitives.