On April 20, the CNCF’s Serverless Working Group announced its first release (v0.1) of a new specification called CloudEvents. This specification is a first-of-its-kind for the CNCF, but before we get into the details of the specification, let me first provide a bit of history…

CNCF’s Serverless Working Group

Back in April 2017, the CNCF’s Technical Oversight Committee (TOC) started up a new working group around Serverless computing. The TOC was looking for some insight into this relatively new technology—in short, they wanted to understand what was going on in that space and what, if anything, should the CNCF do as it relates to Cloud Native.

The working group’s (WG) initial goals were to produce:
  • A summary of Serverless characteristics:
    • How it differs from Functions as a Service
    • Common use-cases for Serverless
    • How it relates to other Cloud Native technologies
    • A high-level design of the Serverless processing model
  • A landscape of the current offerings and tooling (both open source and proprietary).
  • A set of recommendations for the CNCF.
The WG produced two documents in February 2018:
  • A Serverless Whitepaper that covers all of the topics listed in the above list, with one exception (covered in the Serverless Landscape spreadsheet).
  • A Serverless Landscape spreadsheet that tries to list some of the more common/popular Serverless projects, platforms, tooling, and services. It is not meant to promote any particular one, rather just list what’s out there today for people to consider using.
One critical piece of the Serverless Whitepaper is the set of recommended next steps. Recommendations include providing additional educational material, looking for Serverless OSS projects to bring under the CNCF’s umbrella of projects, and a list of potential new areas for “harmonization” across the industry. This last recommendation is where CloudEvents was born.

CloudEvents is conceived

During the process of examining the Serverless landscape, there was a general sense from the WG that one of the pain points was that Serverless platforms looked and felt very similar in their overall designs and features, and yet there was very little being done to help customers avoid vendor lock-in. Even if most of the platforms offered similar features, simple things such as differing Function signatures could be enough to hinder someone from choosing an alternative provider. While there are many possible areas of interoperability that the WG could have looked at, they decided to start with something they considered low-hanging fruit: The shape of an Event being passed between an Event producer and an Event consumer (or the Function).

Before we dive into the Events specification, let’s take a slight tangent and point out that this was actually something new for the CNCF. While there are Working Groups within the CNCF that are developing specifications (such as CSI: Cloud Store Interface and CNI: Cloud Native Interface), those projects were first created outside of the CNCF and then were later brought into the CNCF. The development of the “CloudEvents” specification is the first time the CNCF initiated the development of a new specification. It’ll be interesting to see how well this new process works and what other specifications might emerge from the CNCF in the future.

As mentioned above, CloudEvents is about trying to get some level of interoperability around what Events look like as they pass between systems. While there have been many, many, attempts at standardizing Event formats in the past, CloudEvents is less ambitious in its goals. For the most part, CloudEvents is just focused on defining the minimal set of metadata needed for two purposes: 1) To deliver an Event to its destination, and 2) To understand the common metadata of the Event. It is not trying to define the entire shape of all data that might be within the Event itself.

Let’s look at some of the CloudEvent metadata in more detail to better explain what this means in practice:
  • EventType defines the semantic purpose of the Event. This allows infrastructure an easy mechanism to route the request to the proper component for those types of Events.
  • EventID is a unique identifier for the Event.
  • Source defines the entity that produced the Event.
  • EventTime is when was the Event generated.
  • SchemaURL & ContentType is similar to the HTTP Content-Type header. This allows the infrastructure, or Event consumer, to know the exact shape of the Event data being transferred.
The CloudEvent would also need to include the Event data itself in whatever format the Event producer wishes to use. There really isn’t much to it, but with this small amount of data we should be able to do some of the basic pre-processing of Events (such as routing to the proper receiving component) without needing to understand the contents of the Event data itself.

That’s it?

Why is this useful? Think of it in the same way as HTTP. You can send any data you want between two systems but the interoperability at the HTTP layer (e.g., headers) allow for the infrastructure to transfer the message without having to actually understand the data itself, or reinvent how to do it for each type of message that is sent. CloudEvents is attempting to do something similar—by agreeing on these simple bits of metadata, we’re helping the Events infrastructure to move messages between systems.

However, this isn’t just useful for the hidden infrastructure that is managing things behind the scenes. The hope is that the metadata will also be made available by the hosting providers to the applications (or Functions) acting upon the Events as well. This means the code that was written to process the Events shouldn’t need to be changed too much when it is ported between providers. The code can expect to see the same values in the same metadata fields.

With the announcement of version 0.1 of the CloudEvents specification, we also announce an HTTP Transport Binding specification and a JSON Event Format specification. These define how to serialize a CloudEvent into HTTP both as a raw (binary) Event or when it’s encoded in JSON.

Baby steps and more to come

As exciting as this work is, no one is expecting CloudEvents alone to enable things like the portability of code/Functions between providers. However, this is the first step in, hopefully, several more to come. In particular, the idea of trying to find a common Function signature has come up more than once in our talks, so keep an eye out for future announcements!

If you’re interested in learning more about the CNCF’s Serverless Working Group or CloudEvents, please read the following links. And, of course, we’d love to have you join in the discussions! We’ll also have a few sessions (BoF, WG meeting and normal presentation/session with a potential interop event!! leveraging several Serverless platforms including IBM Cloud Functions) at the upcoming CNCF/Kube-Con event in Copenhagen!

Please stop by and check it out:  

Join The Discussion

Your email address will not be published. Required fields are marked *