CNCF’s Serverless Working GroupBack 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.
- 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.
CloudEvents is conceivedDuring 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.
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 comeAs 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!
- CNCF Serverless Working Group
- CloudEvents github repository
- CloudEvents v0.1 specification
- Cloud Events HTTP Transport Binding specification
- Cloud Events JSON Event Format specification
Please stop by and check it out: