One Event, Two Events, ... Cloudevents!
DISCLAIMER: The following are absolutely personal, not exhaustive, considerations/information/dissemination. There may be errors and inaccuracies. The code?fragments reported are only by way of example.
In the panorama of software systems, whether we are talking about Distributed Systems, Cloud, Domain Driven Development or Streaming, one word is always present: Events. Event Driven Architecture is, in someway a must to know!
The series of books, architectural approaches, posts on successful and unsuccessful architectures built on Events represents a remarkable set of information. It is inevitable that efforts will arise to consolidate knowledge and ideas and in a short time arrive at reference standards: here the Cloudevents Specification is one interesting tool which, as developed, can be considered valid even outside the world of the Cloud. In this post the specification considered is 1.0.2 and the examples shown are related to the http binding
Event Concept
There are different definitions of Event. A definition can be as follow:
...In programming and software design, an event is an action or occurrence recognized by software, often originating asynchronously from the external environment, that may be handled by the software. Computer events can be generated or triggered by the system, by the user, or in other ways...
Another one is simply seeing an Event as a Message (often the term are used as alias... but is the correct path???) to express that something has happened in a system; this information can be listened to by other systems determining, or not, a reaction. The information carried by an event can be reduced since its goal is only to notify the listeners or it can have the transport of more data, enough for the listeners to fully react to what happened. This view leads to the two main event patterns: Event-Notification and Event Carried-State Transfer (elsewhere known respectively as Event-Pointer and Complete-Event)
What are Cloudevents?
The main site of Cloudevents reports that Cloudevents is a specification for describing event data in a common way. Cloudevents is not trying to define a common event format! The short version of the story is that we can see the Cloudevents Specification as the HTTP for Events. Citing version 1.0.2 of the documentation, Cloudevents can be described as an agnostic specification to define the data format of events between systems meaning a set of metadata for the purpose of transporting important information also for events routing.
The Cloudevents specification has its own goals and characteristics:
As part of the initiative, in relation to the last point, an increasing number of SDKs are offered to encourage the adoption of the specification on different programming languages as well as adapters for the main software infrastructures on the market.
Why Cloudevents?
The specification has been constantly evolving since 2019, after the CNCF became aware that Eventing is Everywhere made this element one of the cornerstones of the Cloud Native roadmaps.
The need for specification arises from the fact that in the Eventing sphere the differences deriving from the various solutions lead to realizations where there are islands that do not speak to each other and with which synergy is costly. We can further explain the main problematic situations. Events can be internal to a system or between systems, not only from a software architecture point of view but also between different devices; a heterogeneous set of types of events is created whose validation, transport and management becomes expensive (event dependency problem). The event dependency problem is even more present if we think of the fact that, over time, events can change, some being eliminated and others introduced.
Another problem emerges if we consider the creation of software to work with events: if I have a handler that also performs the role of translator, this handler actually has two dependencies; so if something changes we have a cost to pay.
Normally to avoid these problems what you do is to have a conversion intermediary like a message-broker but this shifts the dependency on middleware which soon becomes expensive and whose performance can suffer as a consequence of the activities of validation, transformation, routing of such heterogeneous data.
We can consider a better solution the one for which the message-broker manages a single format (Cloudevents) and architecturally supports adapters which however are unidirectional: one from source-event to cloudevent and one from Cloudevents to target-event leaving, this time, the intermediary decoupled. If we need to consider a change on the Source or on the Target what we have to change are the converters which are a lower change impact!
On the one hand, with the Cloudevents, if we lower the costs, due to the reduced dependencies, on the other hand we increase the moving parts involved and therefore the complexity of the architecture which can in part be controlled by the other specifications of the Cloud Foundation (OpenTelemetry as example).
The Cloudevents approach
The Cloudevents specification focuses on Business Logic, not integration protocols. This is possible thanks to the introduction of an envelope: wrapping event to make it change without impacting the other parts of and existing event definition. Having a standard envelope allows you to encapsulate and define:
Having a single envelope, it is possible to choose one or more transmission protocols for the same event: switching out protocols later become trivially possible. In this way, result that:
领英推荐
As a result of the above, the use cases of the Cloudevents specification include:
In the future of the Cloudevents, integrations/relative use-cases are foreseen:
In general, it is a highly differentiated working table with many issues that are deepened over time and which attract more and more contributions from different producers and contributors.
Structure of the Cloudevents
An Event is carried via a message that represents the protocol part that the specification does not deal with. Inside a message there is the Event and it is characterized by a context and data.
The context is defined by a series of attributes: mandatory, optional and extensions. These attributes, which appear as key/value pairs, have names that cannot be longer than 20 characters and must be lowercase.
Cloudevents attribute names must consist of lowercase letters ('a' to 'z') or digits ('0' to '9') from the ASCII character set.
The main information of a cloudevent normally answers specific questions:
?Despite this, the set of mandatory elements is limited as shown in the following table
A Type System is defined which defines the only usable types:
An Event must not exceed the size of 64KB. This may seem like a limitation but it must be remembered that the goal is to have maximum independence from who produces and who consumes and the limits to which they may be subjected, so it is necessary to preserve the ability to transport and process events (We will see there are two modes in the spec). This view allows however to have a logical reminder to the Event-Notification/Event-Carried State and it reminds us of obvious abuses as happened in the past with large base64 bodies that limited the scalability of systems. Indeed, the specification present us that:
...Generally, Cloudevents publishers SHOULD keep events compact by avoiding embedding large data items into event payloads and rather use the event payload to link to such data items. From an access control perspective, this approach also allows for a broader distribution of events, because accessing event-related details through resolving links allows for differentiated access control and selective disclosure, rather than having sensitive details embedded in the event directly...
The Cloudevents specification, in addition to the definition of an envelope (context metadata), has two operating modes: Structured and Binary. The first mode is to be considered in those use-cases where it is preferable to have a single datum to be examined (the given language or tool has difficulties with a given protocol); the events therefore have a single body, of type JSON, which encapsulates data and metadata. The second mode allows you to separate the context and therefore the metadata, especially for routing, from the actual data.
...but there's much more: Topologies and Additional Specifications
A certainly interesting aspect is that the Cloudevents specification was developed also considering a broader vision of what can be the ecosystem in which events are created, transported, verified, transformed and consumed. This determines basic topologies whose combination leads to more complex realities. A basic element is the classic situation deriving from an Event Driven Architecture: a producer, a channel and a consumer; what is produced/consumed are Cloudevents carrying different events. This topology can be extended by considering several producers whose activity becomes the object of consumption and consolidation of an Aggregator which allows a final consumer to receive aggregated data or data which have undergone a transformation. The more complex topology envisages multiple intermediaries (Aggregators) to reflect a scenario where companies with different roles and possibilities implement value-added manipulations on the events produced by multiple producers or other intermediaries.
The Cloudevents initiative does not only consider routing but also wants to approach other aspects of the events lifecycle: Discovery, Message Delivery, Message Schema, Schema Registry (given the importance of metadata, their standardization and the impact vi may be on the tooling )
So at the end we have some new specification:
?Discovery API: to have to ability to a producer to declare and for a consumer to find what it produces, which attributes are used, and how to subscribe to the given events.
Subscriptions API: This specification defines mechanisms, including an API definition, for Event Consumers to subscribe to events. The software entity handling these subscriptions and responsible for distributing events is abstractly referred to as a Subscription Manager.
Schema Registry: A Registry Service exposes resources, and their metadata, for the purposes of enabling discovery of those resources for either end-user consumption or automation and tooling
Conclusions
The specification of the Cloudevents is certainly an interesting element that enriches the panorama of Cloud management tools but not only: Cloudevents can be an effective bridge in realizations with different ages.
The possibility of treating events in a more agnostic way is undoubtedly useful and the rich ecosystem of specifications aimed at tooling and infrastructure manufacturers makes everything even more attractive. This is also demonstrated by the presence and support of Cloudevents in security products and in business-rules or workflow managers... And we will see what it will happens on infrastructure or new architectural approach as for Event-Mesh!
The picture is completed by the complementarity with respect to the specification of the Async-API which leads to the possibility of a complete description of an Event Driven Distributed System.
Routing and Events were already important issues at the time of SOAP Web Services that were suffocated by the same specifications that were supposed to guarantee their longevity. A different maturity, different contributors but, above all, a different vision from that of the moment of the first ESBs and much more focused on light and distributed processes, should lead to a happier ending for this specification!