A diagram of the event-driven application architecture for brokers and triggers.

Red Hat OpenShift 4.5 makes it easier than ever to deploy and run event-driven applications that react to real-time information via event notifications. Empowered by OpenShift Serverless, applications come to life through events, scaling up resources as needed (or up to a pre-configured limit), and then scaling back to zero after the resource burst is over.

In this article, I briefly introduce the OpenShift Serverless features for developing event-driven applications in OpenShift 4.5. I also demonstrate these features with an example featuring Knative services and a Kafka event source.

Event-driven application architecture

Events provide a simple mechanism for applications to subscribe to a variety of event sources, including your own applications, cloud services from multiple providers, Software-as-a-Service (SaaS) systems, and Red Hat services such as AMQ Streams. The new Developer perspective in the OpenShift 4.5 web console makes it even easier to deploy event-driven applications without relying on YAML.

Serverless eventing in OpenShift 4.5

OpenShift Serverless provides several mechanisms for building event-driven applications:

  • Direct connections
  • Channels and subscriptions
  • Event filtering with brokers and triggers

The best method to use depends on the needs of the service.

Direct connections

The most simple event-driven architecture is a direct connection. Figure 1 shows the architecture for directly connecting a Knative service to an event source. Later in the article, I will show you how to use the new OpenShift Developer perspective to create a direct connection.

A diagram of the event-driven application architecture for a direct connection.
Figure 1: The event-driven application architecture for a direct connection.

Directly connecting sources to services works well, but what if you need to group multiple sources? What if multiple services need to subscribe to those groups?

Channels and subscriptions

Multiple sources and sinks can work together via OpenShift Serverless channels and subscriptions. Figure 2 shows the architecture of channels and subscriptions in an event-driven application.

A diagram of the event-driven application architecture for channels and subscriptions.
Figure 2: The event-driven application architecture for channels and subscriptions.

Event channels make groups of event sources easy to reuse. Subscriptions offer a simple way to tie events to Knative services.

Event brokers and triggers

OpenShift Serverless lets us quickly group and reuse events, but what about filtering event notifications? One option would be to add a function to the application code to only process certain kinds of events. While this approach might work, it risks notifying services about events that they don't need and will just throw out. Another method is to use filtering notifications, which will only notify the service when it is necessary.

The OpenShift Serverless event broker and trigger build on event sources to filter events before notifying the service, as shown in Figure 3.

A diagram of the event-driven application architecture for brokers and triggers.
Figure 3: The event-driven application architecture for brokers and triggers.

Creating Knative services

Since OpenShift 4.4, it has been possible to select a Knative Service resource type when adding a new application to a project. Adding a Knative Service resource type instantly allows any application to benefit from the power of OpenShift Serverless, as demonstrated in Figure 4.

A demonstrating of creating a Knative service in OpenShift.
Figure 4: Creating a Knative service in OpenShift.

Binding an event source to a Knative service

You can now use the OpenShift Developer perspective to create and bind event sources to Knative services. As demonstrated in Figure 5, you just drag the event source connector (arrow icon) out of an existing Knative service and select Event Source. Then, you configure the event source (in this case, a Kafka event source) with the event type that should trigger the application.

A demonstration of binding a Kafka event source to a Knative service in the OpenShift Developer perspective.
Figure 5: Binding a Kafka event source to a Knative service in the OpenShift Developer perspective.

Notice that the OpenShift Developer perspective provides a simple slide-out so that you can quickly see all of the resources related to the newly created event source.

Validating the event-driven application

The last step in building an event-driven application is to validate that the service is receiving notifications. The demo in Figure 6 shows the Kafka event source using two different Kafka topics to trigger the Knative service.

A demonstration of coding event notifications from a Kafka event source.
Figure 6: Event notifications from a Kafka event source.

Give us your feedback!

A huge part of the OpenShift developer experience process is receiving feedback and collaborating with our community and customers. We'd love to hear from you. We hope you will share your thoughts on the OpenShift 4.5 Developer Experience feedback page. You can also join our OpenShift Developer Experience Google Group to participate in discussions and learn about our Office Hours sessions, where you can collaborate with us and provide feedback about your experience using the OpenShift web console.

Get started with OpenShift 4.5

Are you ready to get started with the new OpenShift 4.5 web console? Try OpenShift 4.5 today.

Last updated: July 27, 2020