Why?

Events are everywhere. However, event publishers tend to describe events differently.

What?

Enter CloudEvents, a specification for describing event data in a common way. CloudEvents seeks to ease event declaration and delivery across services, platforms and beyond!

CloudEvents is a new effort and it’s still under active development. However, its working group has received a surprising amount of industry interest, ranging from major cloud providers to popular SaaS companies. Our end goal is to offer this specification to the Cloud Native Computing Foundation.

Contribute!

This effort is organized via the CNCF’s Serverless Working Group and everyone is encouraged to join us. If you’re interested in contributing, please collaborate with us in the CloudEvents Github Org, join our weekly call every Thursday at 9AM PT via Zoom, and review our Governance model to familiarize yourself with our process.

v0.3 Announcement!

CloudEvents 0.3 Release

On June 13 the CloudEvents project approved version 0.3 of the specification and accompanying documents. It’s been about 6 months since the last release and there have been a lot of really good changes that have been made since then. However, before we get into the list of changes, let’s first discuss what this release really means. While the version number appears very small, don’t let that fool you. Our roadmap only goes up to v0.5 and if you look at the list of work items for 0.4 and 0.5, most are related to clarifications or working on secondary documents, like additional protocol bindings. The point is that the group considers the ‘core’ part of the spec to be nearing completion - and that’s huge!

While we expect stability as we reach v1.0, we don’t know what will pop up during our testing and verification phase that we’re planning on doing prior to v1.0. But it means that we consider the bigger design decisions to be behind us. We have agreed on the scope and goals of the specification, and we’re just putting the final touches on things. As proof, as of this writing, we don’t have any open PRs targeted for v1.0 and only 9 open issues.

The current plan is to try to resolve these remaining issues within weeks and then determine how long we’ll need for a final review and verification phase. We already have CloudEvents being used by several key Cloud players and open-source projects, so that already gives us a good feeling about its readiness. Net: watch this space!

Let’s discuss some of the bigger changes in the specifications since v0.2:
- An SDK design doc was been provided to help guide SDK authors and to promote consistency (when appropriate) between the various language SDKs.
- We enabled support for batching of CloudEvents. It mainly becomes a transport issue, but we do describe how to do it for HTTP.
- The “contenttype” attribute has been renamed to “datacontenttype”. While this might seem trivial, the potential confusion of this attribute with the Content-Type HTTP header was a sore point for many people.
- In the area of security, we added some guidance around how to manage sensitive data.
- In order to help promote interop, we mandated that CloudEvent components needs to support messages at of least 64k in size.
- A “subject” attribute was added. While “source” indicates where the event came from, “subject” indicates which resource the event is about.
- Added some processing rules around how to serialize the data types, in particular unknown extensions. In the end, they’re just strings if the transport doesn’t support a type system.
- Two new extensions were defined: “dataref” which can be used for a claim-check pattern of retrieval of large data, and “paritionkey” which helps consumers place the incoming event into the correct grouping mechanism for more efficient processing.
- A section for pointing to “proprietary” protocols that define a CloudEvents mapping was added. This allows for transports that are mainly focused on one particular implementation to still be included within the project. The first one to be added was a reference to the RocketMQ CloudEvents mapping.
- Clarified which properties are used for uniqueness checking, to enable de-dupe logic if necessary

Finally, the SDK work is continuing nicely, so if you’re interested in using CloudEvent those might be helpful in your coding efforts. And if you’re interested in learning more about CloudEvents you should go to the github repo and start by reading the Primer. It provides a good overview of the project goals and design decisions. Then, of course, the spec itself is where you’ll get all of the details you’ll need about CloudEvents.

TOC sponsors of the project include Ken Owens and Brian Grant.

The CNCF Sandbox is a home for early stage projects, for further clarification around project maturity levels in CNCF, please visit our outlined Graduation Criteria.