Serverless Eventing Architecture
Serverless is all about providing service on a provision as-used basis. Combining both you get the best of both worlds.
Join the DZone community and get the full member experience.Join For Free
Event-Driven Architecture (EDA) is a way of designing applications and services to respond to real-time information based on the sending and receiving of information about individual events. Serverless is all about providing service on a provision as-used basis. Combining both you get the best of both worlds.
Loose coupling of services - For better fault tolerance, and can add/remove functionality on the go without affecting others.
Near real-time streaming process - No more polling but react immediately when the event occurred
Fine-grained scaling - Independently scaled up and down to ZERO, to meet the event volume.
OpenShift Serverless Eventing
There are many options when it comes to serverless, but if you are already a firm believer of open source, none vendor lock-in solution on the cloud, then the best is going to be Kubernetes. Knative runs on Kubernetes and enables serverless capabilities. Knative Eventing is built for systems that want to adopt EDA in a serverless world.
Here are some of the components in Knative Eventing that you need to know before designing the Serverless Integration.
Channel and Brokers in terms of functionality are doing the same thing. (But when it comes to installation, you will need to set up Channel before Broker). Both are forwarding cloud events to its subscribers. As a pure Knative Developer you will use Subscription to get all events from the Channel and Triggers to get a selection of events from the Brokers.
Subscription: Listens to mychannel for events and populate the events to a knative function called myservice
Trigger: Listens to thebroker for events and populate the events to a knative function called myservice
With the above, we can start integration with events, and startup the serverless functions.
As a Camel K developer, you can forget about this complexity of Trigger and Subscription, we can still utilize both Channel and Broker but not worry about the detailed implementations, focus on what you need to Integrate.
Camel K has all the components that you need for creating serverless Integration functions. First, it runs natively on OpenShift/Kubernetes, so it’s automatically packaged as a container. It detects if Openshift Serverless is enabled, and automatically turns the application into a serverless function. Camel K runs on Quarkus, with it’s lightning bootstrap time, the latency is minimized when it first starts up after receiving the event when cold. Lastly, the new knative components allowing developers to easily retrieve and publish to the Channels and Brokers in the environments.
In terms of integration, Apache Camel is hard to beat, with all the established integration patterns and built-in components, now we have just boosted your serverless system with infinite possibilities to connect to almost anywhere.
Listens to mychannel for events and populate the events to a knative function called myservice
Listens to thebroker for events and populate the events to a knative function called myservice
There is no dependency needed, all developers have to do it to run the Camel K CLI to create an integration function.
Putting Both Together — Sample Architecture
Using the Camel components, such as Salesforce, to retrieve or populate data to external sources and automatically wrap the data into CloudEvents. Continue with the flow, now the event is ready to be sent to Channels, Brokers, or other Knative service endpoints. Camel K can subscribe to a Channel and start its normal integration work, such as normalizing dataformats, Data enrichment, event splitting, content-based routing...etc. The same applies when subscribing to brokers. Lastly, events can be passed to other cloud services, internal microservice, applications, or any data store as sink. Again, the components in Camel K come to the rescue, simply configure the endpoint in Camel K to write to the destination.
Camel K can be also used to orchestrate functions for separation of concern by removing the integration process from the function making each function cleaner with just its business value.
In Eventing, there is so-called sequential or parallel flow, it can easily be done by Camel K, by each subscribing to channels for sequential flow that are in-order and get runs when events are sent to the channel. The parallel is just simply subscribing to brokers, and each integration will execute in parallel instantly after the event arrives.
Here is a small exercise for you if you are interested in learning more about Camel K with OpenShift Serverless Platform. This shows an idiomatic way of using Camel K in OpenShift Serverless for building serverless event-driven applications. (Click Here)
Opinions expressed by DZone contributors are their own.