3 Specifications to Consider When Designing Event-Driven Applications
Make your event-driven applications interoperable and portable with AsyncAPI, CloudEvents, and Serverless Workflow specifications.
Event-driven applications are loosely-coupled and distributed in nature, built with multiple self-contained components.
These applications are often blamed for the lack of standardization in the components. For example, two event-driven systems will name their operations and event schemas differently, forcing developers to redo the same things repeatedly.
Three promising specifications are emerging in the event-driven application landscape to provide a common way to do things. They are aiming at making event-driven applications portable and interoperable across multiple cloud environments.
This article explores each of them on a high level.
AsyncAPI specification
Event-driven applications are often criticized for being hard to reason about the code. Their asynchronous, loosely-coupled nature made it difficult to trace the execution flow of an application.
For example, an event producer doesn’t know where the events it is producing would end up. Similarly, event consumer has no idea about who produced the event.
These applications are built and operated as loosely-coupled, independent components. Thus, developers have to bank on the documentation to understand the execution flow. The documentation can be a simple wiki page, calling a senior developer, or nothing at all.
That makes it hard for new developers to pick up the project’s pace in a short time. Also, teams who own different application components are not on the same page most of the time.
The AsyncAPI specification addresses this problem by providing a machine-readable specification to document and describe event-driven applications.
It documents the event producers and consumers of an application along with the events they exchange. That provides a single source of truth for the application in terms of control flow. Apart from that, the specification can be used to generate the implementation code and the validation logic.
The following is an example of an event producer that produces UserSignedUp events.
The specification is currently at version 2.0. There’s a vibrant open-source community behind this initiative providing contributions in language SDKs, code generators, and parsers.
Refer this to understand the AsyncAPI specification with a practical example.
CloudEvents specification
In an event-driven system, the events exchanged across components take different shapes. For example, the naming of events and attributes can be different across components.
The lack of a common way of describing events means developers have to write new event handling logic for each event source. Also, there are no common libraries, tooling, and infrastructure for cross-component event delivery. That reduces the portability and interoperability across systems.
CloudEvents is a specification that standardizes how event publishers describe their events. It aims to simplify event declaration and delivery across services, platforms, and beyond.
In a nutshell, CloudEvents adds meta-data attributes to any given event. For example, a unique ID for the event and the type of the event. The following is a collection of required and optional attributes for a typical CloudEvent.
Also, developers can add their own set of attributes with CloudEvents extensions. Like AsyncAPI, the specification provides language-specific SDKs to read and write CloudEvents.
CloudEvents is an initiative organized by the Serverless Working Group of Cloud Native Computing Foundation. It is a new effort, and it’s still under active development, with version 1.0.1 released recently. But many cloud service providers and open-source projects have already adopted the specification. Google Cloud Eventarc, Azure Event Grid, and Knative Eventing are few notable examples.
Serverless Workflow specification
Workflows have become critical components of Serverless applications today. But workflow implementations tend to describe workflows differently.
That leaves developers no consistent way of modeling their serverless orchestrations. No standard workflow format means no shared libraries, tooling, and infrastructure for modeling serverless workflows across different cloud platforms or containers.
That is where the Serverless Workflow specification steps in. Serverless Workflow is a specification for describing workflows in a standard way. It provides a vendor-neutral and platform-independent markup for orchestrating services on multiple runtimes and cloud/container platforms.
At a very high level, the Serverless Workflow specifies how to document a workflow with a set of state transitions and event formats. The workflow can be specified with JSON or YAML. When defining the structure of events, CloudEvents and Serverless Workflow complements each other.
The following is an example workflow written in JSON. It shows a single Operation state with one action that calls the “greeting” function.
{
"id": "greeting",
"version": "1.0",
"name": "Greeting Workflow",
"description": "Greet Someone",
"start": "Greet",
"functions": [
{
"name": "greetingFunction",
"operation": "file://myapis/greetingapis.json#greeting"
}
],
"states":[
{
"name":"Greet",
"type":"operation",
"actions":[
{
"functionRef": {
"refName": "greetingFunction",
"arguments": {
"name": "${ .person.name }"
}
},
"actionDataFilter": {
"results": "${ .greeting }"
}
}
],
"end": true
}
]
}The workflow data input is assumed to be the name of the person to greet:
{
"person": {
"name": "John"
}
}The results of the action is assumed to be the greeting for the provided persons name:
{
"greeting": "Welcome to Serverless Workflow, John!"
}Which is added to the states data and becomes the workflow data output.
Serverless Workflow is a new effort, and it’s still under active development as a CNCF Cloud Native Sandbox level project. Its working group consists of several leaders in the business automation industry and enthusiasts in that field.
Conclusion
Both AsyncAPI and Serverless Workflow initiatives standardize the way of describing and documenting event-driven applications as a whole. They reuse CloudEvents to describe the format of the events exchanged.
Even though these specifications are still at the early stages, they pave a path towards portable and interoperable event-driven applications.
When you architect your next event-driven application, consider complying with these standards to make your application more interoperable and maintainable in the future.
