Cloud Events : Part 1

Cloud Events is one of the emerging specifications which tries to promote the interoperability of cloud-native eventing systems. As you know, Event-Driven Architecture promotes loose coupling between distributed systems. Event producer emits an event with context & facts about an occurrence of significance to be consumed by event consumers. The occurrence could be a creation/updation/deletion of an entity like a customer in an application, or it could be something like commit of code into GitHub. The challenge has been these event data model has semantics specific to each application landscape or platform. It was not an issue until we have reached a scenario where we need to assemble business capabilities spanning multiple cloud-native business platforms and technology platforms over which we don't have much control in terms of its design & evolution. For instance, AWS Services has its event semantics, and similar is the case for cloud-native business platforms like Stripe. It has increased the learning curve for the developers understanding those semantics & also operational overhead in terms of configuring routing & monitoring the events produced by each class of event sources. 

Cloud Events specification intends to address the above challenges by dictating event semantics so that

• Event Consumer could specify event or class of events which they are interested in even before event producers produce such events. For instance, one could specify interest in listening to all events concerning code commit to any source code repository.
• Event Producer could specify event which they will generate even before the existence of any consumer for the same.

Cloud Events specification focuses on a set of attributes or rather metadata that enables the routing of the event to appropriate event consumers who have subscribed to such events. It does not care much of event payload as such but those metadata elements which impact routing. The specification has called out following one viz. "Function build and invocation process," "Language-specific runtime APIs," "Selecting a single identity/access control system," "Inclusion of protocol-level routing information," and "Event persistence processes" as out of the scope of the specification. The primary intention for these exclusion is to avoid anything which could potentially impact interoperability. For instance, the event model cannot have protocol-specific routing attribute as each protocol it's own has semantics for the routing, so there is no need for duplicating the same. At the same time, the event may be intended for handling by  consumer based on web hook, but due to the unavailability of the same, it's pushed to dead letter queue, which could be picked by some other consumer for further processing. In short, event producer could not foresee how the events could be consumed, so having protocol-specific semantics for routing do not encourage interoperability in such scenarios. Similarly specification do not dictate how event objects are constructed basically how the attributes of events objects are populated. 

In this post, I tried to provide the intent of new specification . I will share more details on its core attributes, extensionability, frameworks supporting the same plus others in the next post.